1. پاسخ کوتاه: آیا به FortiWeb 8 ارتقا بدهیم؟

اگر به قابلیت‌های شاخه 8.0 نیاز دارید، پلتفرم شما پشتیبانی می‌شود و تست و Rollback آماده است، مهاجرت مرحله‌ای منطقی است؛ اما صرفاً به‌خاطر عدد ۸ یا FortiAI، ارتقای مستقیم Production توصیه نمی‌شود.اگر نسخه فعلی از نظر امنیتی نیاز به Patch دارد، رفع آسیب‌پذیری اولویت دارد؛ این کار ممکن است با Patch مناسب همان شاخه نیز انجام شود و الزاماً به معنی مهاجرت Major نیست.

• ارتقا را برنامه‌ریزی کنیدنیاز مشخص به Client-Side Security، MCP، JA4، بهبود gRPC یا رفع Bug مرتبط دارید و آزمون پذیرش را می‌توانید اجرا کنید.
• ابتدا Pilotسرویس حیاتی، HA، Lua سفارشی، Authentication پیچیده، HSM یا حساسیت بالا به False Positive دارید.
• فعلاً مهاجرت را متوقف کنیدپلتفرم نامشخص یا خارج از فهرست، وابستگی به Authentication قدیمی، بکاپ غیرقابل بازیابی یا نبود مسیر بازگشت دارید.
• تأخیر در مهاجرت، نه تأخیر در امنیتدر صورت ماندن روی 7.6، Patchهای امنیتی، PSIRT و چرخه پشتیبانی را پیگیری کنید؛ «نسخه فعلی کار می‌کند» دلیل کافی برای ماندن روی Build آسیب‌پذیر نیست.

2. مقایسه درست: شاخه8.0.xبا Patch 8.0.8 تفاوت دارد

در این مقاله «نسخه ۸» به شاخهFortiWeb8.0.xاشاره دارد و نمونه مقصد بررسی‌شده8.0.8است. راهنمای Administration Guide، تغییرات تجمعی شاخه را نمایش می‌دهد؛ Release Notes نسخه 8.0.8 صریحاً آن را Patch Release بدون قابلیت یا Enhancement جدید معرفی می‌کند. بنابراین نباید همه قابلیت‌های8.0.xرا «جدید در 8.0.8» نامید.

مقایسه اصلی با شاخه 7.6 است؛ برای 7.4، 7.2 و قدیمی‌تر، فاصله تغییرات و ملاحظات Migration بیشتر می‌شود. این متن منتخب تغییرات اثرگذار را بررسی می‌کند، نه Diff کامل همه CLIها و همه Patchهای7.x. وجود یک قابلیت در فهرست معرفی 8.0 نیز به معنی نبود هر شکل مشابه یا Backport آن در تمام نسخه‌های قدیمی‌تر نیست.

3. تغییرات امنیت برنامه و API؛ چه چیزی واقعاً مهم است؟

Client-Side Security و حفاظت داخل مرورگر

در 8.0.0، Client-Side Security به یک ساختار ماژولار تبدیل می‌شود که کنترل‌های جدید و موجود را کنار هم قرار می‌دهد. Client-Side Protection جدید با Telemetry مبتنی بر JavaScript یا تحلیل Passive HTML، رفتارهای غیرمجاز سمت مرورگر را بررسی می‌کند و حالت Monitor/Block دارد. HTTP Header Security بازطراحی شده و کنترل‌های مرتبط با CSP، SRI و حفاظت Runtime در یک چارچوب روشن‌تر قرار می‌گیرند.

برای وب‌سایت پرداخت، Login یا برنامه متکی به اسکریپت‌های Third-party، این تغییر مهم است؛ چون ریسک فقط درخواست ورودی به سرور نیست و می‌تواند در مرورگر رخ دهد. پیش از Enforcement، رفتار CSP، SRI، گزارش‌گیری و اثر روی اسکریپت‌های معتبر را در برنامه واقعی بسنجید. ارتقا به‌تنهایی تمام این کنترل‌ها را صحیح تنظیم نمی‌کند.

CMD Syntax-Based Detection

