FortiWeb (WAF)

FortiWeb WAF هو جدار حماية تطبيقات الويب من Fortinet الذي يحمي تطبيقات الويب وواجهات API المتاحة للعموم من OWASP Top 10 وشبكات البوتات واستغلالات طبقة التطبيقات. يضيف طبقة اكتشاف ثانية قائمة على تعلّم الآلة فوق طبقة الفحص الكلاسيكية المكوّنة من تواقيع الهجمات وسمعة عناوين IP والتحقق من البروتوكول؛ ويعمل كجهاز مادي وجهاز افتراضي وحاوية وسحابة وSaaS، ويساعد على تلبية بنود جانب العميل في PCI DSS 4.0.

وتُظهر بيانات الاختراقات الحديثة سبب كون هذه الطبقة بندًا استثماريًا منفصلًا. فوفقًا لتقرير Verizon 2025 Data Breach Investigations Report بلغت حصة استغلال الثغرات كناقل وصول أولي في الاختراقات 20% بارتفاع قدره 34% مقارنة بالتقرير السابق؛ أما الأجهزة الطرفية وشبكات VPN فقد استحوذت على 22% من أهداف عمليات الاستغلال — بعد أن كانت هذه النسبة 3% قبل عام (Verizon DBIR، 2025). وعلى الجانب الأوروبي، حلّل تقرير ENISA Threat Landscape 2025 عدد 4,875 حادثة وكشف أن استغلال الثغرات شكّل 21.3% من عمليات الوصول الأولي (ENISA، 2025). وعندما تتجاوز سرعة المهاجم في تسليح ثغرة جديدة سرعةَ فريق التطوير في إنتاج التصحيح بشكل منتظم، تصبح طبقة الفحص أمام التطبيق هي المصدّ الواقعي الوحيد.

ما الهجمات التي يمنعها FortiWeb؟

يوقف FortiWeb الطلبات التي تستهدف منطق التطبيق مباشرة؛ وفي مقدمتها فئات OWASP Top 10، والبرمجة النصية عبر المواقع (XSS)، وحقن SQL، وتزوير الطلبات عبر المواقع (CSRF)، واختطاف الجلسات (ورقة بيانات Fortinet FortiWeb، 2025). ويضم محرك السياسات نفسه التحقق من البروتوكول، والالتزام بمعايير HTTP RFC، والحماية من هجمات القوة الغاشمة، وتوقيع ملفات تعريف الارتباط وتشفيرها، واكتشاف SQLi/XSS القائم على البنية النحوية، وأمان ترويسات HTTP، وتسجيل نقاط التهديد وترجيحها، ومنع تسريب البيانات، والحماية من تشويه صفحات الويب (defacement)، والحماية من الهجمات داخل المتصفح (Man-in-the-Browser).

وهذا لا يحل محل الحماية على طبقة الشبكة؛ بل يكمّلها. فبينما يقيّم جدار الحماية من الجيل التالي FortiGate الجلسة على مستوى الشبكة والتعرّف على التطبيقات، يفحص FortiWeb متن طلب HTTP/HTTPS ومعاملات الاستعلام وملفات تعريف الارتباط والترويسات في سياق نموذج السلوك الخاص بالتطبيق المحمي. فالتحكّم بالتطبيقات في جدار الجيل التالي يقول “هذه الحركة متجهة إلى تطبيق ويب”؛ أما WAF فيستطيع أن يقول “هذا الطلب ليس بالصيغة المتوقعة لهذا الحقل في هذا التطبيق”. وفي المؤسسات التي تنشر صفحات دفع أو نماذج تقديم طلبات أو بوابات عملاء متاحة للعموم، تُنشر الطبقتان معًا.

ماذا يوفّر التصحيح الافتراضي في التطبيقات التي يتعذّر تصحيحها؟

التصحيح الافتراضي هو حظر الطلب الذي يستغل الثغرة على مستوى WAF إلى حين إغلاق الثغرة في الشيفرة. وتشرح بيانات DBIR مجددًا سبب أهمية ذلك: فرغم الجهد الكبير الذي بذلته المؤسسات لإغلاق ثغرات الأجهزة الطرفية، لم تتمكن خلال العام من معالجة سوى نحو 54% منها معالجة كاملة، واستغرق ذلك 32 يومًا كوسيط (Verizon DBIR، 2025). وفي التطبيقات المطوَّرة داخليًا أو التي لم يعد مُصنّعها يدعمها، تطول هذه المدة أكثر في معظم الأحيان.

