الهوية بلا مهمة: لماذا تظل بيانات الاعتماد لكل وكيل تمنح صلاحيات مفرطة

التحسين، وأين يتوقف

امنح وكيل ذكاء اصطناعي بيانات اعتماد تنتهي صلاحيتها عند انتهاء مهمته، وستكون قد أزلت واحدة من أقدم المشكلات في إدارة الوصول: الرمز المميز طويل الأمد الموجود في ملف إعدادات، صالح لأشهر، ومفيد للمهاجم بعد زوال عملية الوكيل بوقت طويل. كل من الطرح على غرار 1Password ومقترحات IAM الأوسع للوكلاء تدفع في هذا الاتجاه. تُصدر بيانات الاعتماد لكل مهمة، وتُربط بجلسة، وتُلغى عند إغلاق المهمة. تتقلص النافذة التي يكون فيها الرمز المسرب مفيدًا من أشهر إلى دقائق. هذا مكسب حقيقي.

وهو أيضًا مكسب متعامد مع السؤال الذي تهتم به معظم مراجعات الأمان فعليًا: ما الذي يمكن لبيانات الاعتماد هذه الوصول إليه أثناء صلاحيتها؟ رمز مميز محدد بالمهمة بعمر خمس دقائق وله s3:GetObject على * لا يزال نافذة مدتها خمس دقائق على الحاوية بأكملها. العمر ضيق. النطاق ليس كذلك. والنطاق ليس شيئًا يقرره نظام إصدار بيانات الاعتماد من تلقاء نفسه — بل يُورث من قرار اتُخذ سابقًا، بواسطة مكوّن مختلف، بمفردات مختلفة.

النطاق ناتج عن التفكيك

تأمل تعليمتين قد يسلمهما منسّق إلى وكيل فرعي:

subtask: reconcile the account
subtask: read invoice 4417

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

المخطط، بعبارة أخرى، يمارس التحكم في الوصول سواء تعامل معه أحد بهذه الصفة أم لا. عندما يقسم "التعامل مع شكوى العميل" إلى "اقرأ التذكرة، اقرأ الطلب، أصدر استردادًا"، يكون قد قرر للتو ما ستحتاجه بيانات الاعتماد في السرب. وعندما يقسم الطلب نفسه إلى "اقرأ التذكرة، اقرأ الطلب، اقرأ سجل الدفع، اقرأ سجل الشحن، اقرأ ملاحظات الحساب"، يكون قد قرر شيئًا أوسع. طبقة IAM في المصب شكلية؛ القرار الجوهري حدث في المنبع، في مكوّن لا يزال معظم الفرق يصفه بالتنسيق.

هذا هو الجزء الذي لا يعالجه نموذج بيانات الاعتماد لكل مهمة. إنه يصلح مشكلة العمر لأن العمر خاصية يتحكم بها المُصدر. ولا يصلح مشكلة النطاق لأن النطاق خاصية للتفكيك، والتفكيك ينتجه نموذج لغوي يفكر في طلب مستخدم، لا محرك سياسات يفكر في أقل صلاحية.

ما تتطلبه قابلية التدقيق

إذا كان النطاق ناتجًا عن التفكيك، فإن تدقيق الوصول يعني تدقيق التفكيك. سجل إصدار الرموز الذي يسجل agent-7 requested scope X, granted scope X لا يخبر المراجع شيئًا عن مدى تبرير X. إنه يسجل الخطوة الشكلية ويغفل الجوهرية.