FortiWeb 8.0.0 علاوه بر Syntax-Based Detection موجود برای SQL/XSS، تحلیل دستورهای Shell برای Command Injection را معرفی می‌کند. منطق آن بر ساختار Command، Chaining و Obfuscation تمرکز دارد. سند محدودیت مهمی هم دارد: آرگومان‌ها به‌طور کامل تحلیل نمی‌شوند؛ Shell Script با Control Flow پیچیده و زبان‌هایی مانند Python، PHP یا Node.js در دامنه همین موتور نیستند.

Zombie API و بهینه‌سازی ML

در Zombie API Discovery معرفی‌شده در 8.0.0، Endpoint کشف‌شده‌ای که هفت روز متوالی ترافیک ندارد، در API Category برچسب Zombie می‌گیرد؛ بررسی هر ده دقیقه انجام می‌شود و با برگشت ترافیک، برچسب پاک می‌شود. این یک کمک به Inventory و بازبینی چرخه عمر است، نه اثبات آسیب‌پذیر بودن Endpoint یا حذف خودکار آن.

URL Clustering نیز برای URLهای دارای بخش‌های پویا مانند شناسه، ساختارهای مشابه را برای ML تعمیم می‌دهد تا تنوع ظاهری URLها ظرفیت یادگیری را بی‌جهت مصرف نکند. طبق سند، هنگام فعال بودن Machine Learning در Server Policy، این بهینه‌سازی خودکار است.

فایل‌های بزرگ و پوشش محدود بازرسی

در 8.0.0، اگر فایل از Maximum Antivirus Buffer Size عبور کند، FortiWeb به‌جای کنار گذاشتن کامل بازرسی، تا طول قابل Cache تحلیل انجام می‌دهد. این تغییر ریسک Bypass مبتنی بر Padding را کاهش می‌دهد، ولیتحلیل بریده‌شده معادل اسکن کل فایل نیستو همه Ruleهای DLP یا File Security الزاماً از داده ناقص نتیجه معتبر نمی‌گیرند. پوشش همچنین به نوع Upload و Module وابسته است.

4. AI Application، gRPC و Bot؛ تفاوت با یک WAF صرفاً HTTP

MCP Security با FortiAI اشتباه گرفته نشود

MCP Security در 8.0.3 برای برنامه‌هایی که Model Context Protocol را روی Streamable HTTP یا SSE تبادل می‌کنند معرفی شده است. FortiWeb پیام‌های JSON جریانی را Parse و فیلدهایی مانند Tool Parameter، Method، Tool Description و Prompt Content را با کنترل‌های مربوط بررسی می‌کند. این قابلیت برای حفاظت از برنامه AI پشت WAF است؛ FortiAI دستیار مدیریتی خود تجهیز است و نقش دیگری دارد.

در 8.0.7، Validation و Investigation مربوط به MCP گسترش پیدا می‌کند و Dashboard ترافیک/امنیت MCP معرفی می‌شود. اگر لاگ Body و جزئیات Validation را نگه می‌دارید، به حساسیت Prompt، Tool Argument و داده Resource توجه کنید؛ این محتوا ممکن است اطلاعات محرمانه برنامه را در لاگ قابل مشاهده کند.

gRPC File Inspection در 8.0.7

بازرسی فایل‌های حمل‌شده داخل Protobuf، به کنترل‌های File Security/AV، DLP و Web Shell Detection متصل می‌شود. این قابلیت صرفاً شناختن Content-Type نیست: IDL و Rule متناظر باید Message را Decode کنند و فیلدهای File Name و File Content به‌درستی Map شوند. Rule gRPC و Policy بازرسی پایین‌دستی هر دو باید در Inline Web Protection Profile مورد استفاده Server Policy قرار گیرند.

پشتیبانی مستند این قابلیت شامل Native gRPC روی HTTP/2 و gRPC-Web مبتنی بر Protobuf روی HTTP/1.1 است. DLP می‌تواند مطابق Direction روی Request، Response یا هر دو اعمال شود؛ Web Shell Detection در همین قابلیت برای Upload از Client به Server است، نه فایل‌های برگشتی در Response.