يتكامل FortiWeb مع أبرز ماسحات الثغرات مثل Acunetix وHP WebInspect وIBM AppScan وQualys وImmuniWeb وWhiteHat؛ وتُحوَّل الثغرات التي يعثر عليها الماسح تلقائيًا إلى قواعد أمنية، فيبقى التطبيق محميًا إلى أن يصحّح فريق التطوير الشيفرة (ورقة بيانات Fortinet FortiWeb، 2025). وعندما يلزم إعادة معالجة التطبيق نفسه، ننفّذ خطة التصحيح ضمن الجدول الزمني نفسه مع فريق تطوير الويب والواجهات الخلفية المخصص لدينا.

ما الذي تغيّره طبقة تعلّم الآلة في جدار حماية تطبيقات الويب؟

الجواب المختصر: تلتقط الانحرافات التي لا توقيع لها وتقلّل عبء النتائج الإيجابية الخاطئة. فطبقة الدفاع الأولى في FortiWeb هي محركات WAF الكلاسيكية. أما الحركة التي تتجاوز هذه الطبقة فتُقارَن بنموذج سلوك التطبيق المحدَّث باستمرار؛ وتقوم آلة متجهات الدعم (Support Vector Machine) التي تستخدم أنماط المتجهات الواردة من FortiGuard Labs بتقسيم الشذوذ إلى فئتين: “انحراف غير ضار” و“هجوم” (ورقة بيانات Fortinet FortiWeb، 2025).

والمقابل العملي لهذا التمييز هو التالي: المستخدم الذي يُدخل بالخطأ حرفًا زائدًا في حقل نموذج، والمهاجم الذي يكتب استعلام قاعدة بيانات في الحقل نفسه، كلاهما “شذوذ” وفق النموذج؛ لكن الثاني وحده هو الذي يُحظر. أما مقاربات التعلّم التلقائي التي تعدّ كل شذوذ تهديدًا فتنتج عددًا كبيرًا من عمليات الحظر الخاطئة. والنتيجة في الميدان معروفة: يخفّف المسؤول القواعد، ويتحول WAF فعليًا إلى أداة مراقبة، وتبقى قدرته على الحظر حبرًا على ورق.

وهنا يلزم تنبيه صريح. فعبارة “دقة تقارب 100%” الواردة في ورقة بيانات Fortinet ليست قياسًا مخبريًا مستقلًا بل تصريحًا نوعيًا من المُصنّع؛ ولا ينبغي التعامل معها كإحصاء. والأسلوب الصحيح هو تشغيل FortiWeb WAF أولًا في وضع التعلّم والمراقبة على حركة الإنتاج الخاصة بك، ثم فحص النموذج المُنتَج والقواعد التي جرى تفعيلها، ثم الانتقال تدريجيًا إلى وضع الحظر. ونحن في Sora Yazılım نطبّق هذا الترتيب في مشاريع التشغيل، وننفّذ الانتقال إلى وضع الحظر بموافقة الفريق المالك للتطبيق.

كيف يكتشف FortiWeb واجهات API ويحميها؟

يعمل اكتشاف واجهات API في FortiWeb تلقائيًا عبر تعلّم الآلة: تُقيَّم حركة التطبيق باستمرار ليُستخرج جرد لنقاط النهاية المنشورة، ويُبنى على هذا الجرد نموذج أمني إيجابي. وعندما ترفع المؤسسة تعريف المخطط الخاص بها — وصيغ المخططات المدعومة هي OpenAPI وXML وJSON العام — تُرفَض الاستدعاءات غير المطابقة للمخطط، ويمكن دمج التحقق من المخطط في خط CI/CD بحيث تتجدد السياسة تلقائيًا مع كل تحديث لواجهة API (ورقة بيانات Fortinet FortiWeb، 2025).

