Мандатная модель управления доступом (Mandatory Access Control, MAC) — способ разграничения доступа с фиксированным набором полномочий. Обычно настоящий MAC используется в системах с повышенным требованиями к безопасности и стоит на службе всевозможных силовых ведомств и организаций, связанных с государственной или служебной тайной. 

Модель MAC


MAC несмотря на то, что содержится во множестве статей и материалов, чаще всего упоминается вскользь и в виде пряного соуса к чему-нибудь вроде краткого упоминания MLS в SELinux. Так как многие ограничивают свою дружбу с SELinux применением рецепта «как отключить SELinux», то и MAC часто удостаивается той же чести. Поэтому сперва коротко о MAC.

Если вы хорошо знакомы с моделью, можете сразу перейти к следующему разделу.

Основная идея


Абстрактная модель безопасности, реализуемая в классическом MAC (каким его знают сотрудники силовых ведомств), выглядит следующим образом (классическая картинка, иллюстрирующая модель Белла — Лападулы):



Модель MAC по своей сути является «электронной» реализацией бумажного «секретного» документооборота. В MAC имеются следующие «действующие лица»:

  • Иерархия уровней доступа, которые обрабатываются в системе (обычно регистрируются в ОС). Для удобства часто задается в виде беззнаковых чисел (от 0 до значения, ограниченного реализацией). В этом случае для сравнения уровней доступа (выше/ниже/равно) используются простейшие арифметические операции (равно, меньше, больше).
  • Объект с уровнем секретности. Любой файл, каталог в файловой системе, ячейка или запись в таблице БД, таблица в БД, сама БД, сетевой пакет и т.д. Объекту присваивается любое значение из иерархии уровней доступа. Для объекта допускается повышение уровня секретности (изменение до большего значения уровня, чем текущий). Понижение уровня секретности категорически не допускается (хотя вполне реализуемо при помощи определенных уловок).
  • Субъект с уровнем доступа. Процесс какого-либо приложения либо сеанс пользователя (по сути тоже процесс приложения). Метка уровня доступа наследуется от субъекта всеми создаваемыми данным субъектом объектами. 


Значение уровня доступа субъекта или уровня секретности объекта обычно называют термином «мандатный уровень», «мандатная метка» или просто «метка» (в STCSEC данный термин называется «hierarchical classification level»). Просто, емко и почти однозначно. 

Проверка полномочий осуществляется при каждом факте доступа субъекта к объекту, защищаемому MAC. При этом мандатная модель управления доступом обычно используется совместно с другими механизмами контроля доступа, например, DAC (UNIX-моделью и POSIX ACL). При этом MAC проверяется в последнюю очередь. Сперва проверяется доступ по DAC (как наименее защищенный), а затем уже MAC.

При проверке правомочности доступа субъекта к объекту согласно мандатной модели возможны следующие комбинации:

  1. Мандатная метка субъекта равна мандатной метке объекта. В этом случае субъекту разрешено читать и изменять объект.
  2. Мандатная метка субъекта выше мандатной метки объекта. Субъекту разрешено только читать объект: он его видит, но не может изменить.
  3. Мандатная метка субъекта ниже мандатной метки объекта. Субъекту формально разрешено создать объект с более высокой мандатной меткой (так называемое «повышение уровня секретности объекта»). На практике у субъекта нет технической возможности для выполнения данной операции (он просто «не видит» изменяемый объект, например, файл или каталог с файлами).


Также в MAC существует такое понятие, как «категория» (в терминологии STCSEC данный термин называется «non-hierarchical categories»). Категории в MAC являются опциональными к применению. В практике реализации MAC категории используются для «горизонтального» разграничения доступа между различными подразделениями организации. В этом случае сотрудники, несмотря на один мандатный уровень, будут получать доступ только к тем категориям объектов, к которым для них открыт доступ согласно их метке.

Ограничения и уязвимости



MAC обладает своими ограничениями и особенностями:

  1. Пользователи системы не могут самостоятельно определять доступ субъектов к объектам. Из всего арсенала управления доступом к объекту в MAC имеется только мандатная метка и мандатная категория, которые привязаны к этому объекту. Управление доступом субъектов к объектам осуществляют только администраторы.
  2. Если пользователь хочет изменить мандатную метку объекта, автором которого он является, то ему необходимо перейти в сеанс целевой метки. Связано с тем, что пользователь не может указать метку по своему желанию, а может лишь передать метку объекту «по наследству». Одновременно пользователь может работать только в сеансе одной мандатной метки.
  3. Так как MAC используется совместно с другими моделями управления доступом, возникают коллизии: иногда не так просто выяснить, в каком «слое» системы безопасности произошёл отказ в предоставлении доступа. Требуется тонкий «тюнинг» всех слоёв защиты.
  4. Помимо самой настройки доступа посредством инструментария MAC требуется наличие регламента безопасности. В нём должно быть описано, что значат конкретные значения мандатных меток (это находится за пределами MAC), какие объекты как защищаются, какие субъекты имеют право на доступ. Без наличия согласованного регламента MAC сама по себе не даст security enhancement.
  5. Использование MAC в распределённой сетевой инфраструктуре. Традиционный подход к настройке MAC — локально, вручную, при помощи администратора в соответствии с инструкцией. Есть решения, позволяющие реализовать централизованно управляемое хранилище MAC (вроде ALD), но они имеют свои особенности и сложности построения.


Проектирование приложения с поддержкой MAC



Несмотря на все ограничения модели, для тех, кто работает с госсектором, а в особенности с силовыми ведомствами, вопрос построения приложений с поддержкой мандатной модели управления доступом актуален как никогда. Вдруг завтра именно вам придется поддерживать MAC в своем продукте?

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

Итак, что у нас есть в наборе:


Каким бы странным ни выглядел данный аспект взаимодействия по сравнению с рассмотренными ранее, но не остановиться на нем нельзя. Ведь именно для пользователя чаще всего строятся приложения с поддержкой MAC, не так ли?

Приложение с поддержкой MAC практически ничем не отличается от такового без MAC в части пользовательского интерфейса во всех режимах, за исключением режима одновременной работы с несколькими мандатными метками.

На примере распространенных сегодня веб-приложений чаще всего встречаются следующие кейсы:
Системное ПО
Описание
ОС Astra Linux Special Edition / SELinux
ОС с поддержкой MAC. Предоставляет хранилище информации о мандатных разрешениях пользователей, связанное с хранилищем пользователей операционной системы. Предоставляет механизмы контроля доступа к объектам, защищаемым MAC (объектам файловой системы, запуску приложений в режиме мандатной метки и т.д.).