محرك الأدوار

1) نماذج الترخيص

RBAC (التحكم في الوصول القائم على الأدوار): يتلقى الموضوع أدوارًا، وترتبط الأدوار بالأذونات. فقط أدير، جيد للواجبات النموذجية.
ABAC (التحكم في الوصول القائم على السمات) - يعتمد الحل على سمات الموضوع والموارد والعمل والبيئة (الوقت، الملكية الفكرية، المنطقة، المخاطر). مرنة وقابلة للتطوير إلى قواعد معقدة.
RBAC + ABAC الهجين: الأدوار تعطي قدرة «أساسية»، السمات تضيقها (الظروف).
(اختياري) ReBAC/Relationship-based: relationship graph (المالك، عضو الفريق، المندوب)، مفيد للوثائق والمواد.

2) الهندسة المعمارية: PDP/PEP والتدفقات

PEP (نقطة إنفاذ السياسة): حيث يتم تطبيق الحل (بوابة API، طريقة الخلفية، طبقة SQL، واجهة المستخدم).
PDP (نقطة قرار السياسة): الخدمة/المكتبة التي تحسب «السماح/DENY» حسب السياسات والسمات.
PIP (نقطة معلومات السياسات): مصادر السمات (IdP/profile، البيانات الوصفية للموارد، معدل المخاطر، geo).
PAP (نقطة إدارة السياسات) - الوصلة البينية الإدارية/مستودع السياسات (النسخ والمشاريع والمنشورات).

التدفق: يشكل طلب → PEP سياقًا → يقوم PDP بسحب السمات المفقودة (عبر PIP) → يحسب القرار → يطبقه PEP (حقول التمكين/التعطيل/القطع) → التدقيق.

3) نموذج البيانات

• "subject' (المستخدم/الخدمة) с атрибутами:" المستأجر _ id "،" الأدوار "،" الإدارات "،" المخاطر _ المستوى "،" mfa _ تم التحقق منها "،" النطاقات "،" المطالبات ".
• «المصدر» مع النوع والسمات: «نوع»، «مالك _ معرف»، «مستأجر _ معرف»، «تصنيف» (عام/سري)، «منطقة»، «علامات».
• «إجراء»: «قراءة»، «كتابة»، «حذف»، «تصدير»، «موافقة»، «انتحال شخصية» и т. п.
• «البيئة»: «الوقت»، «ip»، «الجهاز»، «geo»، «auth _ strength»، «الأعمال التجارية _ السياق» (канал، тариф).

• «رولز (هوية، tenant_id، اسم، ورث [])» - دعم التسلسلات الهرمية والأنماط.
• «permissions (id، resource_type، action، construction ؟)».
• «role _ permissions (role_id, permission_id)».
• «الإشارات (subject_id، role_id، النطاق)» - النطاق: عالمي/حسب المشروع/حسب الكائن.

• "سياسة (معرف، تأثير = السماح" deny، الهدف: {موضوع، مورد، عمل}، الشرط: expr، الأولوية، النسخة، الحالة) ".

4) مبادئ صنع القرار

تجاوزات الرفض: الحظر الصريح يعطي الأولوية للأذونات.
أقل امتياز (PoLP): إصدار الحد الأدنى من الوصول المطلوب، والتوسع من خلال الظروف.
الفصل بين الواجبات (SoD): حظر الجمع بين الأدوار/الإجراءات (على سبيل المثال، «خلق الدفع» ≠ «القبض»).
إدراك السياق: تعزيز المتطلبات المعرضة لخطر أكبر (لا يوجد ملكية فرعية مشبوهة).
الحتمية: نفس السياق → نفس الرد ؛ سجل نسخة بوليصة.

5) أنماط التنفيذ

5. 1 RBAC→ABAC هجين (تكييف)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 صف/مستوى الأمن الميداني

على مستوى قاعدة البيانات: سياسات RLS (بواسطة 'المستأجر _ id' و 'المالك _ id').
على مستوى واجهة برمجة التطبيقات: قم بتصفية مجموعات وحقول الأقنعة إذا لم يكن هناك "allow: read_sensitive_fields'.

5. 3 حلول تصعيد

allow if action == "export" and subject. mfa_verified == true else deny

5. 4 تحملات مؤقتة

المنح مع TTL: "مهمة. expires_at'، الوصول إلى «النوافذ» (خلال ساعات العمل في منطقة الموارد).

6) الأداء والتخزين المؤقت

مخبأ القرار حسب المفتاح «(subject_hash، resource_key، العمل، policy_version)» مع TTL قصير.
Edge cache of their categories (claims in the token) + سمات الموارد الكسولة.
الإبطال التدريجي: الإعاقة حسب الأحداث (تغيير الأدوار، تغيير السياسات، تحويل الموارد إلى «سرية»).
عمليات التحقق من الدفعة: بالنسبة للقوائم - قم بالتقييم باستخدام «مرشح» (سياسة التنبؤ بالضغط) حتى لا تسحب PDP سطرًا بسطر.

7) مستأجر متعدد