وهاتان القدرتان معًا تجيبان عن أصعب مشكلتين في أمن واجهات API المؤسسية. الأولى هي واجهات API الظلية: نقاط نهاية غير موثّقة ولا تظهر في الجرد لكنها مفتوحة على الإنترنت؛ والاكتشاف القائم على الحركة يجعلها مرئية. والثانية هي عجز السياسة الأمنية عن مجاراة سرعة التطوير؛ إذ إن ربط التحقق من المخطط بخط البناء يجعل السياسة جزءًا من دورة الإصدار. كما يوفّر FortiWeb فحص التوافق مع بروتوكولَي XML وJSON، وتواقيع خدمات الويب، ووظيفة بوابة API؛ وتُحمى خدمات الواجهة الخلفية لتطبيقات الهاتف ضمن مجموعة السياسات نفسها.

وفي معماريات الخدمات المصغّرة القائمة على الحاويات يمثّل تحديد موضع نقطة الحماية قرارًا تصميميًا منفصلًا. ونحدد ما إذا كانت هناك حاجة إلى نقطة فحص واحدة أمام الـ ingress أم إلى سياسة منفصلة لكل مجموعة خدمات، بالنظر إلى خط النشر الحالي لديك ضمن نطاق خدمة DevOps والبنية التحتية.

كيف تُفصل حركة البوتات وتُدار؟

يجمع FortiWeb بين تعلّم الآلة والاكتشاف القائم على العتبات وخداع البوتات (deception) والتحليل السلوكي البيومتري ليميّز المستخدم البشري عن البوت الجيد والبوت الضار؛ ويطبّق عند الحاجة CAPTCHA وReal Browser Enforcement. ومن بين أنواع الهجمات المستهدَفة: حركة البوتات الآلية، وكشط الويب (scraping)، وبوتات الزحف، وحصاد البيانات، وحشو بيانات الاعتماد (credential stuffing) (ورقة بيانات Fortinet FortiWeb، 2025).

والتعرّف على البوتات الجيدة أهم مما يُظن في التجارة الإلكترونية والنشر: فقاعدة تحظر عن طريق الخطأ زواحف محركات البحث قد تسبب خسارة في الظهور تفوق بكثير المكسب الأمني. ويميّز FortiWeb بتقنيات تتبّع متقدمة بين الطلبات البشرية والطلبات الآلية والمهاجمين المتكررين مع مرور الوقت؛ وبفضل لوحة البوتات في FortiView وتصنيف هجمات OWASP Top 10 يستطيع الفريق أن يوثّق أي حركة حُظرت ولماذا. وعلى صعيد حشو بيانات الاعتماد، يقارن اشتراك FortiGuard Credential Stuffing Defense محاولات تسجيل الدخول بقائمة بيانات الاعتماد المسرَّبة لدى FortiGuard، ويمكن تعريف إجراءات متعددة تتدرج من التنبيه إلى الحظر.

ويجب أيضًا رسم حدود النطاق بوضوح. فـ FortiWeb يوفّر منع هجمات الحرمان من الخدمة على طبقة التطبيقات ووظيفة جدار حماية شبكي ذي حالة على الطبقة 4؛ لكن هجمات DDoS الحجمية التي تشبع الخط تتطلب خدمة مشغّل أو خدمة تنقية (scrubbing) في المسار الأعلى. وقد برزت هجمات DDoS في تقرير ENISA لعام 2025 بوصفها أكثر أنواع التهديدات شيوعًا على مستوى الاتحاد الأوروبي، وأثّرت على أكثر من قطاع بنسبة 81.4% (ENISA، 2025)؛ ولهذا يجب التخطيط لحماية طبقة التطبيقات والحماية من الهجمات الحجمية بشكل منفصل.

أي بنود PCI DSS 4.0 يلبّيها FortiWeb؟

ثلاثة بنود مباشرة: 6.4.2 و6.4.3 و11.6.1. يُلزم PCI DSS v4.0 في البند 6.4.2 بوجود حل تقني آلي أمام تطبيقات الويب المتاحة للعموم يكتشف الهجمات القائمة على الويب ويمنعها باستمرار، ويعرّف هذا البند بأنه “ممارسة جيدة” حتى 31 مارس 2025 ثم إلزامي بعد ذلك (PCI SSC، PCI DSS v4.0، 2022). والتاريخ نفسه ينطبق على البند 6.4.3. ويلخّص الجدول التالي ما يقابل هذه البنود في FortiWeb.

