سياسات الوصول لـ DKE 365 (RBAC + ABAC)
نموذج التحكم في الوصول في Cockpit v2 لـ DKE 365 — RBAC للإدارة وسياسات وصول ABAC تُفرَض عند فك التشفير.
يمتلك Cockpit v2 طبقتين متمايزتين للتحكم في الوصول. بالنسبة لـ DKE 365 تجيبان عن سؤالين مختلفين:
| الطبقة | تحكم في | ماذا يعني ذلك لـ DKE |
|---|---|---|
| RBAC (الأدوار والصلاحيات) | من يمكنه إدارة Cockpit | من يمكنه نشر / تفعيل / تدوير خدمات DKE |
| سياسات الوصول ABAC | من، ومن أين، ومتى يمكنه تنفيذ عملية تشفير وقت التشغيل | من يمكنه **فك تشفير** محتوى محمي بـ DKE، ومن أي عنوان IP / دولة / وقت / مجموعة |
تصف صفحتا RBAC والتحكم في الوصول بمبدأ الثقة الصفرية الحاليتان التحكم في الوصول على Cockpit v1. أما في Cockpit v2 فيُنفَّذ القصد نفسه بواسطة محرك السياسات الموصوف أدناه، المرتبط بخدمة DKE عبر access_policy_id الخاص بها.
RBAC — صلاحيات الإدارة
تحكم الإجراءات الإدارية (نشر خدمات DKE وتفعيلها وتدويرها، وإدارة سياسات الوصول) بواسطة التحكم في الوصول القائم على الأدوار. تُسنَد الأدوار للمستخدمين ويمكن حصرها بوحدة تنظيمية (OU)؛ يجتاز المسؤولون جميع الفحوصات.
ABAC — سياسات الوصول المرتبطة بخدمة DKE
سياسة الوصول هي سجل محدد النطاق بالمستأجر يُقيَّم عند كل عملية فك تشفير لـ DKE. تُربَط بخدمة عبر ضبط access_policy_id الخاص بالخدمة (راجع تكوين DKE).
طبقة التحكم في الوصول في Cockpit v2 هي محرك سياسات كامل، وليست قائمة سماح ثابتة. تُركِّب السياسة الواحدة خمسة أبعاد مستقلة (المستخدم، وعنوان IP، والموقع، والوقت، والمجموعة)، لكل منها دلالات قائمة سماح / قائمة حظر / إلزام، تحت واحد من ثلاثة إجراءات سياسة (Allow / Block / Bypass) بأسبقية حتمية. وهي مُغلَقة أمنياً عند الفشل، ومحددة النطاق بالمستأجر، واختيارياً محددة النطاق بالوحدة التنظيمية، وتعتمد على مصفوفة قدرات لكل نوع تطبيق، ويُكتَب كل قرار في مسار تدقيق جنائي — كل ذلك يُفرَض على جانب الخادم في مسار فك التشفير، بحيث تنتقل حماية التسمية مع البيانات نفسها بدلاً من العميل.
شكل السياسة
تمتلك السياسة اسماً ووصفاً، وإجراءً عاماً (سماح، أو حظر، أو تجاوز)، ونطاق وحدة تنظيمية اختيارياً (وإلا فعلى مستوى المستأجر بأكمله)، وعلامة تفعيل، وكتل قواعد لكل بُعد من أبعاد الوصول الخمسة أدناه.
أبعاد الوصول الخمسة
يحمل كل مدخل بُعد وضع تطابق (قائمة سماح، أو قائمة حظر، أو إلزام) وعند الاقتضاء عامل تطابق. يدعم DKE 365 جميع الأبعاد الخمسة.
| البُعد | يطابق حسب |
|---|---|
| المستخدم | UPN / الاسم المعروض / البريد الإلكتروني (يدعم regex) |
| عنوان IP | عنوان محدد، أو نطاق CIDR، أو نطاق بداية-نهاية (IPv4/IPv6) |
| الموقع | رموز دول ISO-3166 |
| الوقت | يوم الأسبوع + نطاق الدقيقة من اليوم |
| المجموعة | عضوية مجموعة مزوّد الهوية |
كيف يعمل الفرض (عند فك التشفير)
عدم وجود سياسة يعني عدم وجود قيد
إذا لم تكن أي سياسة مرتبطة (أو كانت معطَّلة)، يُسمَح بفك التشفير بالسماح — لا سياسة تعني عدم وجود قيد.
بناء سياق الوصول
يبني Cockpit v2 سياق وصول من هوية المتصل: المستخدم، وعنوان IP، والدولة، والوقت الحالي، وعضوية المجموعة. رمز Azure AD JWT هو المرجع الموثوق؛ تُستخدَم رؤوس التوجيه / CDN (عنوان IP للعميل، الدولة) فقط كاحتياط وتحقق مزدوج، ولا تُوثَق إلا عندما تصل من عناوين مصدر ضمن قائمة CIDR الخاصة بالوكيل الموثوق المُهيَّأة.
تقييم كل بُعد
يُقيَّم كل بُعد بواسطة محرك السياسات.
تطبيق أسبقية القرار
أسبقية القرار: Bypass > Block > Allow > رفض افتراضي.
الإغلاق الآمن عند الفشل
السياسة المُفعَّلة بلا قواعد ترفض. إذا تعذر كتابة سجل تدقيق أمني لقرار allow في بيئة الإنتاج، تُرفَض عملية فك التشفير.
تسجيل القرار
يُكتَب كل قرار في سجل تدقيق سياسة وصول جنائي، يظهر في سجلات النشاط.
تُنشَأ السياسات وتُدار من Cockpit، وكل قرار فرض متاح كمسار تدقيق يظهر في سجلات النشاط.
مثال: سياسة فك تشفير DKE
تسمح سياسة فك تشفير DKE النموذجية بفك التشفير فقط لأعضاء مجموعة محددة لدى مزوّد الهوية (على سبيل المثال، جمهور التسمية)، من دولك المؤسسية، خلال ساعات العمل — بينما تحظر أي دولة خاضعة للعقوبات تماماً. تجمع قاعدة مجموعة مع قاعدتي موقع ووقت، وتربط السياسة بخدمة DKE (access_policy_id)، وتُقيَّم كل عملية فك تشفير بعدها مقابلها، ويُسجَّل كل قرار في مسار التدقيق.
سياسات الوصول هي كيفية تنفيذ DKE 365 لفك التشفير بمبدأ الثقة الصفرية على Cockpit v2: المصادقة هي رمز Azure AD، والتفويض — من / أين / متى / أي مجموعة — هو سياسة الوصول. اجمع قاعدة مجموعة (جمهور التسمية فقط) مع قاعدتي موقع ووقت للحصول على وضعية محكمة.