Из Википедии, свободной энциклопедии
Перейти к навигацииПерейти к поиску

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

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

Исторически и традиционно MAC был тесно связан с многоуровневой безопасностью (MLS) и специализированными военными системами. В этом контексте MAC подразумевает высокую степень строгости, чтобы удовлетворить ограничения систем MLS. Однако в последнее время MAC вышел из ниши MLS и стал более популярным. Более поздние реализации MAC, такие как SELinux и AppArmor для Linux и Mandatory Integrity Control для 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] Были определены два относительно независимых компонента устойчивости: уровень доверия и функциональность. Оба были указаны с такой степенью точности, которая гарантирует значительную уверенность в сертификации, основанной на этих критериях.

Оценка

В Common Criteria [4] основана на этой науке и он намерен сохранить уровень доверия , как уровни EAL и спецификации функциональности как Protection Profiles . Из этих двух основных компонентов объективных тестов устойчивости точно сохранились только уровни EAL. В одном случае уровень C2 [5] TCSEC (не относящаяся к категории MAC) был достаточно точно сохранен в общих критериях как профиль защиты контролируемого доступа (CAPP). [6] Профили защиты многоуровневой безопасности (MLS) (такие как MLSOSPP, аналогичные B2) [7] является более общим, чем B2. Они соответствуют MLS, но не имеют подробных требований к реализации, как их предшественники Orange Book , уделяя больше внимания целям. Это дает органам по сертификации более субъективную гибкость при принятии решения о том, адекватно ли технические характеристики оцениваемого продукта достигают цели, что потенциально снижает согласованность оцениваемых продуктов и упрощает получение сертификата для менее надежных продуктов. По этим причинам важность технических деталей профиля защиты имеет решающее значение для определения пригодности продукта.

Такая архитектура не позволяет аутентифицированному пользователю или процессу на определенной классификации или уровне доверия получить доступ к информации, процессам или устройствам на другом уровне. Это обеспечивает механизм сдерживания пользователей и процессов, как известных, так и неизвестных (неизвестная программа (например) может содержать ненадежное приложение, в котором система должна отслеживать и / или контролировать доступ к устройствам и файлам).

Реализации

Несколько реализаций MAC, такие как Unisys ' Blacker проект, были сертифицированы достаточно прочной , чтобы отделить Совершенно секретно от несекретного в конце прошлого тысячелетия. Их базовая технология устарела, и они не обновлялись. Сегодня нет текущих реализаций, сертифицированных TCSEC для такого уровня надежной реализации. Однако существуют менее надежные продукты.

  • RSBAC (Контроль доступа на основе набора правил) Амона Отта обеспечивает основу для ядер Linux, которая позволяет использовать несколько различных модулей политики / принятия решений. Одна из реализованных моделей - модель обязательного контроля доступа. Общая цель разработки RSBAC состояла в том, чтобы попытаться достичь (устаревшего) уровня B1 Orange Book (TCSEC). Модель принудительного контроля доступа, используемая в RSBAC, в основном такая же, как и в Unix System V / MLS, версия 1.2.1 (разработана в 1989 году Национальным центром компьютерной безопасности США по классификации B1 / TCSEC). RSBAC требует набора исправлений для стандартного ядра, которые достаточно хорошо поддерживаются владельцем проекта.
  • NSA исследовательский проект под названием SELinux добавил Обязательную архитектуры управления доступом к среде Linux Kernel , который был слит в версию магистральной в Linux в августе 2003. Он использует функцию ядра 2.6 Linux под названием LSM (Linux интерфейс модулей безопасности). Red Hat Enterprise Linux версии 4 (и более поздних версий) поставляется с ядром с поддержкой SELinux. Хотя SELinux может ограничивать все процессы в системе, целевая политика по умолчанию в RHEL ограничивает наиболее уязвимые программы из неограниченного домена, в котором выполняются все другие программы. RHEL 5 поставляет 2 других типа бинарной политики: строгий, который пытается реализовать наименьшие привилегии , и MLS , который основан на strict и добавляет метки MLS . RHEL 5 содержит улучшение дополнительных MLS и получил 2 LSPP / RBACPP / CAPP / EAL4 + сертификаты в июне 2007 года [8]
  • TOMOYO Linux - это облегченная реализация MAC для Linux и Embedded 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 как в лучшем случае DAC для некоторых устройств - хотя это верно для любой доступной сегодня бытовой электроники.
  • grsecurity - это патч для ядра Linux, обеспечивающий реализацию MAC (точнее, реализацию RBAC ). grsecurity не реализуется через LSM API. [11]
  • Microsoft Начиная с Windows Vista и Server 2008 Windows включает обязательный контроль целостности , который добавляет уровни целостности (IL) к процессам, выполняющимся в сеансе входа в систему. MIC ограничивает права доступа приложений, которые работают под одной и той же учетной записью и могут быть менее надежными. Определены пять уровней целостности: низкий, средний, высокий, системный и надежный установщик. [12] Процессы, запущенные обычным пользователем, получают средний уровень интеллекта; повышенные отростки имеют высокий ИЖ. [13] Хотя процессы наследуют уровень целостности процесса, который их породил, уровень целостности можно настроить для каждого процесса: например, IE7а загруженные исполняемые файлы работают с низким IL. Windows контролирует доступ к объектам на основе IL, а также для определения границ оконных сообщений с помощью изоляции привилегий пользовательского интерфейса . Именованные объекты , включая файлы , ключи реестра или другие процессы и потоки , имеют запись в ACL, управляющую доступом к ним, которая определяет минимальный IL процесса, который может использовать объект. MIC требует, чтобы процесс мог записывать или удалять объект только тогда, когда его IL равен или выше, чем IL объекта. Более того, чтобы предотвратить доступ к конфиденциальным данным в памяти, процессы не могут открывать процессы с более высоким IL для доступа на чтение.[14]
  • FreeBSD поддерживает обязательный контроль доступа , реализованный как часть проекта TrustedBSD. Он был представлен во FreeBSD 5.0. Начиная с FreeBSD 7.2, поддержка MAC включена по умолчанию. Фреймворк расширяемый; различные модули MAC реализуют такие политики, как Biba и многоуровневая безопасность .
  • Sun Trusted 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 вместе с ограничениями на уровне строк.
  • Trusted RUBIX - это СУБД с принудительным контролем доступа, которая полностью интегрируется с SE-Linux для ограничения доступа ко всем объектам базы данных. [19]
  • ОС Astra Linux, разработанная для российской армии, имеет собственный принудительный контроль доступа. [20]
  • Smack ( Simplified Mandatory Access Control Kernel ) - это модуль безопасности ядра Linux, который защищает данные и взаимодействие процессов от злонамеренных манипуляций с помощью набора настраиваемых правил обязательного контроля доступа, при этом простота является основной целью разработки. [21] Он был официально объединен с момента выпуска Linux 2.6.25. [22]
  • ZeroMAC, написанный Питером Габором Дьюлаем, представляет собой патч ядра Linux LSM. [23]