يكتشف FortiWeb Client-Side Protection باستمرار أكواد JavaScript الضارة وغير المصرح بها التي تعمل في متصفح المستخدم ويمنعها؛ ويحمي صفحة الدفع من هجمات مثل formjacking وMagecart وكشط بيانات البطاقات عبر الإنترنت (skimming). وتضع Fortinet هذه الوظيفة في موضع متوافق مباشرة مع البندين 6.4.3 و11.6.1 من PCI DSS 4.0 (ورقة بيانات Fortinet FortiWeb، 2025). ويجب أن نضيف أيضًا أن الامتثال لا يكتمل بمنتج واحد: فـ FortiWeb WAF يلبّي الضابط التقني الذي يسأل عنه المدقق؛ أما تحديد النطاق وتوثيق السياسات واختبارات الاختراق فبنود منفصلة.

أي طراز FortiWeb وأي شكل نشر ينبغي اختياره؟

يتحدد الاختيار بمتغيّرين: حجم حركة HTTPS المطلوب فحصها، وتفضيل النشر. تتوسّع عائلة أجهزة FortiWeb WAF من 100 ميجابت/ثانية إلى 70 جيجابت/ثانية، والتأخير في جميع الطرازات أقل من 5 مللي ثانية؛ وفي الطرازات 600F وما فوق تُعالَج عمليات SSL/TLS في العتاد (ورقة بيانات Fortinet FortiWeb، 2025). وفي السيناريوهات التي يُنهى فيها تشفير الحركة يكون هذا التمييز أكثر المعايير التقنية حسمًا في الاختيار.

جميع القيم الواردة في الجدول هي القيم “القصوى” التي قاستها Fortinet في ظروف مخبرية مثالية، وهي تتغير بحسب تهيئة النظام؛ أما السعة الفعلية فتعتمد على ملفات تعريف الأمان المفعَّلة وعلى عبء إنهاء SSL. وفي جميع الطرازات المادية يكون ترخيص التطبيقات غير محدود، ويُدعم التجميع Active/Passive وActive/Active، وتتوفر وحدة النظام الأساسي الموثوق (TPM). ولا بد من التشديد على نقطة: لا تنشر Fortinet لـ FortiWeb مقاييس مفصّلة كتلك الموجودة في أوراق بيانات FortiGate (مثل إنتاجية IPS أو إنتاجية فحص SSL)؛ إذ يحتوي الجدول على سطر إنتاجية إجمالية واحد. ولهذا تجري المقارنة بين الطرازات على أساس قيمة واحدة، ويستند تخطيط السعة إلى سقف متوقَّع لا مقيس. والأسلوب الصحيح عمليًا هو التالي: استخرج من سجلات موازن التحميل أو خادم الويب الحالي عدد الطلبات في الثانية وعدد الاتصالات المتزامنة الفعلي، وقرّر ما إذا كان إنهاء SSL سيجري على FortiWeb أم على الخوادم الخلفية، ثم اختر الطراز بناءً على هذين المدخلين. فمن بين تركيبين في فئة الإنتاجية نفسها، قد يستهلك أحدهما موارد أعلى بوضوح من الآخر لمجرد عبء تبادل مفاتيح TLS واختيار مجموعة الشيفرات؛ وهذا الفارق لا يظهر في جدول ورقة البيانات.

ماذا تقدّم خيارات الأجهزة الافتراضية والحاويات وSaaS؟

