تحكم إلزامي بالوصول

في مجال أمن الكمبيوتر، يشير التحكم الإلزامي في الوصول ( MAC ) إلى نوع من التحكم في الوصول حيث تقوم بيئة مؤمنة (مثل نظام التشغيل أو قاعدة البيانات) بتقييد قدرة الشخص أو البادئ على الوصول إلى كائن أو هدف أو تعديله.[1] في حالة أنظمة التشغيل، يكون الموضوع هو العملية أو الخيط، بينما تكون الكائنات هي الملفات أو الدلائل أو منافذ TCP / UDP أو أجزاء الذاكرة المشتركة أو أجهزة الإدخال والإخراج. كل من الموضوعات والأشياء لديها مجموعة من سمات الأمان. عندما يحاول أي كائن الوصول إلى كائن ما، يقوم نواة نظام التشغيل بفحص سمات الأمان هذه، وفحص قواعد الترخيص (المعروفة أيضًا باسم السياسة) الموضوعة، ويقرر ما إذا كان سيُمنح الوصول أم لا. يمكن لنظام إدارة قواعد البيانات، في آلية التحكم في الوصول الخاصة به، أن يطبق أيضًا التحكم في الوصول الإلزامي؛ في هذه الحالة، تكون الكائنات عبارة عن جداول، وعروض، وإجراءات، وما إلى ذلك.

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

من الناحية التاريخية والتقليدية، ارتبطت تقنية MAC ارتباطًا وثيقًا بالأمن متعدد المستويات (MLS) والأنظمة العسكرية المتخصصة. في هذا السياق، يتطلب MAC درجة عالية من الدقة لتلبية قيود أنظمة MLS. وفي الآونة الأخيرة ومع ذلك، انحرفت MAC عن نطاق MLS وبدأت تصبح أكثر شيوعًا. تسمح تطبيقات MAC الأحدث، مثل SELinux وAppArmor لنظام Linux وMandatory Integrity Control لنظام Windows، للمسؤولين بالتركيز على مشكلات مثل هجمات الشبكة والبرامج الضارة دون صرامة أو قيود MLS.

التاريخ والخلفية

تاريخيًا، ارتبط MAC ارتباطًا وثيقًا بالأمن متعدد المستويات (MLS) كوسيلة لحماية المعلومات السرية للولايات المتحدة. قدمت معايير تقييم نظام الكمبيوتر الموثوق به (TCSEC)، العمل الرائد في هذا الموضوع والمعروف غالبًا باسم الكتاب البرتقالي، التعريف الأصلي لـ MAC على أنه "وسيلة لتقييد الوصول إلى الكائنات بناءً على حساسية (كما هو موضح بواسطة تسمية) المعلومات الموجودة في الكائنات والترخيص الرسمي (أي الموافقة) للكيانات للوصول إلى معلومات بهذه الحساسية".[2] ركزت التطبيقات المبكرة لنظام MAC مثل Honeywell 's SCOMP وUSAF 's SACDIN وNSA 's Blacker وBoeing 's MLS LAN على MLS لحماية مستويات تصنيف الأمان الموجهة للجيش من خلال تطبيق قوي.

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

في بعض الأنظمة، يتمتع المستخدمون بالسلطة لاتخاذ القرار بشأن منح حق الوصول لأي مستخدم آخر. وللسماح بذلك، يجب أن يكون لدى جميع المستخدمين تصاريح لجميع البيانات. ليس هذا بالضرورة صحيحًا بالنسبة لنظام MLS. إذا كان هناك أفراد أو عمليات قد يُحرمون من الوصول إلى أي من البيانات الموجودة في بيئة النظام، فيجب الوثوق بالنظام لفرض MAC. نظرًا لأنه يمكن أن يكون هناك مستويات مختلفة لتصنيف البيانات وموافقات المستخدم، فهذا يعني وجود مقياس كمي للمتانة. على سبيل المثال، تُشير بيئات الأنظمة التي تحتوي على معلومات سرية للغاية ومستخدمين غير مصرح لهم بدخولهم إلى مستوى أعلى من المتانة، مقارنةً ببيئات الأنظمة التي تحتوي على معلومات سرية ومستخدمين غير مصرح لهم بدخولهم إلى مستوى "سري للغاية". ولتعزيز الاتساق وإزالة التحيز في درجات المتانة، أنتج تحليل علمي شامل وتقييم مخاطر لهذا الموضوع معيارًا مرجعيًا بارزًا يُحدد قدرات متانة الأنظمة الأمنية، ويُطابقها مع درجات الثقة المطلوبة لمختلف بيئات الأمن. وثقت النتيجة في CSC-STD-004-85.[3] عُرف عنصرين مستقلين نسبيًا للمتانة: مستوى الضمان والوظيفة. وقد حُدد كلا منهما بدرجة من الدقة التي استحقت ثقة كبيرة في الشهادات المبنية على هذه المعايير.

