السؤالان اللذان يخلطهما الاحتواء
يجيب الاحتواء عن سؤال ميكانيكي ضيق: ما الذي يمكن لهذه العملية لمسه؟ ويجيب التصريح عن سؤال مختلف: هل كان هذا الإجراء ضمن التفويض الممنوح؟ هذان ليسا السؤال نفسه، ومانع التنفيذ على مستوى نظام التشغيل غير مؤهَّل للإجابة عن الثاني.
تعمل البدائية على مستوى المضيف مثل Windows Execution Containers، أو آليات Job Object وAppContainer الأقدم التي بُنيت عليها، على استدعاءات النظام والمقابض والرموز وSIDs. إنها ترى عملية تطلب مقبض ملف، أو مفتاح سجل، أو مقبس شبكة، أو تخصيص ذاكرة. لكنها لا ترى النية، أو نطاق المهمة، أو موافقة المستخدم، أو الفرق بين وكيل يحرّر مستندًا بشكل مشروع داخل مساحة عمله المخصصة والوكيل نفسه يسرّب ذلك المستند لأن حقنًا في الـ prompt أعاد توجيهه. لا يملك النواة أي تمثيل لـ "هذا الإجراء كان ضمن التفويض". لديها فقط تمثيل لـ "هذا المقبض مُنح أو رُفض".
يهم هذا التمييز لأن الفرق الواقعة تحت ضغط التسليم غالبًا ما تطمسه. يُهيَّأ صندوق رمل، فيمنع الكتابة خارج مجلد معيّن، فيستنتج الفريق أن الحوكمة قد تمت معالجتها. لكن ما بُني فعليًا هو حدّ عزل. أما سجل التدقيق الخاص بالتصريح — من وافق على ماذا، وتحت أي مهمة، وبأي فئات بيانات — فيصبح الآن داخل إعدادات صندوق الرمل أو، الأسوأ من ذلك، في طبقة لا يملكها أحد. وعندما يسأل مراجعة الحادث عن سبب قراءة وكيل لسجل عميل لا حق له فيه، لن تكون الإجابة في سجل الاحتواء. سجل الاحتواء يُظهر فقط أن القراءة نجحت.
أين يقع الحد فعليًا
تمتلك الطبقتان قوتين متعاكستين. البدائيات على مستوى النواة قوية في العزل وضعيفة في الدلالات. يمكن للحاوية أن تمنع بشكل موثوق عملية من الكتابة إلى C:\\Windows\\System32، أو فتح مقبس خام، أو إنشاء عملية فرعية ترث رمزها. لكنها لا تستطيع إخبارك ما إذا كان يُفترض بتلك العملية أن تفعل ذلك. محركات السياسات هي العكس: قوية في الدلالات وضعيفة في التنفيذ. يمكن لمحرك سياسات أن يقيّم "هذا الوكيل يحمل تصريحًا للمهمة invoice-reconcile-4417 مقيّدًا بفئة بيانات المالية، ينتهي خلال خمس عشرة دقيقة" ويقرر أن قراءة دفتر الموردين ضمن النطاق. لكنه لا يستطيع، بمفرده، إيقاف استدعاء نظام. إذا تجاوز أحدهم محرك السياسات، أو إذا استُشير بعد وقوع الفعل، فقد وقعت الكتابة بالفعل.
لذلك فإن الواجهة بينهما هي سطح التصميم الذي يهم. قائمة السماح الثابتة — مجموعة ثابتة من المسارات والمضيفين التي يسمح بها صندوق الرمل — هي الشكل الخاطئ، لأنها لا تملك مفهوم المهمة، ولا انتهاء الصلاحية، ولا طريقة للتعبير عن أن الوكيل نفسه يجب أن يمتلك حقوقًا مختلفة لمهام مختلفة. الشكل الصحيح هو منح صلاحية موقّع: رمز منظَّم تصدره طبقة السياسات، ويُقدَّم إلى طبقة التنفيذ، ويُتحقق منه عند نقطة الاستخدام. يحمل المنح كحد أدنى معرّف مهمة، ونطاقًا (أي فئات بيانات، وأي مسارات، وأي وجهات شبكة)، وانتهاء صلاحية، وحالة نهائية. تتحقق طبقة التنفيذ من التوقيع والنطاق؛ ولا تعيد تفسير التفويض.
هذا قريب من نموذج الصلاحيات الذي استخدمته أنظمة التشغيل لعقود، مطبَّقًا على أحمال عمل الوكلاء. تصبح طبقة السياسات هي الجهة المُصدِرة للصلاحيات؛ وتصبح طبقة نظام التشغيل هي مرجع المراقبة. لا تكفي أي منهما وحدها.
قواعد التصميم للاحتواء الطبقي
كل منح يحمل نطاق مهمة وفئات بيانات وحالة نهائية. المنح الذي يقول "هذا الوكيل يجوز له قراءة D:\\data" ليس منحًا؛ إنه ثقب دائم. أما المنح الذي يقول "المهمة invoice-reconcile-4417 يجوز لها قراءة فئة البيانات finance-vendor-ledger حتى الساعة 14:32 UTC، وبعدها تُلغى الصلاحية وتُنهى العملية" فهو قابل للتدقيق. الحالة النهائية تهم بقدر ما يهم النطاق: الوكيل الذي أنهى مهمته لا ينبغي أن يحتفظ بصلاحية حيّة، لأن وكيلًا
الرفض افتراضيًا في طبقة نظام التشغيل؛ والتصريح بالاستثناء في طبقة السياسات. ينبغي أن تبدأ الحاوية بلا وصول إلى نظام الملفات أو الشبكة أو الأجهزة، وأن تتلقى الصلاحيات فقط عبر واجهة المنح. وينبغي أن تبدأ طبقة السياسات من موقف الرفض أيضًا، وألا تصدر المنح إلا عندما يتوافق تعريف مهمة، وتسمية تصنيف بيانات، وسجل موافقة مستخدم أو خدمة. هذا يعكس النمط الشائع، حيث يكون صندوق الرمل متسامحًا وتكون طبقة السياسات مجرد فكرة لاحقة للتسجيل.
سجّل المنح وقرار التنفيذ بشكل منفصل. هذان حدثان مختلفان بمالكين مختلفين. يسجّل سجل المنح أن طبقة السياسات أصدرت صلاحية للمهمة X، والنطاق Y، والانتهاء Z، بناءً على سلطة سجل الموافقة W. ويسجّل سجل التنفيذ أن طبقة نظام التشغيل سمحت أو رفضت طلب مقبض محددًا تحت تلك الصلاحية. عند وقوع حادث، يجيب سجل المنح عن "هل كان هذا مُصرَّحًا به؟" ويجيب سجل التنفيذ عن "هل صمد الحد؟" ودمجهما في تدفق واحد يفقد القدرة على إسناد الفشل إلى طبقة السياسات أو طبقة التنفيذ، وهو بالضبط الإسناد الذي تحتاجه أثناء المراجعة.
المقايضة الصادقة
يكلّف الاحتواء الطبقي زمن استجابة وتعقيدًا. كل فحص صلاحية هو رحلة ذهاب وإياب إلى طبقة السياسات أو تحقق مقابل رمز موقّع، وكل مهمة تحتاج دورة حياة منح تتضمن الإصدار والتجديد والإلغاء. الفرق التي تتخطى هذا وتعتمد على صندوق رمل واحد متسامح تشحن أسرع، وتبدو، لفترة، وكأنها تعمل. نمط الفشل ليس اختراقًا دراماتيكيًا؛ إنه تراكم بطيء لأذونات دائمة لا يستطيع أحد تعدادها، يتبعه حادث يكون فيه سجل الاحتواء كاملًا وسجل التصريح فارغًا.
الجزء غير المريح هو أن مانع التنفيذ على مستوى نظام التشغيل لن يستطيع أبدًا تقرير التصريح، لأن التصريح عبارة عن بيان حول النية البشرية والتفويض التنظيمي، والنواة لا تملك وصولًا إلى أي منهما. أفضل ما يمكنه فعله هو تنفيذ قرار اتُّخذ في مكان آخر، بأمانة وسرعة. وتصميم الواجهة بين الطبقتين — صيغة المنح، ونقطة التحقق، ومسار الإلغاء، والسجلات المنفصلة — هو العمل الهندسي الفعلي. أما التعامل مع صندوق الرمل كضابط الحوكمة فهو الاختصار الذي ينقل سجل التدقيق خارج طبقة السياسات وإلى ملف إعدادات لا يراجعه أحد.
اختبار مفيد: اختر أي إجراء وكيل يسمح به نظامك اليوم واسأل سؤالين. أي طبقة قررت أنه مسموح، وأي طبقة جعلته ممكنًا؟ إذا أجابت الطبقة نفسها عن كليهما، فالحد ليس طبقيًا، وستضطر مراجعة الحادث التالية إلى إعادة بناء التصريح من سجلات تنفيذ لم تُصمَّم أبدًا لحمل ذلك.