در بسیاری از سازمانها، Backup از فایروال تا زمانی که حادثهای رخ ندهد جدی گرفته نمیشود. اما در عمل، از دست رفتن Configuration یک فایروال میتواند به معنای توقف کامل سرویسهای حیاتی باشد. خطای انسانی، خرابی سختافزار، Upgrade ناموفق، Corruption فایل سیستم یا حتی تغییر اشتباه Policy همگی سناریوهایی هستند که بدون Backup ساختارمند، بازیابی آنها زمانبر و پرریسک خواهد بود.
در محیطهای مبتنی بر Cisco ASA و همچنین در معماریهای نسل جدید مانند Cisco Secure Firewall، مدل Backup و Restore تفاوتهایی دارد. در ASA تمرکز بر روی Startup Configuration و Running Configuration است، در حالی که در Secure Firewall موضوع شامل Backup از FMC، Policy Database و Device Configuration نیز میشود. در این مقاله، بهترین روشهای مهندسی برای Backup و Restore قابل اعتماد در هر دو معماری را بررسی میکنیم.
در Cisco ASA درک تفاوت میان Running Configuration و Startup Configuration یکی از پایهایترین اما در عین حال بحرانیترین مفاهیم عملیاتی است. بسیاری از خطاهای جدی در محیطهای Production نه به دلیل ضعف طراحی، بلکه به دلیل سوءبرداشت از همین تفاوت ساده رخ میدهد.
Running Config همان پیکربندی فعال در حافظه RAM است. هر تغییری که در CLI یا از طریق ASDM اعمال میشود، بلافاصله در Running Config ثبت و اجرا میشود. این یعنی اثر تغییر آنی است و روی ترافیک جاری تأثیر میگذارد. اما این Configuration در حافظه موقت قرار دارد و در صورت Reload، خاموش شدن ناگهانی دستگاه یا Crash، از بین میرود.
در مقابل، Startup Config نسخه ذخیرهشده در حافظه Flash است که هنگام Boot شدن دستگاه بارگذاری میشود. این فایل نمایانگر آخرین وضعیت ذخیرهشده رسمی سیستم است. اگر تغییرات Running Config ذخیره نشوند، Startup Config همچنان شامل تنظیمات قبلی خواهد بود.
بحران زمانی رخ میدهد که مهندس تغییر مهمی در Policy یا NAT اعمال کند و تصور کند کار تمام شده است، در حالی که دستور ذخیره اجرا نشده باشد. در صورت یک Reload غیرمنتظره، دستگاه به وضعیت قبل بازمیگردد. در یک پروژه واقعی، پس از اعمال تغییرات گسترده روی ACL و VPN، برق دیتاسنتر قطع شد. چون تغییرات ذخیره نشده بود، ASA با Startup Config قبلی بالا آمد و بخشی از دسترسیهای جدید از بین رفت. بازسازی دستی این تغییرات چندین ساعت زمان برد.
نکته مهمتر این است که Running Config میتواند شامل تغییرات موقت یا تستی باشد که هرگز نباید بهعنوان نسخه پایدار تلقی شوند. در برخی سناریوها، مهندس برای تست یک Rule آن را اضافه میکند و پس از تأیید عملکرد، آن را اصلاح میکند. اگر در این میان Save انجام شود، ممکن است نسخه نهایی با آنچه در ذهن بوده متفاوت باشد. بنابراین مدیریت صحیح Running و Startup فقط به ذخیره کردن خلاصه نمیشود، بلکه بخشی از Change Management است.
در محیطهای High Availability نیز موضوع پیچیدهتر میشود. در حالت Failover، Running Config بین Nodeها Sync میشود، اما باید اطمینان حاصل شود که Startup Config نیز هماهنگ است. اگر یکی از Nodeها Reload شود و Startup Config آن قدیمی باشد، ممکن است اختلاف Configuration ایجاد شود. بنابراین بررسی همزمانی نسخه ذخیرهشده در هر دو Node اهمیت دارد.
از منظر Backup نیز این تفاوت حیاتی است. گرفتن Backup فقط از Running Config بدون ذخیره آن بهعنوان Startup میتواند باعث شود نسخه پشتیبان شامل تغییراتی باشد که هرگز بهصورت رسمی تثبیت نشدهاند. رویکرد حرفهای این است که پس از تأیید نهایی تغییر، Configuration ذخیره شود و سپس از Startup Config Backup گرفته شود تا نسخه پشتیبان دقیقاً همان نسخه پایدار باشد.
در Cisco ASA گرفتن Backup صرفاً اجرای یک دستور copy نیست. اگر فرآیند Backup ساختارمند نباشد، در زمان بحران ممکن است فایل در دسترس نباشد، ناقص باشد یا شامل آخرین تغییرات پایدار نباشد. بنابراین Backup باید بخشی از فرآیند رسمی Change Management و Disaster Recovery باشد، نه یک اقدام موردی.
اولین اصل این است که همیشه پس از نهایی شدن تغییرات، Running Config به Startup Config ذخیره شود و سپس از نسخه Startup Backup گرفته شود. گرفتن Backup از Running Config پیش از Save میتواند باعث شود نسخهای ذخیره شود که در صورت Reload هرگز اجرا نخواهد شد. نسخه پشتیبان باید بازتابدهنده وضعیت رسمی و پایدار سیستم باشد.
اصل دوم، نگهداری Backup خارج از دستگاه است. ذخیره فایل Configuration فقط روی Flash داخلی ASA کافی نیست. خرابی سختافزار، Corruption فایل سیستم یا حتی خطای انسانی میتواند دسترسی به فایل داخلی را از بین ببرد. استفاده از پروتکلهایی مانند SCP یا SFTP نسبت به TFTP ارجحیت دارد، زیرا امنیت انتقال و احراز هویت را فراهم میکند. در محیطهای Enterprise، Backup باید روی سرور امن با دسترسی کنترلشده ذخیره شود.
اصل سوم، Versioning ساختارمند است. فایل Backup نباید صرفاً با نام config.txt ذخیره شود. نام فایل باید شامل تاریخ، ساعت و در صورت امکان شماره Change Request یا توضیح مختصر تغییر باشد. این کار در زمان Rollback بسیار حیاتی است. در یکی از پروژهها، به دلیل نبود Versioning، آخرین Backup سالم مربوط به سه ماه قبل بود و بازگشت به آن باعث از دست رفتن تغییرات مهم بعدی شد. پس از آن، فرآیند Versioning رسمی تعریف گردید.
اصل چهارم، Backup کامل فراتر از فقط Configuration متنی است. در ASA علاوه بر فایل کانفیگ، فایلهای مهم دیگری نیز وجود دارند که باید در Backup لحاظ شوند. Image سیستمعامل، فایلهای مربوط به AnyConnect، Certificateها و کلیدهای VPN همگی برای بازیابی کامل ضروریاند. در یک سناریوی واقعی، Configuration بازیابی شد اما به دلیل نبود Certificate خصوصی، تونلهای VPN بالا نیامدند. این تجربه نشان داد Backup ناقص بهاندازه نبود Backup خطرناک است.
اصل پنجم، خودکارسازی فرآیند Backup است. اتکا به اجرای دستی دستور copy ریسک فراموشی را بالا میبرد. استفاده از اسکریپتهای زمانبندیشده یا سیستمهای مدیریت مرکزی باعث میشود Backup بهصورت منظم و بدون وابستگی به اقدام انسانی انجام شود. در سازمانهای بزرگ، معمولاً Backup شبانه یا هفتگی بهصورت خودکار انجام میشود.
اصل ششم، نگهداری چند نسخه اخیر و تعریف Retention Policy است. نگهداری فقط آخرین Backup کافی نیست. اگر تغییر اشتباهی ذخیره شده باشد، نیاز است به نسخه قبل بازگشت. بنابراین حداقل چند نسخه قبلی باید در دسترس باشد تا در صورت نیاز Rollback دقیق انجام شود.
اصل هفتم، تست دورهای فرآیند Restore است. Backup زمانی ارزشمند است که قابل بازیابی باشد. بسیاری از سازمانها سالها Backup میگیرند اما هرگز Restore را در محیط آزمایشی تست نمیکنند. در یکی از سازمانها، هنگام تست Restore مشخص شد فایل Backup ناقص بوده و بخشی از Configuration در آن وجود ندارد. پس از اصلاح فرآیند، کنترل کیفیت Backup به روال عملیاتی اضافه شد.
در معماری مبتنی بر Cisco Secure Firewall، مفهوم Backup دیگر فقط ذخیره یک فایل متنی Configuration نیست. وقتی مدیریت از طریق Cisco Firepower Management Center انجام میشود، تمام منطق Policy، Objectها، Userها، تنظیمات سیستم، Integrationها و حتی برخی اطلاعات عملیاتی در Database مرکزی FMC ذخیره میشود. بنابراین اگر FMC از دسترس خارج شود و Backup معتبری وجود نداشته باشد، عملاً کل معماری مدیریتی فلج خواهد شد.
در این مدل، باید بین دو لایه Backup تمایز قائل شد. لایه اول Backup از خود FMC است که شامل System Configuration، Policy Database، Objectها، User Accountها، تنظیمات Integration مانند LDAP یا Syslog و تنظیمات مدیریتی است. لایه دوم Backup مربوط به خود دستگاههای FTD است که شامل تنظیمات لوکال، Registration و برخی پارامترهای سیستمی است. اگرچه Policyها از FMC به دستگاه Push میشوند، اما بازیابی کامل بدون FMC تقریباً غیرممکن یا بسیار زمانبر خواهد بود.
بهترین روش این است که Backup کامل FMC بهصورت منظم و زمانبندیشده انجام شود. FMC امکان گرفتن Backup کامل سیستم را فراهم میکند که بهصورت فایل آرشیوی ذخیره میشود. این فایل باید روی Storage جداگانه و امن نگهداری شود، نه فقط روی همان سرور FMC. اگر FMC بهصورت VM اجرا میشود، تکیه صرف بر Snapshot ماشین مجازی کافی نیست. Snapshot میتواند مفید باشد، اما Backup داخلی FMC همچنان باید گرفته شود، زیرا شامل ساختار منطقی Database است.
در یک پروژه Enterprise، خرابی Datastore مربوط به VM باعث شد FMC از دسترس خارج شود. خوشبختانه Backup هفتگی FMC روی یک Storage جداگانه وجود داشت. FMC جدید نصب شد، نسخه نرمافزار مطابق با Backup تنظیم شد و فایل Backup Restore گردید. پس از Restore، دستگاههای FTD مجدداً Register شدند و Policyها بدون نیاز به بازسازی دستی بازیابی شدند. اگر این Backup وجود نداشت، بازسازی صدها Object و Rule هفتهها زمان میبرد.
یکی از نکات حیاتی در Backup FMC، تطابق نسخه نرمافزار است. فایل Backup معمولاً باید روی نسخهای مشابه یا سازگار Restore شود. بنابراین پیش از هر Upgrade، باید Backup کامل گرفته شود و صحت آن بررسی گردد. در برخی سناریوها، Upgrade ناموفق باعث Corruption Database شده است و تنها راه بازگشت، Restore Backup قبلی بوده است.
همچنین باید به Integrationهای خارجی توجه داشت. اگر FMC با سیستمهایی مانند Active Directory، Syslog Server یا SIEM یکپارچه است، تنظیمات این Integrationها بخشی از Backup هستند. اما گاهی Certificateها یا کلیدهای خاص نیز باید جداگانه بررسی شوند. اطمینان از اینکه این اجزا نیز در فرآیند Backup پوشش داده شدهاند اهمیت دارد.
در محیطهایی که چند FMC یا معماری High Availability برای FMC وجود دارد، Backup باید از Node اصلی گرفته شود و وضعیت Sync بررسی گردد. Restore در چنین محیطهایی باید با دقت برنامهریزی شود تا ناسازگاری میان Nodeها ایجاد نشود.
Restore فقط بازگردانی فایل نیست. باید بررسی شود که نسخه نرمافزار مقصد با نسخه Backup سازگار است. در ASA، Restore Configuration روی نسخه متفاوت ممکن است باعث خطا در Parsing برخی دستورات شود.
در Secure Firewall نیز Restore FMC Backup معمولاً نیازمند نسخه مشابه یا سازگار است. بنابراین قبل از Upgrade نسخه، باید Backup کامل گرفته شود و سازگاری آن بررسی گردد.
در سناریوهای HA، پس از Restore روی Node اصلی، باید وضعیت Sync بررسی شود تا Node ثانویه نیز هماهنگ گردد. در یکی از پروژهها، Restore فقط روی Active Node انجام شد و Standby Sync نشد که باعث اختلاف Configuration گردید.
Backup تنها زمانی مفید است که قابل ردیابی باشد. استفاده از Versioning استاندارد باعث میشود بدانیم هر Backup مربوط به چه تغییر یا پروژهای است. اتصال Backup به Change Management یک رویکرد حرفهای است.
برای مثال، قبل از هر تغییر عمده Policy، یک Backup با اشاره به شماره Change Request ذخیره میشود. اگر تغییر باعث اختلال شود، میتوان به نسخه قبل بازگشت.
همچنین نگهداری Backup در چند محل، مانند Storage داخلی و مخزن خارجی امن، ریسک از دست رفتن همزمان را کاهش میدهد.
بسیاری از سازمانها Backup میگیرند اما هرگز فرآیند Restore را تست نمیکنند. در زمان بحران، تازه مشخص میشود فایل Backup ناقص بوده یا نسخه ناسازگار است.
رویکرد حرفهای شامل تست دورهای Restore در محیط آزمایشی است. این کار اطمینان میدهد که فایل Backup سالم است و فرآیند بازیابی مستند و قابل اجراست.
در یک سازمان بزرگ، در اولین تست Restore مشخص شد فایل Backup شامل Certificateها نبود. پس از اصلاح فرآیند، Backup کاملتری تعریف شد.
فایلهای Backup شامل اطلاعات حساس مانند کلیدهای VPN، Certificate و ساختار Policy هستند. بنابراین باید در محل امن و با دسترسی محدود نگهداری شوند. ذخیره Backup روی یک TFTP عمومی بدون کنترل دسترسی یک ریسک امنیتی جدی است.
بهتر است Backup روی سرورهای امن با احراز هویت مناسب ذخیره شود و دسترسی به آن محدود به تیم مشخص باشد.
در Cisco ASA و Cisco Secure Firewall، Backup و Restore بخشی از معماری پایداری است، نه یک اقدام اختیاری. Backup منظم، Versioning ساختارمند، تست دورهای Restore و نگهداری امن فایلها چهار ستون اصلی این فرآیند هستند.
در محیطهای Enterprise، از دست رفتن Configuration میتواند منجر به توقف سرویسهای حیاتی شود. طراحی یک استراتژی Backup حرفهای تضمین میکند که حتی در شرایط بحرانی، بازگشت به وضعیت پایدار سریع و کنترلشده انجام شود.
پیادهسازی یک استراتژی Backup قابل اعتماد نیازمند شناخت دقیق ساختار Configuration، وابستگیهای Policy و سناریوهای Disaster Recovery است. بسیاری از سازمانها Backup دارند، اما استراتژی Recovery ندارند.
وینو سرور با تجربه عملی در طراحی زیرساختهای مبتنی بر Cisco Secure Firewall و Cisco ASA میتواند فرآیند Backup و Restore سازمان شما را بازبینی و استانداردسازی کند تا در زمان بحران، بازیابی سریع و بدون خطا انجام شود. اگر هدف شما پایداری واقعی و کاهش ریسک عملیاتی است، وینو سرور میتواند مرجع تخصصی شما در این مسیر باشد.
وینو سرور، اولین استارتاپ ارائه تجهیزات و سیستم های سخت افزاری، به صورت مستقیم از تولید کننده به مصرف کننده است. همواره تلاش مجموعه بر این اصل استوار بوده است تا مشتریان بتوانند بهترین سیستم را برای پروژه خود انتخاب کرده و با مناسبترین قیمت، آن را تهیه کنند. تیم وینو سرور، همواره سعی میکند تا جامعترین خدمات را به مشتریان ارائه دهد تا خرید را برای شما به کاری لذتبخش و آسان تبدیل کند.
مطلع شدن از پست های جدید
میخواهم اولین نفری باشم که از مقالههایی که در وینو سرور منتشر میشود، آگاه شوم.
