التحكم في الوصول RBAC و ABAC: النماذج التي يجب أن تعرفها

مقدمة#

التحكم في الوصول هو جانب حاسم من جوانب الأمان في أي نظام. فهو يضمن أن المستخدمين المصرح لهم فقط يمكنهم الوصول إلى الموارد وأداء الإجراءات. التحكم في الوصول المستند إلى الدور (RBAC) والتحكم في الوصول المستند إلى السمات (ABAC) هما اثنان من أكثر نماذج التحكم في الوصول شهرة المستخدمة في الأنظمة الحديثة. يتم تبني كلا النموذجين على نطاق واسع ويمكن استخدامهما لتطبيق سياسات التحكم في الوصول بشكل فعال. لكن ما هي وكيف تختلف؟

التحكم في الوصول المستند إلى الدور (RBAC)#

تم تقديم التحكم في الوصول المستند إلى الدور (RBAC) لأول مرة في أوائل التسعينيات. يعود الفضل في رسم هذا النموذج إلى ديفيد فيرييولو وريك كوهن في ورقة نُشرت في عام 1992. منذ ذلك الحين، أصبح RBAC واحدًا من أكثر نماذج التحكم في الوصول المستخدمة على نطاق واسع في الصناعة.

في RBAC، تستند سياسات التحكم في الوصول إلى الأدوار، وهي مجموعات من الأذونات. يُعيَّن للمستخدمين أدوار (مثل المدير، المحرر، المشاهد)، وتُحدد حقوق وصولهم بالأذونات (مثل الإنشاء، التعديل، الحذف) للموارد المحددة (مثل الملفات، قواعد البيانات، التطبيقات). يبسط إدارة سياسات التحكم في الوصول عن طريق تجميع المستخدمين بناءً على أدوارهم وتعيين الأذونات لها. من السهل إضافة أو إزالة المستخدمين من الأدوار، وستنعكس التغييرات تلقائيًا في سياسات التحكم في الوصول.

المكونات الرئيسية لـ RBAC#

• المورد: المورد هو كيان يمكن للمستخدم الوصول إليه. يمكن أن تكون الموارد أي شيء من الملفات، قواعد البيانات، واجهات برمجة التطبيقات، أو أي كيان آخر في النظام يحتاج إلى الحماية.
• الإذن: الإذن هو إجراء معين يمكن للمستخدم تنفيذه على المورد. على سبيل المثال، الإنشاء، التعديل، الحذف، العرض. قد يختلف تعريف الأذونات اعتمادًا على النظام. في معظم الحالات، تُعرَّف الأذونات عند مستوى المورد مع الحد الأدنى من التفاصيل.
• الدور: الدور هو مجموعة من الأذونات التي تحدد مجموعة من الإجراءات التي يمكن للمستخدم تنفيذها. على سبيل المثال، قد يتمتع دور المدير بأذونات لإنشاء وتعديل وحذف الموارد، بينما قد يتمتع دور المشاهد بالإذن لعرض الموارد.
• المستخدم: المستخدم هو كيان يمكن تعيين دور أو أكثر له. يُمنح المستخدمون حق الوصول إلى الموارد بناءً على الأذونات المرتبطة بالأدوار التي تم تعيينهم لها.

أنواع RBAC#

هناك العديد من أنواع RBAC التي تمدد النموذج الأساسي لاستيعاب متطلبات التحكم في الوصول الأكثر تعقيدًا:

• RBAC0: النموذج الأساسي حيث يتم تعيين المستخدمين للأدوار وتُعيَّن الأذونات للأدوار.
• RBAC1: يضيف مفهوم الهياكل الهرمية للأدوار. يمكن للأدوار أن ترث الأذونات من أدوار أخرى. يُعرف أيضًا بـ RBAC الهرمي.
• RBAC2: يضيف تقييدات على الأدوار. يمكن استخدام التقييدات لتعريف ظروف إضافية يجب استيفاؤها لكي يتم تعيين المستخدم لدور. يُعرف أيضًا بـ RBAC المستند إلى القيود.
• RBAC3: يجمع ميزات RBAC1 و RBAC2. يدعم كل من الهياكل الهرمية للأدوار والتقييدات.

لمزيد من المعلومات حول هذه الأنواع، الرجاء الرجوع إلى نماذج RBAC وتطورها.

مزايا RBAC#

• البساطة: RBAC سهل الفهم والتنفيذ. تعيين الأذونات للأدوار والأدوار للمستخدمين أمر مباشر.
• الكفاءة: يبسط إدارة سياسات التحكم في الوصول عن طريق تجميع المستخدمين بناءً على أدوارهم. من السهل إضافة أو إزالة المستخدمين من الأدوار دون تغيير سياسات التحكم في الوصول. خاصة في المنظمات الكبيرة ذات الهياكل الإذن المحددة، يمكن أن يكون RBAC فعالًا جدًا.
• الشفافية: يوفر RBAC خريطة واضحة بين الأدوار والأذونات والمستخدمين. من السهل تدقيق ومراجعة سياسات التحكم في الوصول.

