سياسات الوصول (RBAC + ABAC)
طبقتا التحكم في الوصول في DuoKey Cockpit — الإدارة القائمة على الأدوار وسياسات الوصول القائمة على السمات (ABAC) التي تحكم كل عملية تشفير وقت التشغيل.
يمتلك Cockpit طبقتين متمايزتين للتحكم في الوصول. تجيبان عن أسئلة مختلفة وتُفرَضان في نقاط مختلفة، لذا يُعدّ الفصل بينهما أمراً أساسياً:
| الطبقة | تحكم في | أين تُطبَّق |
|---|---|---|
| RBAC (الأدوار والصلاحيات) | من يمكنه إدارة Cockpit | واجهة إدارة API — نشر تطبيق، تدوير مفتاح، تعديل سياسة |
| سياسات الوصول ABAC | من، ومن أين، ومتى يمكنه تنفيذ عملية تشفير وقت التشغيل | مرتبطة بخدمات DKE والتطبيقات ونقاط نهاية XKS؛ تُقيَّم عند فك التشفير / الوصول إلى المفتاح |
سيُضاف هنا شرح موجز لإنشاء سياسة وصول ومشاهدة فرضها.
RBAC — صلاحيات الإدارة
الإجراءات الإدارية محمية بصلاحيات دقيقة وهرمية قائمة على الأدوار تحكم من يمكنه تنفيذ كل إجراء. يُمنَح المستخدم إجراءً إذا كان يمتلك الصلاحية المطابقة أو أي صلاحية أعلى تتضمنها؛ يجتاز المسؤولون جميع الفحوصات.
الصلاحيات
صلاحيات دقيقة تتداخل هرمياً — الصلاحية الأعلى تمنح ضمنياً كل ما تحتها.
الأدوار
يجمع كل دور مجموعة من الصلاحيات ويُسنَد للمستخدمين. يمكن حصر الأدوار بوحدة تنظيمية (OU) بحيث ينطبق المنح فقط ضمن ذلك الفرع.
نطاق الوحدة التنظيمية
يقصر إسناد دور محدد النطاق بوحدة تنظيمية الصلاحيات على موارد تلك الوحدة، مما يدعم الإدارة المفوَّضة.
تُنشَأ الأدوار ومجموعات صلاحياتها ونطاقها التنظيمي وتُدار من وحدة تحكم إدارة Cockpit.
ABAC — سياسات الوصول
سياسة الوصول هي سجل محدد النطاق بالمستأجر يُقيَّم كلما استُخدِم مفتاح محمي — مثل فك تشفير DKE، أو عملية تشفير عامة لتطبيق، أو فك تشفير AWS XKS. تُفرَض السياسات بواسطة محرك سياسات المنصة، وهي طبقة التفويض التي تعلو أي رمز حامل صادَق على المتصل.
شكل السياسة
| السمة | المعنى |
|---|---|
| الاسم | اسم السياسة المقروء للبشر |
| الوصف | وصف نصي حر |
| الإجراء | الإجراء العام للسياسة — سماح، أو حظر، أو تجاوز |
| نوع التطبيق | نوع التطبيق المستهدف — مثل DKE365، وOracle TDE، وAWS XKS |
| نطاق الوحدة التنظيمية | نطاق وحدة تنظيمية اختياري (غير محدد = على مستوى المستأجر بأكمله) |
| مُفعَّلة | ما إذا كانت السياسة نشطة |
| القواعد والمجموعات | أربع كتل قواعد مصنّفة — المستخدم، والجهاز (IP)، والموقع، والوقت — إضافة إلى مجموعات مزوّد الهوية |
أبعاد الوصول الخمسة
كل بُعد هو قائمة من المدخلات. يحمل كل مدخل وضع تطابق (تضمين = قائمة سماح، استثناء = قائمة حظر، إلزام) وعند الاقتضاء عامل تطابق (أي من، يحتوي).
| البُعد | يطابق حسب |
|---|---|
| المستخدم | UPN / الاسم المعروض / البريد الإلكتروني (يدعم regex) |
| عنوان IP | عنوان محدد، أو نطاق CIDR، أو نطاق بداية-نهاية (IPv4/IPv6) |
| الموقع | رموز دول ISO-3166 |
| الوقت | يوم الأسبوع + نطاق الدقيقة من اليوم |
| المجموعة | عضوية مجموعة مزوّد الهوية |
لا يدعم كل نوع تطبيق كل بُعد. يعرض Cockpit مصفوفة قدرات تحدد أي من الفئات الخمس يمكن لكل نوع تطبيق احترامها، وتُعطِّل واجهة المستخدم علامات تبويب القواعد غير المنطبقة. يدعم DKE365 جميع الأبعاد الخمسة؛ بينما تدعم عدة أنواع تطبيقات عامة أبعاد IP / الموقع / الوقت فقط.
ربط سياسة
لا تأثير لسياسة حتى تُربَط بمورد. يُلحِق الربط السياسة بالهدف:
| الهدف | كيفية الربط |
|---|---|
| خدمة DKE | مُلحَقة بالخدمة — تُفرَض على كل فك تشفير |
| تطبيقات عامة (بما في ذلك Oracle TDE) | مُلحَقة بالتطبيق — تُفرَض على عمليات التشفير الخاصة بالتطبيق |
| نقطة نهاية AWS XKS | مُلحَقة لكل نقطة نهاية — تُفرَض في مسار فك تشفير XKS |
كيف يعمل الفرض
البحث عن السياسة المرتبطة
عند تشغيل عملية محمية، يبحث Cockpit عن السياسة المرتبطة بالمورد. إذا لم تكن مُلحَقة أي سياسة، أو كانت السياسة معطَّلة، تُسمَح العملية بالسماح — عدم وجود سياسة يعني أن المورد غير مقيَّد.
بناء سياق الوصول
يبني Cockpit سياق وصول من هوية المتصل والنقل: المستخدم (من JWT)، وعنوان IP، والدولة، والوقت الحالي، وعضوية المجموعة. JWT هو المرجع الموثوق. تُستخدم رؤوس التوجيه / CDN (عنوان IP للعميل، الدولة) فقط كاحتياط وتحقق مزدوج، وفقط عندما تصل من عناوين مصدر ضمن قائمة CIDR الخاصة بالوكيل الموثوق المُهيَّأة.
تقييم كل بُعد
يُقيَّم كل بُعد مدعوم بواسطة محرك السياسات مقابل السياق.
تطبيق أسبقية القرار
تُحسَم القرارات حسب الأسبقية: تجاوز > حظر > سماح > رفض افتراضي.
الإغلاق الآمن عند الفشل
السياسة المُفعَّلة بلا قواعد ترفض — لا تسمح بصمت. إذا تعذر كتابة سجل تدقيق أمني لقرار سماح في بيئة الإنتاج، تُرفَض العملية.
تسجيل القرار
يُكتَب كل قرار في سجل تدقيق سياسة وصول جنائي، يظهر في سجلات النشاط.
الافتراضي هو الرفض. إلحاق سياسة مُفعَّلة لكن فارغة يحظر كل وصول إلى المورد حتى تتطابق قاعدة Include/Allow واحدة على الأقل مع المتصل. تحقق من سياسة من طرف إلى طرف قبل ربطها بمورد إنتاجي.
واجهة API لسياسات الوصول
تُنشَأ سياسات الوصول وتُسرَد وتُحدَّث وتُربَط بالموارد وتُدقَّق عبر وحدة تحكم Cockpit وواجهة إدارتها. تعرض الواجهة نفسها مصفوفة القدرات لكل نوع تطبيق والمجموعات المتاحة لقواعد المجموعة.
أمثلة على القواعد
تتجمع الأبعاد الخمسة للتعبير عن قواعد مثل:
- حظر دولة — رفض العمليات الصادرة من دولة معينة وفق ISO-3166.
- السماح لمستخدمين محددين فقط — السماح لمستخدمين محددين بالاسم (عبر البريد الإلكتروني أو UPN) واستثناء غيرهم.
- التقييد حسب عنوان IP والوقت — السماح فقط لشبكة فرعية معروفة، وفقط خلال نافذة يومية محددة (مثلاً من الاثنين 08:00 إلى 18:00).
- التقييد حسب مجموعة مزوّد الهوية — إلزام عضوية مجموعة IdP محددة.
تجميع كل ذلك
إنشاء السياسة
أنشئ السياسة لنوع التطبيق الصحيح بالقواعد المطلوبة — على سبيل المثال، السماح بالعمليات فقط من شبكة فرعية معروفة (بُعد IP) خلال ساعات العمل (بُعد الوقت).
ربطها بمورد
ألحقها بالهدف — خدمة DKE، أو تطبيق عام، أو نقطة نهاية AWS XKS.
الفرض والتدقيق
تُقيَّم كل عملية تشفير على ذلك المورد مقابل السياسة، ويُسجَّل كل قرار في مسار تدقيق سياسة الوصول.
تجمع السياسة المُحكَمة النموذجية بين قاعدة IP (فقط مضيفو العميل / الشبكة الفرعية المتوقعون) وقاعدة وقت (نافذة التشغيل أو الصيانة المسموح بها)، تاركة رمز الحامل للمصادقة والسياسة للتفويض. أضف قاعدة مستخدم أو مجموعة فوق ذلك عندما تكون هوية المتصل معروفة.