JA4 و اعتبارسنجی Bot

8.0.5 قابلیت JA4 را برای شناسایی مشخصات TLS Client معرفی می‌کند؛ استفاده از Fingerprint در Lua و Custom Rule نیز اضافه می‌شود. Reverse Proxy، True Transparent Proxy و WCCP شرایط کانفیگ متفاوت دارند؛ Offline Protection، Transparent Inspection و FTP Policy برای این قابلیت پشتیبانی‌شده اعلام نشده‌اند. پیاده‌سازی FortiWeb اختصاصی است و رشته Fingerprint ممکن است با خروجی ابزارهایی مانند Wireshark متفاوت باشد.

Cryptographic Bot Authentication و تشخیص AI Crawler نیز در تغییرات 8.0.5 آمده‌اند. در 8.0.7 کنترل ظرفیت Runtime رکوردهای Period Block برای IP و Client ID بر پایه منابع پلتفرم تنظیم می‌شود؛ روی VM این ظرفیت به حافظه موجود وابسته است، نه تعداد vCPU لایسنس. این ظرفیت را با Throughput یا حداکثر تعداد Policy یکی ندانید.

5. TLS، Routing، Authentication و HA؛ تغییرات مؤثر بر سازگاری

Authentication قدیمی: تغییر Breaking که نباید نادیده گرفته شود

در 7.6.1، GUI مرتبط با Framework قدیمی برداشته شده بود، اما Backend CLI باقی مانده بود. 8.0.0 با حذف جدول‌هایی مانند user local-user، user user-group، waf http-authen http-authen-rule و http-authen-policy این گذار را کامل می‌کند. این تغییر درباره Framework قدیمی HTTP Authentication است، نه حذف حساب ادمین محلی دستگاه.

قبل از ارتقا، وابستگی کانفیگ و Automation خود را به این جدول‌ها بررسی کنید. مسیر جایگزین مستند، تعریف Remote Server، ساخت Authentication Server Pool، ایجاد Site Publish Rule و اعمال آن در Server Policy است. جابه‌جایی را با آزمون Login، Logout، SSO، Group/Attribute و دسترسی غیرمجاز اعتبارسنجی کنید.

6. سخت‌سازی سیستم و تغییرات نگهداری در 8.0.7

Automatic Patch Upgrades؛ یک پیش‌فرض مهم

در 8.0.7، نصب خودکار Patchهای واجد شرایط اضافه شده و طبق راهنمابه‌صورت پیش‌فرض فعال است. فقط Patch جدیدتر در همان Minor Release انتخاب می‌شود؛ مثلاً8.0.xبه Patch جدیدتر8.0.xنه8.1.x. Registration، Entitlement مناسب و اتصال به FortiGuard لازم است. نصب در Maintenance Window تنظیم‌شده انجام می‌شود و تجهیز ریبوت می‌کند.

اگر سازمان Approval Gate یا پنجره تغییر محدود دارد، بعد از ارتقا وضعیت Enable، Delay، روز و Window را صریحاً بررسی کنید. غیرفعال کردن نصب خودکار، Discovery دوره‌ای Image را متوقف نمی‌کند. این قابلیت دلیل حذف فرایند بررسی Release Notes نیست.

Full Log Disk Encryption

رمزنگاری محلی دیسک لاگ با LUKS2، داده At Rest را در برابر دسترسی Offline به دیسک محافظت می‌کند؛ لاگ ارسال‌شده به مقصد بیرونی را رمزنگاری نمی‌کند. باز شدن Volume در Startup با کلید مدیریت‌شده محلی انجام می‌شود.

رمزنگاری Configuration و Integrity Monitoring

Configuration Files Encryption برای فایل‌های کاری ذخیره‌شده محلی اضافه شده و پیش‌فرض آن Disable است. اگر Private Encryption Key فعال باشد از کلید Device-specific استفاده می‌شود؛ در غیر این صورت Static Fallback Key با سطح حفاظت کمتر به کار می‌رود. Disable و Enable مجدد Private-key Encryption کلید جدید می‌سازد و ممکن است محتوای رمز‌شده با کلید قبلی غیرقابل دسترس شود.