عيوب RBAC#

• الصلابة: يمكن أن يكون RBAC صلبًا عندما يتعلق الأمر بتعريف سياسات التحكم في الوصول المعقدة. قد لا يكون مناسبًا للأنظمة التي تحتاج سياسات التحكم في الوصول فيها إلى أن تكون أكثر ديناميكية وتعتمد على السياق.
• الدقة: قد يفتقر RBAC إلى الدقة اللازمة للتحكم في الوصول بدقة عالية. ترتبط سياسات التحكم في الوصول بأدوار محددة جيدًا، وقد يتطلب الأمر جهدًا إضافيًا لتحديد الأذونات بمستوى أكثر دقة.
• انفجار الأدوار: في المنظمات الكبيرة ذات هياكل الإذن المعقدة، يمكن أن يتزايد عدد الأدوار على نحو متسارع، مما يؤدي إلى انفجار الأدوار. يمكن أن يكون إدارة عدد كبير من الأدوار تحديًا.

التحكم في الوصول المستند إلى السمات (ABAC)#

في أواخر العقد الأول من القرن الحادي والعشرين، ومع تعقيد الأنظمة وزيادة ديناميكيتها، بدأت المزيد والمزيد من المنظمات في اعتماد التحكم في الوصول المستند إلى السمات (ABAC) كبديل لـ RBAC. يعد نشر الإصدار الخاص من معهد NIST 800-162 في عام 2014 علامة بارزة في إضفاء الطابع الرسمي على ABAC.

ABAC هو نموذج للتحكم في الوصول أكثر مرونة مقارنةً بـ RBAC. إنه نموذج تفويض يحدد سياسات التحكم في الوصول بناءً على سمات المستخدم والمورد والإجراء والبيئة. يسمح للمنظمات بتحديد سياسات التحكم في الوصول بدقة عالية يمكنها التكيف مع السياقات والظروف المختلفة.

المكونات الرئيسية لـ ABAC#

• الموضوع: الموضوع هو كيان يطلب الوصول إلى المورد. يمكن أن يكون مستخدمًا، جهازًا، تطبيقًا، أو أي كيان آخر يحتاج إلى الوصول إلى الموارد.
• المورد: كما هو الحال في RBAC، المورد هو كيان يمكن أن يصل إليه الموضوع. يمكن أن تكون الموارد ملفات، قواعد بيانات، واجهات برمجة التطبيقات، أو أي كيان آخر في النظام.
• الإجراء: الإجراء هو عملية معينة يمكن للموضوع تنفيذها على المورد. يمكن أن يكون إنشاء، قراءة، تحديث، حذف، أو أي عملية أخرى تحتاج إلى التحكم.
• البيئة: البيئة هي السياق الذي تُقدَّم فيه طلب الوصول. يمكن أن تشمل السمات مثل الوقت من اليوم، الموقع، الشبكة، الجهاز، إلخ.
• السمة: السمة هي صفة لموضوع، مورد، إجراء، أو بيئة. يمكن أن تكون السمات أي شيء من أدوار المستخدمين، القسم، الموقع، عنوان IP، نوع الجهاز، إلخ.
• السياسة: السياسة هي قاعدة تحدد الظروف التي يتم فيها منح الوصول أو رفضه. يتم تعريف السياسdات بناءً على السمات.

مزايا ABAC#

• المرونة: يمكن لـ ABAC استيعاب سياسات التحكم في الوصول المعقدة التي تستند إلى سمات متعددة. يسمح للمنظمات بتحديد السياسات بدقة عالية يمكنها التكيف مع السياقات والظروف المختلفة.
• ديناميكية: يمكن أن تكون سياسات ABAC ديناميكية وتعتمد على السياق. يمكن اتخاذ قرارات التحكم في الوصول بناءً على السمات في الوقت الحقيقي مثل الموقع، الوقت من اليوم، نوع الجهاز، إلخ.
• الدقة: يوفر ABAC تحكمًا دقيقًا في الوصول من خلال السماح للمنظمات بتحديد السياسات بناءً على سمات متعددة. على عكس تحديد الأدوار والأذونات، يمكن أن تكون السياسات المستندة إلى السمات أكثر دقة.

عيوب ABAC#