تحمل نسخ FortiWeb-VM مجموعة الميزات نفسها الموجودة في الطرازات المادية، وتُرخَّص على خمسة مستويات من 1 vCPU إلى 16 vCPU؛ وقيم إنتاجية HTTP هي على التوالي 25 ميجابت/ثانية و100 ميجابت/ثانية و500 ميجابت/ثانية و3 جيجابت/ثانية و6 جيجابت/ثانية. وتتراوح الذاكرة الموصى بها من 8 جيجابايت إلى 64 جيجابايت، ويتراوح عدد نطاقات الإدارة بين 4 و64 بحسب الذاكرة المخصصة. أما مشرفات الافتراضية المدعومة فهي VMware وMicrosoft Hyper-V وCitrix XenServer وXen مفتوح المصدر وVirtualBox وKVM وDocker؛ وعلى صعيد السحابة العامة يمكن استخدامه كجهاز افتراضي على AWS وAzure وGoogle Cloud وOracle Cloud أو بصيغة WAF كخدمة (ورقة بيانات Fortinet FortiWeb، 2025).

وتعمل نسخ الحاويات (FWB-VMC01–VMC08) مع مدير حاويات Docker؛ ويبدأ أصغر مستوى بإنتاجية HTTP قدرها 25 ميجابت/ثانية. وهنا يوجد تناقض داخل ورقة البيانات نفسها، ومن الأصح ذكره بدل إخفائه: فبالنسبة لأعلى مستوى VMC08 يذكر جدول الأداء 3 جيجابت/ثانية بينما يذكر قسم معلومات الطلب 2 جيجابت/ثانية. وفي التصميمات التي يكون فيها الحد الأعلى حاسمًا نؤكد هذه القيمة كتابيًا عبر Fortinet قبل الطلب. وفي نسخ الحاويات تُدرَج ذاكرة لا تقل عن 4 جيجابايت ويُوصى بـ 8 جيجابايت، وتخزين يتراوح بين 30 جيجابايت و500 جيجابايت؛ أما دعم التوافر العالي فغير مُدرَج، ولهذا يجب التخطيط لمعمارية التوافر على طبقة التنسيق (orchestration). ولإدارة أكثر من جهاز FortiWeb من نقطة واحدة يُقدَّم ترخيص FortiWeb Central Manager بخيارَي 10 أجهزة أو عدد غير محدود من الأجهزة.

كيف يُوضع FortiWeb في الشبكة؟

هناك خمسة خيارات للتموضع: Reverse Proxy وInline Transparent وTrue Transparent Proxy وOffline Sniffing وWCCP (ورقة بيانات Fortinet FortiWeb، 2025). وReverse Proxy هو الوضع الأكثر شيوعًا؛ وبما أن FortiWeb يُنهي الاتصال، تتاح في هذا الوضع وظائف تسليم التطبيقات مثل إعادة كتابة عناوين URL وتوجيه المحتوى وموازنة تحميل الخوادم على الطبقة 7 وتفريغ HTTPS/SSL وضغط HTTP والتخزين المؤقت. أما وضعا Inline Transparent وTrue Transparent Proxy فيوفران الفحص على المسار دون تغيير مخطط عناوين IP؛ ويُفضَّلان في البيئات التي يكون فيها المساس بالمعمارية القائمة مكلفًا.

أما وضع Offline Sniffing فيراقب الحركة فقط من منفذ مرآة (SPAN) ولا يحظر شيئًا. وهو خطوة بداية مفيدة للتقييم قبل التشغيل، ولقياس سطح الهجوم الحالي، ولإنضاج نموذج تعلّم الآلة بحركة الإنتاج. أما وضع WCCP فيتيح توجيه الحركة إلى FortiWeb من جهاز أعلى في المسار (عادةً FortiGate).

كيف يتلاءم FortiWeb مع البنية التحتية القائمة ومع متطلبات الامتثال في تركيا؟

لا يتموضع FortiWeb كصندوق يعمل بمفرده بل كمكوّن من Fortinet Security Fabric. ويتيح التكامل مع FortiGate وFortiSandbox تحليل عمليات رفع الملفات المشبوهة تحليلًا معمّقًا ومشاركة معلومات الموارد الداخلية المخترقة؛ كما تُنقل معلومات عناوين IP الموضوعة في الحجر الصحي بين الأجهزة. ووفقًا لتصريح Fortinet تضم منظومة Security Fabric أكثر من 500 حل من أطراف ثالثة (Fortinet، 2026)، وتعالج FortiGuard Labs وتحلّل أكثر من 100 مليار حدث يوميًا (Fortinet، 2026). وتذكر Fortinet أن محرك مكافحة الفيروسات من FortiGuard الذي يستخدمه FortiWeb في فحص الملفات المرفوعة يحصل على 1.8 مليون تعريف جديد أسبوعيًا (ورقة بيانات Fortinet FortiSASE، 2026).

