WikiDer > Обязательный контроль доступа

Mandatory access control

В компьютерная безопасность, принудительный контроль доступа (MAC) относится к типу контроль доступа по которому Операционная система ограничивает возможности предмет или же инициатор для доступа или выполнения каких-либо операций с объект или же цель.[1] На практике предметом обычно является процесс или поток; объекты - это конструкции, такие как файлы, каталоги, TCP/UDP порты, сегменты совместно используемой памяти, устройства ввода-вывода и т. д. Каждый субъект и объект имеют набор атрибутов безопасности. Всякий раз, когда субъект пытается получить доступ к объекту, правило авторизации применяется операционной системой. ядро проверяет эти атрибуты безопасности и решает, может ли доступ иметь место. Любая операция любого субъекта над любым объектом проверяется на соответствие набору правил авторизации (также известных как политика), чтобы определить, разрешена ли операция. А система управления базами данныхв своем механизме управления доступом также может применять принудительный контроль доступа; в этом случае объектами являются таблицы, представления, процедуры и т. д.

При обязательном управлении доступом эта политика безопасности централизованно контролируется администратором политики безопасности; пользователи не имеют возможности переопределить политику и, например, предоставить доступ к файлам, которые в противном случае были бы ограничены. Напротив, дискреционный контроль доступа (DAC), который также управляет способностью субъектов получать доступ к объектам, позволяет пользователям принимать политические решения и / или назначать атрибуты безопасности. (Традиционный Unix система пользователей, групп и разрешений на чтение-запись-выполнение является примером DAC.) Системы с поддержкой MAC позволяют администраторам политик реализовывать политики безопасности в масштабах всей организации. Под MAC (и в отличие от DAC) пользователи не могут случайно или намеренно переопределить или изменить эту политику. Это позволяет администраторам безопасности определять центральную политику, которая гарантированно (в принципе) будет применяться для всех пользователей.

Исторически и традиционно MAC был тесно связан с многоуровневая безопасность (MLS) и специализированные военные системы. В этом контексте MAC подразумевает высокую степень строгости, чтобы удовлетворить ограничения систем MLS. Однако в последнее время MAC вышел из ниши MLS и стал более популярным. Более поздние реализации MAC, такие как SELinux и AppArmor для Linux и Обязательный контроль целостности для Windows, позволяют администраторам сосредоточиться на таких проблемах, как сетевые атаки и вредоносное ПО, без строгости или ограничений MLS.

Историческая справка и значение для многоуровневой безопасности

