AWS عرضت نمطين لحماية Amazon Bedrock AgentCore Runtime عبر WAF

نشرت AWS نموذجين معماريين لحماية وكلاء الذكاء الاصطناعي في Amazon Bedrock عبر AWS WAF، واختبرت مع مصادقة SigV4 و OAuth عبر Amazon Cognito JWT.

لماذا يحتاج AgentCore Runtime إلى حماية WAF

AgentCore Runtime—مكون من Amazon Bedrock لتشغيل وكلاء الذكاء الاصطناعي في الإنتاج—لا يحتوي على تصفية مدمجة على مستوى تطبيق الويب بشكل افتراضي. بدون بنية إضافية، يمكن لهاجم مهاجمة الوكيل بحقن أو DDoS أو تزوير الطلبات بالوصول المباشر إلى الخدمة.

يسمح AWS WAF (جدار حماية تطبيقات الويب) بحظر متجهات الهجوم المعروفة وتحديد معدل الطلبات وتطبيق مجموعات القواعس المدارة قبل وصول الطلب إلى الوكيل. يستخدم كلا النموذجين المقدمين موازن تحميل تطبيق (ALB) يمكن الوصول إليه من الإنترنت مع AWS WAF مرفق وتوجيه حركة المرور عبر نقطة نهاية واجهة VPC إلى AgentCore Runtime.

المعاملات الرئيسية لكلا الحلين:

• ALB معرض للإنترنت، AWS WAF يفتش كل طلب وارد
• يتم توجيه حركة المرور عبر نقطة نهاية واجهة VPC إلى AgentCore Runtime
• تحظر سياسة الموارد الالتفاف المباشر على WAF
• يتم دعم مصادقة SigV4 و OAuth (Amazon Cognito JWT)
• يتم اختبار كلا النموذجين في سيناريوهات من النهاية إلى النهاية

النموذج 1 مقابل النموذج 2: ما الفرق

النموذج 1 يضع AWS Lambda بين ALB ونقطة نهاية VPC في دور وكيل. تتلقى الوظيفة الطلب بعد تصفية WAF، ويمكنها تحويله—إضافة رؤوس، تطبيع المسارات، تعديل الجسم—ثم تمريره إلى AgentCore عبر نقطة نهاية واجهة VPC. يوفر هذا أقصى درجات التحكم في حركة المرور، مفيد بشكل خاص إذا كانت هناك حاجة إلى منطق تحويل الطلب أو التحقق الإضافي قبل الوكيل. التكلفة هي زيادة الكمون وتكاليف استدعاء Lambda.

النموذج 2 يلغي قفزة Lambda تماما: ALB يعالج بشكل مباشر عناوين IP من ENIs (Elastic Network Interfaces) على نقطة نهاية واجهة VPC. هذا مخطط أكثر مباشرة مع زيادة كمون أقل وبدون عبء Lambda. مناسب عندما لا تكون تحويل الطلب مطلوبة وتقليل الزيادة الزمنية مع الحفاظ على حماية WAF هو الأولوية.

"يتم اختبار كلا النموذجين من النهاية إلى النهاية مع مصادقة

SigV4 و OAuth (Amazon Cognito JWT)"، تلاحظ AWS في مدونة Machine Learning.

كيفية إغلاق الباب الخلفي من خلال سياسة الموارد

الجزء الأكثر حساسية في كلا النموذجين هو التكوين الصحيح لسياسة موارد AgentCore Runtime. بدونها، تفقد حماية WAF معناها: يمكن لهاجم اكتشاف نقطة نهاية AgentCore العام واستدعاؤه مباشرة، متجاوزاً ALB و WAF تماما.

الحل هو شرط `aws:SourceVpce` في سياسة الموارد. يسمح بالاستدعاءات إلى AgentCore فقط عبر نقطة نهاية واجهة VPC معينة، مما يضمن مرور حركة المرور عبر ALB و AWS WAF. يتم إغلاق الباب الخلفي المباشر على مستوى سياسة IAM.

يطبق هذا النهج الدفاع بالعمق: WAF هو خط الدفاع الأول، وسياسة الموارد هي الثانية، مما يمنع الالتفاف حول الأول.

ما يعنيه ذلك

توفر إرشادات AWS لمطوري وكلاء الذكاء الاصطناعي على Bedrock نماذج جاهزة واختبرت بدلاً من إعادة اختراع مخططات الحماية بأنفسهم. الاختيار بينهم واضح: إذا كان تحويل الطلب مطلوباً—النموذج 1 مع Lambda؛ إذا كانت السرعة والبساطة ذات أولوية—النموذج 2 مع مسار مباشر إلى ENI.

أسئلة شائعة

ما طرق المصادقة التي يدعمها كلا النموذجين؟

يتم اختبار كلا النموذجين مع AWS SigV4 (توقيع الطلب عبر مفاتيح الوصول AWS) و OAuth مع رموز Amazon Cognito JWT. الاختيار يعتمد على بنية التطبيق الخاص بك.

لماذا WAF وحده غير كافٍ بدون سياسة الموارد؟

AWS WAF يحمي فقط حركة المرور التي تمر عبر ALB. إذا لم تقم بإغلاق الوصول المباشر إلى نقطة نهاية AgentCore مع سياسة موارد باستخدام شرط `aws:SourceVpce`، يمكن لهاجم تجاوز WAF بالوصول إلى AgentCore مباشرة على عنوانه العام.

لماذا Amazon Bedrock AgentCore Runtime معرض للخطر بدون WAF؟

AgentCore Runtime لا يحتوي على تصفية مدمجة على مستوى تطبيق الويب بشكل افتراضي. بدون بنية إضافية، يمكن لهاجم مهاجمة الوكيل بحقن أو DDoS أو تزوير الطلبات.