طراحی Security Fabric در FortiGate از جایی شروع میشود که topology شبکه را جدی بگیریم. اگر فقط وارد GUI شویم و چند دستگاه را به Fabric اضافه کنیم، ممکن است تصویر اولیه ساخته شود، اما در اولین incident یا تغییر policy معلوم میشود طراحی واقعی انجام نشده است. در پروژه سازمانی باید از قبل بدانیم FortiGate ریشه کدام است، downstreamها چطور وصل میشوند، لاگ کجا ذخیره میشود، policyها با چه استانداردی نگهداری میشوند و چه کسی مالک تغییرات است.
در مستند رسمی Deploying the Security Fabric، Fortinet نمونهای با root FortiGate و چند downstream FortiGate توضیح میدهد و برای پیادهسازی به FortiAnalyzer با نسخه مناسب اشاره میکند. همین ساختار نشان میدهد Fabric یک مفهوم ترتیبی و وابسته به topology است. اگر root اشتباه انتخاب شود، اگر routeها ناپایدار باشند یا اگر branchها ارتباط مدیریتی قابل اعتماد نداشته باشند، خروجی Fabric هم قابل اعتماد نخواهد بود.
قدم اول: انتخاب root FortiGate
root FortiGate باید جایی باشد که دید مرکزیتری به شبکه دارد و از نظر منابع، نسخه FortiOS، مسیر لاگ و دسترسی مدیریتی برای این نقش مناسب است. در بعضی شبکهها FortiGate دیتاسنتر انتخاب طبیعی است؛ در بعضی محیطها که اینترنت مرکزی ندارند یا شعب ساختار متفاوتی دارند، باید دقیقتر تصمیم گرفت. انتخاب root فقط انتخاب یک دستگاه قویتر نیست؛ انتخاب نقطهای است که قرار است relation بین اجزا از آن خوانده شود.
قبل از نهایی کردن root، باید این موارد بررسی شود: نسخه FortiOS، وضعیت HA، VDOMها، routing، DNS، NTP، دسترسی administrative، وضعیت FortiGuard و پایداری sessionها. اگر همین پایهها مشکل داشته باشند، Fabric بعداً خطاهایی نشان میدهد که ریشهشان خود طراحی است.
قدم دوم: لاگ و FortiAnalyzer
بدون لاگ درست، Security Fabric بیشتر شبیه یک نقشه ناقص است. FortiAnalyzer فقط آرشیو لاگ نیست؛ در طراحی Fabric، منبعی برای دید متمرکز، تحلیل رخداد، گزارش امنیتی و پیگیری تغییرات است. اگر لاگ فقط روی خود FortiGate بماند یا retention کافی نباشد، در incident واقعی نمیتوان مسیر رخداد را درست بازسازی کرد.
در طراحی عملی باید مشخص شود کدام eventها لاگ میشوند، retention چقدر است، زمان دستگاهها sync است یا نه، نام deviceها استاندارد است یا نه، و آیا لاگهای branchها در شرایط اختلال WAN هم قابل اتکا هستند. اینها جزئیات خشک نیستند؛ همین جزئیات تعیین میکنند Fabric در روز حادثه کمک میکند یا فقط چند هشدار پراکنده تولید میکند.
قدم سوم: policy قبل از automation
بعضی تیمها خیلی زود سراغ automation و connectorها میروند، در حالی که policyهای اصلی FortiGate هنوز تمیز نیست. اگر address objectها نامفهوم باشند، ruleهای قدیمی مالک نداشته باشند، logging روی ruleهای حساس خاموش باشد یا policyها بر اساس segment طراحی نشده باشند، Fabric فقط همان آشفتگی را در سطح بزرگتری نمایش میدهد.
قبل از گسترش Fabric بهتر است policyها مرور شوند: ruleهای اینترنت، دسترسی بین VLANها، VPN، سرویسهای مدیریتی، ruleهای temporary، دسترسی vendorها و logging. این کار با مشاوره و پیادهسازی فایروال سازمانی همپوشانی مستقیم دارد، چون Fabric وقتی خوب جواب میدهد که فایروال پایه درست داشته باشد.
قدم چهارم: branch و downstream FortiGateها
در شبکههای چندشعبهای، Security Fabric میتواند کمک کند دید شعب از حالت جزیرهای خارج شود. اما branchها معمولاً محدودیتهای خودشان را دارند: لینک WAN ضعیفتر، NATهای پیچیده، اختلاف نسخه FortiOS، naming متفاوت، یا تغییرات دستی توسط افراد مختلف. اگر قبل از اضافه کردن branchها استاندارد تعریف نشود، Fabric خیلی زود پر از deviceهایی میشود که وضعیتشان روشن نیست.
برای branchها بهتر است یک baseline داشته باشیم: نسخه مجاز FortiOS، قالب نامگذاری، حداقل logging، تنظیم NTP، policyهای ثابت، دسترسی remote، و وضعیت backup. بعد از آن میشود به Fabric به عنوان لایه دید و کنترل مرکزی نگاه کرد.
قدم پنجم: FortiManager و کنترل تغییر
FortiManager در محیطهایی که چند FortiGate دارند، نقش مهمی در مدیریت policy و configuration پیدا میکند. اما ورود FortiManager هم باید با نظم انجام شود. اگر تیم فنی هنوز فرایند تغییر، review، deploy window و rollback ندارد، مدیریت مرکزی ممکن است خطا را سریعتر و گستردهتر منتشر کند.
طراحی خوب یعنی مشخص باشد چه چیزی از FortiManager مدیریت میشود، چه چیزی local باقی میماند، چه کسی approve میکند، و بعد از deploy چه چیزی بررسی میشود. Fabric باید با این جریان هماهنگ باشد، نه جدا از آن.
یک چکلیست کوتاه برای شروع طراحی
- root FortiGate و دلیل انتخاب آن مشخص شده است.
- FortiAnalyzer آماده دریافت و نگهداری لاگهای لازم است.
- نسخه FortiOS و وضعیت FortiGuard دستگاهها بررسی شده است.
- policyهای اصلی قبل از توسعه Fabric تمیز و قابل فهم شدهاند.
- برای branchها naming، logging، NTP و backup استاندارد شده است.
- مسئولیت تغییرات بین FortiGate، FortiManager و تیم عملیات روشن است.
جمعبندی عملی
Security Fabric در FortiGate زمانی درست طراحی میشود که از topology شروع کند و به policy، لاگ و عملیات روزمره برسد. اگر root، FortiAnalyzer، branchها و فرایند تغییر درست چیده شوند، Fabric میتواند دید امنیتی قابل استفاده بسازد. اگر نه، فقط یک نمای گرافیکی از همان بینظمی قبلی خواهد بود.
اگر در حال طراحی یا بازبینی FortiGate هستید، بهتر است قبل از فعالسازی گسترده Fabric، وضعیت فعلی ruleها، لاگها و معماری شبکه بررسی شود. برای شروع میتوانید صفحه مشاوره و عیبیابی FortiGate یا مسیر کلیتر طراحی امنیت شبکه و سختسازی زیرساخت را ببینید.
اگر میخواهید وضعیت FortiGate، لاگها یا آمادگی Security Fabric در شبکه خودتان بررسی شود، از صفحه تماس با من خلاصه توپولوژی، مدل دستگاهها و نیاز اصلی را بفرستید.
برای بررسی اجرایی این موضوع، صفحه مشاوره و پیادهسازی FortiGate و Security Fabric و چکلیست آمادگی Security Fabric را هم ببینید.