Исторически MAC был тесно связан с многоуровневая безопасность (MLS) как средство защиты секретной информации США. В Критерии оценки доверенных компьютерных систем (TCSEC), основополагающая работа по этому вопросу, предоставила исходное определение MAC как «средства ограничения доступа к объектам на основе секретности (представленной меткой) информации, содержащейся в объектах, и формальной авторизации (т. Е. , разрешение) субъектов доступа к информации такой важности ".[2] Ранние реализации MAC, такие как Honeywell SCOMP, USAF SACDIN, NSA Blacker и Boeing 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, например Unisys' Чернее project, были сертифицированы достаточно надежными, чтобы отделить Top Secret от Unclassified в конце прошлого тысячелетия. Их базовая технология устарела, и они не обновлялись. Сегодня нет текущих внедрений, сертифицированных TCSEC до этого уровня надежной реализации. Однако существуют менее надежные продукты.

  • RSBAC (Контроль доступа на основе набора правил) Амона Отта обеспечивает основу для ядер Linux, которая позволяет использовать несколько различных модулей политики / принятия решений. Одна из реализованных моделей - модель обязательного контроля доступа. Общая цель разработки RSBAC состояла в том, чтобы попытаться достичь (устаревшего) уровня B1 Orange Book (TCSEC). Модель управления принудительным доступом, используемая в RSBAC, в основном такая же, как и в Unix System V / MLS, версия 1.2.1 (разработана в 1989 году Национальным центром компьютерной безопасности США по классификации B1 / TCSEC). RSBAC требует набора исправлений для стандартного ядра, которые достаточно хорошо поддерживаются владельцем проекта.
  • An АНБ исследовательский проект под названием SELinux добавлена ​​архитектура обязательного контроля доступа к Ядро Linux, который был объединен с основной версией Linux в августе 2003 года. Он использует функцию ядра Linux 2.6 под названием LSM (Интерфейс модулей безопасности Linux). Red Hat Enterprise Linux версия 4 (и более поздние версии) поставляются с ядром с поддержкой SELinux. Хотя SELinux может ограничивать все процессы в системе, по умолчанию целевой политика в RHEL ограничивает наиболее уязвимые программы из неограниченный домен в котором работают все остальные программы. RHEL 5 поставляет 2 других типа бинарных политик: строгий, который пытается реализовать наименьшая привилегия, и MLS, который основан на строгий и добавляет MLS этикетки. RHEL 5 содержит дополнительные улучшения MLS и получил 2 ЛСПП/ RBACPP / CAPP / EAL4 + в июне 2007 г.[8]
  • TOMOYO Linux это легкая реализация MAC для Linux и Встроенный Linux, разработан NTT Data Corporation. Он был объединен с основной веткой ядра Linux версии 2.6.30 в июне 2009 года.[9] В отличие от на основе этикеток подход, используемый SELinux, TOMOYO Linux выполняет на основе пути Обязательный контроль доступа, разделение доменов безопасности в соответствии с историей вызовов процессов, которая описывает поведение системы. Политика описана в виде путевых имен. Домен безопасности просто определяется цепочкой вызовов процесса и представлен строкой. Есть 4 режима: отключен, учусь, разрешительный, принудительный. Администраторы могут назначать разные режимы для разных доменов. TOMOYO Linux представил режим «обучения», в котором доступы, происходящие в ядре, автоматически анализируются и сохраняются для генерации политики MAC: этот режим затем может быть первым этапом написания политики, что упрощает настройку позже.
  • SUSE Linux и Ubuntu 7.10 добавили реализацию MAC под названием AppArmor. AppArmor использует функцию ядра Linux 2.6 под названием LSM (Интерфейс модулей безопасности Linux). LSM предоставляет ядро API что позволяет модулям кода ядра управлять ACL (DAC ACL, списки контроля доступа). AppArmor не может ограничивать все программы и может быть включен в ядро ​​Linux начиная с версии 2.6.36.[10]
  • Linux и многие другие дистрибутивы Unix имеют MAC для ЦП (мульти-кольцо), диска и памяти; в то время как программное обеспечение ОС может плохо управлять привилегиями, Linux стал известен в 1990-х годах как более безопасный и гораздо более стабильный, чем альтернативы, отличные от Unix. Дистрибьюторы Linux отключают MAC в лучшем случае как ЦАП для некоторых устройств - хотя это верно для любой доступной сегодня бытовой электроники.
  • grsecurity - это патч для ядра Linux, обеспечивающий реализацию MAC (точнее, это RBAC выполнение). grsecurity не реализуется через LSM API.[11]
  • Microsoft Начиная с Виндоус виста и Сервер 2008 Windows включает Обязательный контроль целостности, что добавляет Уровни честности (IL) для процессов, запущенных в сеансе входа в систему. MIC ограничивает права доступа приложений, которые работают под одной и той же учетной записью и могут быть менее надежными. Определены пять уровней целостности: низкий, средний, высокий, системный и надежный установщик.[12] Процессы, запущенные обычным пользователем, получают средний уровень интеллекта; повышенный процессы имеют высокий IL.[13] Хотя процессы наследуют уровень целостности процесса, который их породил, уровень целостности можно настроить для каждого процесса: например, IE7 а загруженные исполняемые файлы работают с низким IL. Windows контролирует доступ к объекты на основе IL, а также для определения границы оконных сообщений через Изоляция привилегий пользовательского интерфейса. Названный объекты, включая файлы, реестр ключи или другое процессы и потоки, есть запись в ACL управление доступом к ним, определяющее минимальный IL процесса, который может использовать объект. MIC требует, чтобы процесс мог записывать или удалять объект только тогда, когда его IL равен или выше IL объекта. Более того, чтобы предотвратить доступ к конфиденциальным данным в памяти, процессы не могут открывать процессы с более высоким IL для доступа на чтение.[14]
  • FreeBSD поддерживает Обязательный контроль доступа, реализованный в рамках проекта TrustedBSD. Он был представлен во FreeBSD 5.0. Начиная с FreeBSD 7.2, поддержка MAC включена по умолчанию. Фреймворк расширяемый; различные модули MAC реализуют такие политики, как Биба и многоуровневая безопасность.
  • Солнце Надежный Solaris использует обязательный и принудительный механизм контроля доступа (MAC), где допуски и метки используются для обеспечения соблюдения политики безопасности. Однако обратите внимание, что возможность управлять метками не означает, что ядро ​​может работать в многоуровневая безопасность Режим[нужна цитата]. Доступ к этикеткам и механизмам контроля не[нужна цитата] надежно защищен от повреждения в защищенном домене, поддерживаемом ядром. Приложения, запускаемые пользователем, объединяются с меткой защиты, с которой пользователь работает в сеансе. Доступ к информации, программам и устройствам контролируется слабо[нужна цитата].
  • Фреймворк Apple Mac OS X MAC - это реализация TrustedBSD Структура MAC.[15] Ограниченный высокоуровневый интерфейс песочницы предоставляется функцией командной строки sandbox_init. См. Документацию на странице руководства sandbox_init.[16]
  • Oracle Label Security реализация обязательного контроля доступа в СУБД Oracle.
  • SE-PostgreSQL в стадии разработки по состоянию на 27 января 2008 г.,[17][18] обеспечение интеграции в SE-Linux. Он нацелен на интеграцию с версией 8.4 вместе с ограничениями на уровне строк.
  • Надежный RUBIX СУБД, обеспечивающая обязательный контроль доступа, полностью интегрируется с SE-Linux для ограничения доступа ко всем объектам базы данных.[19]
  • Astra Linux ОС разработана для Русская армия имеет собственный контроль обязательного доступа.[20]
  • Хлопать (Упрощенное ядро ​​обязательного контроля доступа) это Ядро Linux модуль безопасности который защищает данные и взаимодействие процессов от злонамеренных манипуляций с помощью набора настраиваемых правил обязательного контроля доступа, при этом простота является основной целью разработки.[21] Он был официально объединен с момента выпуска Linux 2.6.25.[22]
  • ZeroMAC написано Питер Габор Дьюлай это патч ядра Linux LSM.[23]

