Мандатное управление доступом в windows

Разграничение доступа пользователей в ОС Windows. ПАК СЗИ НСД «Аккорд-Win64» (10/11)

Мандатный механизм управления доступом

Здравствуйте!

В данной лекции мы поговорим о мандатном механизме управления доступом, рассмотрим требования этого механизма и понятие используемой в нем решетки уровней конфиденциальности информации, приведем пример схемы реализации мандатного механизма управления доступом. А также поговорим, как происходит настройка уровня доступа пользователей и настройка уровня конфиденциальности (меток допуска) объектов в программно-аппаратном комплексе СЗИ от НСД «Аккорд-Win64», то есть настройка правил разграничения доступа с использованием данного механизма.

Итак,  как мы уже говорили в лекции про дискреционный механизм управления доступом – все элементы компьютерной системы, как известно, разделяются на множество субъектов и объектов. Будем называть их обобщенно — сущностями КС.

Мандатное управление доступом к объектам компьютерной системы предполагает выполнение следующих требований:

• все сущности компьютерной системы должны быть однозначно идентифицированы;
• должна быть задана решетка уровней конфиденциальности информации;
• каждой сущности компьютерной системы должен быть присвоен уровень конфиденциальности — метка допуска, задающая установленные ограничения на доступ к ней;
• каждому субъекту КС должен быть присвоен уровень доступа, задающий его уровень полномочий в системе;
• субъект может получить доступ к сущности только том случае, когда уровень доступа субъекта позволяет предоставить ему данный доступ к сущности с заданным уровнем конфиденциальности, и реализация доступа не приведет к возникновению информационных потоков от сущностей с высоким уровнем конфиденциальности к сущностям с низким уровням конфиденциальности.

Решетка уровней конфиденциальности классически задается в числовом виде – «0», «2»,  … «15», где «0» — самый низкий уровень, а «15» — самый высокий (уровень «1» зарезервирован для более сложных задач). Но может быть задана и иначе, например, когда имеется всего 4 уровня конфиденциальности. Здесь ОД – это общедоступно, К – конфиденциально, С – секретно, СС – совершенно секретно.

Реализацию мандатного механизма управления доступом можно схематично изобразить следующим образом. Пусть, например, у нас есть Объект 1 (некоторый файл) и несколько субъектов (S1, S2, S3). Объект 1 имеет уровень конфиденциальности «Конфиденциально» и Субъект 2 имеет уровень доступа «Конфиденциально», Субъект 1 имеет уровень доступа «Секретно», а Субъект 3 – «Общедоступно». Слева мы видим решетку уровней конфиденциальности для данного случая. В соответствии с требованиями мандатной политики  управления доступом Субъект 1 (с более высоким уровнем доступа, чем у нашего файла) не может писать (W) в файл с уровнем доступа ниже, но может его читать (R). Субъект 2 (с таким же уровнем доступа, что и наш файл) может и писать в файл и читать его (RW) ), а Субъект 3 (с уровнем доступа ниже, чем наш файл) не может ни читать, ни писать в файл (RW) ), но может добавлять туда информацию без перезаписи (А) ).

Теперь давайте рассмотрим, как происходит задание правил разграничения доступа (ПРД) с использованием мандатного механизма в комплексе «Аккорд».

Для включения мандатного механизма разграничения доступа необходимо в главном окне программы «Настройка комплекса «Аккорд» в поле «Механизмы защиты» установить флаги «Мандатный» и «Контроль процессов». Установим их. Нажмем «Сохранить» и выйдем из программы.

Теперь необходимо выполнить настройку уровня доступа пользователей. Для этого зайдем в программу «Редактор прав доступа». После установки в настройках комплекса галочек «Мандатный» и «Контроль процессов» в главном окне данной программы на панели инструментов становятся активными кнопки «Уровень доступа пользователя» и «Установить мандатные метки допуска к объектам».

С помощью кнопки «Уровень доступа пользователя» можно установить, или изменить уровень доступа пользователя. Выберем пользователя из списка и обратим внимание на то, что в поле «Уровень доступа пользователя» по умолчанию установлен самый низкий уровень доступа — «Общедоступно».