يعتمد معيار المعايير المشتركة[4] على هذا العلم ويهدف إلى الحفاظ على مستوى الضمان كمستويات EAL ومواصفات الوظيفة كملفات تعريف للحماية. من بين هذين العنصرين الأساسيين لمعايير المتانة الموضوعية، حُفظ على مستويات EAL فقط بأمانة. في إحدى الحالات، حُفظ على مستوى TCSEC C2[5] (ليس فئة قادرة على MAC) بأمانة إلى حد ما في المعايير المشتركة، مثل ملف تعريف حماية الوصول المُتحكم فيه (CAPP).[6] ملفات تعريف حماية MLS (مثل MLSOSPP المشابهة لـ B2)[7] أكثر عمومية من B2. إنها تتبع نظام MLS، لكنها تفتقر إلى متطلبات التنفيذ التفصيلية التي كانت موجودة في نصوص الكتاب البرتقالي السابقة، وتركز بشكل أكبر على الأهداف. وهذا يمنح الجهات المانحة للشهادات مرونة ذاتية أكبر في تحديد ما إذا كانت الميزات التقنية للمنتج الذي قُيم تحقق الهدف بشكل كافٍ، مما قد يؤدي إلى تآكل اتساق المنتجات التي قُيمت وتسهيل الحصول على الشهادة للمنتجات الأقل جدارة بالثقة. ولهذه الأسباب، فإن أهمية التفاصيل الفنية لملف الحماية تعتبر أمراً بالغ الأهمية لتحديد مدى ملاءمة المنتج.

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

أُعتمد عدد قليل من تنفيذات MAC، مثل مشروع Blacker التابع لشركة Unisys، على أنها قوية بما يكفي لفصل Top Secret عن Unclassified في أواخر الألفية الماضية. أصبحت التكنولوجيا الأساسية لديهم قديمة ولم تُحدث. اليوم لا توجد أي تنفيذات حالية معتمدة من قبل TCSEC لهذا المستوى من التنفيذ القوي. ومع ذلك، هناك بعض المنتجات الأقل قوة.

في أنظمة التشغيل

مايكروسوفت

بدءًا من Windows Vista وServer 2008، قامت Microsoft بدمج Mandatory Integrity Control (MIC) في نظام التشغيل Windows، والذي يضيف مستويات السلامة (IL) إلى العمليات الجارية. الهدف هو تقييد وصول العمليات الأقل موثوقية إلى المعلومات الحساسة. يعرف MIC خمسة مستويات للسلامة: منخفضة، ومتوسطة، وعالية، ونظام، ومثبت موثوق.[8] بشكل افتراضي، بدأت العمليات عند الوسيط IL. تتلقى العمليات المرتفعة IL عاليًا.[9] ترث العمليات الفرعية، بشكل افتراضي، سلامة العملية الأصلية، على الرغم من أن العملية الأصلية يمكنها تشغيلها باستخدام مستوى سلامة أقل. على سبيل المثال، يقوم Internet Explorer 7 بتشغيل العمليات الفرعية الخاصة به باستخدام IL منخفض. يتحكم Windows في الوصول إلى الكائنات استنادًا إلى ILs. تحتوي الكائنات المسماة، بما في ذلك الملفات أو مفاتيح التسجيل أو العمليات والخيوط الأخرى، على إدخال في قائمة التحكم في الوصول (ACL) الخاصة بها يشير إلى الحد الأدنى لعدد عمليات الوصول إلى العملية التي يمكنها استخدام الكائن. يفرض MIC أن العملية يمكنها الكتابة إلى كائن أو حذفه فقط عندما يكون IL الخاص بها مساويًا أو أعلى من IL الخاص بالكائن. علاوة على ذلك، لمنع الوصول إلى البيانات الحساسة في الذاكرة، لا يمكن للعمليات فتح العمليات ذات IL أعلى للوصول للقراءة.[10]

