نموذج تفويض التحكم في الوصول (MAC): نظرة عامة وتطبيقات التطبيقات

نموذج التحكم في الوصول الإلزامي (MAC) - طريقة للتحكم في الوصول مع مجموعة ثابتة من الأذونات. عادةً ما يتم استخدام نظام MAC هذا في الأنظمة التي تتمتع بمتطلبات أمنية عالية وهو في خدمة وكالات ومؤسسات إنفاذ القانون المختلفة المرتبطة بأسرار الدولة أو الأسرار الرسمية.

نموذج ماك

غالبًا ما يتم ذكر MAC على الرغم من احتوائها في العديد من المقالات والمواد ، بشكل عرضي وفي شكل صلصة حارة لشيء مثل ذكر موجز لـ MLS في SELinux. نظرًا لأن الكثيرين يقيدون صداقتهم مع SELinux مع وصفة " كيفية تعطيل SELinux " ، فغالبًا ما يكرمها MAC كذلك. لذلك ، أولا لفترة وجيزة حول MAC.

إذا كنت معتادًا على النموذج ، يمكنك الانتقال إلى القسم التالي على الفور.

الفكرة الرئيسية

نموذج الأمان التجريدي المطبق في MAC الكلاسيكية (كما يعلم ضباط إنفاذ القانون) كما يلي (الصورة الكلاسيكية التي توضح نموذج Bell-Lapadula ):


نموذج MAC هو بطبيعته تطبيق "إلكتروني" لسير العمل "السري" الورقي. يحتوي MAC على "العناصر الفاعلة" التالية:

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

عادة ما تسمى قيمة مستوى الوصول للموضوع أو مستوى سرية الكائن المصطلح "مستوى الاعتماد" أو "تسمية الاعتماد" أو "التسمية" ببساطة (في STCSEC يسمى هذا المصطلح "مستوى التصنيف الهرمي"). بسيطة ، رحيب وغامضة تقريبا .

يتم إجراء تدقيق التخويل في كل حقيقة من وصول الموضوع إلى الكائن المحمي بواسطة MAC. في هذه الحالة ، يتم عادةً استخدام نموذج التحكم في الوصول إلى بيانات الاعتماد بالاقتران مع آليات التحكم في الوصول الأخرى ، على سبيل المثال ، DAC (نموذج UNIX و POSIX ACL). في هذه الحالة ، يتم فحص MAC آخر مرة. أولاً ، يتم التحقق من الوصول بواسطة DAC (باعتباره الأقل أمانًا) ، ثم عن طريق MAC.

عند التحقق من أهلية وصول الشخص المعني إلى الكائن وفقًا للنموذج الإلزامي ، تكون المجموعات التالية ممكنة:

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

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

القيود و الثغرات الأمنية

لدى MAC قيودها وميزاتها:

1. لا يمكن لمستخدمي النظام تحديد وصول الكائنات إلى الكائنات بشكل مستقل. من كامل ترسانة التحكم في الوصول إلى الكائنات في MAC ، لا يوجد سوى فئة بيانات اعتماد وفئة بيانات اعتماد مرتبطة بهذا الكائن. تتم إدارة الوصول إلى الموضوعات إلى الكائنات من قبل المسؤولين فقط.
2. إذا أراد المستخدم تغيير تسمية بيانات الاعتماد للكائن الذي هو مؤلفه ، فعليه الانتقال إلى جلسة التصنيف المستهدفة. هذا يرجع إلى حقيقة أنه لا يمكن للمستخدم تحديد التسمية في الإرادة ، ولكن يمكن فقط تمرير التسمية إلى الكائن "عن طريق الميراث". في الوقت نفسه ، لا يمكن للمستخدم العمل إلا في جلسة واحدة من تصنيف بيانات الاعتماد.
3. نظرًا لاستخدام MAC بالاقتران مع نماذج التحكم في الوصول الأخرى ، تنشأ الاصطدامات: في بعض الأحيان لا يكون من السهل للغاية معرفة "طبقة" الوصول إلى نظام الأمان مرفوضة. مطلوب "ضبط" رقيقة لجميع طبقات الحماية.
4. بالإضافة إلى إعدادات الوصول من خلال مجموعة أدوات MAC ، يلزم وجود سياسة أمان. يجب أن تصف ما تعنيه القيم المحددة لبيانات الاعتماد (هذا خارج MAC) ، ما هي الكائنات المحمية ، والموضوعات التي لها الحق في الوصول إليها. بدون تنظيم متفق عليه ، لن توفر MAC وحدها تعزيزًا أمنيًا.
5. استخدام MAC في بنية شبكة موزعة. الطريقة التقليدية لتكوين MAC هي محليًا ، يدويًا ، بمساعدة مسؤول وفقًا للتعليمات. هناك حلول تسمح لك بتنفيذ وحدة تخزين MAC مُدارة مركزياً (مثل ALD) ، ولكن لها خصائصها الخاصة وصعوبات البناء.

