|
تضامنًا مع حق الشعب الفلسطيني |
أمان متعدد المستويات
الأمان متعدد المستويات أو مستويات الأمان المتعددة (Multilevel security MLS) هو تطبيق لنظام الكمبيوتر لمعالجة المعلومات ذات السرية غير المتوافقة (على سبيل المثال، عند مستويات أمان مختلفة)، والسماح بالوصول من قِبل المستخدمين الذين لديهم تصاريح أمنية مختلفة واحتياجات المعرفة، ومنع المستخدمين من الوصول إلى المعلومات التي لا يملكون الإذن بالوصول إليها. هناك نوعان من السياقات لاستخدام الأمن متعدد المستويات. الأول هو الإشارة إلى نظام مناسب لحماية نفسه من التخريب ولديه آليات قوية لفصل مجالات المعلومات، أي جدير بالثقة. سياق آخر هو الإشارة إلى تطبيق لجهاز كمبيوتر يتطلب أن يكون الكمبيوتر قويًا بما يكفي لحماية نفسه من التخريب وامتلاك آليات كافية لفصل مجالات المعلومات، أي نظام يجب أن نثق به. هذا التمييز مهم لأن الأنظمة التي يجب الوثوق بها ليست بالضرورة جديرة بالثقة.
أنظمة تشغيل موثوقة
تتطلب بيئة تشغيل MLS غالبًا نظام معالجة معلومات جدير بالثقة للغاية مبني غالبًا على نظام تشغيل MLS (OS)، ولكن ليس بالضرورة. يمكن دعم معظم وظائف MLS بواسطة نظام مؤلف بالكامل من أجهزة كمبيوتر غير موثوق بها، على الرغم من أنها تتطلب عدة أجهزة كمبيوتر مستقلة مرتبطة بقنوات متوافقة مع أمان الأجهزة (انظر القسم B.6.2 من تفسير الشبكة الموثوقة، NCSC-TG-005). مثال على MLS الذي يتم فرضه بواسطة الأجهزة هو العزلة غير المتماثلة.[1] إذا تم استخدام أحد أجهزة الكمبيوتر في وضع MLS، فيجب أن يستخدم هذا الكمبيوتر نظام تشغيل موثوقًا (OS). نظرًا لأن جميع المعلومات الموجودة في بيئة MLS يمكن الوصول إليها فعليًا بواسطة نظام التشغيل، يجب وجود ضوابط منطقية قوية لضمان التحكم الصارم في الوصول إلى المعلومات. عادةً ما يتضمن هذا التحكم الإلزامي في الوصول الذي يستخدم ملصقات الأمان، مثل نموذج Bell – LaPadula.
يطلب العملاء الذين ينشرون أنظمة تشغيل موثوقة عادةً أن يكمل المنتج تقييمًا رسميًا لأمن الكمبيوتر. يكون التقييم أكثر صرامة بالنسبة لنطاق أمان أوسع، وهي مستويات التصنيف الأدنى والأعلى التي يمكن للنظام معالجتها. كانت معايير تقييم نظام الكمبيوتر الموثوق (TCSEC) هي معايير التقييم الأولى التي تم تطويرها لتقييم MLS في أنظمة الكمبيوتر. بموجب هذه المعايير، كان هناك تخطيط موحد واضح[2] بين متطلبات الأمن واتساع نطاق أمان MLS. تاريخياً، تم اعتماد عدد قليل من التطبيقات القادرة على معالجة MLS مع نطاق أمان من Unclassified من خلال Top Secret. وكان من بينهم برنامج SCOMP لشركة Honeywell، وUSAF SACDIN، وNSA 's Blacker، وMLS LAN من Boeing، وكلها تابعة لـ TCSEC، ومقرها Intel 80386. حاليًا، يتم تقييم منتجات MLS وفقًا للمعايير المشتركة. في أواخر عام 2008، تم اعتماد نظام التشغيل الأول بمستوى ضمان عالي التقييم: مستوى ضمان التقييم (EAL) - EAL 6+ / قوة عالية، تحت رعاية برنامج حكومي أمريكي يتطلب أمانًا متعدد المستويات في حالة بيئة بها تهديد شديد. في حين أن هذا المستوى من التأكيد له العديد من أوجه التشابه مع مستوى الكتاب البرتقالي القديم A1 (مثل الأساليب الرسمية)، فإن المتطلبات الوظيفية تركز على سياسات العزل الأساسية وتدفق المعلومات بدلاً من سياسات المستوى الأعلى مثل Bell-La Padula. نظرًا لأن المعايير المشتركة فصلت اقتران ضمان TCSEC (EAL) والوظائف (ملف تعريف الحماية)، فقد تم فقدان التخطيط الموحد الواضح بين متطلبات الأمان وقدرة نطاق أمان MLS الموثقة في CSC-STD-004-85 إلى حد كبير.
تشمل أنظمة التشغيل المتاحة مجانًا مع بعض الميزات التي تدعم الأمان متعدد المستويات نظام Linux مع تمكين ميزة Security-Enhanced Linux و FreeBSD.[3] كان يُعتقد في السابق أن التقييم الأمني يمثل مشكلة بالنسبة إلى تطبيقات MLS المجانية هذه لثلاثة أسباب:
- من الصعب دائمًا تنفيذ إستراتيجية الحماية الذاتية لـ kernel بالدقة اللازمة لثقة MLS، ولم يتم تصميم هذه الأمثلة أو اعتمادها لملف تعريف حماية MLS، لذا فقد لا تقدم الحماية الذاتية اللازمة لدعم MLS.
- بصرف النظر عن مستويات EAL، تفتقر المعايير المشتركة إلى جرد لملفات الحماية عالية التأكيد المناسبة التي تحدد المتانة اللازمة للعمل في وضع MLS.
- حتى إذا تم استيفاء (1) و (2)، فإن عملية التقييم تكون مكلفة للغاية وتفرض قيودًا خاصة على التحكم في تكوين البرنامج الذي تم تقييمه.
على الرغم من هذه الافتراضات، فقد جرى اعتماد Red Hat Enterprise Linux 5 ضد LSPP و RBACPP و CAPP في EAL4 + في يونيو 2007.[4] يستخدم نظام Linux المحسّن للأمان لتطبيق MLS وكان أول شهادة معايير مشتركة لفرض خصائص أمان TOE مع Linux المحسّن للأمان.
يمكن أن تكون استراتيجيات اعتماد البائعين مضللة للأشخاص العاديين. تستغل الإستراتيجية الشائعة التركيز المفرط للشخص العادي على مستوى EAL مع الإفراط في الاعتماد، مثل التصديق على ملف تعريف حماية EAL 3 (مثل CAPP)[5] إلى مستويات مرتفعة، مثل EAL 4 أو EAL 5. إضافة ميزات دعم MLS واعتمادها (مثل ملف تعريف حماية التحكم في الوصول المستند إلى الدور (RBACPP) وملف تعريف حماية الأمان المسمى (LSPP)) إلى نواة لم يتم تقييمها إلى ملف تعريف حماية قادر على MLS. هذه الأنواع من الميزات هي خدمات يتم تشغيلها على النواة وتعتمد على النواة لحمايتها من الفساد والتخريب. إذا لم يتم تقييم النواة إلى ملف تعريف حماية قادر على MLS، فلا يمكن الوثوق بميزات MLS بغض النظر عن العرض التوضيحي. وتجدر الإشارة بشكل خاص إلى أن CAPP على وجه التحديد ليس ملفًا شخصيًا قادرًا على MLS لأنه يستبعد على وجه التحديد قدرات الحماية الذاتية الحاسمة لـ MLS.
تقدم شركة جنرال ديناميكس نظام التشغيل PitBull، وهو نظام تشغيل به أمان متعدد المستويات موثوق به. يتم تقديم PitBull حاليًا فقط كإصدار محسن من Red Hat Enterprise Linux، ولكن توجد إصدارات سابقة لـ Sun Microsystems Solaris و IBM AIX و SVR4 Unix. يوفر PitBull آلية أمان Bell LaPadula، وآلية سلامة Biba، واستبدال امتياز للمستخدم المتميز، والعديد من الميزات الأخرى. تمتلك PitBull قاعدة الأمان لمنتج بيئة الشبكة الموثوقة (TNE) لشركة General Dynamics منذ عام 2009. تمكّن TNE مشاركة المعلومات متعددة المستويات والوصول إليها للمستخدمين في مجتمعات وزارة الدفاع والاستخبارات التي تعمل بمستويات تصنيف مختلفة. إنها أيضًا الأساس لبيئة مشاركة التحالف متعدد المستويات، وتم توسيع أنظمة جمع معلومات Battlefield واستغلالها[6] (BICES-X).
تقدم شركة صن ميكروسيستمز الآن Oracle Corporation، ملحقات Solaris الموثوقة كميزة متكاملة لأنظمة التشغيل التجارية Solaris وOpenSolaris. بالإضافة إلى ملف تعريف حماية الوصول الخاضع للرقابة (CAPP)، وملفات تعريف الحماية للتحكم في الوصول المستند إلى الأدوار (RBAC)، تم اعتماد الإضافات الموثوقة أيضًا في EAL4 إلى ملف تعريف حماية الأمان المسمى (LSPP).[7] يتضمن هدف الأمان كلاً من وظائف سطح المكتب والشبكة. يفرض LSPP أن المستخدمين غير مصرح لهم بتجاوز سياسات وضع العلامات التي يتم فرضها بواسطة kernel وX Window System (خادم X11). لا يتضمن التقييم تحليل قناة سرية. نظرًا لأن هذه الشهادات تعتمد على CAPP، فلا توجد شهادات Common Criteria تشير إلى أن هذا المنتج جدير بالثقة لـ MLS.
تقدم شركة BAE Systems نظام XTS-400، وهو نظام تجاري يدعم MLS فيما يدعي البائع أنه «ضمان عالي». تم تقييم المنتجات السابقة (بما في ذلك XTS-300) على مستوى TCSEC B3، وهو قادر على MLS. تم تقييم XTS-400 وفقًا للمعايير المشتركة في EAL5 + مقابل ملفات تعريف حماية CAPP و LSPP. يعد كل من CAPP و LSPP ملفات تعريف حماية EAL3 ليست قادرة بطبيعتها على MLS، ولكن الهدف الأمني[8] لتقييم المعايير العامة لهذا المنتج يحتوي على مجموعة غنية من وظائف الأمان التي توفر إمكانية MLS.
مجالات المشاكل
يعتبر التعقيم Sanitization مجال مشكلة لأنظمة MLS. الأنظمة التي تطبق قيود MLS، مثل تلك التي حددها نموذج Bell-LaPadula، تسمح فقط بالمشاركة عندما لا تنتهك بشكل واضح قيود الأمان. يمكن للمستخدمين الذين لديهم تصاريح أقل مشاركة عملهم بسهولة مع المستخدمين الذين لديهم تصاريح أعلى، ولكن ليس العكس. لا توجد آلية فعالة وموثوقة يمكن للمستخدم من خلالها تحرير ملف سري للغاية، وإزالة جميع المعلومات السرية، ثم تسليمها إلى المستخدمين الذين لديهم تصاريح سرية أو أقل. من الناحية العملية، تتغلب أنظمة MLS على هذه المشكلة من خلال الوظائف المميزة التي تسمح للمستخدم الجدير بالثقة بتجاوز آلية MLS وتغيير تصنيف أمان الملف. ومع ذلك، فإن هذه التقنية غير موثوقة.
تُشكل القنوات السرية مشكلة أخرى لأنظمة الأمان متعدد المستويات. لكي يحتفظ نظام MLS بالأسرار تمامًا، يجب ألا تكون هناك طريقة ممكنة لعملية سرية فائقة لنقل الإشارات من أي نوع إلى عملية سرية أو أقل. يتضمن ذلك الآثار الجانبية مثل التغييرات في الذاكرة المتوفرة أو مساحة القرص، أو التغييرات في توقيت العملية. عندما تستغل عملية ما مثل هذا التأثير الجانبي لنقل البيانات، فإنها تستغل قناة سرية. من الصعب للغاية إغلاق جميع القنوات السرية في نظام حوسبة عملي، وقد يكون ذلك مستحيلًا في الممارسة العملية. عملية تحديد جميع القنوات السرية هي عملية صعبة في حد ذاتها. لا تحاول معظم أنظمة MLS المتاحة تجاريًا إغلاق جميع القنوات السرية، على الرغم من أن هذا يجعل من غير العملي استخدامها في تطبيقات الأمان العالي.
يمثل التجاوز Bypass مشكلة عند تقديمه كوسيلة للتعامل مع كائن مرتفع في النظام كما لو كان موثوقًا به في MLS. والمثال الشائع هو استخراج البيانات من عنصر مرتفع في نظام سري ليتم إرسالها إلى وجهة غير مصنفة، مع الإشارة إلى بعض خصائص البيانات كدليل موثوق به على أنها «غير مصنفة حقًا» (مثل التنسيق «الصارم» strict). لا يمكن الوثوق بالنظام العالي للحفاظ على أي دليل موثوق به، والنتيجة هي فتح مسار بيانات علني بدون طريقة منطقية للتوسط فيه بشكل آمن. يمكن أن يكون التجاوز محفوفًا بالمخاطر لأنه، على عكس القنوات السرية ذات النطاق الترددي الضيق التي يصعب استغلالها، يمكن أن يؤدي التجاوز إلى حدوث تسرب علني كبير يسهل استغلاله في النظام. غالبًا ما ينشأ التجاوز عن الفشل في استخدام بيئات التشغيل الموثوقة للحفاظ على الفصل المستمر لمجالات الأمان وصولاً إلى أصلها. عندما يقع هذا الأصل خارج حدود النظام، فقد لا يكون من الممكن التحقق من صحة الفصل الموثوق به إلى الأصل. في هذه الحالة، يمكن أن يكون خطر التجاوز أمرًا لا مفر منه إذا كان التدفق ضروريًا حقًا.
أحد الأمثلة الشائعة على التجاوز الذي لا يمكن تجنبه هو «نظام موضوع» مطلوب لقبول حزم IP السرية من مصدر غير موثوق به، وتشفير بيانات المستخدم السرية وليس العنوان وإيداع النتيجة في شبكة غير موثوق بها. يقع المصدر خارج مجال تأثير نظام الموضوع. على الرغم من أن المصدر غير موثوق به (على سبيل المثال مرتفع في النظام)، إلا أنه يتم الوثوق به كما لو كان MLS لأنه يوفر حزمًا تحتوي على رؤوس غير مصنفة وبيانات مستخدم نص عادي سرية، وهي بنية بيانات MLS. نظرًا لأن المصدر غير موثوق به، فقد يكون تالفًا ويضع أسرارًا في رأس الحزمة غير المصنفة. قد تكون رؤوس الحزمة التالفة هراء ولكن من المستحيل على النظام الموضوع تحديد ذلك بأي موثوقية معقولة. بيانات مستخدم الحزمة محمية بشكل جيد من ناحية التشفير ولكن رأس الحزمة يمكن أن يحتوي على أسرار يمكن قراءتها. إذا تم تمرير الحزم التالفة إلى شبكة غير موثوق بها بواسطة النظام الموضوع، فقد لا تكون قابلة للتوجيه ولكن بعض العمليات الفاسدة المتعاونة في الشبكة يمكن أن تلتقط الحزم وتتعرف عليها وقد لا يكتشف النظام الموضوع التسرب. يمكن أن يكون هذا تسربًا علنيًا كبيرًا يصعب اكتشافه. عرض الحزم المصنفة ذات الرؤوس غير المصنفة باعتبارها هياكل عالية للنظام بدلاً من هياكل MLS، فهي تمثل تهديدًا شائعًا جدًا ولكنها خطيرة.
يمكن تجنب معظم التجاوز. غالبًا ما ينتج التجاوز الذي يمكن تجنبه عندما يصمم مهندسو النظام نظامًا قبل التفكير في الأمان بشكل صحيح، ثم يحاولون تطبيق الأمان بعد حدوثه كوظائف إضافية. في هذه الحالة، يبدو أن التجاوز هو الطريقة الوحيدة (السهلة) لجعل النظام يعمل. تم اقتراح بعض المخططات الآمنة الزائفة (والموافقة عليها!) التي تفحص محتويات البيانات التي تم تجاوزها في محاولة عبثية لإثبات أن البيانات التي تم تجاوزها لا تحتوي على أسرار. هذا غير ممكن دون الوثوق بشيء ما حول البيانات مثل تنسيقها، وهو ما يتعارض مع الافتراض بأن المصدر غير موثوق به للحفاظ على أي خصائص لبيانات المصدر. «التجاوز الآمن» هو أسطورة، تمامًا مثل ما يسمى بالحماية عالية التأكيد (HAG) التي تنفذ التجاوز بشفافية. وقد تم الاعتراف منذ فترة طويلة بالمخاطر التي تسببها هذه؛ الحلول الموجودة هي في نهاية المطاف إجرائية، وليست تقنية. لا توجد طريقة لمعرفة على وجه اليقين مقدار المعلومات السرية المأخوذة من أنظمتنا عن طريق استغلال التجاوز.
التطبيقات
تعد البنية التحتية مثل أنظمة التشغيل الموثوقة مكونًا مهمًا لأنظمة MLS، ولكن من أجل تلبية المعايير المطلوبة بموجب تعريف MLS بواسطة CNSSI 4009، يجب أن يوفر النظام واجهة مستخدم قادرة للسماح للمستخدم بالوصول إلى المحتوى ومعالجته على مستويات تصنيف متعددة من نظام واحد. يدير UCDMO مسارًا يركز بشكل خاص على MLS في ندوة NSA Information Assurance في عام 2009، والتي سلطت فيها الضوء على العديد من أنظمة MLS المعتمدة (قيد الإنتاج) والناشئة. لاحظ استخدام MLS في SELinux.[9]
هناك العديد من قواعد البيانات المصنفة على أنها أنظمة أمان متعدد المستويات. تمتلك Oracle منتجًا يسمى Oracle Label Security (OLS) يقوم بتنفيذ عناصر تحكم الوصول الإلزامية - عادةً عن طريق إضافة عمود «تسمية» إلى كل جدول في قاعدة بيانات Oracle. ويجري نشر عملية شريان الحياة في الجيش الأمريكي INSCOM كأساس لقاعدة بيانات الاستخبارات «عن المصدر» تغطي JWICS و SIPRNet الشبكات. هناك مشروع لإنشاء نسخة ذات تصنيف من PostgreSQL، وهناك أيضًا تطبيقات أقدم لقواعد البيانات المسماة مثل Trusted Rubix. توفر أنظمة قاعدة بيانات MLS نظامًا خلفيًا موحدًا للمحتوى الذي يمتد إلى عدة تسميات، لكنها لا تحل التحدي المتمثل في جعل المستخدمين يعالجون المحتوى على مستويات أمان متعددة في نظام واحد مع فرض ضوابط الوصول الإلزامية.
هناك أيضًا العديد من تطبيقات المستخدم النهائي MLS. القدرة MLS الأخرى الموجودة حاليًا على خط الأساس UCDMO تسمى MLChat، وهي خادم دردشة يعمل على نظام التشغيل XTS-400 - تم إنشاؤه بواسطة مختبر الأبحاث البحرية الأمريكية. نظرًا لأن المحتوى من المستخدمين في المجالات المختلفة يمر عبر خادم MLChat، يتم استخدام المسح بالكلمات القذرة لحماية المحتوى المصنف، وكان هناك بعض الجدل حول ما إذا كان هذا حقًا نظام MLS أو شكل من أشكال حماية البيانات عبر المجال. يتم الحفاظ على ضوابط الوصول الإلزامية من خلال مجموعة من XTS-400 والآليات الخاصة بالتطبيق.
التبادل المشترك عبر النطاقات (JCDX) هو مثال آخر على قدرة MLS الموجودة حاليًا في UCDMO خط الأساس. JCDX هو نظام القيادة والتحكم والاتصالات والكمبيوتر والاستخبارات (C4I) المعتمد من وزارة الدفاع (DoD) ووكالة استخبارات الدفاع (DIA) الوحيد المعتمد من قبل وزارة الدفاع (MLS)، والذي يوفر دعمًا استخباراتيًا وتحذيريًا في الوقت الفعلي تقريبًا. تم دمج بنية JCDX بشكل شامل مع نظام تشغيل آمن عالي الضمان من المستوى الرابع (PL4)، باستخدام تصنيف البيانات لنشر معلومات البيانات في الوقت الفعلي تقريبًا حول أنشطة القوة والتهديدات الإرهابية المحتملة في محيطات العالم وحولها. يتم تثبيته في مواقع في الولايات المتحدة والدول الشريكة المتحالفة حيث يكون قادرًا على توفير البيانات من Top Secret / SCI وصولاً إلى مستويات Secret-Releasable، كل ذلك على منصة واحدة.
تتضمن تطبيقات MLS التي ليست حاليًا جزءًا من خط الأساس UCDMO العديد من التطبيقات من BlueSpace. لدى BlueSpace العديد من تطبيقات الأمان متعدد المستويات، بما في ذلك عميل البريد الإلكتروني MLS وتطبيق بحث MLS ونظام MLS C2. تستفيد BlueSpace من إستراتيجية البرامج الوسيطة لتمكين تطبيقاتها من أن تكون منصة محايدة، وتنظم واجهة مستخدم واحدة عبر مثيلات نظام تشغيل Windows متعددة (جلسات المحطة الطرفية الافتراضية أو البعيدة) قام مختبر الأبحاث البحرية الأمريكية أيضًا بتطبيق إطار عمل تطبيق ويب متعدد المستويات يسمى MLWeb والذي يدمج إطار عمل Ruby on Rails مع قاعدة بيانات متعددة المستويات تعتمد على SQLite3.
المستقبل
ربما يكون أكبر تغيير يحدث في مجال الأمان متعدد المستويات اليوم هو تقارب MLS مع الافتراضية. يتزايد عدد أنظمة التشغيل الموثوقة التي تبتعد عن وضع العلامات على الملفات والعمليات، وتتجه بدلاً من ذلك نحو حاويات UNIX أو الأجهزة الافتراضية. تشمل الأمثلة مناطق في Solaris 10 TX، وHypervisor الخلية المبطنة في أنظمة مثل منصة Integrity في Green Hill و XenClient XT من Citrix. يعد نظام High Assurance Platform من NSA كما تم تنفيذه في بيئة المحاكاة الافتراضية الموثوقة (TVE) التابع لشركة General Dynamics مثالًا آخر - فهو يستخدم SELinux في جوهره، ويمكنه دعم تطبيقات MLS التي تمتد عبر مجالات متعددة.
انظر أيضًا
- نموذج بيل لابادولا
- نموذج ببا، نموذج النزاهة ببا
- نموذج كلارك ويلسون
- التحكم في الوصول التقديري (DAC)
- مستوى ضمان التقييم (EAL)
- نموذج جراهام دينينج
- التحكم في الوصول الإلزامي (MAC)
- أمان متعدد الفئات (MCS)
- مصادقة متعددة العوامل
- نموذج عدم التدخل (الأمني)
- التحكم في الوصول المستند إلى الدور (RBAC)
- أوضاع التشغيل الأمنية
- وضع النظام العالي
- نموذج أخذ المنح
المراجع
- ^ Davidson، J.A. (9 ديسمبر 1996). Asymmetric isolation. ص. 44–54. DOI:10.1109/CSAC.1996.569668. ISBN:978-0-8186-7606-2.
{{استشهاد بكتاب}}:|عمل=تُجوهل (مساعدة) - ^ CSC-STD-004-85: Computer Security Requirements - Guidance For Applying The Department Of Defense Trusted Computer System Evaluation Criteria In Specific Environments (25 June 1985) نسخة محفوظة 2016-12-21 على موقع واي باك مشين.
- ^ Multi-Level Security confidentiality policy in FreeBSD نسخة محفوظة 11 مايو 2021 على موقع واي باك مشين.
- ^ "Validated Product - Red Hat Enterprise Linux Version 5 running on IBM Hardware". National Information Assurance Partnership, Common Criteria Evaluation and Validation Scheme, United States. 7 يونيو 2007. مؤرشف من الأصل في 2021-04-17.
- ^ Controlled Access Protection Profile (CAPP) نسخة محفوظة 2021-04-17 على موقع واي باك مشين.
- ^ Corrin, Amber (8 Aug 2017). "How BICES-X facilitates global intelligence". C4ISRNET (بen-US). Archived from the original on 2021-04-17. Retrieved 2018-12-10.
{{استشهاد ويب}}: صيانة الاستشهاد: لغة غير مدعومة (link) - ^ "Solaris 10 Release 11/06 Trusted Extensions". Communications Security Establishment Canada. 11 يونيو 2008. مؤرشف من الأصل في 2011-06-17. اطلع عليه بتاريخ 2010-06-26.
- ^ "Security Target, Version 1.22 for XTS-400, Version 6.4.U4" (PDF). National Information Assurance Partnership, Common Criteria Evaluation and Validation Scheme, United States. 1 يونيو 2008. مؤرشف من الأصل (PDF) في 2011-07-23. اطلع عليه بتاريخ 2010-08-11.
- ^
For example: Petersen، Richard (2011). Fedora 14 Administration and Security. Surfing Turtle Press. ص. 298. ISBN:9781936280223. مؤرشف من الأصل في 2021-04-17. اطلع عليه بتاريخ 2012-09-13.
The SELinux reference policy [...] Multi-level security (MLS) adds a more refined security access method. MLS adds a security level value to resources.
قراءة متعمقة
- Lampson, B. (1973). "A note on the confinement problem". Communications of the ACM. ج. 16 ع. 10: 613–615. DOI:10.1145/362375.362389. مؤرشف من الأصل في 2008-12-02.
- NCSC (1985). "Trusted Computer System Evaluation Criteria". National Computer Security Center. (المعروف أيضًا باسم TCSEC أو «الكتاب البرتقالي»).
- NCSC (1986). "Trusted Network Interpretation". National Computer Security Center. (يُعرف أيضًا باسم TNI أو «الكتاب الأحمر»). [1]
- Smith، Richard (2005). "Chapter 205: Multilevel security". في Hossein Bidgoli (المحرر). Handbook of Information Security, Volume 3, Threats, Vulnerabilities, Prevention, Detection and Management. New York: John Wiley. مؤرشف من الأصل في 2006-05-06. اطلع عليه بتاريخ 2006-05-21.(ردمك 0-471-64832-9).
- Patel, D., Collins, R., Vanfleet, W. M., Calloni, B. A., Wilding, M. M., MacLearn, L., & Luke, J. A. (نوفمبر 2002). "Deeply Embedded High Assurance (Multiple Independent Levels of Security/Safety) MILS Architecture" (PDF). Center for research on economic development and policy reform. مؤرشف من الأصل (PDF) في 2003-04-28. اطلع عليه بتاريخ 2005-11-06.
{{استشهاد بدورية محكمة}}: صيانة الاستشهاد: أسماء متعددة: قائمة المؤلفين (link) - PA Loscocco و SD Smalley و PA Muckelbauer و RC Taylor و SJ Turner و JF Farrell. حتمية الفشل: الافتراض الخاطئ للأمان في بيئات الحوسبة الحديثة. في وقائع المؤتمر الوطني الحادي والعشرين لأمن نظم المعلومات، الصفحات 303-314، أكتوبر 1998. [2].
