أفضل نموذج لقاعدة بيانات التحكم في الوصول القائم على الدور (RBAC) [مغلق]

Question

ما هو أفضل مخطط لقاعدة البيانات لتتبع عناصر التحكم في الوصول المستندة إلى الأدوار لتطبيق ويب؟

أنا أستخدم Rails، لكن المكون الإضافي RBAC المرتبط بواسطة Google يبدو غير خاضع للصيانة (300 فقط ملتزم بـ SVN؛آخرها كان منذ عام تقريبًا).

هذا المفهوم بسيط بما فيه الكفاية للتنفيذ من الصفر، ولكنه معقد ومهم بما فيه الكفاية بحيث يستحق تنفيذه بشكل صحيح.

فكيف يقوم الآخرون بتصميم وتنفيذ نموذج RBAC الخاص بهم؟

Answer 1

وفقًا لمعرفتي الأساسية في هذا المجال، فإن الجهات الفاعلة الأساسية في RBAC هي:

• موارد.
• الأذونات.
• المستخدمين.
• الأدوار (أي.مجموعات).

موارد <- يتطلب -> (واحد أو أكثر) الأذونات.

الأدوار <- عبارة عن مجموعات من -> (واحد أو أكثر) الأذونات.

المستخدمين <- يمكن أن يكون -> (واحد أو أكثر) الأدوار.

الجداول لمثل هذا النموذج ستكون:

• إذن
• دور
• مستخدم
• role_permission
• دور المستخدم

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

Answer 2

وهنا هو رسم تخطيطي بسيط لتوضيح الإجابة عمرو مصطفى الممتازة

Answer 3

أنا أعمل على نظام RBAC الفرعي هنا في العمل في هذه اللحظة ...يالها من صدفة.

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

rule 14: guest role + page name + read permission
rule 46: approver role + add column + execute permission

وما إلى ذلك وهلم جرا.سأترك ERD كتمرين للقارئ؛-) إذا كانت لديك أسئلة، اترك تعليقًا.

يوفال = 8-)

Answer 4

ويمكنك استخدام مريحة ACL القضبان المساعد .

Answer 5

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

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

كما ترغب أيضًا في إبقاء الأمور بسيطة؛اقتراحي سيكون؛

• يجب أن يكون أي كائن بسبب قيود rbac مستمدًا من كيان أساسي.
• يجب أن تكون هناك قائمة بالأدوار التي ترتبط بشكل فردي مع الكيان.
• يجب أن تكون هناك قائمة بالعلاقات بين المستخدمين والأدوار.

ولأخذ الأمور خطوة أخرى إلى الأمام، أود أيضًا أن أوصي بما يلي (بالنسبة لـ RAC الآلي)

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

لكن للأسف، هذا متاح فقط لـ .NET، وبقدر ما أعرف لا تحتوي Java على سمات مخصصة، لذا فمن غير المحتمل أن تكون متاحة لـ Java بعد.

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

Answer 6

متطلبات دور يعمل مع مصادقة مريحة بشكل جيد للغاية لتوفير وظائف المصادقة المستندة إلى دور و والواقعات.

Answer 7

لتطبيقات .NET يجب أن ننظر في شيء من هذا القبيل البصرية الحرس HTTP: //www.visual-guard. كوم / لتجنب الاضطرار إلى التعامل مع الأذونات والأدوار من الصفر.

وأيضا لصافي، لديك موفري العضوية ودور وتفويض التعامل مع التكوين. http://www.odetocode.com/Articles/427.aspx

Answer 8

يحاول https://github.com/ThoughtWorksStudios/piece, ، إنه محرك قاعدة لإدارة التحكم في الوصول بناءً على دور المستخدم:

1. تحديد قواعد التحكم في الوصول
2. الجمع بين القواعد لبناء قواعد جديدة

يمكنك العثور على مثال كامل لتطبيق Rails هنا: https://github.com/xli/piece-blog

Answer 9

مقدمة إلى RBAC -

نظام التحكم في الوصول القائم على الدور هو وسيلة لتقييد الوصول إلى "بعض المصادر أو التطبيقات أو بعض ميزات التطبيقات" بناءً على أدوار مستخدمي المؤسسة.

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

وإذا تعمقنا قليلاً في RBAC، فهو يحتوي بشكل أساسي على 3 ميزات.

1) المصادقة - تؤكد هوية المستخدم.عادةً ما يتم ذلك عبر حسابات المستخدمين وكلمات المرور أو بيانات الاعتماد.

2) التفويض - يحدد ما يمكن للمستخدم فعله وما لا يمكنه فعله في التطبيق.السابق."تعديل الطلب" مسموح به ولكن "إنشاء طلب جديد" غير مسموح به.

3) تدقيق إجراءات المستخدم على التطبيقات.- يتتبع تصرفات المستخدم على التطبيقات، وكذلك من منح حق الوصول إلى أي مستخدم؟

كانت هذه صورة عرض علوية أساسية جدًا لنظام RBAC.

يمكن أن يحتوي الهيكل الأساسي لنظام RBAC على المكونات التالية:المستخدمون، الأدوار، الأذونات أو القيود، الموارد.

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

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

Answer 10

وأنا أحب هذا بلوق وظيفة: HTTPS: // المحتوى. pivotal.io/blog/access-control-permissions-in-rails

وتحرير:

ويبدو أن ryanb من railscasts يعتقد على نفس المنوال، وخلق جوهرة دعا كانكان HTTPS: // جيثب. كوم / ryanb / كانكان باستخدام تقنية أساسية مماثلة لpivotollabs نشر.