قاعدة التصميم التي تتبع ذلك ليست معقدة، وإن كانت أكثر تدخلًا مما تبدو. يجب أن يحمل كل طلب بيانات اعتماد معرفين: المهمة الفرعية التي ينتمي إليها، وعقدة الخطة الأم التي أنتجت تلك المهمة الفرعية. يجب رفض المنح إذا تجاوز النطاق المطلوب ما يمكن للمهمة الفرعية المعلنة أن تحتاجه بشكل معقول — و"بشكل معقول" هنا تعني سياسة يُلزم التفكيك بتحقيقها، لا حكمًا يصدره المُصدر على البديهة. والمنح، عند إصداره، يجب تسجيله إلى جانب التفكيك الذي حفّزه، حتى يتمكن المراجع من إعادة بناء المنطق: هذا الرمز موجود لأن عقدة الخطة P أنتجت المهمة الفرعية S، وS محدودة النطاق بالفاتورة 4417، والرمز يمكنه قراءة الفاتورة 4417.

{
  "plan_node": "P-118",
  "subtask": "S-118-3",
  "intent": "read invoice 4417",
  "requested_scope": ["billing:invoices:read:4417"],
  "granted_scope": ["billing:invoices:read:4417"],
  "parent_scope_ceiling": ["billing:invoices:read:*"]
}

حقل parent_scope_ceiling هو المهم. إنه الحد الأقصى للنطاق المسموح لعقدة الخطة بتوزيعه على أبنائها، ويُضبط عند إنشاء الخطة، لا عند طلب بيانات الاعتماد. هذا يمنح المراجع أمرين ليفحصهما: ما إذا بقيت المهمة الفرعية ضمن سقف والدها، وما إذا كان سقف الوالد نفسه مبررًا بالطلب الأصلي. الفحص الثاني هو الذي يلتقط مخططًا قرر بهدوء أن![Close-up of r

نمط الفشل الذي يجب مراقبته ليس وكيلًا خبيثًا. بل وكيلًا مفيدًا. يصطدم وكيل بخطأ صلاحيات — حاول قراءة الفاتورة 4417 وكان النطاق billing:invoices:read:4417 لكن الفاتورة تقع في نظام مختلف، أو تحتاج التسوية سجل الدفع أيضًا — فيعيد المحاولة. إذا سُمح لمنطق إعادة المحاولة بتوسيع النطاق، فسيوسع الوكيل النطاق. هذا ليس خللًا في الوكيل؛ بل هو الوكيل يفعل ما تفعله الوكلاء، وهو السعي نحو الهدف. الخلل في سياسة إعادة المحاولة التي تعامل خطأ الصلاحيات كطلب لمزيد من الصلاحيات بدلًا من إشارة إلى أن التفكيك كان خاطئًا.

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

المقايضة الصادقة

لا شيء من هذا مجاني. اشتراط أن يحمل كل طلب بيانات اعتماد معرف مهمة فرعية وسقف عقدة خطة يعني أن على المخطط إصدار تفكيكات منظمة، لا أوصاف مهام نصية حرة. يعني أن على طبقة التنسيق الاحتفاظ برسم بياني للخطة مع تعليقات النطاق، وأن يُنَسَّخ هذا الرسم ويُدقق. يعني أن بعض المهام المشروعة ستفشل لأن التفكيك كان خشنًا جدًا ولا يستطيع الوكيل تصحيح نفسه ضمن نطاقه — والاستجابة الصحيحة لذلك الفشل هي إعادة تخطيط أبطأ ومرئية للبشر، لا رمز أوسع.

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

ما يجب بناؤه

• عامل المخطط كمكوّن ذي صلة أمنية. مخرجاته قرارات تحكم في الوصول.
• اشترط معرفات المهمة الفرعية وعقدة الخطة الأم على كل طلب بيانات اعتماد.
• فرض سقف نطاق للوالد يُضبط عند إنشاء الخطة، لا عند إصدار بيانات الاعتماد.
• سجّل التفكيك إلى جانب المنح، حتى يكون التبرير قابلًا لإعادة البناء.
• افشل مغلقًا عند إعادة المحاولة بنطاق أوسع، ووجّه الفشل إلى إعادة التفكيك بدلًا من منح أوسع.

بيانات الاعتماد ضيقة فقط بقدر ضيق المهمة التي أنتجتها. إذا ذُكرت المهمة بحبيبية خاطئة، فستكون بيانات الاعتماد كذلك.