Integrity Monitoring به‌صورت خودکار هر پنج دقیقه SHA-256 فایل‌های تحت نظارت را با Baseline مقایسه می‌کند. تغییر مجاز Baseline را به‌روز می‌کند؛ عدم تطابق Event و Banner ایجاد می‌کند، ولی به‌تنهایی هویت تغییر‌دهنده یا مخرب بودن تغییر را اثبات نمی‌کند.

رابط مدیریتی و FortiAI

در 8.0.7، Client Side Security به دسته سطح اول منو منتقل می‌شود. FortiAI نیز گزارش تصویری و سهمیه Starter Tokens می‌گیرد؛ اما نیاز به کنترل دسترسی و سیاست داده باقی است. برای محیط‌های دارای منع پردازش بیرونی، مسیر FortiAI Proxy/LLM را پیش از استفاده بررسی کنید؛ فعال شدن قابلیت محصول مجوز سازمانی برای ارسال داده ایجاد نمی‌کند.

7. ریسک‌های Patch مقصد: Resolved و Known Issues نسخه 8.0.8

رفع اشکال‌های مهم

وجود Fix در 8.0.8، آن را برای محیط مرتبط نسبت به Patch معیوب گزینه بررسی می‌کند؛ ولی ثابت نمی‌کند تمام Patchهای 7.6 یا همه محیط‌ها همان Bug را دارند. Scope نسخه‌های آسیب‌پذیر هر Bug را از Support یا Release Notes مرتبط تأیید کنید.

مشکلات شناخته‌شده صفحه جاری 8.0.8

8. امنیت: برای رفع آسیب‌پذیری حتماً باید به ۸ برویم؟

نه الزاماً.چند Advisory رسمی برای شاخه‌های مختلف نسخه اصلاح‌شده جدا ارائه می‌کنند. مثال‌های زیر نشان می‌دهند تصمیم Patch امنیتی و تصمیم مهاجرت Feature Release دو تصمیم مرتبط اما مستقل هستند.

این جدول فهرست کامل PSIRT نیست و عددهای «از نسخه X» فقط حداقل اصلاح همان Advisory هستند، نه توصیه نسخه مقصد برای همه تهدیدها. در روز Change، تمام Advisoryهای مربوط به Build مبدا و مقصد، Exposure رابط مدیریتی و وضعیت پشتیبانی را دوباره بررسی کنید. ارتقا آثار احتمالی نفوذ قبلی را لزوماً پاک نمی‌کند؛ در صورت نشانه Compromise، مسیر Incident Response و Support جداگانه لازم است.

9. پیش‌نیازها و مسیر ارتقای رسمی

پلتفرم و منابع

فهرست 8.0.8 شامل مدل‌های E و F مشخص و چند مدل D از نوع USG است. پشتیبانی نام کلی «D-Series» به معنی مجاز بودن همه مدل‌های D نیست؛ مدل‌هایی مانند 100D در فهرست این نسخه وجود ندارند. پشتیبانی خود Firmware نیز با پشتیبانی هر Feature، مانند JA4، FortiAI یا QinQ، یکی نیست.

Hypervisor و Cloud را با نسخه‌های آزموده‌شده جدول رسمی تطبیق دهید. راهنما برای عملکرد VM، حداقل 2 vCPU و حافظه بیشتر از 8 GB را توصیه می‌کند؛ این توصیه Performance است، نه تضمین Sizing مناسب برای ترافیک شما. Capacity را با TLS، AV، ML و قابلیت‌های فعال خود بسنجید.

Hop میانی و فضای دیسک

طبق Supported Upgrade Paths، اگر مبدا7.6.1 یا پایین‌ترباشد، ابتدا به 7.6.2 ارتقا دهید و سپس ادامه دهید. مثال رسمی برای مبدا 7.2.1 چنین است

7.6.2 اندازه Partition را افزایش می‌دهد و برای این مرحله حداقل1.5 GB فضای آزاد Log Diskلازم است. قبل از اجرا، ظرفیت واقعی و تکمیل مرحله را بررسی کنید.