• التعقيد: يمكن أن يكون ABAC أكثر تعقيدًا في التنفيذ والإدارة مقارنةً بـ RBAC. قد يتطلب تعريف السمات والسياسات مزيدًا من الجهد والخبرة. على عكس RBAC، حيث تكون الأدوار والأذونات مهيكلة جيدًا، قد تكون السمات أكثر ديناميكية وكذلك السياسات. قد يكون من الصعب إدارة عدد كبير من السمات والسياسات في نظام معقد. غالبًا ما يلزم محرك مركزي لتقيم السياسات لتقييم السياسات.
• الأداء: يمكن أن يؤثر تقييم السمات على الأداء، خاصةً في البيئات التي تتطلب استجابة في الوقت الحقيقي. يمكن أن تؤدي السياسات المستندة إلى سمات متعددة وشروط الوقت الحقيقي إلى زيادة التأخير في قرارات التحكم في الوصول.

جدول المقارنة#

من جدول المقارنة، يتضح أن RBAC أفضل للأنظمة ذات هياكل الأذونات المحددة جيدًا والسياسات التي تكون ثابتة نسبيًا. من ناحية أخرى، ABAC هو الأنسب للأنظمة حيث تحتاج سياسات التحكم في الوصول إلى أن تكون ديناميكية، مستندة إلى السياق، وتحتاج إلى دقة عالية.

أمثلة#

السيناريو: نظام مستشفى يحتاج إلى إدارة الوصول إلى سجلات المرضى لأعضاء طاقم العمل المختلفين.

• الطاقم: الأطباء، الممرضات، المديرين
• الموارد: سجلات المرضى
• الأذونات: قراءة، كتابة، حذف

الحالة 1#

سياسات التحكم في الوصول بسيطة نسبيًا:

1. يمكن للأطباء قراءة وكتابة سجلات المرضى.
2. يمكن للممرضات قراءة سجلات المرضى.
3. يمكن للمديرين قراءة وكتابة وحذف سجلات المرضى.

نموذج RBAC#

في هذه الحالة، يكون RBAC بسيطًا وفعالًا. يمكننا تعريف أدوار للأطباء والممرضات والمديرين، وتعيين الأذونات المناسبة لكل دور.

تقييم التحكم في الوصول مباشرة:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

نموذج ABAC#

في هذه الحالة، قد يكون ABAC مبالغًا فيه، لكن لا يزال يمكن استخدامه لتعريف سياسات دقيقة استنادًا إلى السمات مثل القسم، الدور، إلخ.

السمات:

• user.role: doctor, nurse, admin
• resource.name: patient-record
• action: read, write, delete

السياسات:

• السياسة 1: السماح بالوصول لقراءة المستندات بناءً على user.role و resource.name
  • subject: مستخدم بدور doctor, nurse, admin
  • resource: مورد باسم patient-record
  • action: read
  • effect: السماح
  • rationale: "السماح بوصول لقراءة سجلات المرضى لجميع الأدوار"
• السياسة 2: الوصول للتعديل للأطباء والمديرين
  • subject: مستخدم بدور doctor, admin
  • resource: مورد باسم patient-record
  • action: write
  • effect: السماح
  • rationale: "السماح بوصول للتعديل لسجلات المرضى للأطباء والمديرين"
• السياسة 3: الوصول للحذف للمديرين
  • subject: مستخدم بدور admin
  • resource: مورد باسم patient-record
  • action: delete
  • effect: السماح
  • rationale: "السماح بوصول للحذف لسجلات المرضى للمديرين"

بالنسبة لكل طلب قراءة/كتابة/حذف، يقيم محرك السياسة جميع السياسات ذات الصلة بناءً على السمات ويتخذ قرار التحكم في الوصول.

المقارنة#

في هذه الحالة، سياسات التحكم في الوصول بسيطة ومهيكلة جيدًا. يتطلب فحص إذن بمستوى واحد لتحديد ما إذا كان لدى المستخدم حق الوصول إلى مورد.

• في نموذج RBAC، ستبقى عملية تقييم التحكم في الوصول لمورد سجلات المرضى بسيطة ومباشرة، سواء كان لدى المستخدم إذن read, write, أو delete;
• بينما يحتاج ABAC إلى تضمين سمات إضافية مثل department-id و doctor-id. ماذا لو كان هناك جهاز إنترنت الأشياء يحتاج إلى الوصول إلى سجلات المرضى؟ سيتطلب إدخال سمة جديدة device-id في تقييم السياسة. كيف سيتم منح إذن read مؤقت لطبيب متدرب؟

في الخلاصة، RBAC هو الاختيار الأنسب. RBAC بسيط وفعال للأنظمة ذات هياكل الأذونات المحددة جيدًا حيث تكون سياسات التحكم في الوصول ثابتة.

الحالة 2#

