وقتی FortiGate چند سال در مسیر اصلی اینترنت، دیتاسنتر یا شعبه کار کرده باشد، مشکل اصلی معمولا خود دستگاه نیست؛ Rule Base شلوغ، Objectهای تکراری، NATهای قدیمی، دسترسیهای موقت و لاگ ناقص است. بازبینی Policy یعنی قبل از اینکه تغییر بعدی دردسر بسازد، وضعیت واقعی فایروال را قابل فهم و قابل نگهداری کنیم.
بازبینی Policy در FortiGate دقیقا چه چیزی را بررسی میکند؟
در یک بررسی جدی، فقط دنبال Ruleهای «Any Any» نمیگردیم. باید مسیر ترافیک، ترتیب اجرای Policy، Zoneها، Interfaceها، NAT، Security Profile، VPN، Local-in Policy، دسترسی مدیریتی و کیفیت لاگ کنار هم دیده شوند. ممکن است یک Rule ظاهرا محدود باشد، اما به خاطر Object Group اشتباه یا NAT نامشخص، عملا سطح دسترسی زیادی ایجاد کند.
خروجی خوب هم فقط یک گزارش بلند نیست. تیم فنی باید بداند کدام Rule پرریسک است، چرا پرریسک است، قبل از تغییر چه چیزی باید تست شود، بعد از تغییر چه لاگی باید دیده شود و اگر سرویس تحت تاثیر قرار گرفت، مسیر برگشت چیست.
نشانههایی که میگویند Rule Base به بازبینی نیاز دارد
- Ruleهایی که نام یا توضیح ندارند و مالک سرویس مشخص نیست.
- Objectهایی که چند بار با نامهای مختلف ساخته شدهاند.
- Policyهایی که برای تست موقت ایجاد شدهاند اما هنوز فعال ماندهاند.
- NATهایی که معلوم نیست مربوط به کدام سرویس یا کدام تیم هستند.
- Ruleهای قدیمی که Hit ندارند، اما کسی جرات حذف آنها را ندارد.
- Security Profileهایی که برای بعضی مسیرها فعال است و برای مسیرهای مشابه نه.
- VPN یا SD-WAN که با تغییر Policy رفتار غیرقابل پیشبینی پیدا میکند.
ترتیب امن برای مرتبسازی Ruleها
مرتبسازی FortiGate نباید با حذف سریع Ruleها شروع شود. اول باید یک تصویر قابل اعتماد از مسیرهای مهم ساخته شود: سرویسهای حیاتی، کاربران راه دور، شعبهها، سرورها، Published Serviceها، مسیرهای مانیتورینگ و دسترسیهای مدیریتی. بعد میتوان Ruleها را به چند گروه تقسیم کرد: ضروری و فعال، مشکوک و نیازمند بررسی، قابل محدودسازی، قابل غیرفعالسازی آزمایشی و قابل حذف بعد از دوره مشاهده.
برای هر تغییر، بهتر است قبل و بعد از اجرا چند شاهد مشخص داشته باشیم: Session، لاگ Forward Traffic، لاگ UTM، وضعیت VPN، مسیر برگشت و نتیجه تست سرویس. این کار شاید کندتر از پاکسازی سریع به نظر برسد، اما در شبکه عملیاتی جلوی قطعیهای بیدلیل را میگیرد.
اشتباه رایج: مرتبسازی فقط بر اساس ظاهر Ruleها
گاهی Ruleها از نظر نامگذاری و ترتیب مرتب میشوند، اما ریسک واقعی باقی میماند. مثلا Source محدود است ولی Destination یک گروه بزرگ و قدیمی است. یا Service به جای چند پورت مشخص، یک گروه عمومی دارد. یا لاگ فقط برای بخشی از ترافیک فعال است و در زمان حادثه نمیشود فهمید چه اتفاقی افتاده است. بازبینی درست باید به اثر واقعی Rule روی مسیر ترافیک نگاه کند، نه فقط به ظاهر تمیز جدول Policy.
ارتباط Policy Review با هاردنینگ FortiGate
بازبینی Rule Base با امنسازی دسترسی مدیریتی FortiGate فرق دارد، اما از آن جدا نیست. اگر پنل مدیریت از مسیرهای اشتباه در دسترس باشد، اگر حسابهای مدیریتی مشترک باشند، یا اگر لاگ ورود مدیران درست نگهداری نشود، حتی Rule Base مرتب هم تصویر کاملی از ریسک نمیدهد.
از طرف دیگر، اگر هدف شما اجرای کاملتر باشد، صفحه مشاوره و پیادهسازی FortiGate مسیر خدماتی را توضیح میدهد و برای شروع پروژه مناسبتر است. برای شبکهای که الان مشکل عملیاتی دارد، مطلب عیبیابی FortiGate از Policy و NAT تا VPN و لاگ نقطه شروع دقیقتری است.
خروجی قابل استفاده برای تیم فنی
در پایان بازبینی، باید یک فهرست قابل اجرا وجود داشته باشد: Ruleهای پرریسک، Ruleهای بدون مالک، Objectهای تکراری، NATهای مبهم، مسیرهای فاقد لاگ، دسترسیهای مدیریتی حساس، پیشنهاد تغییر مرحلهای و ترتیب اجرا. کنار هر پیشنهاد باید دلیل فنی، ریسک احتمالی، تست قبل و بعد، و روش Rollback نوشته شود.
اگر FortiGate در سازمان شما در مسیر سرویسهای حساس قرار دارد، بهتر است بازبینی را مثل یک پروژه تغییر ببینید، نه مثل یک تمیزکاری ساده. هدف این نیست که تعداد Ruleها فقط کمتر شود؛ هدف این است که هر Rule دلیل، مالک، لاگ و مسیر نگهداری روشن داشته باشد.
