برنامه تغییرات در Cisco FMC و FTD؛ قبل از Upgrade و Deploy چه چیزهایی را چک کنیم؟
در Cisco Firepower خیلی از دردسرها از خود policy شروع نمیشود؛ از تغییراتی شروع میشود که بدون برنامه انجام شدهاند. upgrade، deploy گسترده، تغییر certificate، تغییر access policy، یا اضافهکردن device جدید اگر بدون backup و چک سلامت انجام شود، میتواند یک کار ساده را به قطعی طولانی تبدیل کند. در محیطی که FMC چند FTD را مدیریت میکند، تغییر کوچک هم باید با نگاه عملیاتی انجام شود.
این مقاله برای زمانی است که قرار است روی FMC یا FTD تغییر جدی بدهید: upgrade، deploy حساس، تغییر policy اصلی، فعالسازی قابلیتهای سنگین مثل SSL Decryption، یا اصلاح ساختار ruleها. هدف این نیست که جای مستند رسمی Cisco را بگیرد؛ هدف این است که قبل از ورود به مستند، ذهن عملیاتی مرتب شود.
قبل از تغییر، وضعیت فعلی را ثبت کنید
اول باید بدانید الان سیستم در چه وضعیتی است. نسخه FMC و FTDها، مدل دستگاهها، health alertها، وضعیت license، deploy pending، HA status، زمان آخرین backup و آخرین تغییرات مهم باید روشن باشد. اگر قبل از تغییر این تصویر را نداشته باشید، بعد از مشکل نمیدانید ایراد از تغییر جدید است یا از وضعیت قبلی.
در شبکههای واقعی زیاد پیش میآید که قبل از upgrade، چند deploy قدیمی pending مانده، یک device مدتها health warning داشته، یا یکی از سنسورها لاگ کامل نمیفرستاده است. اینها باید قبل از تغییر حل یا حداقل مستند شوند.
Backup فقط وقتی ارزش دارد که قابل برگشت باشد
داشتن فایل backup کافی نیست. باید بدانید backup شامل چه چیزهایی است، کجا نگهداری میشود، آخرین بار چه زمانی گرفته شده، و در سناریوی خرابی چطور restore میشود. برای FMC، backup قبل از upgrade یا تغییر بزرگ ضروری است. اگر محیط مجازی است، snapshot هم میتواند کمک کند، اما نباید جای backup محصول را بگیرد مگر اینکه روش برگشت دقیقاً تست و تأیید شده باشد.
بهتر است قبل از تغییر، خروجیهای مهم هم ثبت شوند: لیست deviceها، versionها، policy assignment، وضعیت deploy، و اگر لازم است screenshot یا export از بخشهای حساس. در زمان بحران، همین اطلاعات ساده جلوی تصمیمهای عجولانه را میگیرد.
Compatibility را حدسی بررسی نکنید
در Firepower، نسخه FMC و FTD باید با هم سازگار باشند. همچنین ممکن است مدل دستگاه، مسیر upgrade، featureهای فعال و نسخههای میانی مهم باشند. قبل از upgrade باید مستند رسمی Cisco برای همان نسخه خوانده شود، نه اینکه فقط از روی تجربه نسخه قبلی تصمیم بگیریم.
اگر چند FTD با مدلها و نسخههای متفاوت دارید، مسیر upgrade را مرحلهای بچینید. همیشه از دستگاه کمریسکتر یا شعبه کمحساستر شروع کنید، نه از حساسترین مسیر دیتاسنتر. اگر HA دارید، وضعیت pair و روش upgrade باید جداگانه بررسی شود.
Deploy را با upgrade قاطی نکنید
یکی از خطاهای عملیاتی این است که upgrade، پاکسازی policy و تغییرات بزرگ access rule همزمان انجام شود. وقتی چند تغییر در یک پنجره انجام میشود، عیبیابی سخت میشود. بهتر است قبل از upgrade، deployهای pending تعیین تکلیف شوند و policy در وضعیت قابل پیشبینی باشد.
بعد از upgrade هم فوراً سراغ تغییرات سنگین نروید. اول health، لاگ، ارتباط FMC با deviceها، وضعیت eventها، و مسیر ترافیکهای مهم را بررسی کنید. وقتی سیستم پایدار بود، تغییر بعدی را انجام دهید.
Rollback باید واقعی باشد
برنامه rollback یعنی اگر تغییر شکست خورد دقیقاً چه میکنیم، چه کسی تصمیم میگیرد، تا چه زمانی منتظر عیبیابی میمانیم و از کدام نقطه برمیگردیم. جمله «اگر نشد برمیگردانیم» برنامه rollback نیست. در بعضی upgradeها برگشت مستقیم ساده نیست و باید قبل از اجرا این محدودیتها را بدانیم.
برای تغییر policy هم rollback باید مشخص باشد: نسخه قبلی policy، backup/export، ruleهای تغییرکرده، زمان deploy، و معیار موفقیت. اگر بعد از deploy latency بالا رفت یا سرویس خاصی قطع شد، باید بدانید کدام rule یا inspection محتملتر است.
چکلیست کوتاه قبل از تغییر حساس
- نسخه FMC و FTDها ثبت شده است.
- Health alertهای مهم بررسی و مستند شدهاند.
- Backup جدید گرفته شده و محل نگهداری آن مشخص است.
- Deploy pending تعیین تکلیف شده است.
- Compatibility و مسیر upgrade از مستند رسمی Cisco بررسی شده است.
- سناریوی rollback و زمان تصمیمگیری روشن است.
- بعد از تغییر، تست سرویسهای حیاتی و لاگها مشخص است.
این نوع کارها بهتر است کنار برنامه کلی پیادهسازی و بازبینی فایروال سازمانی دیده شود. اگر فقط روی خود upgrade تمرکز کنیم و فرآیند تغییر، backup و تست را نادیده بگیریم، ریسک اصلی همچنان باقی میماند.

SSL Decryption در Cisco Firepower؛ کجا فعال کنیم و کجا نه؟
بازبینی Ruleها در Cisco Firepower؛ چطور Policy شلوغ را قابل دفاع کنیم؟
طراحی Access Control Policy در Cisco Firepower؛ از Ruleهای باز تا Policy قابل دفاع
تنظیم IPS در Cisco Firepower؛ از Alert زیاد تا Policy قابل استفاده
عیبیابی VPN در Cisco Firepower؛ وقتی Tunnel بالا است اما ترافیک عبور نمیکند
عیبیابی Deploy نشدن Policy در Cisco FMC/FTD