نفس نظام المستشفى، الآن دعنا نقدم دورًا جديدًا patient وسمة جديدة patient-id.

سياسات التحكم في الوصول هي:

1. يمكن للأطباء قراءة وكتابة سجلات المرضى.
2. يمكن للممرضات قراءة سجلات المرضى.
3. يمكن للمديرين قراءة وكتابة وحذف سجلات المرضى.
4. يمكن للمرضى قراءة سجلاتهم الخاصة.

نموذج RBAC#

في هذه الحالة، بالإضافة إلى إذن read القديم، نحتاج إلى إدخال إذن جديد read-own. يمكننا تعريف أدوار للأطباء والممرضات والمديرين والمرضى، وتعيين الأذونات المناسبة لكل دور.

الآن أصبحت عملية تقييم التحكم في الوصول أكثر تعقيدًا بعض الشيء، خاصة لإجراء read سجلات المرضى:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

نموذج ABAC#

الآن دعونا نحدث السمات والسياسات في نموذج ABAC لتلائم المتطلبات الجديدة.

السمات:

• user.role: doctor, nurse, admin, patient
• user.id: patient-id
• resource.name: patient-record
• resource.patient-id: patient-id
• action: read, write, delete

السياسات:

• السياسة 1: السماح بالوصول لقراءة جميع سجلات المرضى
  • subject: مستخدم بدور doctor, nurse, admin
  • resource: مورد باسم patient-record
  • action: read
  • effect: السماح
  • rationale: "السماح بوصول لقراءة سجلات المرضى لجميع الأدوار والمرضى أنفسهم"
• السياسة 2: السماح بالوصول للتعديل لجميع سجلات المرضى للأطباء والمديرين
  • subject: مستخدم بدور doctor, admin
  • resource: مورد باسم patient-record
  • action: write
  • effect: السماح
  • rationale: "السماح بوصول للتعديل لسجلات المرضى للأطباء والمديرين"
• السياسة 3: السماح بالوصول للحذف لجميع سجلات المرضى للمديرين
  • subject: مستخدم بدور admin
  • resource: مورد باسم patient-record
  • action: delete
  • effect: السماح
  • rationale: "السماح بوصول للحذف لسجلات المرضى للمديرين"
• السياسة 4: السماح بالوصول لقراءة سجلات المرضى الخاصة
  • subject: مستخدم بدور patient
  • resource: مورد باسم patient-record
  • action: read
  • condition: user.id === resource.patient-id
  • effect: السماح
  • rationale: "السماح بالوصول لقراءة سجلات المرضى الخاصة"

المقارنة#

في هذه الحالة، سياسات التحكم في الوصول أكثر تعقيدًا وتعتمد على السياق. ستتطلب عملية تقييم التحكم في الوصول لمورد سجلات المرضى مستويات متعددة من فحص الأذونات لتحديد ما إذا كان لدى المستخدم حق الوصول إلى المورد.

• في نموذج RBAC، ستحتاج عملية تقييم التحكم في الوصول لمورد سجلات المرضى إلى مستويات متعددة من فحص الأذونات لتحديد ما إذا كان لدى المستخدم حق الوصول إلى المورد. على سبيل المثال، لتحديد ما إذا كان لدى المريض حق الوصول إلى سجلاته الخاصة، سيحتاج النظام لتفقد ما إذا كان لدى المستخدم إذن read-own وإذا كان معرف المستخدم يتوافق مع معرف المريض.
• في نموذج ABAC، يمكن أن تكون عملية تقييم التحكم في الوصول أكثر مباشرة. يمكن تعريف السياسات بناءً على سمات المستخدم، المورد، والإجراء. على سبيل المثال، لتحديد ما إذا كان لدى المريض حق الوصول إلى سجلاته الخاصة، يمكن لمحرك السياسة تقييم السياسة بناءً على معرف المستخدم ومعرف المريض.

في هذه الحالة، قد يكون ABAC مناسبة أفضل. ABAC أكثر ملاءمة للأنظمة التي تحتاج إليها سياسات التحكم في الوصول أن تكون ديناميكية، تعتمد على السياق، وتحتاج إلى دقة عالية.

الخلاصة#

يعتمد الاختيار بين RBAC و ABAC على المتطلبات الخاصة بالنظام. RBAC هو الأنسب للأنظمة ذات هياكل الأذونات المحددة جيدًا حيث تكون سياسات التحكم في الوصول ثابتة. ABAC هو الأنسب للأنظمة حيث تحتاج سياسات التحكم في الوصول أن تكون ديناميكية، تعتمد على السياق، وتحتاج إلى دقة عالية. في الممارسة العملية، قد تختار المنظمات استخدام مزيج من كلا النموذجين لتحقيق المستوى المطلوب من التحكم في الوصول.