کانفیگ و Backup

• Import مجزای Web Protection Profile بین Firmware Versionهای متفاوت در هر دو جهت پشتیبانی نمی‌شود؛ Export Profile را با Backup/Restore کامل یا Migration کانفیگ یکسان ندانید.
• اگر Private Encryption Key در نسخه قبل از 7.6.3 فعال است، هشدار Restore بکاپ را بررسی کنید؛ سند توصیه می‌کند بعد از ارتقا به 7.6.3 بکاپ جدید تهیه شود.
• تغییر HTTP/2 Initial Window Size از max-setting-initial-window-size به h2-setting-initial-window-size در 7.4.13، 7.6.9 و 8.0.6 به بعد آمده است؛ کانفیگ و Templateها را بررسی کنید. این تغییر اختصاصی شاخه ۸ نیست.
• Certificate/Private Key، HSM، Route/VLAN، محتوا و Exceptionها، Lua و تنظیمات Logging را در Inventory ثبت کنید. بازیابی را در محیط جدا آزمایش کنید؛ وجود فایل بکاپ به‌تنهایی اثبات Recoverability نیست.

10. Runbook عملیاتی برای ارتقای کنترل‌شده

۱. قبل از Change

• Build، مدل، Mode، HA، Policyها و قابلیت‌های فعال را ثبت کنید؛ Config و لاگ مورد نیاز را به‌صورت امن نگه دارید.
• Image مخصوص پلتفرم و Checksum رسمی را تأیید کنید؛ مسیر Hopها و فضای دیسک را بررسی کنید.
• Baseline ترافیک، Latency، CPU/Memory، Backend Health، نرخ Error و رخدادهای False Positive را ثبت کنید.
• Pilot را با Login/SSO، Upload، API، WebSocket/gRPC، HTTP/2/3 و مسیرهای حیاتی برنامه اجرا کنید.
• Console یا دسترسی Out-of-band، Backup متناظر با Firmware قبلی و معیار توقف/بازگشت را آماده کنید.

۲. نصب Firmware و مجوز لازم

برای Workflow مستند نصب Alternate Firmware از GUI، حساب admin یا حساب دارایRead/Write در Maintenanceلازم است. مسیر و گزینه در راهنما چنین آمده‌اند

Image انتخاب و Upload می‌شود و تجهیز Restart می‌کند. این مسیر را فقط وقتی استفاده کنید که وضعیت Partition، روش Upgrade پلتفرم و محدودیت Log Disk Encryption اجازه می‌دهد؛ یک روش Universal برای همه Deploymentها نیست.

۳. در محیط HA

Release Notes می‌گوید با ارتقای Active، Standbyها نیز به‌صورت خودکار ارتقا می‌یابند. بنابراین Upgrade را عملیات Cluster-wide در نظر بگیرید؛ Runbook خودسرانه مبتنی بر فرض «فقط یک عضو عوض می‌شود» ننویسید. سلامت Sync، مانیتور Interface و شرایط Failover را قبل و بعد بررسی کنید. از این توضیح، Zero Downtime نتیجه نمی‌شود.

۴. کنترل غیرتخریبی با CLI

فرمان نخست برای ثبت وضعیت سیستم است؛ فرمان دوم فقط برای بررسی وضعیت Manual Failover در Modeهای پشتیبانی‌شده شاخه 8.0 است. فرمان فعال‌سازی Failover، Factory Reset یا فرمت دیسک در این Runbook عمومی ارائه نمی‌شود تا به‌اشتباه اجرا نشوند.

get system status execute ha failover status

۵. بعد از Upgrade

• Build نصب‌شده را از Status تأیید و Cache مرورگر را پاک کنید.
• Active/Standby، Sync، Backend Health، TLS و مسیرهای حیاتی را بررسی کنید؛ فقط باز شدن GUI معیار موفقیت نیست.
• Policy Count روی VM، Cookie Security و Eventهای Worker Stuck را کنترل کنید.
• وضعیت FDS، Update دیتابیس و Entitlement را تست کنید؛ نشانه‌های Known Issues را بررسی کنید.
• Automatic Patch Upgrades و Maintenance Window را مطابق فرایند سازمان تنظیم کنید.
• پس از اعتبارسنجی، Backup جدید مخصوص نسخه مقصد تهیه و در کنار Backup مبدا نگه دارید.

