Okta وAgentCore تضعان وكلاء الذكاء الاصطناعي تحت السيطرة: سحب الوصول خلال ثانية واحدة

الوكيل الذي يحدّث تذكرة أو يقرأ بطاقة عميل يعمل نيابةً عن إنسان وداخل التطبيقات التي يملك هذا الإنسان حق الوصول إليها. ومن هنا ينشأ سؤال محرج لفريق الأمن: أي وكيل بالتحديد يحق له التصرف نيابةً عن أي مستخدم وفي أي تطبيق، وكيف يمكن إيقافه. فموافقات OAuth في كل تطبيق على حدة وحسابات الخدمة المشتركة لا تجيب عن هذا السؤال. وفي الجزء الأول من تحليلها تقترح AWS إجابةً قائمة على الجمع بين Okta Cross App Access (XAA) وAmazon Bedrock AgentCore.

من المسؤول عن ماذا

التوزيع بسيط. Okta هي مستوى التحكم: تقرر أي وكيل يمكنه التصرف نيابةً عن أي مستخدم وفي ما يخص أي مورد. أما AgentCore Identity فهي مستوى التنفيذ: تحفظ بيانات اعتماد الوكيل، وتحوّل قرار Okta إلى رمز يقبله المورد، وتُبقي فيه الهويتين معًا: هوية المستخدم وهوية الوكيل.

يشارك في كل طلب ثلاثة رموز. رمز الهوية (ID token) يبيّن من هو المستخدم. أما ID-JAG فهو قرار Okta نفسه: يُستخدم مرة واحدة ويعيش 5 دقائق. ورمز الوصول (access token) هو ما يقبله المورد المستهدف؛ وهو أيضًا يعيش 5 دقائق، ويذكر المستخدم والوكيل معًا، ويحمل مجموعات المستخدم.

تبدو السلسلة على النحو التالي. يسجّل المستخدم الدخول إلى الواجهة الأمامية (BFF) عبر OpenID Connect. ثم تستبدل BFF رمز الهوية الخاص به برمز ID-JAG لدى Okta وفق RFC 8693، مصادِقةً نفسها بصفتها الوكيل. تتحقق Okta من أن الوكيل نشط، وأن المستخدم معيَّن له، وأن المسؤول ربط الوكيل بخادم التفويض المطلوب مع النطاقات (scopes) المطلوبة. بعد ذلك تستدعي BFF الوكيل في بيئة تشغيل AgentCore مع ID-JAG بوصفه رمز bearer، ولا يسمح مفوِّض JWT في بيئة التشغيل إلا برموز ID-JAG التي أصدرتها Okta لهذا الوكيل تحديدًا. ثم تستبدل AgentCore Identity رمز ID-JAG برمز وصول وفق RFC 7523، ويستخدمه الوكيل للوصول إلى خوادم MCP. ويتحقق Task manager من أن الرمز حصل عليه وكيل مسجَّل، وأن مجموعة المستخدم ونطاقه يسمحان بالأداة المعنية.

أين يسهل التعثر

يسرد المؤلفون بصراحة العقبات التي اصطدموا بها بأنفسهم.

أولًا، ترفض Okta طلب ID-JAG إذا تضمّن نطاقات OpenID Connect مثل openid أو profile (الخطأ invalid_scope). المطلوب نطاق مخصص واحد على الأقل ودون أي نطاق قياسي.

ثانيًا، يجب أن يأتي رمز الهوية من التطبيق نفسه المرتبط بالوكيل. فرمز من تطبيق آخر يُفشل عملية الاستبدال بخطأ مفاده أن العميل غير مسجَّل للتفويض.

ثالثًا، يحتاج كل وكيل في Okta إلى credential provider خاص به: فمحاولة استبدال ID-JAG لوكيل ما نيابةً عن وكيل آخر تنتهي بالرفض بسبب عدم تطابق client_id.

رابعًا، يخزّن SDK رمز workload access token في BedrockAgentCoreContext وليس في ترويسات الطلب. وقد بحثت النسخة الأولى لدى المؤلفين عنه في الترويسات فلم تجده، ولجأت في جميع الطلبات الـ21 التي جرى فحصها إلى المسار الاحتياطي بهوية workload ثانية. ويجب قراءة الرمز من السياق.

وأخيرًا، في سياسة IAM يُكتب مقطع ARN على هيئة oauth2credentialprovider بلا شرطة؛ ومع الشرطة كان كل استدعاء يفشل بالخطأ AccessDeniedException. ويكفي لدور الوكيل بيانان (statements) اثنان: GetResourceOauth2Token وقراءة سر المزوّد.

الأرقام والقيود

بعد أن أزال المسؤول تعيين المستخدم للوكيل، رفضت Okta الطلبات الجديدة خلال نحو ثانية واحدة، بينما انتهت صلاحية الرموز التي صدرت بالفعل في غضون 5 دقائق. واستغرق الاستدعاء الأول مع استبدال ID-JAG نحو نصف ثانية، وأضافت AgentCore Identity في المجمل نحو 0.6 ثانية إلى طلب مدته نحو 30 ثانية. أما الاستدعاء الثاني إلى خادم MCP آخر فأعاد الرمز نفسه من المخزن بمتوسط 58 مللي ثانية، دون استبدال جديد لرمز ID-JAG أحادي الاستخدام. ويعطي ID-JAG جديد للمستخدم نفسه رمزًا جديدًا، ولذلك يعكس كل طلب قرار Okta الحالي.

تحفظات: الشيفرة مثال تعليمي لا يصلح للإنتاج، والمقتطفات توضح النمط وليست حلًا جاهزًا. أُجريت الاختبارات على Okta Integrator المجاني، وفي منطقة AWS واحدة (أوريغون). ويستغرق الشرح العملي نحو ساعة. وفي الإنتاج يلزم توفر المصادقة متعددة العوامل (MFA)، وتدوير السر (أو Private Key JWT بدلًا من السر المشترك)، والتنسيق مع فريقي الأمن والشؤون القانونية.

ما العمل

إذا كان وكلاؤكم يصلون إلى الأنظمة الداخلية عبر حساب خدمة مشترك، فهذا سبب لمراجعة المخطط. سجّلوا الوكيل ككيان مستقل في مزوّد الهوية (IdP)، وقيّدوا النطاقات، وأبقوا الرموز قصيرة العمر، وتحققوا من صلاحيات المستخدم داخل الأدوات نفسها وليس عند المدخل فقط. ويَعِد الجزء الثاني بتناول الأمر نفسه مع AgentCore Gateway وسياسات Cedar ووكيل على EKS والتدقيق في CloudWatch.