Нажмем кнопку «Уровень доступа пользователя» и зададим ему уровень доступа, например, «Конфиденциально». Нажмем кнопку «Сохранить». В поле «Уровень доступа пользователя» появится заданное значение.

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

Далее необходимо открыть окно «Редактирование правил разграничения доступа» и в нем перейти на вкладку «Процессы».

При первом запуске данной программы с включенным флагом «Контроль процессов» в список заносятся все процессы, которые в данный момент находятся в оперативной памяти. Однако на момент старта данной программы некоторые процессы уже завершают свою работу, поэтому более корректно выполнять формирование списка контролируемых процессов несколько иным образом. Мы не будем сейчас рассматривать этот момент, подробности можно прочитать в методических материалах к лекции – документе «Установка правил разграничения доступа».

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

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

Далее можно присваивать уровни конфиденциальности (метки допуска) объектам.  Для этого нужно нажать кнопку «Установить мандатные метки допуска к объектам». Нажмем ее. Выводится окно со списком объектов.

По умолчанию всем объектам присваивается самый низкий уровень – «Общедоступно». Зададим метку допуска произвольному объекту (например, каталогу TEST на диске С:\). Для этого нажмем кнопку «Новый». Откроется окно «Атрибуты доступа к объектам», в котором слева выберем каталог TEST на диске С:. Для выбранного объекта можно изменить только два параметра – наследование прав доступа и метку допуска. «Метка допуска» выставляется выбором значения из списка.

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

А сейчас выберем, например, «Конфиденциально», нажмем кнопку «Сохранить», затем «Закрыть».

Видим, что этот каталог появился в списке с меткой допуска «Конфиденциально».

Объект, которому не присвоена метка допуска, считается общедоступным для всех пользователей.

Для сохранения изменений необходимо нажать «Сохранить».

Подведем итог, на данной лекции мы поговорили о мандатном механизме управления доступом, рассмотрели требования этого механизма, понятие используемой в нем решетки уровней конфиденциальности информации, пример схемы реализации мандатного механизма управления доступом. А также посмотрели, как происходит настройка уровня доступа пользователей и уровня конфиденциальности (меток допуска) объектов в программно-аппаратном комплексе СЗИ от НСД «Аккорд-Win64».

На следующей лекции мы поговорим о контроле процессов с использованием дискреционного и/или мандатного механизмов разграничения доступа.

Спасибо за внимание, до встречи на следующей лекции!

