مهاجرت فایروال سازمانی اگر فقط تبدیل config از دستگاه قدیمی به دستگاه جدید باشد، معمولاً ضعفهای قدیمی را با ظاهر تازه منتقل میکند. Ruleهای مبهم، NATهای بدون مالک، سرویسهای موقت، objectهای تکراری و مسیرهای بدون لاگ همگی همراه مهاجرت میآیند. مهاجرت خوب باید همزمان دو هدف داشته باشد: سرویس قطع نشود و Rule Base تمیزتر و قابل دفاعتر شود.
این کار برای FortiGate، Cisco Firepower، Juniper SRX یا هر فایروال سازمانی دیگر یک منطق مشترک دارد. اول باید فهمید فایروال فعلی واقعاً چه کاری انجام میدهد، نه اینکه فقط config export شود. بعد باید تصمیم گرفت چه چیزی منتقل شود، چه چیزی بازطراحی شود، چه چیزی حذف یا غیرفعال شود و چه چیزی باید بعد از cutover زیر نظر بماند.
قبل از مهاجرت، Rule Base را بخوانید
Rule Base قدیمی معمولاً تاریخچهای از چند سال تغییر است. بعضی Ruleها برای پروژهای موقت ساخته شدهاند، بعضی objectها چند بار با نامهای مختلف تکرار شدهاند، بعضی سرویسها مالک مشخصی ندارند و بعضی NATها فقط چون کسی نمیدانسته حذفشان چه اثری دارد باقی ماندهاند. اگر اینها بدون بررسی منتقل شوند، فایروال جدید از روز اول بدهی امنیتی دارد.
- Ruleهای پرمصرف و حیاتی را جدا کنید.
- Ruleهای بدون hit یا بدون مالک را برای بازبینی علامت بزنید.
- NATهای قدیمی را به سرویس واقعی وصل کنید.
- Objectهای تکراری را قبل از انتقال تمیز کنید.
- برای هر سرویس مهم، سناریوی تست بنویسید.
VPN، Routing و NAT را جدا تست کنید
در بسیاری از مهاجرتها، Policyها درست منتقل میشوند اما مشکل از routing، NAT یا VPN شروع میشود. یک tunnel بالا میآید اما ترافیک از آن عبور نمیکند. یک VIP درست دیده میشود اما source NAT برگشتی اشتباه است. یک route static جا میماند و سرویس فقط از یک شعبه قطع میشود. برای همین تست باید فقط «سرویس باز شد یا نه» نباشد؛ باید مسیر رفت و برگشت، NAT، log و route هم دیده شود.
برای سرویسهای عمومی، WAF و load balancer هم باید وارد برنامه شوند. اگر FortiWeb یا F5 جلوی سرویس قرار دارد، تغییر فایروال ممکن است health check، SNAT، SSL profile یا مسیر backend را تحت تأثیر قرار دهد. مهاجرت موفق یعنی همه این وابستگیها قبل از شب cutover روشن باشند.
Cutover بدون Rollback برنامه نیست
برنامه cutover باید زمانبندی، مسئول هر بخش، سناریوی تست، معیار موفقیت و rollback داشته باشد. اگر بعد از مهاجرت، سرویس حیاتی کار نکرد، چه کسی تصمیم rollback میگیرد؟ تا چه زمانی عیبیابی ادامه میدهیم؟ چه چیزی را برمیگردانیم؟ آیا backup و config قبلی آماده است؟ اگر این پاسخها از قبل آماده نباشد، تیم در لحظه فشار تصمیمهای پرریسک میگیرد.
بعد از مهاجرت کار تمام نمیشود
بعد از cutover باید چند روز لاگها، hitها، denyها، VPN، مصرف منابع و خطاهای سرویس بررسی شود. بعضی مشکلات فقط در ساعت کاری یا در پایان روز مالی دیده میشوند. بهتر است یک بازه hypercare کوتاه تعریف شود و Ruleهایی که موقتاً بازتر شدهاند دوباره محدود شوند. اگر این مرحله انجام نشود، مهاجرت با چند استثنای اضطراری نیمهتمام میماند.
این مطلب مکمل پیادهسازی فایروال سازمانی، راهنمای خواندن دیتاشیت فایروال و بازبینی Rule Base در FortiGate است. مهاجرت فایروال اگر درست انجام شود، فقط جابهجایی دستگاه نیست؛ فرصتی است برای کم کردن ریسک واقعی شبکه.
مهاجرت را به چند موج کوچکتر تقسیم کنید
اگر همه سرویسها در یک cutover بزرگ جابهجا شوند، عیبیابی سخت و فشار تصمیم زیاد میشود. بهتر است تا حد امکان مهاجرت به چند موج تقسیم شود: سرویسهای کمریسک، سرویسهای داخلی، VPNها، سرویسهای عمومی، و در نهایت مسیرهای حساس. این تقسیمبندی همیشه ممکن نیست، اما حتی وقتی cutover اصلی یکشبه است، میتوان تست و آمادهسازی را موجی انجام داد.
برای هر موج باید معیار موفقیت جدا نوشته شود. فقط بالا آمدن interface کافی نیست. باید کاربر واقعی یا تست شبیه کاربر، log، route، NAT، VPN و مانیتورینگ بررسی شود. اگر موج کوچکتر با موفقیت انجام شود، اعتماد تیم برای مرحله بعد بیشتر میشود. اگر مشکل پیدا شود، دامنه اثر محدودتر است و rollback سادهتر انجام میشود.
برای اینکه این موضوع در اجرا هم نتیجه بدهد، بهتر است بعد از هر تغییر یک شاخص ساده برای موفقیت داشته باشیم: آیا سرویس سالم مانده، آیا لاگ کافی داریم، آیا مسیر rollback روشن است، و آیا تیم فنی میتواند سه ماه بعد دلیل این تصمیم را بفهمد؟ اگر جواب این سؤالها مثبت نباشد، حتی تغییر درست هم در نگهداری روزمره دردسر میسازد.
همین نگاه ساده جلوی کارهای نمایشی را میگیرد. معیار موفقیت باید در شبکه واقعی قابل مشاهده باشد، نه فقط در متن گزارش.
در کار اجرایی، یک نکته دیگر هم مهم است: هر پیشنهاد باید صاحب، زمان بازبینی و سطح ریسک داشته باشد. اگر پیشنهادی این سه مورد را ندارد، احتمالاً هنوز برای اجرا آماده نیست. این کار متن را از توصیه عمومی جدا میکند و به برنامهای تبدیل میکند که تیم فنی میتواند آن را مرحلهبهمرحله دنبال کند.