См. Также

  • Модель Белла – ЛаПадулы
  • Список контроля доступа
  • Атрибутный контроль доступа (ABAC)
  • Контроль доступа на основе контекста (CBAC)
  • Дискреционный контроль доступа (DAC)
  • Управление доступом на основе решеток (LBAC)
  • Управление доступом на основе организации (OrBAC)
  • Управление доступом на основе ролей (RBAC)
  • Контроль доступа на основе набора правил (RSBAC)
  • Безопасность на основе возможностей
  • Аутентификация на основе местоположения
  • Риск-ориентированная аутентификация
  • Модель Кларка – Уилсона
  • Классифицированная информация
  • Модель Грэма-Деннинга
  • Обязательный контроль целостности
  • Несколько одноуровневых
  • Режимы безопасности
  • Smack (программное обеспечение)
  • Systrace
  • Модель защиты от взятия гранта
  • Тип принудительного исполнения

Сноски

  1. ^ Белим, SV; Белим, С.Ю. (Декабрь 2018 г.). «Внедрение обязательного контроля доступа в распределенных системах» . Автоматическое управление и компьютерные науки . 52 (8): 1124–1126. DOI : 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 года . Проверено 15 марта 2008 .
  4. ^ "Портал общих критериев" . Архивировано из оригинала на 2006-07-18 . Проверено 15 марта 2008 .
  5. ↑ Министерство обороны США (декабрь 1985 г.). «DoD 5200.28-STD: критерии оценки доверенных компьютерных систем» . Проверено 15 марта 2008 .
  6. ^ «Профиль защиты контролируемого доступа, версия 1.d» . Национальное Агенство Безопасности. 1999-10-08. Архивировано из оригинала на 2012-02-07 . Проверено 15 марта 2008 .
  7. ^ «Профиль защиты для многоуровневых операционных систем в средах, требующих средней устойчивости, версия 1.22» (PDF) . Национальное Агенство Безопасности. 2001-05-23 . Проверено 6 октября 2018 .
  8. ^ Национальное партнерство по обеспечению информации. «Список утвержденных продуктов по схеме оценки и валидации по общим критериям» . Архивировано из оригинала на 2008-03-14 . Проверено 15 марта 2008 .
  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 . Проверено 8 октября 2007 .
  13. ^ Стив Райли. «Обязательный контроль целостности в Windows Vista» . Проверено 8 октября 2007 .
  14. ^ Марк Руссинович . «PsExec, Контроль учетных записей пользователей и границы безопасности» . Проверено 8 октября 2007 .
  15. ^ Проект TrustedBSD. «Структура обязательного контроля доступа (MAC) TrustedBSD» . Проверено 15 марта 2008 .
  16. ^ "man-страница sandbox_init (3)" . 2007-07-07 . Проверено 15 марта 2008 .
  17. ^ "SEPostgreSQL-патч" .
  18. ^ "PostgreSQL с усиленной безопасностью" .
  19. ^ "Надежный RUBIX" . Архивировано из оригинала на 2008-11-21 . Проверено 23 марта 2020 .
  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" .

Ссылки

  • PA Loscocco, SD Smalley, PA Muckelbauer, RC Taylor, SJ Turner и JF Farrell. Неизбежность отказа: ошибочное предположение о безопасности в современных вычислительных средах . В материалах 21-й Национальной конференции по безопасности информационных систем, страницы 303–314, октябрь 1998 г.
  • PA Loscocco, SD Smalley, Достижение критических целей безопасности с помощью улучшенной безопасности Linux Труды на симпозиуме по Linux в Оттаве в 2001 году.
  • ISO / IEC DIS 10181-3, Информационные технологии, Модель безопасности OSI, Security FrameWorks, Часть 3: Контроль доступа, 1993
  • Роберт Н. М. Уотсон. « Десятилетие расширяемости ОС для контроля доступа ». Commun. ACM 56, 2 (февраль 2013 г.), 52–63.

Внешние ссылки

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