تصميم تطبيق MAC

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

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

إذن ما لدينا في المجموعة:

الآن ، دعونا ننظر في كيفية استخدام هذه البنية التحتية عند تطوير تطبيق للحفاظ على وظائف التحكم في الوصول على مستوى البنية التحتية.

لكي يستفيد التطبيق من آلية التسمية الإلزامية لنظام التشغيل ، يجب استيفاء الشروط التالية:

• يجب تسجيل مستخدمي التطبيق في مستودع مستخدمي نظام التشغيل. كحد أدنى ، يجب أن يكون هناك بعض المعرف الذي يسمح لك بتعيين مستخدم التطبيق بشكل فريد لمستخدم نظام التشغيل (عادة ما يكون هذا هو تسجيل الدخول).
• يجب تكوين مستخدمي التطبيق على مستوى آلية MAC لنظام التشغيل بأذونات بيانات اعتماد لأوراق اعتماد محددة (نطاقات الاعتماد).

من وجهة نظر تطبيق سطح المكتب ، سيناريو المستخدم كالتالي:

1. يدخل المستخدم إلى نظام التشغيل تحت الموجات فوق الصوتية الشخصية في وضع الملصق الذي يحتاجه. تطلق التطبيق. ترث عملية التطبيق تسمية الاعتماد.
2. يتفاعل التطبيق مع قاعدة البيانات على PostgreSQL ، حيث يعرض ، على سبيل المثال ، سجلات جداول قاعدة البيانات فقط مع ملصق الاعتماد الحالي.

من وجهة نظر تطبيق الخادم الذي يوفر خدمات الويب ، سيناريو المستخدم قريب من الناحية النظرية ، على الرغم من أنه يبدو أكثر تعقيدًا:

1. يدخل المستخدم إلى نظام التشغيل تحت الموجات فوق الصوتية الشخصية في وضع الملصق الذي يحتاجه. يطلق متصفحًا يدعم MAC ، في مثالنا ، Mozilla Firefox (لن يعمل متصفح "عادي" لهذه الأغراض). ترث عملية المستعرض بيانات الاعتماد.
2. يطلب المستخدم عنوان مورد التطبيق مع دعم بيانات الاعتماد. يقوم المستعرض بتكوين طلب بإضافة علامة اعتماد إليه.
3. تتم معالجة الطلب بواسطة خادم ويب مع دعم لبيانات الاعتماد ، في مثالنا ، خادم Apache Http. يقرأ خادم الويب (العملية التي تعمل في الحد الأدنى لوضع الاعتماد) تسمية بيانات الاعتماد للطلب ، ويجد تطبيق المعالج ويبدأ عمليته بتمرير علامة الاعتماد.
4. يتفاعل التطبيق مع قاعدة بيانات PostgreSQL ، حيث ينقل تسمية الاعتماد في الاستعلامات.

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

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

قمنا بتجميع وصفات لتصميم تطبيق مع دعم MAC ، وضعت على أساس تجربتنا الخاصة. وخلفها ، هناك ليال بلا نوم ، ودفق مستمر من التذاكر من الاختبارات ، وآلاف ساعات تصحيح الأخطاء لأحد التطبيقات التي ، بكل معنى الكلمة ، يجب أن تعمل بشكل صحيح ، لكن لسبب ما لا يعمل بهذه الطريقة. يتم وصف الوصفات في أبسط أشكال التكنولوجيا والأدوات المحايدة ، وهي مزودة بمخططات لتحسين التصور إن أمكن. دعنا نذهب!

كيفية تجنب MAC عندما لا يمكن تجنبها

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

فيما يتعلق بتكاليف اليد العاملة ، سيتعين عليك قضاء وقت إضافي في تنفيذ كل وظيفة من وظائف التطبيق بدعم MAC. ستحتاج إلى تصحيح واختبار الوظيفة نفسها في الوضع دون تسمية بيانات اعتماد ، وبالتالي ستزداد تكلفة الاختبار.

بسبب هذا الحل ، من الممكن توفير التطبيق (وفريق التطوير بأكمله) ، الذي يضطر للعمل في بيئة MAC ، المزايا التالية:

