تغییرات FortiWeb 8 و تصمیم ارتقا به 8.0.x | Partian
تغییرات FortiWeb 8 نسبت به نسخه‌های قبلی؛ آیا ارتقا به 8.0.x توصیه می‌شود؟
ارتقای WAF یک تغییر ظاهری در پنل مدیریت نیست؛ ممکن است روی Parsing درخواست، TLS، Authentication، لاگ، HA و عبور ترافیک معتبر اثر بگذارد. برای تصمیم درباره FortiWeb 8، باید قابلیت‌های جدید را کنار تغییرات ناسازگار و شرایط Patch مقصد قرار داد.
این مقاله مهم‌ترین تغییرات شاخه 8.0.x را نسبت به نسل قبلی، با تمرکز بر 7.6، از مستندات رسمی Fortinet بررسی می‌کند و یک چارچوب عملی برای تصمیم ارتقا، Pilot و Rollback ارائه می‌دهد. هدف، توصیه قابل دفاع برای تیم شبکه و امنیت است، نه پیشنهاد ارتقا صرفاً به دلیل جدیدتر بودن نسخه.
این مقاله بر اساس FortiWeb 8.0.8 و تغییرات معرفی‌شده در شاخه 8.0.x نوشته شده است. در نسخه‌های دیگر، مسیرهای GUI، نام گزینه‌ها، پیش‌فرض‌ها یا رفتار قابلیت‌ها ممکن است متفاوت باشد. تاریخ بررسی منابع: ۹ اکتبر ۲۰۲۶.
دامنه تصمیم: نسخه فعلی، مدل، نوع VM و HA محیط مشخص نشده است. توصیه‌ها برای خوانندگان فنی و به‌صورت شرطی‌اند؛ این متن جای تأیید مسیر دقیق ارتقای تجهیز توسط Support یا آزمون محیط واقعی را نمی‌گیرد.
مروری بر این مقاله
- پاسخ کوتاه: آیا به FortiWeb 8 ارتقا بدهیم؟
- مقایسه درست: شاخه 8.0.x با Patch 8.0.8 تفاوت دارد
- تغییرات امنیت برنامه و API؛ چه چیزی واقعاً مهم است؟
- AI Application، gRPC و Bot؛ تفاوت با یک WAF صرفاً HTTP
- TLS، Routing، Authentication و HA؛ تغییرات مؤثر بر سازگاری
- سخت‌سازی سیستم و تغییرات نگهداری در 8.0.7
- ریسک‌های Patch مقصد: Resolved و Known Issues نسخه 8.0.8
- امنیت: برای رفع آسیب‌پذیری حتماً باید به ۸ برویم؟
- پیش‌نیازها و مسیر ارتقای رسمی
- Runbook عملیاتی برای ارتقای کنترل‌شده
- ماتریس تصمیم: چه زمانی ارتقا، Pilot یا تعویق؟
- خطاهای رایج، Best Practice و چک‌لیست نهایی
- جمع‌بندی
- سؤالات متداول
- منابع رسمی
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 آسیب‌پذیر نیست.
ماهیت توصیه: این‌ها معیارهای تصمیم‌گیری فنی هستند، نه اعلام نسخه Recommended از طرف Fortinet. بدون نسخه/Build فعلی، مدل، نوع استقرار، حالت HA و قابلیت‌های فعال، حکم قطعی برای یک محیط مشخص قابل ارائه نیست.
2. مقایسه درست: شاخه 8.0.x با Patch 8.0.8 تفاوت دارد
در این مقاله «نسخه ۸» به شاخه FortiWeb 8.0.x اشاره دارد و نمونه مقصد بررسی‌شده 8.0.8 است. راهنمای Administration Guide، تغییرات تجمعی شاخه را نمایش می‌دهد؛ Release Notes نسخه 8.0.8 صریحاً آن را Patch Release بدون قابلیت یا Enhancement جدید معرفی می‌کند. بنابراین نباید همه قابلیت‌های 8.0.x را «جدید در 8.0.8» نامید.
| نسخه معرفی |
نمونه تغییرات شاخه |
اهمیت برای تصمیم ارتقا |
| 8.0.0 |
FortiAI اولیه، بازآرایی Client-Side Security، CMD Detection، Zombie API، URL Clustering و Manual HA Failover |
تغییر در سطح قابلیت و معماری؛ علاوه بر سود، نیازمند بررسی Compatibility است. |
| 8.0.3 |
MCP Security، PQC و OpenSSL 3.5، تغییرات HA، JWT و API؛ حذف/تغییرات مدیریتی مرتبط |
تست Protocol، TLS، Authentication و HA را جدی‌تر می‌کند. |
| 8.0.5 |
JA4، Client-Side Script Insights، Granular Monitor Mode، FortiAI Health/Lua و قابلیت‌های Site Publish |
ارزش عملیاتی وابسته به نوع ترافیک و نیاز واقعی است. |
| 8.0.7 |
گسترش بازرسی gRPC، سخت‌سازی Storage، Auto Patch، منوی جدید و FortiAI Reports/Starter Tokens |
پیش‌فرض‌ها، نگهداری و برنامه بازیابی باید بازبینی شوند. |
| 8.0.8 |
رفع Bug؛ بدون Feature یا Enhancement جدید در Release Notes |
انتخاب Patch مقصد باید با Resolved و Known Issues صورت گیرد. |
مقایسه اصلی با شاخه 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 یکی ندانید.
تست ضروری: تصمیم Block بر اساس Fingerprint یا رفتار Bot را ابتدا با ترافیک معتبر مرورگر، اپ موبایل، Clientهای API و Automation سازمان بررسی کنید؛ Fingerprint به‌تنهایی هویت قطعی کاربر نیست.
5. TLS، Routing، Authentication و HA؛ تغییرات مؤثر بر سازگاری
| حوزه |
تغییر مستند در شاخه 8.0 |
نکته عملیاتی |
| HTTP/3 |
Lua Scripting با HTTP/3 در 8.0.0 گسترش یافته است. |
خود پشتیبانی Client-side HTTP/3 قبلاً در 7.6.0 وجود داشته؛ «HTTP/3 برای اولین بار در ۸ آمده» صحیح نیست. |
| TLS / PQC |
در 8.0.3: OpenSSL 3.5، گروه‌های ML-KEM/Hybrid و امضاهای ML-DSA؛ کنترل‌های TLS دو سمت. |
PQC برای TLS 1.3 است؛ قابلیت Negotiation، Certificate و سازگاری Client/Backend را جدا آزمایش کنید. |
| Content Routing |
در 8.0.5: Monitor Mode هر Entry با Inherit / Enable / Disable. |
برای Policyهای Web Protection Profile اثر دارد؛ ML، ZTNA و Protected Hostnames سطح Server Policy همچنان از Monitor Mode همان سطح پیروی می‌کنند. |
| Non-standard HTTP |
در 8.0.5: گزینه allow-nonstd-http در Server Policy. |
پیش‌فرض Enable برای حفظ جریان موجود است؛ Disable را بدون آزمون برنامه‌های قدیمی یا ترافیک خاص اعمال نکنید. |
| Site Publish |
در 8.0.0: حذف باقی‌مانده CLI Authentication قدیمی؛ در Patchهای بعدی: قابلیت‌های OAuth/JWT، PKCE و SAML. |
اگر به Local User و HTTP Authentication Framework قدیمی وابسته‌اید، Migration به Site Publish یک پیش‌نیاز واقعی است. |
| HA |
در 8.0.0: Manual Failover؛ در 8.0.3: Disk State در Election و تنظیمات Preempt/Traffic Distribution در AAH. |
تغییر Primary Selection را تست کنید؛ وجود Manual Failover به معنی ارتقای بدون قطعی نیست. |
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 تنظیم‌شده انجام می‌شود و تجهیز ریبوت می‌کند.
System > Maintenance > Firmware > Automatic Patch Upgrades
اگر سازمان Approval Gate یا پنجره تغییر محدود دارد، بعد از ارتقا وضعیت Enable، Delay، روز و Window را صریحاً بررسی کنید. غیرفعال کردن نصب خودکار، Discovery دوره‌ای Image را متوقف نمی‌کند. این قابلیت دلیل حذف فرایند بررسی Release Notes نیست.
Full Log Disk Encryption
رمزنگاری محلی دیسک لاگ با LUKS2، داده At Rest را در برابر دسترسی Offline به دیسک محافظت می‌کند؛ لاگ ارسال‌شده به مقصد بیرونی را رمزنگاری نمی‌کند. باز شدن Volume در Startup با کلید مدیریت‌شده محلی انجام می‌شود.
هشدار تخریبی: فعال یا غیرفعال کردن این قابلیت، تمام دیسک لاگ را فرمت می‌کند، محتوا را دائماً حذف می‌کند و FortiWeb را ریبوت می‌کند. قبل از عملیات، لاگ مورد نیاز را Export و کانفیگ را Backup کنید. هنگام فعال بودن رمزنگاری لاگ، Boot عادی از Alternate Firmware غیرفعال است؛ بنابراین قبل از فعال‌سازی، برنامه Rollback را بازطراحی کنید.
رمزنگاری Configuration و Integrity Monitoring
Configuration Files Encryption برای فایل‌های کاری ذخیره‌شده محلی اضافه شده و پیش‌فرض آن Disable است. اگر Private Encryption Key فعال باشد از کلید Device-specific استفاده می‌شود؛ در غیر این صورت Static Fallback Key با سطح حفاظت کمتر به کار می‌رود. Disable و Enable مجدد Private-key Encryption کلید جدید می‌سازد و ممکن است محتوای رمز‌شده با کلید قبلی غیرقابل دسترس شود.
System > Admin > Settings > Miscellaneous > Configuration Files 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
رفع اشکال‌های مهم
| Bug ID |
رفع اشکال در 8.0.8 |
محیطی که باید توجه کند |
| 1338995 |
Server Policy Limit روی VM به‌جای Scale با vRAM به 20 برمی‌گشت. |
VM با تعداد Policy زیاد؛ هشدار رسمی عدم ارتقا به 8.0.7 برای بیش از 20 Policy را جدی بگیرید. |
| 1340331 |
Cookie Security باعث Internal Lock و Hang شدن Proxy Worker می‌شد. |
محیط دارای Cookie Security؛ صحت عبور درخواست و عدم تکرار رخداد Worker Stuck را تست کنید. |
| 1329255 |
قطع ارتباط Samba در Link Transition می‌توانست Kernel Panic و Reboot ایجاد کند. |
محیط دارای Samba خارجی؛ رفتار هنگام قطعی و اتصال مجدد را بررسی کنید. |
وجود Fix در 8.0.8، آن را برای محیط مرتبط نسبت به Patch معیوب گزینه بررسی می‌کند؛ ولی ثابت نمی‌کند تمام Patchهای 7.6 یا همه محیط‌ها همان Bug را دارند. Scope نسخه‌های آسیب‌پذیر هر Bug را از Support یا Release Notes مرتبط تأیید کنید.
مشکلات شناخته‌شده صفحه جاری 8.0.8
| Bug ID |
اثر |
اقدام پیش از تصمیم |
| 1343994 |
خرابی ca-bundle.pem می‌تواند اتصال FDS را متوقف کند، لایسنس را نامعتبر نشان دهد و Update دیتابیس را مختل کند. |
وضعیت دیسک و FortiGuard را بررسی کنید. Workaround رسمی Factory Reset با Backup/Restore و پنجره حدود 30 دقیقه است؛ این Workaround مخرب را صرفاً برای تشخیص و زیر کنترل Support اجرا کنید. |
| 1350974 |
عدم Sync جدول Bot Public Keys پیش‌فرض می‌تواند Not Sync یا Init روی Secondary ایجاد کند. |
Sync جدول و وضعیت اعضا را بررسی کنید. Workaround رسمی شامل جداسازی Secondary، Backup هر عضو، پاک‌سازی جدول در Copy کانفیگ و بارگذاری یکسان FDS Package برای بازسازی IDهاست؛ بدون Runbook تأییدشده اجرا نشود. |
مرجع زمان‌مند: Known Issues ممکن است بعد از انتشار نسخه به‌روز شود. این مقاله صفحه جاری رسمی را در تاریخ بررسی ملاک قرار داده است؛ نبودن Bug در یک فایل PDF قدیمی یا Snippet جست‌وجو تضمین نبود مشکل نیست.
8. امنیت: برای رفع آسیب‌پذیری حتماً باید به ۸ برویم؟
نه الزاماً. چند Advisory رسمی برای شاخه‌های مختلف نسخه اصلاح‌شده جدا ارائه می‌کنند. مثال‌های زیر نشان می‌دهند تصمیم Patch امنیتی و تصمیم مهاجرت Feature Release دو تصمیم مرتبط اما مستقل هستند.
| Advisory |
نسخه‌های 8.0 درگیر / اصلاح |
شاخه قدیمی‌تر / اصلاح |
نتیجه تصمیم |
| FG-IR-26-087 — API Protection Buffer Overflow |
8.0.0 تا 8.0.2؛ اصلاح از 8.0.3 |
7.6.0 تا 7.6.6؛ اصلاح از 7.6.7. برای 7.4/7.2 در این Advisory مهاجرت به Fixed Release آمده است. |
صرف 8.0 بودن، امنیت را تضمین نمی‌کند؛ Patch دقیق مهم است. |
| FG-IR-26-158 — RADIUS Admin Authentication |
8.0.0 تا 8.0.2؛ اصلاح از 8.0.3 |
7.6.0 تا 7.6.6؛ اصلاح از 7.6.7 |
برای این مشکل، مسیر اصلاح در هر دو شاخه وجود دارد؛ تنظیم غیرپیش‌فرض Wildcard هم اهمیت دارد. |
| FG-IR-25-151 — GUI SQL Injection |
در جدول این Advisory ردیف 8.0 درج نشده است؛ این مقاله از نبود ردیف حکم کلی نمی‌سازد. |
7.6.0 تا 7.6.3؛ اصلاح از 7.6.4؛ اصلاح‌های 7.4/7.2/7.0 نیز در سند آمده است. |
Fortinet بهره‌برداری واقعی را گزارش کرده؛ Patch و بررسی مواجهه/Compromise را به تصمیم Feature موکول نکنید. |
این جدول فهرست کامل 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.2.1 → 7.6.2 → 8.0.8
7.6.2 اندازه Partition را افزایش می‌دهد و برای این مرحله حداقل 1.5 GB فضای آزاد Log Disk لازم است. قبل از اجرا، ظرفیت واقعی و تکمیل مرحله را بررسی کنید.
برای مبدا 7.6.3 یا جدیدتر: مثال بالا را به معنی Downgrade اجباری به 7.6.2 ندانید. صفحه Upgrade Paths، هم توضیح نسخه‌محور «7.6.1 یا پایین‌تر» و هم عبارت عمومی عبور از 7.6.2 را دارد. مسیر دقیق Build مبدا/مقصد و پلتفرم را تأیید کنید؛ این مقاله برای مبدا اعلام‌نشده مسیر قطعی صادر نمی‌کند.
کانفیگ و 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 لازم است. مسیر و گزینه در راهنما چنین آمده‌اند:
System > Maintenance > Firmware > Alternate partition > Upload and Reboot
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 یا تعویق؟
| وضعیت محیط |
تصمیم پیشنهادی |
شرط ادامه |
| 7.6 روی Build اصلاح‌شده، پایدار، بدون نیاز به Feature جدید |
ماندن موقت روی شاخه فعلی می‌تواند قابل دفاع باشد. |
PSIRT و Support/Lifecycle تأیید شود؛ تعویق مهاجرت به معنی تعویق Patch نیست. |
| نیاز واقعی به MCP، Client-Side Protection، JA4 یا gRPC File Inspection |
Pilot و سپس مهاجرت مرحله‌ای به Patch مقصد تأییدشده |
Feature و Mode/Platform سازگار باشد؛ معیار پذیرش و Rollback Pass شوند. |
| VM با بیش از 20 Server Policy و قصد رفتن به 8.0.7 |
8.0.7 را انتخاب نکنید. |
هشدار رسمی را رعایت کنید؛ Fix نسخه 8.0.8 و تعداد Policy بعد از Upgrade را آزمایش کنید. |
| Legacy HTTP Authentication از CLI |
ارتقا قبل از Migration توصیه نمی‌شود. |
وابستگی به Framework حذف‌شده به Site Publish منتقل و رفتار Authentication تست شود. |
| HA حیاتی با Bot Public Keys |
Pilot و بررسی Support قبل از Change |
Known Issue 1350974، Sync و Runbook Recovery پوشش داده شوند. |
| مدل یا Hypervisor خارج از فهرست پشتیبانی |
No-Go تا روشن شدن Compatibility |
تأیید رسمی یا برنامه Migration پلتفرم لازم است. |
| نسخه فعلی دارای آسیب‌پذیری مرتبط / مواجهه مدیریتی بالا |
رفع امنیتی فوری طبق Advisory و Change اضطراری |
Patch مقصد از نظر Feature و Known Issues هم بررسی شود؛ در صورت Compromise، IR جداگانه. |
| فقط علاقه به FortiAI، بدون نیاز امنیتی/عملیاتی جدید |
به‌تنهایی دلیل کافی برای تغییر Major نیست. |
منفعت واقعی، Entitlement، Data Policy و هزینه Migration باید توجیه شوند. |
قاعده Go/No-Go: سود مشخص + سازگاری تأییدشده + تست قابل تکرار + بازیابی قابل اجرا = کاندید Go. نبود یکی از این چهار شرط، مهاجرت را به Pilot یا No-Go تبدیل می‌کند؛ این قاعده توصیه مهندسی مقاله است.
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 و کاربردهای واقعی سازمان متصل شود.
<grammarly-desktop-integration data-grammarly-shadow-root="true" style="visibility: visible !important;"></grammarly-desktop-integration>