11. ماتریس تصمیم: چه زمانی ارتقا، Pilot یا تعویق؟

12. خطاهای رایج، Best Practice و چک‌لیست نهایی

خطاهایی که تصمیم را خراب می‌کنند

• نامیدن تمام تغییرات8.0.xبه‌عنوان Feature جدید 8.0.8.
• فرض کردن اینکه 7.6 هیچ HTTP/3، API Protection یا ML ندارد.
• انتخاب نسخه بر پایه جدیدترین عدد بدون خواندن Known Issues و هشدار VM.
• اعتماد به Export Profile برای Restore بین Firmwareهای متفاوت.
• فعال کردن Encryption دیسک بدون Export لاگ و برنامه Recovery.
• فرض Zero Downtime به‌خاطر وجود HA یا Manual Failover.
• فعال‌سازی هم‌زمان همه قابلیت‌های جدید در روز Upgrade؛ در این حالت علت False Positive یا افت Performance قابل تفکیک نیست.

Best Practice

ابتدا Firmware و مهاجرت کانفیگ را تثبیت کنید؛ سپس Featureهای جدید را یکی‌یکی، با Scope محدود و معیار پذیرش روشن فعال کنید. برای Client-Side Protection و Ruleهای جدید از حالت مشاهده‌ای مناسب استفاده کنید، اما اثر Monitor Mode را در سطح Server Policy و Content Routing یکسان فرض نکنید. در Rollback، Firmware و Backup متناظر را با هم در نظر بگیرید؛ Downgrade ممکن است تنظیم ناسازگار را حذف کند یا به Default برگرداند.

چک‌لیست Go/No-Go

• نسخه و Build مبدا/مقصد و Image صحیح ثبت شده‌اند.
• مدل/Hypervisor/Mode و Featureهای لازم پشتیبانی می‌شوند.
• مسیر Hopها و فضای آزاد مرحله 7.6.2 تأیید شده‌اند.
• Framework قدیمی Authentication و Templateهای HTTP/2 بازبینی شده‌اند.
• Backup مبدا و Recovery با کلیدهای لازم آزمایش شده است.
• Known Issues مقصد و PSIRT روز Change بررسی شده‌اند.
• Pilot با ترافیک واقعیِ پاک‌سازی‌شده و سناریوهای حمله کنترل‌شده Pass شده است.
• در HA، Sync، Failover و Update عضوهای Cluster در Runbook پوشش داده شده‌اند.
• وضعیت Auto Patch و Window با سیاست سازمان سازگار است.
• لاگ لازم قبل از عملیات Storage نگه داشته شده و اثر Encryption روی Alternate Boot مشخص است.
• معیار توقف، مسئول تصمیم، بازه Validation و مسیر بازگشت تعیین شده‌اند.

13. جمع‌بندی

شاخه FortiWeb 8.0 فقط افزودن FortiAI نیست: کنترل‌های سمت مرورگر، بازرسی پروتکل‌های ساختاریافته و AI Application، Fingerprinting، ML/API Inventory، TLS و سخت‌سازی Storage تغییرات مهمی دارند. در مقابل، حذف Authentication قدیمی، پیش‌فرض Auto Patch، محدودیت‌های Feature/Platform و Known Issues می‌توانند روی عملیات Production اثر مستقیم بگذارند.

توصیه نهایی: برای محیط واجد نیاز و آماده مهاجرت، ارتقای مرحله‌ای به Patch تأییدشده شاخه 8.0 قابل توصیه است؛ برای محیط پایدار روی Patch اصلاح‌شده 7.6 و بدون نیاز مشخص، مهاجرت Major را می‌توان تا تکمیل Pilot به تعویق انداخت، نه Patch امنیتی را.انتخاب قطعی مقصد و مسیر، باید به Build، مدل، HA و کاربردهای واقعی سازمان متصل شود.