• تطبيق عبر النظام الأساسي (يقتصر فقط على قدرات لغات البرمجة) واستقلالها عن وقت التشغيل.
• القدرة على استخدام أدوات المحاكاة الافتراضية الحديثة (على سبيل المثال ، Docker) للتشغيل الآلي.
• سهولة اختبار ميزات تصحيح الأخطاء التي لا ترتبط مباشرة بـ MAC.

التوصيات :

أضف الخيار لتمكين / تعطيل دعم بيانات الاعتماد في التطبيق.

في جميع الأماكن التي تتطلب التفاعل مع MAC ، أولاً ، تحقق من قيمة المعلمة.

عند تصحيح الأخطاء والاختبار ، من الضروري تصحيح (على جانب فريق التطوير) واختبار (على جانب فريق الاختبار) كلا وضعي التطبيق.

فرق تسد

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

هذه هي نفس البنية التحتية ، التي يكون الاستخلاص منها صعبًا جدًا ، وأحيانًا مستحيلًا. لذلك ، يجب تقسيم التطبيق إلى وحدات ، ولكل وحدة ، تحليل الحاجة إلى دعم MAC. ربما يكون في حالتك أنه يكفي لدعم MAC في وحدة واحدة فقط ، وليس هناك معنى لأن هذه الوحدة لتعقيد التطبيق بأكمله؟
إذا كنا نفكر في وحدة نمطية مجردة معينة (أو التطبيق بأكمله ، إذا كان تقسيم التطبيق إلى وحدات غير مطلوب) ، فإن النماذج التالية ممكنة:

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

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

تصنيف الوحدات حسب أوضاع معالجة MAC

"تشغيله": تشغيل الوحدة النمطية في وضع الحد الأدنى من بيانات الاعتماد

الدافع لتنفيذ هذه الآلية في الوحدة النمطية:

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

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

أمثلة على الحالات العملية التي يكون فيها استخدام وضع الملصق الأدنى الإلزامي مناسبًا:

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

"HURT ME PLENTY": تشغيل الوحدة النمطية في وضع بيانات اعتماد واحد

هذه الحالة أكثر تعقيدًا بعض الشيء ، لكن من نواحٍ كثيرة تشبه الحالة مع الحد الأدنى من علامة الاعتماد. من وجهة نظر المستخدم ، لا يتغير العمل مع التطبيق كثيرًا: كل القوائم المألوفة للسجلات والبطاقات والعمليات "عرض" و "تحرير" و "حفظ". الاختلاف الوحيد هو أنه في هذا الوضع ، يرى المستخدم فقط السجلات التي تتوافق مع علامة الاعتماد لجلسته الحالية.

يمكن أيضًا تطوير خيار محدود: تلتقط الوحدة قيمة معلمة "تسمية الاعتماد الافتراضية". في هذه الحالة ، يكون تشغيل الوحدة النمطية ممكنًا فقط باستخدام تسمية الاعتماد المحددة ، ولكن هذا الخيار يكون أسهل في التنفيذ.

يمكن أن تكون هذه الحالة مفيدة في الحالات التالية:

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

C , :

• , , – , .
• - . , , .

. , .

, :

• . , ( , ..). , . .
• . , , ( ) . «» , « », «» .

«NIGHTMARE!»:

, , .

, ( « »). - . .

:

• (, ) ( ). , .
• / / , .
• / ( ).

- - . , . .

, . - -. , . , , ..

:

• ( ).
• ( ) ( ).
• / .

, :

1. . , .
2. . , .

MAC . :

• :
  
  • :
    
    • ;
    • ( , ) .
  • ;
  • ( );
  • ( POSIX ACL, UNIX ..);
  • ;
  • ;
  • ;
• MAC;
• MAC:
  
  • (, PostgreSQL):
    
    • (, , , , , , , , ..).
• .

.

MAC-

MAC «» . , MAC , , ( ).

MAC?

, , . . . , , .

:

MAC- MAC

, MAC, MAC.

. «» , . , , . «» MAC , .

MAC , MAC, , , .

MAC- MAC

MAC , , . , , / .

— PostgresSQL. MAC MAC, :

• Astra Linux: PostgreSQL, SE.
• SELinux: sepgsql.

PostgreSQL ( , ) :

• .
• .
• .
• .
• .
• .

MAC «»: «» «» . MAC . .

MAC-

, . MAC, ?

MAC MAC , .

- :

النتائج

MAC. , , . , .

MAC — «» . , . «» MAC- :

• ( , , );
• MAC (, );
• MAC- .

! , !