طراحی پالیسی فایروال سازمانی
پالیسیهای ضعیف فایروال دلیل شماره ۱ حوادث امنیتی هستند. این راهنما اصول طراحی که در مقیاس سازمانی کار میکنند را پوشش میدهد.
قوانین طلایی
۱. رد پیشفرض: همه چیز را مسدود کنید، آنچه نیاز است را Whitelist کنید
۲. ترتیب قوانین اهمیت دارد: اولین تطابق برنده میشود — قوانین خاص را قبل از عمومی قرار دهید
۳. هر قانون را نامگذاری کنید: «allow-web-servers-to-db» بهتر از «rule-47» است
۴. همه چیزی که مسدود میکنید را لاگ بگیرید
۵. بازبینی فصلی: قوانین مرده تجمع مییابند؛ آنها را پاک کنید
قالب ساختار قانون
TEXT
نام قانون: [ZONE-SRC]-to-[ZONE-DST]-[SERVICE]
منبع: IP/گروه خاص (نه «any»)
مقصد: IP/گروه خاص (نه «any»)
سرویس: شیء سرویس نامگذاریشده (نه شماره پورت)
عملکرد: Accept | Deny
لاگ: بله (همیشه روی Deny؛ روی Accept برای حساس)معماری مبتنی بر منطقه
TEXT
اینترنت → [Fortigate/فایروال]
|
┌───────────┼───────────┐
▼ ▼ ▼
DMZ CORP SERVER
(وب/ایمیل) (کارمندان) (DB/App)جریانهای ترافیک:
- اینترنت → DMZ: فقط پورتهای ۸۰/۴۴۳ به وب سرورها
- DMZ → CORP: هرگز
- CORP → SERVER: فقط پورتهای مورد نیاز
- CORP → اینترنت: HTTP/HTTPS از طریق Proxy، رد همه موارد دیگر
اشتباهات رایج
- قوانین «any-any» باقیمانده از راهاندازی اولیه
- قوانین همپوشانی که باعث اجازه ناخواسته میشوند
- بدون لاگ = بدون پزشکی قانونی هنگام حوادث
- فیلترینگ Egress گمشده (مهاجمان این را دوست دارند)
چکلیست پاکسازی فصلی
- [ ] حذف قوانین با تعداد Hit صفر > ۹۰ روز
- [ ] تأیید وجود تمام اشیاء آدرس
- [ ] بررسی قوانین Shadow (قوانینی که هرگز تطابق پیدا نمیکنند)
- [ ] بازبینی قوانین دسترسی مدیریتی
- [ ] بهروزرسانی مستندات