يتلقى DeployBot رمزاً مميزاً (token) طويل الأمد لنشر المخرجات البرمجية (artifacts) من مسار البناء (build pipeline). تقوم إحدى المهام بطباعة الرمز في سجلات التكامل المستمر (CI logs)، فيتمكن المهاجم من الحصول على مخرجات السجل، ويُستخدم الرمز نفسه بنجاح لنشر حزمة داخلية من عنوان IP جديد. لم يحتج المهاجم إلى كلمة مرور خاصة بموظف، أو صفحة تصيد، أو جلسة مستخدم؛ بل احتاج فقط إلى بيانات اعتماد تمثل كياناً (principal) مؤتمتاً.
تُعرف الهوية غير البشرية بأنها الكيان (principal) الذي يقف وراء عبء عمل مؤتمت، أو خدمة، أو مسار عمل (pipeline)، أو جهاز، أو وكيل (agent). في هذه البيئة، يمتلك DeployBot صلاحية التنفيذ لأن الخدمات اللاحقة تقبل الرمز الخاص به، وليس لأن بشراً يقوم بإتمام عملية المصادقة متعددة العوامل (MFA) عند كل طلب. لذا، فإن السؤال الذي يواجه المدافعين هو سؤال تشغيلي: كيف نصدر صلاحيات محدودة النطاق، ونقوم بتدويرها (تغييرها دورياً) دون تعطيل بيئة الإنتاج، ونكتشف سوء الاستخدام في حال خروج بيانات الاعتماد عن نطاق التشغيل المخصص لها؟
تتضمن أبسط حالات الفشل مدخلاً واحداً ونتيجة واحدة. يقدم DeployBot نسخة من رمز الحامل (bearer token) إلى سجل المخرجات البرمجية (artifact registry)، فيقوم السجل بنشر المخرج لأن الرمز لا يزال صالحاً ويحمل الإذن المطلوب. يثبت الرمز حيازة الصلاحية، ولا يثبت الموقع أو العملية المشروعة التي حصلت عليه، ما لم تضف بنية الهوية المحيطة فحوصات إضافية للتحقق من ذلك.
قاعدة الحدود يجب أن تحدد بيانات الاعتماد غير البشرية هوية الكيان (principal)، وتقيّد صلاحياته، وتظل قابلة للمراقبة والرصد بعد إصدارها.
يُعد تسريب الرمز أمراً بالغ الأهمية لأن DeployBot يمثل مسار هوية واحداً فقط ضمن بيئة prod-gke-1. تشغّل مجموعة Kubernetes (cluster) كلاً من Orders API وBilling API وInventory API. وإلى جانب هذه الخدمات، يستدعي SupportAgent أدوات دعم معتمدة، ويقوم ETLBot باستيراد البيانات، بينما يتولى DeployBot بناء ونشر المخرجات البرمجية. يولد كل كيان قراراً بالتفويض، ودورة حياة لبيانات الاعتماد، وأدلة يجب على المدافعين الاحتفاظ بها.
لا تقتصر مساحة الهجوم على مجموعة Kubernetes (cluster) وحدها؛ إذ تعبر الطلبات حدود المجموعة، وحدود شبكة الخدمات (service-mesh) الفاصلة بين أعباء العمل، وسجل المخرجات البرمجية، ومخزن الأسرار (secrets store)، ومزود الهوية وخادم التفويض، وواجهات برمجة التطبيقات (APIs) الخاصة بمزودي البرمجيات كخدمة (SaaS) الخارجيين. يمكن قبول بيانات اعتماد نُسخت من نطاق معين في نطاق آخر عندما تتعامل السياسات مع بيانات الاعتماد كدليل كافٍ دون النظر إلى الجهة المصدرة، أو الجمهور المستهدف، أو عبء العمل، أو المصدر، أو الإجراء المسموح به. توفر البيئة الموضحة أدناه هدفاً متسقاً لآليات التحكم اللاحقة.
لنقم بتتبع مسارات عبور بيانات الاعتماد والرموز المميزة عبر تلك الحدود:
يوضح هذا الرسم البياني كيف تنتقل الصلاحيات عبر أنظمة متعددة باستخدام الرموز (tokens)، بينما يسجل كل نظام جزءاً فقط من مسار الطلب.
نظراً لأن سجل الأصول (inventory) يحدد كل مسار للصلاحيات، يمكننا نمذجة سيناريو الفشل قبل اختيار آلية التحكم المناسبة. فمثلاً، يتيح تسريب مفتاح واجهة برمجة التطبيقات (API key) من مستودع برمجيات أو سجلات التكامل المستمر (CI) للمهاجم انتحال شخصية الكيان المصرح له (principal) حتى يتم إلغاء المفتاح. كما يمكن استخدام “سر عميل OAuth” (OAuth client secret) المسروق لإنشاء رموز وصول جديدة، أو قد تنجح عملية إعادة استخدام رمز وصول (token replay) من شبكة أو بيئة تشغيل غير متوقعة. ورغم اختلاف مسارات السرقة هذه، إلا أنها تشترك جميعاً في تجاوز نفس الحدود: حيث يقدم طرف خارجي بيانات اعتماد مخصصة في الأصل لحمل عمل (workload) خاضع للتحكم.
يؤدي النطاق الواسع جداً للصلاحيات إلى تغيير حجم التأثير في حال حدوث السرقة. فإذا كان بإمكان وكيل الدعم (SupportAgent) قراءة سجلات الفواتير واستدعاء أداة لمعالجة المبالغ المستردة بموجب صلاحية واحدة شاملة، فقد يؤدي طلب للأداة ناتج عن مدخلات (prompt-driven) أو اختراق لمكون من مكونات الوكيل إلى تنفيذ إجراء يتجاوز الصلاحيات الممنوحة فعلياً لمقدم الطلب. تُعرف هذه المشكلة باسم “النائب المرتبك” (confused deputy): حيث تقوم خدمة تتمتع بصلاحيات مشروعة بتنفيذ إجراء لصالح جهة استدعاء غير موثوقة أو لا تملك الصلاحيات الكافية. ولا يكمن الحل في مجرد تعزيز المصادقة؛ بل يتطلب استدعاء الأداة وجود سياسة صريحة تربط بين الكيان الطالب، والمورد المستهدف، والعملية المسموح بها.
تُعد عملية تدوير بيانات الاعتماد (rotation) مصدراً لفشل من نوع أكثر خفاءً؛ فقد يحتوي مخزن الأسرار على بيانات اعتماد بديلة بينما يستمر ETLBot في استخدام السر القديم المخزن مؤقتاً، أو قد يستمر مزود خدمة SaaS (التابع للنظام) في قبول كلا الإصدارين لفترة أطول مما هو مخطط له. ولا تكتمل عملية التدوير إلا عندما تصبح بيانات الاعتماد القديمة غير قادرة على منح صلاحية للطلبات، مع إثبات قدرة حمل العمل على استخدام البديل الجديد.
يربط العرض التالي كل تهديد بآلية الوقاية والأدلة اللازمة للكشف عنه:
يربط جدول المقارنة أدناه بين كل حالة فشل في بيانات الاعتماد وبين الحدود المعنية، وإجراء الوقاية، ومصدر الأدلة.