فصل حماية HTTP عن حماية الشبكة

المهارة والحد

يبدأ تصميم حماية التطبيق من نوع الطلب والطبقة التي يمكن فحصه فيها. قاعدة مجموعة أمان تضبط التدفق إلى الواجهة أو الخادم بحسب العنوان والمنفذ؛ لا تفهم مسار HTTP أو حمولة الطلب. تحلل AWS WAF طلبات HTTP(S) الواصلة إلى مورد مدعوم عبر قائمة تحكم ويب وقواعدها، فتستطيع معالجة نمط حقن في سلسلة استعلام أو تحديد فعل على طلبات معينة. توفر AWS Shield طبقة حماية من هجمات حجب الخدمة، ولها مستويات وقدرات مختلفة. هذه الأدوات تتكامل لكنها لا تتبادل الوظائف: نجاح WAF في حظر سلسلة ضارة لا يعني أن قاعدة البيانات صارت خاصة، كما أن إغلاق منفذ في مجموعة أمان لا يميز مسار `/checkout` من `/health` على المنفذ نفسه.

نموذج القرار

ارسم مسار العميل إلى CloudFront أو ALB، ثم إلى الخدمة، ثم إلى قاعدة البيانات. لكل وصلة اكتب البروتوكول والمنفذ ونطاق المصدر والهدف. عند حافة HTTP حدد الموارد المدعومة التي ستربط بها web ACL وقاعدة الاختبار التي ستبدأ بوضع Count قبل Block عندما تحتاج قياس الإيجابيات الخاطئة. عند مسار الشبكة اسمح فقط بالمنفذ اللازم من مجموعة أمان الواجهة إلى الخدمة، ثم من الخدمة إلى قاعدة البيانات، ولا تفتح قاعدة البيانات للعميل. سجّل أين تُرى رؤوس الطلب وحمولته وأين لا تُرى. الهجوم الحجمي على الشبكة يتطلب تحليل توافر وقدرات Shield والهندسة العامة، لا مجرد قاعدة نص في WAF.

حالة محلولة

نفذ على الورق تجربة متدرجة: حدد طلبًا ضارًا ممثلًا وطلب دفع شرعيًا يشبهه، واكتب قاعدة WAF دقيقة وعدادين لكل منهما. ابدأ بالمراقبة، قارن عينات الطلبات ونتائج الأعمال، ثم فعّل الحظر فقط عندما تملك دليلًا أن القاعدة لا تمنع الطلب الشرعي. راقب 4xx ووقت الاستجابة ومعدل إتمام الحجز بعد التغيير. إذا اكتشفت أن الحركة ليست HTTP أصلًا بل تدفق UDP يستهلك السعة، انتقل إلى تحليل DDoS وحماية الشبكة بدل محاولة كتابة قاعدة HTTP لا ترى الحزم. وإذا بقيت الخدمة الداخلية متاحة مباشرة من عنوان عام، أصلح الرسم الشبكي أيضًا؛ WAF على ALB وحده لا يغلق طريق تجاوز الواجهة.

الشرط المضاد هنا واضح: لو كانت المشكلة طلبات شرعية كثيفة فوق قدرة التطبيق، فقاعدة تعتمد على سلسلة خبيثة لا تعالج الاختناق؛ تحتاج قياس السعة والتحجيم وربما سياسة معدل محددة وتأثيرها على المستخدمين. ولو كانت قاعدة البيانات تقبل الاتصال من الإنترنت، فإن ضبط web ACL لا يكفي، لأن اتصال قاعدة البيانات لا يمر عبر فحص HTTP. اكتب لهذا السبب مقياسين مختلفين: نسبة الطلبات التي طابقت القاعدة عند الحافة، وعدد الاتصالات المقبولة إلى قاعدة البيانات من مصادر غير الخدمة ويجب أن يظل صفرًا. لا تستنتج نجاح الحماية من انخفاض رسم بياني واحد. في محضر التغيير افصل اختبار مستوى الحافة عن مستوى الأصل. الأول يرسل طلبًا مطابقًا لنمط الحقن وآخر مشروعًا قريبًا منه ويسجل قرار web ACL وتغير معدل الإتمام. الثاني يحاول الاتصال المباشر بالخدمة وبقاعدة البيانات من مصدر غير مصرح، ويجب أن يفشل حتى لو عُطلت قاعدة WAF الاختبارية. راقب إذا كانت رؤوس المصدر المستخدمة في القاعدة تأتي من وكيل موثوق؛ قبول رأس يضعه العميل نفسه قد يجعل قاعدة معدل مبنية عليه قابلة للتحايل. لا تعتبر عينة طلب واحدة تمثيلًا لمختلف اللغات ومسارات الدفع، بل اختبر الحالات الشرعية التي يمكن أن تشبه النمط المحظور.

تمرين وناتج

مراجعة الحل