أثناء عملي كمهندس معماري في مشاريع تنفيذ IdM ، قمت بتحليل عشرات تطبيقات آليات الترخيص سواء في الحلول الداخلية للشركات أو في المنتجات التجارية ، ويمكنني القول أنه في كل مكان تقريبًا مع متطلبات معقدة نسبيًا ، لم يتم تصنيعها بشكل صحيح أو ، على الأقل ، وليس بالشكل الأمثل. السبب ، في رأيي ، هو قلة اهتمام كل من العملاء والمطورين بهذا الجانب في المراحل الأولية والتقييم غير الكافي لتأثير المتطلبات. هذا يؤكد بشكل غير مباشر إساءة استخدام المصطلح على نطاق واسع: عندما أرى عبارة "ترخيص عاملين" ، بدأت أشعر بالألم أسفل ظهري. من أجل الاهتمام ، قمنا بتحليل أول 100 مقالة عن Habré في نتائج البحث عن "إذن" ، وكانت النتيجة مخيبة للآمال ، كان هناك الكثير من الألم:
في أكثر من 80 ٪ من الحالات ، يتم استخدام المصطلح بشكل غير صحيح ، يجب استخدام كلمة "المصادقة" بدلاً من ذلك. بعد ذلك ، سأحاول شرح ماهية ذلك ولماذا من الأهمية بمكان إيلاء اهتمام خاص لهذا الموضوع.
ما هذا؟
على حد تعبير ويكيبيديا:
من وجهة نظر أي نظام معلومات ، هذه هي عملية صنع القرار بشأن توفير الوصول إلى الموضوع لأداء العملية بناءً على أي معرفة بالموضوع. في هذه المرحلة ، ينبغي بالفعل
تحديد الموضوع ، كقاعدة عامة (نحتاج إلى معرفة من هو)
والمصادقة عليه (تأكيد هويته).
يعد تنفيذ التفويض في تطوير نظام معلومات أو منتج للشركة يركز على قطاع الشركات مهمة بالغة الصعوبة والمسؤولية ، والتي غالباً ما لا تحظى باهتمام كافٍ في مرحلة التصميم ومرحلة التطوير الأولية ، مما يؤدي في المستقبل إلى تنفيذ "عكاز".
مشاكل
دعونا نرى ما هي متطلبات الترخيص التي تم الوفاء بها ، ولماذا من الأهمية بمكان النظر فيها في البداية عند تصميم نظام ، وليس تأجيله للمستقبل. عادة ما يكون هناك مصدران لمتطلبات الترخيص في نظام معلومات الشركة - وهما أمن المعلومات والأعمال. بشكل عام ، تريد الشركة الحفاظ على سرية الأسرار وتوفير الصلاحية للمستخدمين وفقًا لوظائفهم في عملية الأعمال ، ويريد الأمن ضمان الحد الأدنى من كفاية السلطة لكل مستخدم والوصول إلى التدقيق.
خذ على سبيل المثال ، نظامًا افتراضيًا للتفاوض على عقود الشركات الكبيرة ، وهي مؤسسة دموية نموذجية.
سوف تنشأ
متطلبات ترخيص الأعمال التالية على الأرجح:
- المستخدم الذي لا يرتبط بعقد معين يجب ألا يراه في النظام
- يجب أن يراها صاحب العقد في جميع المراحل.
- يحق للمستخدم الذي لديه درجة لا تقل عن 10 الحق في إنشاء عقد.
- يجب على الزائر رؤية العقد ، بدءًا من استلامه في المرحلة وما بعدها.
- يجب على رؤساء الإدارات رؤية عقود وحداتهم في التسلسل الهرمي.
- يحق لصاحب العقد ورئيس الوحدة سحب العقد في أي مرحلة من مراحل الموافقة.
- يجب على إدارة وأمانة المكتب الرئيسي الاطلاع على الوثائق الخاصة بجميع الفروع.
- يجب ألا يكون للمستخدم الذي أنشأ العقد الحق في المصادقة عليه.
من الأمان ، يمكننا الحصول على المتطلبات التالية :
- معرفة من لديه حق الوصول إلى عقد محدد.
- معرفة من كان لديه حق الوصول إلى عقد محدد في وقت معين.
- لحرمان المستخدم من الوصول إلى المستندات المتاحة مسبقًا عند تغيير واجبات وظيفته.
أعتقد أن المطورين كانوا خائفين بالفعل :). ألم إضافي هو التباين العالي لهذه المتطلبات. بالمناسبة ، وفقًا لإحصائيات امتياز 1C الكبير ، تعد متطلبات الترخيص الإضافية واحدة من أكثر المهام شيوعًا لتخصيص التكوينات النموذجية.
لذلك ، نشير إلى سبب كون هذه المتطلبات إشكالية:
- أنها ليست مستقرة. احتمال تغيرهم ، حتى في المدى القصير ، يميل إلى 1.
- فهي شاملة. يؤثر تنفيذها على جميع الطبقات ، من تصميم قاعدة البيانات إلى واجهة المستخدم.
- إنهم يكذبون في الطائرة الخاصة بالموضوع. يؤدي ذلك إلى اتصال قوي بآلية التفويض بطبقة من منطق الأعمال.
- أنها تؤثر على الأداء.
طرق الحل
تساعدنا نماذج التحكم في الوصول المتقدمة في حل هذه المشكلة:
MAC هو نموذج للتحكم في الوصول إلى بيانات الاعتماد. يتم تحديد وصول الشخص إلى الكائن حسب مستوى وصوله: يجب ألا يكون مستوى وصول الشخص أقل من مستوى سرية الكائن.
لجنة المساعدة الإنمائية - التحكم في الوصول المباشر. يتم تحديد وصول الكائن إلى الكائن من خلال وجود الموضوع في قائمة الوصول
(ACL) للكائن.
RBAC هو نموذج التحكم في الوصول. يتم تحديد الوصول إلى الموضوع إلى الكائن من خلال وجود دور الموضوع الذي يحتوي على الصلاحيات المقابلة للوصول المطلوب.
ABAC هو نموذج سمة التحكم في الوصول. يتم تحديد وصول الكائن إلى الكائن ديناميكيًا استنادًا إلى تحليل السياسات التي تأخذ في الاعتبار قيم سمات الموضوع والكائن والبيئة. وهذا يشمل أيضًا
PBAC و RAdAC و CBAC ، مع بعض الفروق الدقيقة (
مراجعة أنيقة من CUSTIS ).
ينصح بشدة أن تستخدم في شكلها الأصلي دون إعادة اختراع العجلة. غالبًا ما يتم استخدام مزيج من النماذج في أنظمة المعلومات المعقدة. على سبيل المثال ، تكون مجموعة ACL + RBAC شائعة عند تضمين دور في قائمة وصول. ومع ذلك ، فإن الاستخدام الصحيح للنماذج الجاهزة ليس بالمهمة السهلة. لا يمكن للجميع اختيار النموذج المناسب ، وفصله عن منطق الأعمال وتحقيق الأداء المقبول لآلية التفويض.
لتنفيذ المتطلبات المذكورة أعلاه في قسم "المشكلات" ، للوهلة الأولى ، سأختار مجموعة PBAC + ACL. يمكن تنفيذ المتطلبات على النحو التالي:
يتم تنفيذ متطلبات IS المدرجة دون أي مشاكل في استخدام قوائم ACL ، لكننا نطبق متطلبات العمل 5 و 7 باستخدام PBAC. لتنفيذ متطلبات IS 1 و 2 ، سيتعين عليك إضافة مجلة أو آلية مماثلة إليها ، لأن القواعد الديناميكية لجمالها تخضع للمراجعة الضعيفة:
في المجموع
يعتبر الإذن موضوعًا مهملاً بشكل غير مستحق ، سواء في المنشورات أو مباشرة في عملية التطوير. المصادقة ثنائية العامل عبر الرسائل النصية القصيرة سيتم شدها إلى الموقع من قبل الطفل. إن تنفيذ التفويض بشكل صحيح في نظام الشركات دون عمل عكازات هو مهمة صعبة يكسرها اللوردات والمهندسون المعماريون ، والعديد من المنتجات التجارية الشعبية (على سبيل المثال ، Atlassian Jira) تقف على عكازين بسبب تعقيد المتطلبات.
نحن نخطط لسلسلة من المقالات حول نماذج الترخيص والموضوع ككل. نحن نرحب الأسئلة والاقتراحات حول المواضيع للنظر فيها.