النمط المُبلَّغ عنه
تُنشر أنظمة الوكلاء بشكل متزايد لتنفيذ مهام تتطلب الوصول إلى بيانات الشركة: قراءة المستودعات، والاستعلام من قواعد البيانات، واستدعاء واجهات API الداخلية. ومن الملاحظات المتكررة في المراجعات التشغيلية أنه بعد انتهاء تشغيل الوكيل، تظل بيانات اعتماده صالحة. فالوكيل لم يعد ينفّذ، ومع ذلك لا يزال الرمز المميز أو المفتاح الذي استخدمه يمنح الوصول. هذه ليست مشكلة تعيين أو إنهاء خدمة. الفجوة تقع بين إتمام المهمة وانتهاء صلاحية بيانات الاعتماد.
في سير العمل البشري التقليدي، يرتبط الوصول بدور الشخص ويُراجَع دوريًا. أما في سير عمل الوكلاء، فيرتبط الوصول بمهمة، لكن دورة حياة بيانات الاعتماد غالبًا ما تُورَث من أسرار ثابتة أو حسابات خدمة طويلة الأمد. والنتيجة فئة من بيانات الاعتماد التي تعيش أطول من العمل الذي صدرت من أجله.
لماذا تُعدّ مدة الصلاحية (TTL) التجريد الخاطئ
مدة الصلاحية الثابتة هي تخمين لطول المدة التي ستستغرقها المهمة. فتشغيلات الوكلاء متقطعة: قد تكتمل في ثوانٍ، أو قد تتوقف لدقائق في انتظار حد معدل، أو موافقة بشرية، أو حدث خارجي. ومدة صلاحية قصيرة بما يكفي لتكون آمنة لاستعلام سريع ستنتهي في منتصف مهمة مشروعة طويلة الأمد. ومدة صلاحية طويلة بما يكفي لتغطية أسوأ الحالات تترك نافذة واسعة من الوصول غير الضروري.
الوكلاء طويلو الأمد مع نقاط التحقق (checkpointing) قد يعيشون أطول من أي مدة صلاحية معقولة. فعندما يحفظ الوكيل حالته ويستأنف لاحقًا، قد تكون بيانات الاعتماد الأصلية قد انتهت صلاحيتها، مما يستدعي تجديدها. وإذا كان التجديد تلقائيًا ولا يعيد تفويض المهمة، فسيتم تمديد بيانات الاعتماد فعليًا إلى أجل غير مسمى. وتصبح مدة الصلاحية شكليّة: بيانات اعتماد قصيرة الأمد تُجدَّد دون مراجعة هي بيانات اعتماد دائمة بخطوات إضافية.
المشكلة الأعمق أن مدد الصلاحية تقيس الوقت، لا الصلاحية. فهي تجيب عن سؤال "إلى متى؟" لكن ليس "لأي غرض؟" أو "تحت سيطرة من؟". فالوكيل الذي ينهي مهمته في عشر ثوانٍ والوكيل الذي يعمل عشر ساعات يتلقيان الفئة نفسها من بيانات الاعتماد، فقط بطوابع زمنية مختلفة لانتهاء الصلاحية.
ربط الصلاحية بالتشغيل
النموذج الأكثر متانة يربط بيانات الاعتماد بمعرّف التشغيل والمهمة المُعلَنة. فبدلًا من إصدار رمز مميز بصلاحية ثابتة، يُصدر المنسّق (orchestrator) بيانات اعتماد صالحة فقط أثناء نشاط التشغيل وفقط للعمليات المُعلَنة في مواصفات المهمة. وبيانات الاعتماد ليست رمزًا مميزًا حاملًا (bearer token) يمكن استخدامه في أي مكان؛ بل هي قدرة (capability) محدودة النطاق لتشغيل محدد ومجموعة محددة من الإجراءات.
المنسّق كسلطة إبطال
المنسّق الذي يبدأ التشغيل ينبغي أن يكون أيضًا السلطة القادرة على إبطال بيانات الاعتماد. فعندما ينتهي التشغيل — سواء بالإتمام أو الفشل أو الإلغاء — يضع المنسّق علامة على التشغيل بأنه غير نشط. وأي بيانات اعتماد تُقدَّم بمعرّف ذلك التشغيل تُرفض. وهذا يعكس الوضع الافتراضي: فبدلًا من الاعتماد على انتهاء الصلاحية، يعتمد النظام على النشاط. لا تشغيل نشط، لا بيانات اعتماد صالحة.
الاستئناف كحدث تفويض جديد
عندما يستأنف الوكيل من نقطة تحقق، فهو يبدأ سياق تنفيذ جديد. وينبغي أن يتعامل المنسّق مع هذا كحدث تفويض جديد: إعادة تقييم المهمة، وإعادة إصدار بيانات اعتماد محدودة النطاق للتشغيل المستأنَف، وطلب فحوص السياسات نفسها التي طُلبت للتشغيل الأصلي. وهذا يمنع نقطة التحقق من أن تصبح بابًا خلفيًا للوصول غير المحدود. والمقايضة هي زمن استجابة إضافي وتعقيد: فكل استئناف يستلزم رحلة تفويض ذهابًا وإيابًا، وعلى المنسّق أن يحتفظ بحالة التشغيلات النشطة. وبالنسبة للوكلاء عاليي التكرار وقصيري الأمد، قد تكون هذه الكلفة مقبولة؛ أما في خطوط المعالجة الحساسة لزمن الاستجابة، فقد تتطلب تخزينًا مؤقتًا أو تفويضًا مسبقًا لأنماط مهام معروفة.
آلية ملموسة: رموز مميزة محدودة النطاق بالتشغيل
التنفيذ العملي يستخدم رمزًا مميزًا موقّعًا يضم معرّف التشغيل ونطاق المهمة وتوقيع المنسّق. ويُقدَّم الرمز إلى نقطة إنفاذ السياسات (PEP) التي تتحقق من أمرين: أن التوقيع صالح، وأن معرّف التشغيل مُعلَّم كنشط في مخزن حالة المنسّق. ولا تعتمد نقطة الإنفاذ على انتهاء صلاحية الرمز وحده. فإذا كان المنسّق قد علّم التشغيل كمنتهٍ، يُرفض الرمز حتى لو كان انتهاء صلاحيته في المستقبل. وتتطلب هذه الآلية مخزن حالة مشتركًا بين المنسّق ونقطة الإنفاذ، ومسار إبطال سريعًا بما يكفي ليكون ذا جدوى. والمقايضة هي الاعتماد على توافر المنسّق: فإذا تعذّر الوصول إلى مخزن الحالة، على نقطة الإنفاذ أن تقرر بين الفشل المفتوح أو الفشل المغلق. والفشل الم
الكشف
حتى مع بيانات الاعتماد محدودة النطاق بالتشغيل، يبقى الكشف ضروريًا. وينبغي تجهيز سجلات التدقيق لرصد بيانات الاعتماد المستخدمة بعد انتهاء التشغيل الذي أصدرها. وهذا استعلام مباشر إذا كانت بيانات الاعتماد تحمل معرّف التشغيل: اربط سجل استخدام بيانات الاعتماد بسجل دورة حياة التشغيل وابحث عن أحداث استخدام انتهى فيها التشغيل قبل الطابع الزمني للاستخدام.
المقياس الثاني هو الفجوة بين آخر استدعاء أداة وانتهاء صلاحية بيانات الاعتماد. وفي نظام سليم، ينبغي أن تكون هذه الفجوة قريبة من الصفر للتشغيلات المكتملة: إذ ينبغي أن تصبح بيانات الاعتماد غير صالحة بمجرد انتهاء التشغيل. والفجوة المستمرة تشير إلى أن بيانات الاعتماد تعيش أطول من تشغيلاتها، سواء بالتجديد أو التخزين المؤقت أو الإخفاق في الإبطال. وتتبع هذه الفجوة بمرور الوقت يكشف الانحدارات في مسار الإبطال.
الإشارة الثالثة هي معدل أحداث الاستئناف التي لا تُطلق إعادة تفويض. فإذا كانت نقاط التحقق تُستخدم لتمديد الوصول دون حدث تفويض جديد، فهذا انتهاك للسياسة ينبغي أن يظهر في مسار التدقيق.
الواقع التشغيلي
تنفيذ بيانات الاعتماد محدودة النطاق بالتشغيل والإبطال القائم على المنسّق ليس مجانيًا. فهو يتطلب تغييرات في كيفية طلب الوكلاء للوصول، وكيفية تتبع المنسّق لحالة التشغيل، وكيفية تحقق نقاط إنفاذ السياسات من بيانات الاعتماد. وهو يُدخل اعتمادًا على حياة المنسّق واختناقًا محتملًا عند مخزن الحالة. وبالنسبة للأنظمة التي لديها بالفعل منسّق مركزي مع إدارة حالة موثوقة، يكون التغيير تدريجيًا. أما الأنظمة التي يُنشئ فيها الوكلاء وكلاء فرعيين أو تعمل عبر منسّقات متعددة، فيصبح تزامن الحالة أكثر تعقيدًا.
البديل — الاعتماد على مدد الصلاحية والمراجعات الدورية — أبسط في التنفيذ لكنه يترك فجوة بنيوية. والفجوة ليست بين التعيين والإنهاء؛ بل بين إتمام المهمة وانتهاء صلاحية بيانات الاعتماد. وسدّ هذه الفجوة يتطلب التعامل مع بيانات الاعتماد كقدرات مرتبطة بتشغيل، لا كأسرار لها مؤقت.