تفاحة

قامت شركة Apple Inc. بدمج تنفيذ إطار عمل TrustedBSD في أنظمة التشغيل iOS وmacOS الخاصة بها.[11] (الكلمة "mac" في "macOS" هي اختصار لـ " Macintosh " وليس لها علاقة باختصار "التحكم في الوصول الإلزامي" توفر وظيفة سطر الأوامر sandbox_init واجهة حماية محدودة عالية المستوى.[12]

جوجل

تستخدم الإصدارات 5.0 والإصدارات الأحدث من نظام التشغيل Android، التي طورتها Google SELinux لفرض نموذج أمان MAC على نهج DAC الأصلي القائم على UID.[13]

عائلة لينكس

يحتوي Linux والعديد من توزيعات Unix الأخرى على MAC لوحدة المعالجة المركزية (متعددة الحلقات)، والقرص، والذاكرة. على الرغم من أن برامج نظام التشغيل قد لا تدير الامتيازات بشكل جيد، فقد اكتسب Linux شهرة خلال التسعينيات باعتباره أكثر أمانًا وأكثر استقرارًا من البدائل غير التابعة لـUnix. وحدات أمان Linux الرئيسية الثلاث التي تنفذ MAC هي SELinux وAppArmor وTOMOYO Linux.[14]

لينكس المعزز أمنيًا (SELinux) طور في الأصل بواسطة وكالة الأمن القومي وصُدر لمجتمع المصدر المفتوح (Open Source) في عام 2000.[15] إنه أحد أول تطبيقات MAC لنظام Linux وهو أيضًا أحد أكثر التطبيقات شيوعًا.[16] دُمج في نوى Linux منذ الإصدار 2.4، ومُكن افتراضيًا على Android 5.0+ وRed Hat/Fedora. يوفر SELinux تحكمًا قويًا للغاية ودقيقًا، ولكن يجد العديد من المستخدمين أن قوته وتفاصيله تأتي مع درجة عالية من التعقيد ومنحنى تعليمي حاد.[17]

TOMOYO Linux هو تطبيق MAC خفيف الوزن لنظام Linux وLinux المضمن، طور بواسطة NTT Data Corporation. دُمج في إصدار Linux Kernel الرئيسي 2.6.30 في يونيو 2009.[18] على عكس النهج القائم على العلامات الذي يستخدمه SELinux، يقوم TOMOYO Linux بإجراء التحكم في الوصول الإلزامي القائم على اسم المسار، وفصل المجالات الأمنية وفقًا لسجل استدعاء العملية، والذي يصف سلوك النظام. تُوصف السياسات من حيث أسماء المسارات. يُعرف مجال الأمان ببساطة من خلال سلسلة استدعاء العملية، ويُمثل بواسطة سلسلة. هناك 4 أوضاع: الإعاقة، التعلم، التسامح، التنفيذ. يمكن للمسؤولين تعيين أوضاع مختلفة لمجالات مختلفة. قدمت TOMOYO Linux وضع "التعلم"، حيث تُحاا عمليات الوصول التي حدثت في النواة وتخزينها تلقائيًا لتوليد سياسة MAC: يمكن أن يكون هذا الوضع بعد ذلك الخطوة الأولى في كتابة السياسة، مما يجعل من السهل تخصيصها لاحقًا.

AppArmor هو تطبيق MAC يستخدم واجهة Linux Security Modules (LSM) الخاصة بنظام Linux 2.6 وهو مدمج في SUSE Linux وUbuntu 7.10. يوفر LSM واجهة برمجة تطبيقات kernel تسمح لوحدات كود kernel بالتحكم في ACL (DAC ACL، قوائم التحكم في الوصول). لا يمتلك AppArmor القدرة على تقييد جميع البرامج وهو متوفر بشكل اختياري في نواة Linux اعتبارًا من الإصدار 2.6.36.[19]

يوفر RSBAC (التحكم في الوصول المستند إلى مجموعة القواعد) من Amon Ott إطار عمل لنواة Linux يسمح بعدة وحدات مختلفة لسياسة الأمان / القرار. أحد النماذج التي نُفذت هو نموذج التحكم في الوصول الإلزامي. كان الهدف العام لتصميم RSBAC هو محاولة الوصول إلى المستوى B1 من الكتاب البرتقالي (TCSEC) (القديم). نموذج التحكم في الوصول الإلزامي المستخدم في RSBAC هو نفسه إلى حد كبير كما هو الحال في نظام Unix System V/MLS، الإصدار 1.2.1 (طور في عام 1989 من قبل المركز الوطني لأمن الكمبيوتر في الولايات المتحدة الأمريكية مع التصنيف B1/TCSEC). يتطلب RSBAC مجموعة من التصحيحات لنواة المخزون، والتي تُصان بشكل جيد للغاية من قبل مالك المشروع.

Smack (نواة التحكم في الوصول الإلزامي المبسط) هي وحدة أمان نواة Linux التي تحمي البيانات والتفاعل بين العمليات من التلاعب الخبيث باستخدام مجموعة من قواعد التحكم في الوصول الإلزامي المخصصة، مع البساطة كهدف تصميمي رئيسي.[20] دُمج رسميًا منذ إصدار Linux 2.6.25.[21]

grsecurity عبارة عن تصحيح لنواة Linux يوفر تنفيذ MAC (على وجه التحديد، فهو تنفيذ RBAC). لم يُنفذ grsecurity عبر واجهة برمجة التطبيقات LSM.[22]

أنظمة تشغيل أخرى

يدعم FreeBSD التحكم في الوصول الإلزامي، والذي نُفذ كجزء من مشروع TrustedBSD. قُدم في FreeBSD 5.0. بدءًا من FreeBSD 7.2، مُكن دعم MAC بشكل افتراضي. الإطار قابل للتوسع؛ حيث تنفذ وحدات MAC المختلفة سياسات مثل Biba والأمان متعدد المستويات.

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

انظر أيضا

التحكم في الوصول

 

  • Attribute-based access control (ABAC)
  • Context-based access control (CBAC)
  • تحكم بالوصول تقديري (DAC)
  • Lattice-based access control (LBAC)
  • Organisation-based access control (OrBAC)
  • Role-based access control (RBAC)
  • Rule-set-based access control (RSBAC)

مواضيع أخرى

 

الحواشي

  1. ↑ Belim, S. V.; Belim, S. Yu. (Dec 2018). "Implementation of Mandatory Access Control in Distributed Systems". Automatic Control and Computer Sciences (بالإنجليزية). 52 (8): 1124–1126. DOI:10.3103/S0146411618080357. ISSN:0146-4116. S2CID:73725128.
  2. ↑ "Trusted Computer Evaluation Criteria" (PDF). المعهد الوطني للمعايير والتقانة. 15 أغسطس 1983. مؤرشف (PDF) من الأصل في 2023-04-13. اطلع عليه بتاريخ 2023-06-25.
  3. ↑ "Technical Rational Behind CSC-STD-003-85: Computer Security Requirements". 25 يونيو 1985. مؤرشف من الأصل في 2007-07-15. اطلع عليه بتاريخ 2008-03-15.
  4. ↑ "The Common Criteria Portal". مؤرشف من الأصل في 2006-07-18. اطلع عليه بتاريخ 2008-03-15.
  5. ↑ US Department of Defense (ديسمبر 1985). "DoD 5200.28-STD: Trusted Computer System Evaluation Criteria". اطلع عليه بتاريخ 2008-03-15.
  6. ↑ "Controlled Access Protection Profile, Version 1.d". National Security Agency. 8 أكتوبر 1999. مؤرشف من الأصل في 2012-02-07. اطلع عليه بتاريخ 2008-03-15.
  7. ↑ "Protection Profile for Multi-Level Operating Systems in Environments Requiring Medium Robustness, Version 1.22" (PDF). National Security Agency. 23 مايو 2001. اطلع عليه بتاريخ 2018-10-06.
  8. ↑ Matthew Conover. "Analysis of the Windows Vista Security Model". Symantec Corporation. مؤرشف من الأصل في 2008-03-25. اطلع عليه بتاريخ 2007-10-08.
  9. ↑ Steve Riley. "Mandatory Integrity Control in Windows Vista". اطلع عليه بتاريخ 2007-10-08.
  10. ↑ Mark Russinovich. "PsExec, User Account Control and Security Boundaries". اطلع عليه بتاريخ 2007-10-08.
  11. ↑ TrustedBSD Project. "TrustedBSD Mandatory Access Control (MAC) Framework". اطلع عليه بتاريخ 2008-03-15.
  12. ↑ "sandbox_init(3) man page". 7 يوليو 2007. مؤرشف من الأصل في 2008-07-25. اطلع عليه بتاريخ 2008-03-15.
  13. ↑ "Security-Enhanced Linux in Android". Android Open Source Project. مؤرشف من الأصل في 2023-06-19. اطلع عليه بتاريخ 2023-06-25.
  14. ↑ "Linux Security Modules Overview: SELinux, AppArmor, and TOMOYO Comparison". 24 سبتمبر 2024. اطلع عليه بتاريخ 2025-05-05.
  15. ↑ "National Security Agency Shares Security Enhancements to Linux". NSA Press Release. Fort George G. Meade, Maryland: National Security Agency Central Security Service. 2 يناير 2001. مؤرشف من الأصل في 2018-09-18. اطلع عليه بتاريخ 2025-05-05.
  16. ↑ "Introduction to SELinux". 5 يوليو 2023. اطلع عليه بتاريخ 2025-05-05.
  17. ↑ "Linux Security Modules Overview: SELinux, AppArmor, and TOMOYO Comparison". 24 سبتمبر 2024. اطلع عليه بتاريخ 2025-05-05."Linux Security Modules Overview: SELinux, AppArmor, and TOMOYO Comparison". 2024-09-24. Retrieved 2025-05-05.
  18. ↑ "TOMOYO Linux, an alternative Mandatory Access Control". Linux 2 6 30. Linux Kernel Newbies.
  19. ↑ "Linux 2.6.36 released 20 October 2010". Linux 2.6.36. Linux Kernel Newbies.
  20. ↑ "Official SMACK documentation from the Linux source tree". مؤرشف من الأصل في 2013-05-01.
  21. ↑ Jonathan Corbet. "More stuff for 2.6.25". مؤرشف من الأصل في 2012-11-02.
  22. ↑ "Why doesn't grsecurity use LSM?".

    مراجع

    روابط خارجية

    • تدوينة على مدونة حول كيفية استخدام المحاكاة الافتراضية لتنفيذ التحكم في الوصول الإلزامي.
    • منشور مدونة من أحد موظفي Microsoft يوضح بالتفصيل التحكم الإلزامي في النزاهة وكيف يختلف عن تنفيذات MAC.
    • نموذج سياسة الأمان الرسمية لـ GWV ، فصل النواة، سياسة الأمان الرسمية، ديفيد جريف، ماثيو وايلدينج، ودبليو مارك فانفليت.
    هذه المقالة صادرة عن Wikipedia. النص متاح تحت رخصة المشاع الإبداعي - الإسناد - الترخيص بالمثل. قد تُطبَّق شروط إضافية على ملفات الوسائط.