Смотрите также

Сноски

  1. ^ Белим, С. В .; Белим, С.Ю. (Декабрь 2018 г.). «Внедрение обязательного контроля доступа в распределенных системах». Автоматическое управление и компьютерные науки. 52 (8): 1124–1126. Дои:10.3103 / S0146411618080357. ISSN 0146-4116.
  2. ^ http://csrc.nist.gov/publications/history/dod85.pdf
  3. ^ «Техническое обоснование CSC-STD-003-85: Требования к компьютерной безопасности». 1985-06-25. Архивировано из оригинал 15 июля 2007 г.. Получено 2008-03-15.
  4. ^ "Портал общих критериев". Архивировано из оригинал на 2006-07-18. Получено 2008-03-15.
  5. ^ Министерство обороны США (декабрь 1985 г.). «DoD 5200.28-STD: критерии оценки доверенных компьютерных систем». Получено 2008-03-15.
  6. ^ «Профиль защиты контролируемого доступа, версия 1.d». Национальное Агенство Безопасности. 1999-10-08. Архивировано из оригинал на 2012-02-07. Получено 2008-03-15.
  7. ^ «Профиль защиты для многоуровневых операционных систем в средах, требующих средней надежности, версия 1.22» (PDF). Национальное Агенство Безопасности. 2001-05-23. Получено 2018-10-06.
  8. ^ Национальное партнерство по обеспечению информации. «Список одобренных продуктов по схеме оценки и валидации по общим критериям». Архивировано из оригинал на 2008-03-14. Получено 2008-03-15.
  9. ^ «TOMOYO Linux, альтернативный обязательный контроль доступа». Linux 2 6 30. Новички в ядре Linux.
  10. ^ «Linux 2.6.36 выпущен 20 октября 2010 г.». Linux 2.6.36. Новички в ядре Linux.
  11. ^ «Почему grsecurity не использует LSM?».
  12. ^ Мэтью Коновер. «Анализ модели безопасности Windows Vista». Symantec Corporation. Архивировано из оригинал на 2008-03-25. Получено 2007-10-08.
  13. ^ Стив Райли. «Обязательный контроль целостности в Windows Vista». Получено 2007-10-08.
  14. ^ Марк Руссинович. «PsExec, Контроль учетных записей пользователей и границы безопасности». Получено 2007-10-08.
  15. ^ Проект TrustedBSD. "Структура обязательного контроля доступа (MAC) TrustedBSD". Получено 2008-03-15.
  16. ^ "man-страница sandbox_init (3)". 2007-07-07. Получено 2008-03-15.
  17. ^ «SEPostgreSQL-патч».
  18. ^ «PostgreSQL с усиленной безопасностью».
  19. ^ «РУБИКС, которому доверяют». Архивировано из оригинал на 2008-11-21. Получено 2020-03-23.
  20. ^ (на русском) Ключевые особенности Astra Linux Special Edition по реализации требований информации безопасности В архиве 2014-07-16 в Wayback Machine
  21. ^ "Официальная документация SMACK из дерева исходных текстов Linux". Архивировано из оригинал на 2013-05-01.
  22. ^ Джонатан Корбет. "Еще кое-что для 2.6.25". Архивировано из оригинал на 2012-11-02.
  23. ^ "zeromac.uk".

Рекомендации

внешняя ссылка

  • Запись в блоге о том, как виртуализацию можно использовать для реализации обязательного контроля доступа.
  • Запись в блоге от сотрудника Microsoft, в котором подробно рассказывается об обязательном контроле целостности и его отличиях от реализаций MAC.
  • Модель официальной политики безопасности GWV Формальная политика безопасности разделительного ядра, Дэвид Грев, Мэтью Уилдинг и У. Марк Ванфлит.