وعلى صعيد FortiGuard تتوفر لـ FortiWeb خمسة خيارات اشتراك منفصلة: خدمة سمعة عناوين IP، وFortiWeb Security Service (تواقيع طبقة التطبيقات، ونماذج تهديدات تعلّم الآلة، وقوائم الروبوتات الضارة، وأنماط عناوين URL المشبوهة، وتحديثات ماسح ثغرات الويب)، وCredential Stuffing Defense، والـ sandbox السحابي، ومكافحة الفيروسات. وتختلف الاشتراكات المطلوبة بحسب طبيعة التطبيق المحمي؛ ففي تطبيق يستقبل مدفوعات يُخطَّط عادةً للدفاع ضد حشو بيانات الاعتماد ولفحص الملفات المرفوعة معًا. كما ينبغي إدراج ضغط التصيد القادم عبر البريد الإلكتروني في اللوحة نفسها؛ ويؤدي FortiMail دورًا مكمّلًا في هذه الطبقة، بينما يؤدي FortiEDR الدور نفسه على نقاط النهاية. وإذا كان مطلوبًا إدارة وصول الفرق العاملة عن بُعد إلى التطبيقات الداخلية على أساس الهوية، فيُقيَّم ذلك مع FortiSASE.

ما الذي ينبغي الانتباه إليه من حيث KVKK والتشغيل المحلي؟

يعرّف دليل أمن البيانات الشخصية (التدابير التقنية والإدارية، يناير 2018) الصادر عن هيئة KVKK (قانون حماية البيانات الشخصية في تركيا) جدار الحماية والبوابة بأنهما “خط الدفاع الأول” ضد تهديدات الوصول غير المصرح به القادمة من الإنترنت، ويدرج في جدول ملخص التدابير التقنية — إلى جانب أمن الشبكة — أمن التطبيقات وأنظمة اكتشاف الاختراق ومنعه وسجلات الأحداث واختبار الاختراق كبنود منفصلة (KVKK، 2018). وغياب طبقة فحص أمام تطبيق متاح للعموم يعالج بيانات شخصية يعني عمليًا بقاء بند أمن التطبيقات في هذا الجدول فارغًا.

وعلى صعيد التشغيل تبرز ثلاث مسائل. الأولى هي مكان حفظ السجلات: فعندما تُنقل أحداث FortiWeb إلى FortiAnalyzer داخل البلاد تبقى مدة الحفظ وموقع البيانات تحت السيطرة. والثانية هي الجدول الزمني للانتقال إلى وضع الحظر؛ ففي تطبيق قيد الإنتاج قد يسبب الحظر الخاطئ خسارة أعمال أسرع من الهجوم نفسه. والثالثة هي ربط سياسة WAF بدورة إصدار التطبيق — فعند نشر نقطة نهاية جديدة يجب تحديث السياسة كذلك. وبصفتنا شريك قناة معتمدًا لدى Fortinet نتولّى الترخيص والتركيب والترحيل من WAF الحالي والخدمة المُدارة بدعم باللغة التركية؛ ويمكنك الاطلاع على عائلة حلول Fortinet لدينا لبقية مكوّنات Fortinet، وعلى صفحة حلولنا للمحفظة كاملة.

لاختيار طراز FortiWeb WAF الصحيح لا بد أولًا من تحديد عدد التطبيقات المراد حمايتها، وحجم حركة HTTPS المطلوب فحصها، ونطاق PCI DSS، وتفضيل النشر (جهاز مادي أو جهاز افتراضي أو حاوية أو SaaS). وعندما تشاركنا جرد تطبيقاتك الحالي وملف حركتك، نستخرج معًا الطراز المناسب ومجموعة الاشتراكات وخطة التشغيل، ونجهّز العرض المتضمن بنود العتاد والترخيص والخدمة المُدارة. وللحصول على جلسة تقييم وعرض سعر تواصل معنا عبر صفحة الاتصال.