في كل جدول - 'مستأجر - هوية' ؛ السياسات الافتراضية تقيد الوصول داخل عقد الإيجار.
يدير مديرو الإيجار أدوار/حقوق عقد الإيجار فقط.
الوصول عبر عقود الإيجار - حصريًا من خلال الدعوات/المشاركة الصريحة مع رفض صريح.

8) إدارة السياسات ودورة الحياة

الإصدار: "السياسة. في رد PDP، تخزين في التدقيق.
البيئات: مشروع الكناري → (أجزاء من المرور/وضع الظل) → حث.
مصفوفة الاختبار: جداول الحقيقة حسب الأدوار/الصفات الرئيسية (اختبارات العقد).
إدارة التغيير: دمج طلبات السياسات مع استعراضات الأمن/الامتثال.

9) مراجعة الحسابات وقابلية الملاحظة

Журнал решений: 'القرار _ id'، 'الموضوع'، 'العمل'، 'الموارد _ المرجع'، 'النتيجة'، 'مطابقة _ السياسات'، 'السياسة _ النسخة'، 'السمات _ الهضم'.
المقاييس: QPS PDP، زمن الوصول p95، مخبأ معدل الضرب، رفض الحصة، معدل التصعيد، حوادث SoD.
الآثار: امتداد لكل مكالمة PDP ؛ الارتباط مع طلب API.
إعادة التشغيل: القدرة على «إعادة» القرارات التاريخية بشأن الإصدار الجديد من السياسة (فحص السلامة).

10) التكامل مع المصادقة والرموز

الهوية - من IdP (OIDC/SAML). تحمل الرموز حدًا أدنى من السمات: «sub» و «المستأجر» و «الأدوار» و «auth _ time» و «amr» و «scopes».
بالنسبة لـ ABAC، اسحب العلامات «الثقيلة» من جانب الخادم (PIP) حتى لا تضخم الرمز.
الرموز المرجعية الموقعة (القدرة/الدعوات) - للوفود المحدودة للغاية.

11) رمز PDP الزائف (مبسط)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) الأنماط المضادة

«Role = page» (مئات الأدوار الصغيرة بدون نموذج نطاق).
تخزين السياسات فقط في رمز بدون إصدارات/عمليات تدقيق.
أدى عدم تجاوز الرفض و SoD → زيادة مخاطر الاحتيال.
يسرد «المستخدم _ المعرف» في القواعد (بدلاً من السمات/العلاقات).
لا يوجد تصفية طبقة بيانات (RLS) مع مرشح واجهة المستخدم فقط.
تزامن الأدوار من خلال نصوص يدوية بدون أحداث وإعاقة مخبأة.

13) الحالات والوصفات

13. 1 إخفاء على المستوى الميداني:

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 بيانات التصدير مع وزارة الخارجية فقط:

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. وفد 4 (رمز مقيّد):

يحتوي رمز القدرة على "resource _ id" و "actions = [" read'] "و" expires _ at' و "aud'. تتحقق PEP من التوقيع والموعد النهائي.

14) الاختبار

اختبارات الوحدات للسياسات: جداول الحقيقة حسب المجموعات الرئيسية.
قائم على الملكية: توليد سمات عشوائية للعثور على «ثقوب».
الاختبارات الذهبية: إصلاح مجموعة من الحلول لنقاط النهاية الحرجة.
Canary/Shadow: تقييم مواز للنسخ القديمة والجديدة من السياسات مع تسجيل التناقضات.

15) القدرات ذات الصلة في قسم «الهندسة المعمارية والبروتوكولات»

التوثيق والإذن (OIDC/OAuth2)

إدارة الموافقة

الترميز وإدارة المفاتيح

إمكانية الرصد: السجلات والمقاييس والآثار

التوجيه الجغرافي والتوطين

في الراحة/التشفير العابر

16) قائمة مراجعة المهندس المعماري

1. هل يتم تحديد أدوار الموضوعات وتسلسلها الهرمي ؟

2. هل هناك نموذج هجين: أدوار + شروط على السمات ؟

3. نفذت PDP مع تجاوزات الرفض، SoD والتصعيد ؟

4. أين هو PEP ؟ (بوابة، خلفية، قاعدة بيانات، واجهة مستخدم) - هل هي موحدة في كل مكان ؟

5. هل مخابئ الحلول وإعاقة الحدث مهيأة ؟

6. هل السياسات يتم تحريرها واختبارها وطرحها عن طريق العملية ؟

7. هل قرارات التدقيق والمقاييس والآثار ممكنة ؟

8. دعم عقود الإيجار المتعددة و RLS/الإخفاء الميداني ؟

9. هل لديك كتيب عن الحوادث وتراجع السياسة ؟

خامسا - الاستنتاج

يوفر RBAC إمكانية التحكم، ويوفر ABAC السياق والدقة. من خلال الجمع بين الأدوار وشروط السمة، ومشاركة PDP/PEP، وتنفيذ التخزين المؤقت، والتدقيق، واختبار السياسة، فإنك تبني التفويض كقدرة على النظام الأساسي: يمكن التنبؤ به، ويمكن التحقق منه، وقابل للتطوير للمنتج والمتطلبات التنظيمية.