Мандатная модель управления доступом (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 операционной системы должны быть настроены мандатные разрешения на определённые мандатные метки (диапазоны мандатных меток).

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

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 следует проявлять особую бдительность и следить за всеми «связями» модулей.

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

Классификация модулей по режимам обработки 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 в части пользовательского интерфейса во всех режимах, за исключением режима одновременной работы с несколькими мандатными метками.

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

Выводы

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

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

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

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

Сталкивались ли вы с MAC в своей профессиональной деятельности?

Проголосовали 15 пользователей.

Воздержались 4 пользователя.

From Wikipedia, the free encyclopedia

In computer security, mandatory access control (MAC) refers to a type of access control by which the operating system or database constrains the ability of a subject or initiator to access or generally perform some sort of operation on an object or target.^[1] In the case of operating systems, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices, etc. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any operation by any subject on any object is tested against the set of authorization rules (aka policy) to determine if the operation is allowed. A database management system, in its access control mechanism, can also apply mandatory access control; in this case, the objects are tables, views, procedures, etc.

With mandatory access control, this security policy is centrally controlled by a security policy administrator; users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes. (The traditional Unix system of users, groups, and read-write-execute permissions is an example of DAC.) MAC-enabled systems allow policy administrators to implement organization-wide security policies. Under MAC (and unlike DAC), users cannot override or modify this policy, either accidentally or intentionally. This allows security administrators to define a central policy that is guaranteed (in principle) to be enforced for all users.

Historically and traditionally, MAC has been closely associated with multilevel security (MLS) and specialized military systems. In this context, MAC implies a high degree of rigor to satisfy the constraints of MLS systems. More recently, however, MAC has deviated out of the MLS niche and has started to become more mainstream. The more recent MAC implementations, such as SELinux and AppArmor for Linux and Mandatory Integrity Control for Windows, allow administrators to focus on issues such as network attacks and malware without the rigor or constraints of MLS.

Historical background and implications for multilevel security[edit]

Historically, MAC was strongly associated with multilevel security (MLS) as a means of protecting US classified information. The Trusted Computer System Evaluation Criteria (TCSEC), the seminal work on the subject and often known as the Orange Book, provided the original definition of MAC as «a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity».^[2] Early implementations of MAC such as Honeywell’s SCOMP, USAF SACDIN, NSA Blacker, and Boeing’s MLS LAN focused on MLS to protect military-oriented security classification levels with robust enforcement.

The term mandatory in MAC has acquired a special meaning derived from its use with military systems. In this context, MAC implies an extremely high degree of robustness that assures that the control mechanisms can resist any type of subversion, thereby enabling them to enforce access controls that are mandated by order of a government such as the Executive Order 12958 for US classified information. Enforcement is supposed to be more imperative than for commercial applications. This precludes enforcement by best-effort mechanisms; only mechanisms that can provide absolute or near-absolute enforcement of the mandate are acceptable for MAC. This is a tall order and sometimes assumed unrealistic by those unfamiliar with high assurance strategies, and very difficult for those who are.

Strength[edit]

Degrees[edit]

In some systems, users have the authority to decide whether to grant access to any other user. To allow that, all users have clearances for all data. This is not necessarily true of an MLS system. If individuals or processes exist that may be denied access to any of the data in the system environment, then the system must be trusted to enforce MAC. Since there can be various levels of data classification and user clearances, this implies a quantified scale for robustness. For example, more robustness is indicated for system environments containing classified Top Secret information and uncleared users than for one with Secret information and users cleared to at least Confidential. To promote consistency and eliminate subjectivity in degrees of robustness, an extensive scientific analysis and risk assessment of the topic produced a landmark benchmark standardization quantifying security robustness capabilities of systems and mapping them to the degrees of trust warranted for various security environments. The result was documented in CSC-STD-004-85.^[3] Two relatively independent components of robustness were defined: Assurance Level and Functionality. Both were specified with a degree of precision that warranted significant confidence in certifications based on these criteria.

Evaluation[edit]

The Common Criteria^[4] is based on this science and it intended to preserve the Assurance Level as EAL levels and the functionality specifications as Protection Profiles. Of these two essential components of objective robustness benchmarks, only EAL levels were faithfully preserved. In one case, TCSEC level C2^[5] (not a MAC capable category) was fairly faithfully preserved in the Common Criteria, as the Controlled Access Protection Profile (CAPP).^[6] Multilevel security (MLS) Protection Profiles (such as MLSOSPP similar to B2)^[7] is more general than B2. They are pursuant to MLS, but lack the detailed implementation requirements of their Orange Book predecessors, focusing more on objectives. This gives certifiers more subjective flexibility in deciding whether the evaluated product’s technical features adequately achieve the objective, potentially eroding consistency of evaluated products and making it easier to attain certification for less trustworthy products. For these reasons, the importance of the technical details of the Protection Profile is critical to determining the suitability of a product.

Such an architecture prevents an authenticated user or process at a specific classification or trust-level from accessing information, processes, or devices in a different level. This provides a containment mechanism of users and processes, both known and unknown (an unknown program (for example) might comprise an untrusted application where the system should monitor and/or control accesses to devices and files).

Implementations[edit]

A few MAC implementations, such as Unisys’ Blacker project, were certified robust enough to separate Top Secret from Unclassified late in the last millennium. Their underlying technology became obsolete and they were not refreshed. Today there are no current implementations certified by TCSEC to that level of robust implementation. However, some less robust products exist.

• Amon Ott’s RSBAC (Rule Set Based Access Control) provides a framework for Linux kernels that allows several different security policy / decision modules. One of the models implemented is Mandatory Access Control model. A general goal of RSBAC design was to try to reach (obsolete) Orange Book (TCSEC) B1 level. The model of mandatory access control used in RSBAC is mostly the same as in Unix System V/MLS, Version 1.2.1 (developed in 1989 by the National Computer Security Center of the USA with classification B1/TCSEC). RSBAC requires a set of patches to the stock kernel, which are maintained quite well by the project owner.
• TOMOYO Linux is a lightweight MAC implementation for Linux and Embedded Linux, developed by NTT Data Corporation. It has been merged in Linux Kernel mainline version 2.6.30 in June 2009.^[8] Differently from the label-based approach used by SELinux, TOMOYO Linux performs a pathname-based Mandatory Access Control, separating security domains according to process invocation history, which describes the system behavior. Policy are described in terms of pathnames. A security domain is simply defined by a process call chain, and represented by a string. There are 4 modes: disabled, learning, permissive, enforcing. Administrators can assign different modes for different domains. TOMOYO Linux introduced the «learning» mode, in which the accesses occurred in the kernel are automatically analyzed and stored to generate MAC policy: this mode could then be the first step of policy writing, making it easy to customize later.
• SUSE Linux and Ubuntu 7.10 have added a MAC implementation called AppArmor. AppArmor utilizes a Linux 2.6 kernel feature called LSM (Linux Security Modules interface). LSM provides a kernel API that allows modules of kernel code to govern ACL (DAC ACL, access-control lists). AppArmor is not capable of restricting all programs and is optionally in the Linux kernel as of version 2.6.36.^[9]
• Linux and many other Unix distributions have MAC for CPU (multi-ring), disk, and memory; while OS software may not manage privileges well, Linux became famous during the 1990s as being more secure and far more stable than non-Unix alternatives. Linux distributors disable MAC to being at best DAC for some devices – although this is true for any consumer electronics available today.
• Android since its 5.0 release has used SELinux to enforce a MAC security model on top of its original UID-based DAC approach.^[10]
• grsecurity is a patch for the Linux kernel providing a MAC implementation (precisely, it is an RBAC implementation). grsecurity is not implemented via the LSM API.^[11]
• Microsoft Starting with Windows Vista and Server 2008 Windows incorporates Mandatory Integrity Control, which adds Integrity Levels (IL) to processes running in a login session. MIC restricts the access permissions of applications that are running under the same user account and which may be less trustworthy. Five integrity levels are defined: Low, Medium, High, System, and Trusted Installer.^[12] Processes started by a regular user gain a Medium IL; elevated processes have High IL.^[13] While processes inherit the integrity level of the process that spawned it, the integrity level can be customized on a per-process basis: e.g. IE7 and downloaded executables run with Low IL. Windows controls access to objects based on ILs, as well as for defining the boundary for window messages via User Interface Privilege Isolation. Named objects, including files, registry keys or other processes and threads, have an entry in the ACL governing access to them that defines the minimum IL of the process that can use the object. MIC enforces that a process can write to or delete an object only when its IL is equal to or higher than the object’s IL. Furthermore, to prevent access to sensitive data in memory, processes can’t open processes with a higher IL for read access.^[14]
• FreeBSD supports Mandatory Access Control, implemented as part of the TrustedBSD project. It was introduced in FreeBSD 5.0. Since FreeBSD 7.2, MAC support is enabled by default. The framework is extensible; various MAC modules implement policies such as Biba and multilevel security.
• Sun’s Trusted Solaris uses a mandatory and system-enforced access control mechanism (MAC), where clearances and labels are used to enforce a security policy. However note that the capability to manage labels does not imply the kernel strength to operate in multilevel security mode^{[citation needed]}. Access to the labels and control mechanisms are not^{[citation needed]} robustly protected from corruption in protected domain maintained by a kernel. The applications a user runs are combined with the security label at which the user works in the session. Access to information, programs and devices are only weakly controlled^{[citation needed]}.
• Apple’s Mac OS X MAC framework is an implementation of the TrustedBSD MAC framework.^[15] A limited high-level sandboxing interface is provided by the command-line function sandbox_init. See the sandbox_init manual page for documentation.^[16]
• Astra Linux OS developed for Russian Army has its own mandatory access control.^[17]
• Smack (Simplified Mandatory Access Control Kernel) is a Linux kernel security module that protects data and process interaction from malicious manipulation using a set of custom mandatory access control rules, with simplicity as its main design goal.^[18] It has been officially merged since the Linux 2.6.25 release.^[19]

See also[edit]

Footnotes[edit]

References[edit]

• P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments. In Proceedings of the 21st National Information Systems Security Conference, pages 303–314, Oct. 1998.
• P. A. Loscocco, S. D. Smalley, Meeting Critical Security Objectives with Security-Enhanced Linux Archived 2017-07-08 at the Wayback Machine Proceedings of the 2001 Ottawa Linux Symposium.
• ISO/IEC DIS 10181-3, Information Technology, OSI Security Model, Security FrameWorks, Part 3: Access Control, 1993
• Robert N. M. Watson. «A decade of OS access-control extensibility». Commun. ACM 56, 2 (February 2013), 52–63.

External links[edit]

• Weblog post on the how virtualization can be used to implement Mandatory Access Control.
• Weblog post from a Microsoft employee detailing Mandatory Integrity Control and how it differs from MAC implementations.
• GWV Formal Security Policy Model A Separation Kernel Formal Security Policy, David Greve, Matthew Wilding, and W. Mark Vanfleet.

Статья о разграничении прав доступа в операционных системах Windows: дискретном и мандатном. В статье рассматриваются разграничения прав доступа к папкам и файлам на уровне операционной системы Windows и с помощью Secret Net.

Дискретное разграничение прав доступа

Для того, что бы настроить правила безопасности для папок нужно воспользоваться вкладкой «Безопасность». В Windows XP эта вкладка отключена по умолчанию. Для ее активации нужно зайти в свойства папки (Меню «Сервис» -> «Свойства папки» ->  «Вид») и снять флажок «Использовать простой общий доступ к файлам».

Основные права доступа к папкам

В файловой системе NTFS в Windows XP существует шесть стандартных разрешений:

1. Полный доступ;
2. Изменить;
3. Чтение и выполнение;
4. Список содержимого папки;
5. Чтение;
6. Запись.

В Windows 10 нет стандартного разрешения «Список содержимого папки».

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

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

Создайте папки по названиям разрешений, всего у вас будет 6 папок для Windows XP и для Windows 10. Я рассмотрю на примере Windows XP, на «десятке» вам будет проще. Скачайте папки по ссылке и скопируйте в них содержимое (не сами папки, а то, что в них находится).

Отройте вкладку «Безопасность» в свойствах папки «Список содержимого папки». У меня есть пользователь user, вы можете добавить своего. Для того, что бы изменить право на объект нужно выбрать пользователя и указать ему разрешение, в данном случае «Список содержимого папки». Затем нажмите «Применить» и «ОК».

По аналогии установите права для соответствующих папок.

После установки прав доступа проверьте их. Для этого войдите в операционную систему под пользователем, для которого устанавливали права, в моем случае это user.

«Список содержимого папки» — предоставляет возможность просмотра файлов и папок в текущем каталоге. То есть вы можете посмотреть, что есть в папке, но запустить и открыть ничего не получиться.

«Чтение» — предоставляет возможность открывать в папке все файлы, кроме исполняемых файлов (например, с расширением .exe).

«Чтение и выполнение» — предоставляет возможность открывать в данном каталоге все файлы.

«Запись» — предоставляет возможность добавления файлов в папку без права на доступ к вложенным в него объектам, в том числе на просмотр содержимого каталога.

«Изменить» — предоставляет возможность открывать и создавать (изменять) файлы в папке.

«Полный доступ» — предоставляет все возможности для работы с папкой и вложенными файлами, включая изменение разрешений.

Откройте каждую папку и проверьте, что разрешения выполняются.

Элементы разрешений на доступ

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

Просмотреть элементы разрешений на доступ можно, нажав на кнопку «Дополнительно» во вкладке «Безопасность» и выбрав любой элемент разрешений.

Поэкспериментируйте с элементами и проверьте, как они работаю.

Владелец файла

В файловой системе NTFS у каждого файла есть свой владелец. Владельцем файла является пользователь операционной системы. Он может управлять разрешениями на доступ к объекту независимо от установленных разрешений.

Узнать, какой пользователь является владельцем файла или папки можно на закладке «Владелец» в дополнительных параметрах безопасности.

Наследование прав доступа

В файловой системе NTFS поддерживается наследование разрешений. Если вы устанавливаете разрешение на папку, то оно наследуется для всех вложенных файлов и папок.

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

Для изменения унаследованных разрешений нужно открыть вкладку «Разрешения» в дополнительных параметрах безопасности. Там же можно отключить наследование разрешений.

Запреты

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

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

Разграничение прав доступа с помощью Secret Net (на примере версии 5.1)

При использовании Secret Net доступ к файлам осуществляется, в случае если пользователю присваивается соответствующий уровень допуска. В примере я использую Windows XP с установленным программным продуктом Secret Net 5.1.

Первым делом нужно запустить локальные параметры безопасности от имени Администратора: «Пуск –> Программы –> Secret Net 5 –> Локальная политика безопасности».

Далее необходимо перейти в «Параметры Secret Net» –>  «Настройка подсистем» –> «Полномочное управление доступом: название уровней конфиденциальности».

Введите названия уровней. У меня это:

• Низший – Общедоступно.
• Средний – Конфиденциально.
• Высший – Секретно.

Настройка субъектов

Настройка субъектов в Secret Net производится в группе «Локальные пользователи и группы». Зайдите в меню «Пуск» –>  «Программы» –>  «Secret Net 5» –> «Управление компьютером» –>  «Локальные пользователи и группы» –> «Пользователи».

Что бы настроить права администратора нужно выбрать учетную запись «Администратор» и перейти на вкладку Secret Net 5. Установим уровень доступа «секретно».

Далее установите все флажки.

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

После установки всех флажков нажмите «Применить» и «ОК».

Создадим нового пользователя. Для этого нужно перейти «Локальные пользователи и Группы» –> «Пользователи». Создайте новых пользователей, я назову их «Конфиденциальный» и «Секретный». По аналогии с пользователем Администратор  установите для новых пользователей аналогичные уровни доступа и настройки как на рисунках ниже.

Настройка объектов

Та или иная категория конфиденциальности является атрибутом папки или файла. Изменения этих атрибутов производятся уполномоченными пользователями (в данном случае Администратором). Категория конфиденциальности может присваиваться новым файлам или папкам автоматически или по запросу.

Автоматическое присваивание категории конфиденциальности можно включить или отключить в окне настройки свойств папки. Этот параметр может редактировать только пользователь, у которого есть права на «Редактирование категорий конфиденциальности».

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

Попробуйте создать в паке новый файл или каталог, а после чего изменить ее уровень (повысить) и установить флажок «Автоматически присваивать новым файлам». У вас появиться окно «Изменение категорий конфиденциальности».

Выберите пункт «Присвоение категорий конфиденциальности всем файлам в каталоге» и нажмите «ОК» для присвоения категории конфиденциальности всем файлам кроме скрытых и системных файлов.

В случае если категория допуска пользователя выше чем категория конфиденциальности объект, то пользователь имеет право на чтение документа, но не имеет права изменять и сохранять документ.

Если пользователь с категорией «Общедоступно» попробует прочитать или удалить документ, то он получит соответствующие ошибки.

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

Если вы зайдете под пользователем «Секретный» то вы сможете повысить уровень конфиденциальности файлов и работать с ними.

Не стоит забывать, что конфиденциальные файлы нельзя копировать в общедоступные папки, чтобы не допустить их утечки.

Контроль потоков данных

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

Для этого нужно запустить «Локальные параметры безопасности»: «Пуск» – «Программы» –> «Secret Net 5» –>  «Локальная политика безопасности», затем перейти в группу «Параметры Secret Net» –>  «Настройки подсистем» и выбрать параметр  «Полномочное управление доступом: Режим работы» и включить контроль потоков. Изменения вступят в силу после перезагрузки компьютера.

Если зайти (после перезагрузки) под пользователем «Секретный» появиться выбор уровня конфиденциальности для текущего сеанса. Выберите секретный уровень.

Если вы откроете файл с уровнем «Конфиденциально», отредактируете его и попробуете сохранить под другим именем и в другую папку, то вы получите ошибку, так как уровень сеанса (секретный) выше, чем уровень файла (конфиденциальный) и включен контроль потоков данных.

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