إرفاق WAF بـ CloudFront وALB

ليس WAF جهازًا مستقلًا؛ بل يجب ربطه بمورد يمرر الطلبات إليه. عمليات التكامل المدعومة هي CloudFront وApplication Load Balancer (ALB) وAPI Gateway وAppSync ومجموعات مستخدمي Cognito وApp Runner. ويحدد المكان الذي تربطون فيه WAF موضع إجراء الفحص.

يؤدي ربط WAF بتوزيعة CloudFront إلى فحص الطلبات في مواقع الحافة التابعة لـ AWS قبل انتقالها إلى المصدر الخاص بكم. يحظر ذلك الهجمات بالقرب من المستخدم، ويقلل الحمل على الواجهة الخلفية، ويعمل على مستوى العالم. وهذا مناسب بشكل مثالي لمواقع الويب العامة وتسليم المحتوى، حيث يحقق التصفية عند الحافة أكبر قيمة.

يؤدي ربط WAF بـ Application Load Balancer إلى فحص الطلبات عند وصولها إلى موازن التحميل الإقليمي الخاص بكم. ويناسب ذلك التطبيقات الداخلية وواجهات API الموجودة خلف ALB، أو الحالات التي لا تمر فيها حركة المرور عبر CloudFront. يجب أن تستخدم قائمة التحكم في الوصول إلى الويب نطاق REGIONAL في منطقة ALB.

تذكروا أن قائمة التحكم في الوصول إلى الويب تكون ضمن نطاق CLOUDFRONT (عام، في us-east-1) أو ضمن نطاق REGIONAL. لا يمكنكم ربط قائمة تحكم إقليمية في الوصول إلى الويب بـ CloudFront، أو ربط قائمة تحكم خاصة بـ CloudFront بـ ALB. ويُعد اختيار النطاق الخطأ خطأً شائعًا في النشر يسلط الاختبار الضوء عليه.

للحصول على أقصى قدر من الحماية، يمكنكم وضع CloudFront أمام ALB وربط WAF بكليهما: قائمة تحكم في الوصول إلى الويب خاصة بـ CloudFront للتصفية العامة عند الحافة، وقائمة تحكم إقليمية على ALB كخط دفاع احتياطي. ويحمي ذلك من الطلبات التي تتجاوز CloudFront وتصل إلى ALB مباشرة.

إذا تمكن المهاجمون من الوصول إلى ALB مباشرة، فسيتجاوزون CloudFront وWAF الخاص به. يمكنكم الحد من ذلك بتقييد مجموعة أمان ALB لتسمح فقط بـ نطاقات IP الخاصة بـ CloudFront، أو باستخدام رأس سري مخصص يضيفه CloudFront ويتحقق منه ALB أو WAF، لضمان أن حركة المرور جاءت فعلًا عبر الحافة.

يمكن أيضًا ربط WAF بواجهات REST API في API Gateway وواجهات GraphQL API في AppSync، وكلاهما إقليمي. ويحمي ذلك الواجهات الخلفية التي تعتمد على API من الحقن وإساءة الاستخدام دون الحاجة إلى موازن تحميل منفصل. وبالنسبة إلى واجهات API عديمة الخوادم، تُعد هذه نقطة الإنفاذ الطبيعية.

يمكن ربط WAF بـ مجموعات مستخدمي Cognito للدفاع عن نقاط نهاية المصادقة ضد حشو بيانات الاعتماد وإساءة استخدام التسجيل التي تقودها الروبوتات، مع توافق جيد مع المجموعة المُدارة Account Takeover Prevention. ويحمي ذلك تدفقات الهوية التي تُستهدف كثيرًا. كما يضيف الفحص عند الحافة عبر CloudFront زمن انتقال ضئيلًا، ويحظر الهجمات في وقت أبكر من انتظار وصولها إلى ALB إقليمي.

يمكن ربط المورد بـ قائمة تحكم واحدة فقط في الوصول إلى الويب في كل مرة، ولكن يمكن لقائمة تحكم واحدة في الوصول إلى الويب حماية موارد متعددة. ولتطبيق سياسات مختلفة، تنشئون قوائم تحكم منفصلة في الوصول إلى الويب. ويساعد توحيد القواعد المشتركة في مجموعات قواعد مُدارة أو مخصصة على الحفاظ على اتساق قوائم التحكم المتعددة في الوصول إلى الويب.

اتخذوا القرار بناءً على تدفق حركة المرور: فالمحتوى العام والعالمي يناسبه CloudFront؛ والتطبيقات الإقليمية أو الداخلية يناسبها ALB؛ وواجهات API عديمة الخوادم يناسبها API Gateway أو AppSync. وعند الشك، اربطوا WAF عند الحافة وأضيفوا حماية للمصدر حتى لا يتمكن المهاجمون من الالتفاف حولها.

لا تكون حماية WAF أفضل من موضعها. طابقوا النطاق مع المورد، وفضلوا الربط عند الحافة للتطبيقات العامة، وأضيفوا WAF على ALB كخط دفاع احتياطي، وأحكموا حماية المصدر من خلال CloudFront. وتتكرر خيارات الموضع هذه في سيناريوهات حماية الشبكات ضمن SCS-C02.

طبّقوا معارفكم حول ربط WAF.

يجب ربط WAF بمورد: CloudFront أو ALB أو API Gateway أو AppSync أو Cognito أو App Runner. يفحص CloudFront حركة المرور عالميًا عند الحافة؛ أما ALB وبقية الخدمات فتفحصها إقليميًا وتتطلب قائمة تحكم في الوصول إلى الويب ذات نطاق REGIONAL. ضعوا WAF عند الحافة وعلى ALB، واحموا المصدر باستخدام رأس سري أو نطاقات IP الخاصة بـ CloudFront حتى لا يتمكن المهاجمون من تجاوز التصفية عند الحافة. ويرتبط كل مورد بقائمة تحكم واحدة في الوصول إلى الويب.