طراحی استقرار FortiWeb در سازمان؛ از معماری تا Policy قابل نگهداری

FortiWeb را نباید فقط یک دستگاه جلوی وب‌سایت دید. WAF زمانی ارزش دارد که معماری عبور ترافیک، TLS، شناخت برنامه، policy tuning و فرایند رسیدگی به false positive از قبل طراحی شده باشد. اگر FortiWeb بدون مرحله‌بندی وارد حالت Block شود، احتمال دارد هم سرویس را دچار اختلال کند و هم تیم فنی را نسبت به WAF بدبین کند.

اول معماری را روشن کنید

FortiWeb می‌تواند در سناریوهای مختلفی مثل reverse proxy، transparent یا در کنار load balancer قرار بگیرد. انتخاب حالت استقرار باید با معماری شبکه، مسیر SSL، نیاز به source IP، لاگ‌برداری و روش rollback هماهنگ باشد. اگر در مسیر F5 یا load balancer دیگری دارید، رابطه بین WAF و لود بالانسر باید دقیق مشخص شود.

از Monitor شروع کنید، نه از Block

برای برنامه‌های تولیدی، شروع با مانیتورینگ و یادگیری رفتار برنامه منطقی‌تر است. در این مرحله باید URLهای حساس، فرم‌ها، APIها، فایل آپلود، authentication و الگوهای ترافیک عادی ثبت شود. بعد از آن می‌توان ruleها را دقیق‌تر کرد و فقط روی بخش‌هایی به Block رفت که اثرشان فهمیده شده است.

چک‌لیست طراحی FortiWeb

• TLS و certificate: محل terminate شدن SSL و مدیریت گواهی‌ها را قبل از اجرا مشخص کنید.
• پروفایل برنامه: همه URLها و APIها مثل هم نیستند؛ policy باید با رفتار واقعی برنامه هماهنگ شود.
• false positive: مسیر ثبت، تحلیل و اصلاح false positive باید قبل از سخت‌گیری فعال باشد.
• لاگ و هشدار: معلوم کنید چه رخدادهایی فقط نگهداری شوند و چه رخدادهایی alert عملیاتی بسازند.
• تغییرات برنامه: هر release جدید می‌تواند رفتار WAF را تغییر دهد؛ WAF باید وارد فرایند change management شود.

چه زمانی WAF به پروژه مشاوره نیاز دارد؟

اگر برنامه حساس، چند دامنه، API عمومی، پرداخت، اطلاعات کاربر یا سابقه false positive دارید، استقرار WAF بهتر است با طراحی و پایش دقیق انجام شود. خرید FortiWeb بدون فرایند tuning و بدون هماهنگی با تیم برنامه‌نویسی معمولا نتیجه‌ای کمتر از انتظار می‌دهد.

مرحله‌بندی پیشنهادی برای استقرار کم‌ریسک

در پروژه FortiWeb بهتر است ابتدا فقط مسیر ترافیک و لاگ‌ها پایدار شوند. بعد از آن، URLهای حساس، فرم‌های ورود، فایل آپلود، APIها و رفتار عادی کاربران بررسی می‌شود. وقتی الگوی normal traffic روشن شد، policyها روی بخش‌های مشخص سخت‌گیرتر می‌شوند. رفتن مستقیم به Block روی کل برنامه معمولا هم false positive می‌سازد و هم اعتماد تیم برنامه‌نویسی را کم می‌کند.

برای هر تغییر WAF باید مالک، دلیل، زمان اجرا و روش برگشت مشخص باشد. اگر یک release جدید برنامه باعث block شدن درخواست سالم شد، تیم باید بداند مشکل در کدام rule، signature، exception یا profile رخ داده است. بدون این نظم، FortiWeb به جای ابزار امنیتی تبدیل به مانع تغییرات می‌شود.

مواردی که قبل از Block باید تست شوند

• ورود، خروج، reset password و مسیرهای احراز هویت
• فرم‌های جست‌وجو، پرداخت، آپلود فایل و پنل مدیریت
• APIهای JSON و headerهایی مثل authorization یا token
• رفتار کاربران واقعی پشت proxy، CDN یا load balancer
• ارسال لاگ به FortiAnalyzer، SIEM یا مسیر نگهداری رخدادها

مطالب مرتبط

• هاب FortiWeb
• کاهش False Positive در FortiWeb
• مشاوره و پیاده‌سازی WAF

منبع رسمی: Fortinet FortiWeb documentation.

تعامل WAF با تیم برنامه

FortiWeb زمانی بهتر جواب می‌دهد که تیم برنامه‌نویسی از قبل بداند تغییر فرم، API، header یا مسیر upload می‌تواند رفتار WAF را تغییر دهد. اگر releaseها بدون هماهنگی انجام شوند، WAF یا بیش از حد permissive می‌ماند یا در زمان حساس درخواست سالم را block می‌کند. بنابراین WAF باید بخشی از چرخه تغییر برنامه باشد، نه تجهیزی جدا در لبه شبکه.

معیار موفقیت بعد از استقرار

بعد از راه‌اندازی FortiWeb، موفقیت فقط با روشن بودن سرویس سنجیده نمی‌شود. باید ببینید false positiveها چقدر سریع تحلیل می‌شوند، ruleها چقدر مستندند، لاگ‌ها برای incident response کافی هستند و تیم برنامه قبل از تغییرات مهم WAF را در جریان می‌گذارد یا نه. اگر این معیارها تعریف نشوند، WAF ممکن است نصب شده باشد اما هنوز به کنترل امنیتی قابل اتکا تبدیل نشده باشد.