طراحی Access Control Policy در Cisco Firepower؛ از Ruleهای باز تا Policy قابل دفاع
Cisco Firepower زمانی ارزش واقعی پیدا میکند که Access Control Policy آن با منطق قابل دفاع طراحی شده باشد، نه فقط با چند Rule سریع برای باز شدن ترافیک. در بسیاری از شبکهها مشکل اصلی Firepower خود محصول نیست؛ مشکل این است که Ruleها بدون naming، بدون اولویتبندی، بدون logging درست و بدون مسیر بازبینی دورهای ساخته میشوند.
در این راهنما یک چارچوب عملی برای طراحی Policy در Cisco Firepower، FMC و FTD میبینید؛ چارچوبی که هم برای پیادهسازی اولیه مفید است، هم برای بازبینی شبکهای که قبلاً راهاندازی شده و حالا Ruleهای زیاد، exceptionهای قدیمی یا خطاهای deploy دارد.
Access Control Policy در Firepower چه نقشی دارد؟
Access Control Policy تصمیم میگیرد چه ترافیکی اجازه عبور داشته باشد، چه ترافیکی مسدود شود، کجا inspection انجام شود و چه رخدادهایی لاگ شوند. این Policy معمولاً در FMC مدیریت میشود و روی FTDها deploy میشود. اگر طراحی آن شفاف نباشد، بعد از چند ماه تشخیص اینکه یک ترافیک چرا allow یا block شده سخت میشود.
ساختار پیشنهادی Ruleها
بهتر است Ruleها از بالا به پایین با منطق عملیاتی چیده شوند. یک الگوی قابل دفاع میتواند این باشد:
- Ruleهای حیاتی و محدود برای سرویسهای شناختهشده سازمان
- Ruleهای کاربران و شبکههای داخلی بر اساس Zone و گروه کاربری
- Ruleهای مدیریت، مانیتورینگ، Backup و سرویسهای زیرساختی
- Ruleهای موقت با تاریخ انقضا و توضیح دقیق
- Rule نهایی برای drop یا block کردن ترافیک غیرمجاز همراه با logging کنترلشده
اشتباه رایج: Ruleهای باز و دائمی
Ruleهایی مثل Any to Any یا Source Any به مقصدهای حساس شاید در لحظه مشکل را حل کنند، اما بعداً به نقطه ضعف امنیتی تبدیل میشوند. اگر مجبور به ایجاد Rule موقت هستید، نام Rule، دلیل ایجاد، مالک تغییر، تاریخ بازبینی و شرط حذف آن را در توضیحات ثبت کنید.
Zone و Objectها را قبل از Rule طراحی کنید
قبل از ساخت Rule، Zoneها، Network Objectها، Port Objectها و گروهها باید تمیز باشند. اگر Objectها با نامهای مبهم مثل test، temp یا old باقی بمانند، Policy بعد از مدتی قابل نگهداری نیست. برای شبکههای سازمانی بهتر است نامگذاری از ابتدا استاندارد شود؛ مثلاً Zone مبدا، مقصد، نوع سرویس و هدف Rule در نام یا توضیح مشخص باشد.
Logging را بیهدف فعال نکنید
فعال کردن لاگ برای همه Ruleها همیشه بهترین تصمیم نیست. لاگ زیاد میتواند FMC را شلوغ کند و رخدادهای مهم را پنهان کند. برای Ruleهای حساس، denyها، سرویسهای اینترنتی و تغییرات جدید logging لازم است؛ اما برای ترافیک پرتکرار و کمریسک باید سطح logging با دقت انتخاب شود.
IPS و File Policy را جدا از Allow/Block ببینید
در Firepower فقط allow یا block مهم نیست. ممکن است یک ترافیک مجاز باشد اما همچنان نیاز به IPS، File Policy، Malware Inspection یا URL Filtering داشته باشد. طراحی خوب یعنی برای هر دسته ترافیک مشخص شود آیا فقط عبور کافی است یا inspection هم باید انجام شود.
چکلیست بازبینی Policy
- آیا Ruleهای موقت هنوز لازم هستند؟
- آیا Ruleهای بدون hit در چند ماه اخیر باید حذف یا غیرفعال شوند؟
- آیا Ruleهای allow خیلی گسترده هستند؟
- آیا ترتیب Ruleها باعث bypass شدن inspection نمیشود؟
- آیا logging برای Ruleهای حساس فعال است؟
- آیا قبل از deploy، تغییرات با تیم عملیات یا مالک سرویس هماهنگ شدهاند؟
- آیا بعد از deploy، eventها و health وضعیت طبیعی دارند؟
Deploy در FMC را جدی بگیرید
یکی از خطاهای رایج این است که تغییرات در FMC ساخته میشوند اما deploy با خطا، هشدار یا تأخیر انجام میشود و کسی آن را دنبال نمیکند. بعد از هر تغییر Policy، باید وضعیت deploy، health دستگاه، eventها و اثر واقعی روی ترافیک بررسی شود. اگر deploy fail شد، فقط تکرار deploy کافی نیست؛ باید علت conflict، object مشکلدار، rule ناسازگار یا وضعیت ارتباط FMC و FTD بررسی شود.
چه زمانی بازطراحی لازم است؟
اگر تعداد Ruleها زیاد شده، Ruleهای قدیمی مالک مشخص ندارند، exceptionها زیادند، یا troubleshooting هر مشکل زمان زیادی میگیرد، بهتر است به جای اصلاح موردی، Policy بازطراحی شود. بازطراحی خوب معمولاً مرحلهای انجام میشود تا ریسک قطعی سرویس کم بماند.
نیاز به بازبینی Firepower دارید؟
اگر در FMC یا FTD با Ruleهای زیاد، خطای deploy، لاگهای نامفهوم یا Policyهای باز روبهرو هستید، میتوان وضعیت فعلی را مرحلهای بررسی کرد و مسیر اصلاح کمریسک ساخت.
ارسال درخواست بررسی Cisco Firepower | مطالعه صفحه اصلی Cisco Firepower
تفاوت Vulnerability Assessment، Penetration Test و Red Team Assessment
کنترل امنیت شماره ۱۸: امنیت نرمافزارهای کاربردی
نگهداری، پایش و تحلیل لاگ؛ حافظه قابل اعتماد برای امنیت شبکه