Мандатная модель управления доступом (MAC): обзор и применение в прикладных системах

Мандатная модель управления доступом (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.

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

Системное ПО	Описание
ОС Astra Linux Special Edition / SELinux	ОС с поддержкой MAC. Предоставляет хранилище информации о мандатных разрешениях пользователей, связанное с хранилищем пользователей операционной системы. Предоставляет механизмы контроля доступа к объектам, защищаемым MAC (объектам файловой системы, запуску приложений в режиме мандатной метки и т.д.).
СУБД PostgreSQL (PostgresPro)	Имеет интеграцию с хранилищем учетных записей и мандатных меток ОС. СУБД предоставляет функциональность присваивания мандатной метки к таким объектам, как кластер, база данных, таблица, столбец и запись.
Веб-сервер с поддержкой MAC (Apache Http Server)	Ретранслирует мандатную метку от запроса клиента с поддержкой MAC и запускает обработчик приложения (скрипт/службу) с идентичной меткой и передачей данных аутентификации пользователя.
Браузер с поддержкой MAC (Mozilla Firefox)	Считывает мандатную метку сеанса пользователя (графической оболочки пользователя) и добавляет ее в запросы к веб-приложениям.

Теперь рассмотрим, каким образом можно воспользоваться этой инфраструктурой при разработке приложения для сохранения функций управления доступом на уровне инфраструктуры.

Для того чтобы приложение могло воспользоваться механизмом мандатных меток операционной системы, должны быть выполнены следующие условия:

• Пользователи приложения должны быть зарегистрированы в хранилище пользователей операционной системы. Как минимум должен быть какой-то идентификатор, позволяющий однозначно сопоставить пользователя приложения с пользователем операционной системы (обычно это логин).
• Пользователям приложения на уровне механизма MAC операционной системы должны быть настроены мандатные разрешения на определённые мандатные метки (диапазоны мандатных меток).

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

1. Пользователь входит в ОС под своей личной УЗ в режиме требуемой ему метки. Запускает приложение. Процесс приложения наследует мандатную метку.
2. Приложение взаимодействует с БД на PostgreSQL, отображая пользователю, к примеру, только записи таблиц БД с текущей мандатной меткой.

С точки зрения серверного приложения, предоставляющего веб-сервисы, сценарий работы пользователя концептуально близок, хотя и выглядит немного сложнее:

1. Пользователь входит в ОС под своей личной УЗ в режиме требуемой ему метки. Запускает браузер с поддержкой MAC, в нашем примере — Mozilla Firefox («обычный» браузер для этих целей не подойдет). Процесс браузера наследует мандатную метку.
2. Пользователь запрашивает адрес ресурса приложения с поддержкой мандатных меток. Браузер формирует запрос, добавляя в него мандатную метку.
3. Запрос обрабатывает веб-сервер с поддержкой мандатных меток, в нашем примере — Apache Http Server. Веб-сервер (процесс которого работает в режиме минимальной мандатной метки) считывает мандатную метку запроса, находит приложение-обработчик запускает его процесс с переданной мандатной меткой.
4. Приложение взаимодействует с БД на PostgreSQL, ретранслируя в запросах мандатную метку.

Наличие MAC в операционной системе накладывает достаточно серьезные ограничения на архитектуру приложения. То, что в ОС без мандатной модели управления доступом кажется тривиальным, в ОС с MAC может принести множество сюрпризов всей команде разработки. Особенно руководителю проекта. Поэтому архитектурное решение приложения с поддержкой MAC должно быть построено до начала разработки. Руководитель проекта с MAC должен настоять на том, чтобы проектирование было выполнено архитектурной группой до начала каких-либо движений в сторону реализации.

Разумеется, для разработки простых приложений (утилит либо приложений, ввиду своей специфики нейтральных к MAC) многие советы попросту не пригодятся. Если же приложение является чем-то более сложным, чем однопользовательское локальное приложение, считывающее файл и записывающее результат своей работы также в файл, то желательно четко осознавать «подводные камни».

Мы собрали рецепты по проектированию приложения с поддержкой MAC, сформулированные на основе собственного опыта. За ними стоят бессонные ночи, непрерывный поток тикетов от тестирования, тысячи часов отладки приложения, которое по всем здравым смыслам должно работать правильно, но почему-то работает не так. Рецепты описаны в максимально простой и нейтральной к технологиям и инструментам форме, и по возможности снабжены схемами для улучшения воспринимаемости. Поехали!

Как избежать MAC, когда его уже не избежать

При проектировании приложения с MAC можно использовать одно очень простое архитектурное решение, которое в итоге сэкономит много нервов и времени. В конфигурацию приложения следует добавить параметр, который сообщает приложению, включена ли мандатная модель управления доступом для данной инсталляции, или нет. Во всех местах приложения, где происходит взаимодействие с инфраструктурой MAC, либо бизнес-функция приложения требует проверки метки, следует сперва проверять значение этого параметра. Если MAC согласно ему отключена, то приложение игнорирует все правила бизнес-логики, предназначенные для проверки MAC-совместимых функций.

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

За счет данного решения можно обеспечить приложению (и всей команде разработки), которое вынуждено функционировать в среде MAC, следующие преимущества:

• Кроссплатформерность приложения (ограниченную только лишь возможностями языков программирования) и его независимость от среды выполнения.
• Возможность использования современных инструментов виртуализации (например, Docker) с целью автоматизации.
• Простоту тестирования и отладки функций, которые не связаны непосредственно с MAC.

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

Добавить параметр включения/отключения поддержки мандатных меток в приложении.

Во всех местах, требующих взаимодействия с MAC, прежде всего проверять значение параметра.

При отладке и тестировании необходимо отлаживать (на стороне команды разработки) и тестировать (на стороне команды тестирования) оба режима работы приложения.

Разделяй и властвуй

Другой важный шаг при проектировании, который обязательно должен быть выполнен до начала разработки — разделение модулей, в которых требуется поддержка MAC, от модулей, в которых данный механизм управления доступом не требуется. Использование мандатной модели управления доступом почти всегда усложняет бизнес-логику приложения.

Это та самая инфраструктура, абстрагироваться от которой очень сложно, а порой невозможно. Поэтому приложение следует разбить на модули, а уже по каждому модулю произвести анализ потребности в поддержке MAC. Возможно, именно в вашем случае достаточно поддержать MAC только в одном модуле, и нет смысла из-за данного модуля усложнять все приложение?

Рекомендация:  Следует разделить приложение на модули и классифицировать их по режимам обработки мандатных меток.

В случае, если мы рассматриваем некий абстрактный модуль (или все приложение, если деление приложения на модули не требуется) возможны следующие парадигмы:

• Минимальная метка. Модуль обрабатывает данные в режиме минимальной мандатной метки (минимальная метка, в которой функционируют процессы ОС — например, 0 мандатная метка) либо без мандатной метки.
• Одна метка. Модуль работает с данными только одной мандатной метки выше минимальной мандатной метки (любой метки, отличной от той, в которой функционируют процессы ОС).
• Несколько меток. Модуль работает с данными сразу нескольких мандатных меток (как метки, в которой функционируют процессы ОС, так и других меток, отличных от метки процессов ОС).

Модулям приложения с различными парадигмами обработки мандатных меток не стоит знать друг о друге слишком много. Иначе это чревато возникновением больших и непредсказуемых проблем в части конфликтов доступа к различным объектам и т.д. Идея минимальной связности для модулей очевидна. В случае работы с MAC следует проявлять особую бдительность и следить за всеми «связями» модулей.

Рекомендация: При проектировании следует обеспечивать минимальную связность (cohesion) модулей, работающих в различных парадигмах обработки мандатных меток.

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

Классификация модулей по режимам обработки MAC

«BRING IT ON»: работа модуля в режиме минимальной мандатной метки

Мотивация для реализации данного механизма в модуле:

• Модуль обрабатывает информацию, которая в принципе не может обрабатываться в системе с другими мандатными метками, и не требует особых привилегий для чтения/записи.
• Модуль сильно связан с инфраструктурой ОС, которая ограничивает его функционирование в режиме мандатной метки, отличной от минимальной.

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

Примеры практических кейсов, для которых подходит использование режима минимальной мандатной метки:

• Управление учетными записями пользователей в хранилище приложения. Например, если приложение ведет собственный учет УЗ в файле или БД. Все данные, касающиеся безопасности и управления доступом к приложению, обязательно должны храниться в режиме минимальной мандатной метки, иначе модель безопасности приложения будет попросту «рассыпаться» при выполнении приложения в режиме повышенной мандатной метки. Именно по этой причине все системные приложения запускаются строго под минимальной мандатной меткой.
• Управление правами доступа. Например, если в приложении реализована собственная модель разграничения доступа на уровне бизнес-логики. 
• Управление параметрами конфигурации приложения, которые должны быть доступны под всеми мандатными метками.
• Управление учетными записями в ОС. Если приложению требуется управлять какими-либо атрибутами УЗ в ОС, все операции должны выполняться строго под минимальной мандатной меткой.

«HURT ME PLENTY»: работа модуля в режиме одной мандатной метки

Этот кейс чуть сложнее, но во многом похож на случай с минимальной мандатной меткой. С точки зрения пользователя работа с приложением меняется не сильно: все те же привычные списки записей, карточки и операции «Просмотр», «Редактировать» и «Сохранить». С той лишь разницей, что в данном режиме пользователь видит только те записи, которые соответствуют мандатной метке его текущего сеанса.

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

Данный кейс может быть полезен в следующих случаях:

• Была допущена ошибка в архитектуре при проектировании модуля (не были заложены особенности обработки записей в MAC), и нет ни времени, ни ресурсов все переписывать.
• Поддержка мандатной модели управления доступом вводится в уже функционирующее приложение, и в соответствии с требованиями необходимо обеспечить работу с меткой выше минимальной в ОС. Да, это тот самый случай, когда к вам приходит руководитель и сообщает с радостью, что мы выиграли конкурс и будем внедрять наше решение в «наименование секретного ведомства»!
• Нет целесообразности в реализации полной поддержки одновременной обработки записей нескольких мандатных меток. Нет необходимости в одновременной обработки записей сразу нескольких мандатных меток.
• Приложение функционирует в однопользовательском режиме.

C точки зрения реализации данный кейс не является очень простым, так как нам необходимо:

• Выбирать только те записи, которые соответствуют текущей мандатной метке, так как в соответствии с моделью Белла – Лападулы пользователь будет видеть записи текущей мандатной метки и всех мандатных меток, расположенных ниже по иерархии.
• Проверять мандатную метку перед выполнением какой-либо операции внесения изменений в запись. При попытке внести изменение в запись с мандатной меткой, отличающейся от мандатной метки сеанса, выполнение операции должно быть прервано.

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

При выполнении операций в модуле рекомендуется сверять мандатную метку текущего процесса приложения с мандатной меткой по умолчанию. Если мандатная метка модуля не соответствует мандатной метке сеанса, то пользователь не должен быть допущен к выполнению операции.

Примеры практических кейсов, для которых подходит использование режима одной мандатной метки:

• Расписание. Например, для нескольких мандатных меток формируются отдельные расписания (работы сотрудников, графики и т.д.). В каждом из сеансов из перечня допустимых мандатных меток отображается свое расписание, и добавление информации по другим мандатным меткам усложнит восприятие и создаст пространство для дополнительных ошибок. Внесение изменений в расписание производится также в сеансе только своей мандатной метки.
• Мессенджер. Сообщение, отправленное в сеансе вышестоящей мандатной метки, не будет доступно получателю (или получателям) в сеансе нижестоящей мандатной метки. Поэтому логично «расслоить» мессенджер на различные сеансы, где у каждого адресата будет несколько «каналов общения», отдельный «канал» под каждую мандатную метку.

«NIGHTMARE!»: работа модуля в режиме нескольких мандатных меток

Данный режим работы полезен только в том случае, когда в одном сеансе работы с модулем нам необходимо отображать информацию по всем мандатным меткам, расположенным ниже мандатной метки текущего сеанса по иерархии.

При проектировании необходимо описать функциональные требования к модулю, а в детализации каждого функционального требования указать перечень взаимодействий в части мандатной модели (возможные варианты рассмотрены ниже в разделе «Взаимодействие приложения с окружающей средой»). Это позволит выделить какие-то общие концепции взаимодействия с инфраструктурой в части мандатных меток. Также эта информация будет крайне полезна для оценки сложности разработки и при дальнейшем тестировании.

С точки зрения реализации пользовательского интерфейса обычно используются следующие шаблоны:

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

Дальнейший набор бизнес-процессов зависит от сложности бизнес-логики модуля и специфики обработки данных. Например, можно сделать фильтрацию коллекции записей по мандатной метке. Можно вывести мандатную метку записи в интерфейсе.

Простор комбинаций огромнейший, как и пространство для появления ошибок. Поэтому не рекомендуется обрабатывать в рамках одного юзкейса записи с различной мандатной меткой при наличии какой-либо бизнес-логики. Любые операции с коллекцией записей должны производиться с явным указанием мандатной метки, общей для всей коллекции. Обработали третью метку, затем вторую, и т.д.

Для реализации такого режима необходимо заложить следующие функции:

• Функция получение мандатной метки текущего процесса приложения (сеанса пользователя).
• Функция получения мандатной метки записи (если речь идет о работе с записью в БД) или файла (если речь идет об обработке файлов).
• Функция получения мандатной метки записей БД/файлов в коллекции.

Примеры практических кейсов, для которых годится режим нескольких мандатных меток:

1. Отчетность. Для реализации данного кейса нам необходимо аккумулировать максимум информации по системе, которая доступна для сеанса с текущей мандатной меткой.
2. Журнал. В этом случае разрабатывается интерфейс просмотра всех доступных для просмотра операций с возможностью фильтрации, в том числе и по мандатной метке.

Взаимодействие приложения с окружающей средой

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

• Операционная система:
  
  • Параметры мандатной модели:
    
    • Иерархия мандатных меток ОС;
    • Мандатные разрешения (диапазоны меток, которые может использовать определенный пользователь) УЗ пользователей ОС.
  • Хранилище учетных данных пользователей;
  • Аутентификация в ОС (в том числе с учётом мандатной метки);
  • Другие механизмы управления доступом (дискреционные POSIX ACL, UNIX и т.д.);
  • Работа с ФС;
  • Управление процессами;
  • Работа с сетью;
• Стороннее ПО без поддержки MAC;
• Стороннее ПО с поддержкой MAC:
  
  • СУБД (например, PostgreSQL):
    
    • Объекты БД (ячейки, строки, столбцы, схемы, таблицы, БД, кластеры, последовательности, функции и т.д.).
• Пользователь.

Нюансы взаимодействия с каждым из компонентов рассмотрим отдельно.

Взаимодействие MAC-совместимого приложения с операционной системой

MAC очень «радует» своими трудностями по настройке правил доступа в файловой системе. Например, львиная доля ошибок в приложениях с MAC связана именно с тем, что приложение в режиме текущей мандатной метки не видит файл, но файл при этом существует в режиме другой мандатной метки (уровнем выше).

Чего мы ожидаем от операционной системы в части MAC?

Если наше приложение работает в многопользовательском режиме, то ему наверняка потребуется запрашивать информацию об учетных записях пользователей, данные которых оно обрабатывает. Это необходимо для поддержки разграничения доступа пользователей. Поэтому приложению потребуется запрашивать у ОС информацию о мандатных разрешениях пользователей.  Если УЗ пользователя в ОС управляется нашим приложением, тогда нам потребуется не только читать информацию об УЗ, но и управлять атрибутами УЗ.

Наиболее вероятные потоки взаимодействий ОС и приложения изображены на схеме:

Взаимодействие MAC-совместимого приложения со сторонним ПО без поддержки MAC

Большая часть приложений, которые могут использоваться в ОС с MAC, не умеют обрабатывать MAC. 

Поэтому при организации такого взаимодействия требуется эмулировать мандатную метку при передаче данных или запроса процессу такого приложения. Реализуется это путем «расслоения» потока данных на отдельные каналы, каждый из которых логически предназначен для данных с определенной мандатной меткой. Смешивать такие данные категорически запрещается, они должны идти по отдельным очередям, каналам и чуть ли не по отдельным жилам витых пар сетевым интерфейсам. Правомерность «логической» реализации разделения данных по MAC тоже является неоднозначным вопросом, поэтому чаще всего лежит на совести заказчика и разработчика приложения.

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

Взаимодействие MAC-совместимого приложения со сторонним ПО с поддержкой MAC

В случае взаимодействия с ПО с поддержкой MAC наше приложение должно явно уметь считывать метку процесса, который осуществляет запрос, и выполнять операцию в соответствии с мандатной моделью управления доступом. От приложения, взаимодействующего с таким ПО, требуется только лишь выполнение запросов к стороннему приложению/процессу из процесса с корректной мандатной меткой.

Пример популярного приложения с полноценной поддержкой мандатных меток — СУБД PostgresSQL. В определенных вариантах поставки данной СУБД реализована полная поддержка MAC под некоторые ОС с механизмами MAC, например: 

• Astra Linux: PostgreSQL, идущий в поставке дистрибутива версии SE.
• SELinux: расширение sepgsql.

PostgreSQL позволяет разделять данные по мандатным меткам (есть еще поддержка мандатных категорий, но нас интересуют метки) на следующих уровнях:

• На уровне кластера.
• На уровне БД кластера.
• На уровне схемы БД кластера.
• На уровне таблицы схемы БД кластера.
• На уровне столбца таблицы схемы БД кластера.
• На уровне записи таблицы схемы БД кластера.

В результате в реализации MAC получается такая «матрешка»: каждый «родительский» уровень накладывает свои ограничения на все «дочерние» уровни. Поэтому при реализации взаимодействия с каждым подобным приложением с полноценной поддержкой MAC требуется учитывать его специфику работы. Универсальных рецептов нет.

Взаимодействие MAC-совместимого приложения с пользователем

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

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

На примере распространенных сегодня веб-приложений чаще всего встречаются следующие кейсы:

Кейс	Что требуется предусмотреть
Аутентификация и работа пользователя с сессией	Пользователь должен в каждый момент времени понимать, под какой мандатной меткой его видит приложение. Для этих целей приложение должно отображать простой и понятный индикатор мандатной метки сеанса пользователя, который будет доступен на каждом экране приложения. Также данная функция очень сильно облегчит жизнь тестировщикам приложения.
Отображение списка записей (грида записей) в режиме одновременной обработки нескольких мандатных меток с элементами управления	Стандартный для современных веб-приложений кейс. Нюансы: Пользователю необходимо дать четко понять, какая мандатная метка имеется у каждой записи. Пользователь должен иметь возможность отфильтровать список записей по значению мандатной метки. При выборе одной записи пользователю должно быть понятно, почему с одной записью можно выполнить одну операцию (например, просмотр подробной информации о записи), и нельзя выполнить другую (например, внесение изменений). Желательно, чтобы блок логики, ответственный за данное поведение, располагался где-то в одном месте (например, чтобы backend формировал коллекцию допустимых действий для каждой записи, и не приходилось дублировать данную логику на frontend). При выборе нескольких записей перечень возможных действий должен быть ограничен минимальным набором действий, допустимым для всей выбранной коллекции.
Отображение записи, содержащей связанные данные из нескольких источников (нескольких таблиц БД/нескольких сервисов приложения и т.д.)	Данный кейс уже чуть менее тривиален. Данные, которые видит пользователь для одной карточки (записи), могут храниться в различных таблицах БД и других контейнерах. В этом случае, если вдруг где-то нарушена мандатная целостность данных (для одной записи с одной мандатной метки имеются связанные записи карточки с другими мандатными метками), вывод данных — настоящая боль. Здесь возможны следующие варианты: Ограничить вывод связанных данных только данными с мандатной меткой, которая равна мандатной метке текущей записи. В этом случае данные, нарушающие целостность по мандатной модели, будут существовать, но пользователь их не увидит. Выводить все связанные данные, но помечать и не позволять выполнять операции с «битыми» данными.
Отображение элементов управления для изменения данных (редактирование, удаление)	Желательно, чтобы каждая операция изменения содержала в себе список мандатных меток, которые допустимы для выполнения данной операции. Желательно, чтобы данный список формировался в одном месте (например, в backend приложения), а клиентская логика содержала в себе набор простейших правил проверки множеств на пересечения (сверка множеств мандатных меток элемента управления и управляемой записи). Это очень сильно разгрузит всю команду разработки от отлова неожиданных ошибок с логикой обработки мандатной модели.

Выводы

Мы рассмотрели несколько аспектов разработки приложения с поддержкой MAC. Все случаи предусмотреть, разумеется, сложно. Большая часть особенностей мандатной модели зависит от реализации, доступной для применения в выбранной ОС.

Поддержка MAC приложением — это не дополнительная «фича» приложения. Это серьезное архитектурное решение, требующее планирования и проектирования. Наибольшая «боль» для проектировщика MAC-совместимого приложения:

• взаимодействие с инфраструктурой ОС (файловая система, сетевые взаимодействия, запуск процессов с нужной мандатной меткой в случае выполнения приложения на сервере);
• взаимодействие с прикладным ПО с встроенной поддержкой MAC (например, СУБД);
• взаимодействие с пользователем в части корректной обработки MAC-совместимых операций.

На этом пока все! Дополнения, личный опыт и комментарии к статье приветствуются!