Мандатная политика не записывать вверх ос windows

В этой части рассмотрены следующие вопросы:

• Модели безопасности
• Модель конечных автоматов
• Модель Bell-LaPadula
• Модель Biba
• Модель Clark-Wilson
• Модель информационных потоков
• Скрытые каналы
• Модель невлияния
• Сетчатая модель
• Модель Brewer and Nesh
• Модель Graham-Denning
• Модель Harrison-Ruzzo-Ullman

Обновлено: 02.05.2010

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

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

Модель безопасности преобразует абстрактные цели политики в термины информационных систем, точно описывая структуры данных и средства (методы), необходимые для реализации политики безопасности. Модель безопасности обычно представляется в виде математических и аналитических идей, которые затем преобразуются в технические требования к системе, а затем разрабатывается программистами в коде программы. Таким образом, мы имеем политику, реализующую цели безопасности, типа «каждый субъект должен быть авторизован для доступа к каждому объекту». Модель безопасности берет эти требования и предоставляет необходимые математические формулы, взаимоотношения и структуру, которым необходимо следовать для достижения целей безопасности. Исходя из этого, разработаны технические требования для каждого типа операционной системы (Unix, Windows, Macintosh и т.д.), и отдельные производители могут решать, как им реализовывать механизмы, которые будут соблюдать эти технические требования.

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

Некоторые модели безопасности, такие как Bell-LaPadula, реализуют правила, обеспечивающие защиту конфиденциальности. Другие модели, как, например, Biba, реализуют правила, обеспечивающие защиту целостности. Формальные модели безопасности, такие как Bell-LaPadula и Biba, используются для предоставления высокого уровня гарантий безопасности. Неформальные модели, такие как Clark-Wilson, больше используются в качестве основы для описания того, как политики безопасности должны выражаться и выполняться.

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

Взаимоотношения между Политикой безопасности и Моделью безопасности. Если кто-то говорит вам, что нужно вести правильный и здоровый образ жизни, это очень широкое, общее, абстрактное понятие. Когда вы спрашиваете этого человека – как это сделать, он описывает вам, что вам нужно делать и что не нужно (не наносить другим вреда, не говорить неправду, есть овощи, чистить зубы и т.д.). Аналогично, Политика безопасности предоставляет абстрактные цели, а Модель безопасности говорит, что нужно и что не нужно делать, чтобы достичь эти цели.

В моделях конечных автоматов (state machine model) для проверки безопасности системы используется состояние (state), которое является мгновенным «снимком» всех текущих разрешений и всех текущих экземпляров субъектов, использующихся объектами. Каждая связь субъекта с объектом имеет отношение к поддержанию состояния системы. Система безопасна, если субъекты могут получить доступ к объектам только с помощью средств, соответствующих политике безопасности. Конечные автоматы предоставляют основу для важнейших моделей безопасности. Состояние системы – это ее моментальный снимок. Множество различных действий могут изменить состояние системы. Это называется переходами состояния (state transition). Разработчики операционной системы при реализации модели конечных автоматов должны учесть все возможные переходы состояний и оценить, не могут ли они привести систему в небезопасное состояние. Если все действия, которые могут произойти в системе, не приводят ее в небезопасное состояние, это означает, что система выполняется в безопасной модели конечных автоматов.

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

Модели конечных автоматов используются для описания поведения системы при различных входных данных. Это дает математические конструкции, которые представляют собой множества (субъектов и объектов), и последовательности. Когда объект принимает входные данные, это изменяет состояние переменной. Упрощенный пример состояния переменной – это (Имя, Значение), как показано на Рисунке 3-15. Эта переменная является частью набора команд операционной системы. Когда эта переменная вызывается для использования, в нее может быть записано (Цвет, Красный) из входных данных, введенных пользователем программы. Скажем, пользователь вводит другое значение и теперь в переменную записывается (Цвет, Синий). Это упрощенный пример перехода состояния. Некоторые переходы состояний также являются простыми. Сложность появляется, когда системе нужно решать, следует ли разрешать тот или иной переход. Для принятия решения о возможности перехода, операционной системой должны быть проанализированы атрибуты безопасности объекта и права доступа субъекта.

Рисунок 3-15. Упрощенный пример изменения состояния

Разработчики, которые реализуют модель конечных автоматов, должны идентифицировать все начальные состояния (значения переменных по умолчанию) и описать, как эти значения могут быть изменены (входные данные, которые будут приняты), чтобы любые конечные состояния (результирующие значения) сохраняли уверенность в том, что система остается безопасной. Описание процесса возможных изменений этих значений часто реализуется посредством условных утверждений, типа «ЕСЛИ условие ТОГДА обновление».

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

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

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

В 1970-е годы американские военные использовали мейнфреймы, работающие в режиме разделения времени, и были заинтересованы в безопасности этих систем и защите от утечки классифицированной информации. Модель Bell-LaPadula разработана для таких систем. Это была первая математическая модель многоуровневой политики безопасности, использованная для определения понятия безопасного конечного автомата, режимов доступа и описания правил доступа. Ее разработка была профинансирована американским правительством, для обеспечения платформы для компьютерных систем, используемых для хранения и обработки критичной информации. Основной целью этой модели было предотвращение несанкционированного доступа к секретной информации.

Системы, использующие модель Bell-LaPadula, называют многоуровневыми системами безопасности, т.к. систему используют пользователи с разным допуском, а система обрабатывает данные с различной классификацией. Уровень классификации информации определяет, какие процедуры могут быть использованы для ее обработки. Модель Bell-LaPadula – это модель конечных автоматов, которая реализует аспект конфиденциальности при управлении доступом. Для принятия решения о доступе субъекта к объекту используются матрицы и уровни безопасности. Допуск субъекта сравнивается с классификацией объекта, затем применяются специальные правила для определения возможных вариантов взаимодействия субъекта и объекта.

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

Модель Bell-LaPadula – это модель субъект-объект (например, как пользователь (субъект) может читать элемент данных (объект) из определенной базы данных и записывать данные в эту базу данных). Модель Bell-LaPadula направлена на обеспечение гарантий того, что субъекты надлежащим образом аутентифицированы, имеют необходимый допуск безопасности, категорию «должен знать» и формальное разрешение доступа перед непосредственным доступом к объекту.

Есть три основных правила, используемых и реализованных в модели Bell-LaPadula: простое правило безопасности, правило *-свойства и строгое правило *-свойства. Простое правило безопасности (simple security rule) говорит о том, что субъект не может читать данные, находящиеся на более высоком уровне безопасности, чем его допуск. Например, если Боб имеет допуск безопасности «секретно», это правило говорит, что он не может читать данные, классифицированные как «совершенно секретно». Если компания хочет, чтобы Боб имел возможность читать совершенно секретные данные, она должна сначала дать Бобу соответствующий допуск.

Правило *-свойства (*-property rule, star property rule) говорит о том, что субъект не может записывать данные на меньший уровень безопасности, чем его допуск. Простое правило безопасности называют правилом «не читать сверху» (no read up), а правило *-свойства – правилом «не записывать вниз» (no write down), как показано на Рисунке 3-16. Третье правило – строгое правило *-свойства (strong *-property rule) говорит о том, что субъект может выполнять функции чтения и записи только на том же уровне безопасности, что и его допуск – не выше и не ниже. Таким образом, чтобы субъект имел возможность чтения и/или записи объекта, его уровень допуска должен совпадать с классификацией объекта.

Рисунок 3-16. В модели Bell-LaPadula каждый субъект имеет сетку прав

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

ПРИМЕЧАНИЕ. В терминах управления доступом, слово «доминировать» (dominate) означает быть выше или равным. Таким образом, если вы видите утверждение, например, «субъект может выполнять операцию чтения только в том случае, если его класс доступа доминирует над классом доступа объекта», это означает просто, что субъект должен иметь допуск выше или равный классификации объекта. В модели Bell-LaPadula это называют отношением доминирования, являющимся взаимоотношением допуска субъекта и классификации объекта.

Состояние системы изменяется по мере выполнения различных операций. Модель Bell-LaPadula определяет безопасное состояние, означающее безопасную вычислительную среду и допустимые действия, являющиеся операциями, не нарушающими безопасное состояние системы. Это означает, что эта модель обеспечивает безопасное состояние и разрешает только те операции, которые сохраняют систему в безопасном состоянии и не дают ей перейти в небезопасное состояние. Так, если 100 человек ежедневно с помощью одной этой системы использует 2000 объектов, эта система выполняет достаточно большой объем сложной работы. Однако в конце дня система также безопасна, как была в начале дня. Это является определением Основной теоремы безопасности системы (Basic Security Theorem), используемой в компьютерной науке, которая гласит, что если система была инициализирована в безопасном состоянии, и она допускает только безопасные изменения состояния, она безопасна в любой момент, независимо от входных данных.

ПРИМЕЧАНИЕ. Принцип равновесия (tranquility principle), также используемый в этой модели, гласит, что субъекты и объекты не могут изменить свой уровень безопасности после своего создания.

Важно отметить, что модель Bell-LaPadula была разработана для гарантии сохранения секретности секретной информации, поэтому она обеспечивает и учитывает только конфиденциальность. Эта модель не учитывает целостность данных в системе — только кто может, а кто не может получить доступ к данным, и какие операции может выполнять с ними.

ПРИМЕЧАНИЕ. Обеспечение того, что информация не может переходить с более высокого уровня безопасности на более низкий, называется контролем несанкционированного понижения статуса информации (controlling unauthorized downgrading of information). Это может произойти при выполнении операции «запись вниз» (write down). При этом реальная компрометация произойдет только в том случае и в тот момент, когда пользователь на более низком уровне безопасности прочитает эти данные.

Так что же это означает и зачем это нужно? В Домене 02 рассматривались системы мандатного управления доступом (MAC) в сравнении с системами дискреционного управления доступом (DAC). Все системы МАС основаны на модели Bell-LaPadula, т.к. она позволяет интегрировать многоуровневую безопасность в код. Субъектам и объектам присваиваются метки. Метка субъекта содержит отметку о его допуске («совершенно секретно», «секретно» или «конфиденциально»), а метка объекта содержит его уровень классификации («совершенно секретно», «секретно» или «конфиденциально»). Когда субъект пытается получить доступ к объекту, система сравнивает метку допуска субъекта с меткой классификации объекта, чтобы выяснить, является ли такой доступ допустимым и безопасным. В нашем сценарии, это разрешенное действие и субъект получает доступ к объекту. Теперь, если метка допуска субъекта – «совершенно секретно», а классификация объекта – «секретно», субъект не может записывать в этот объект из-за правила *-свойства, которое гарантирует, что субъект не сможет намеренно или случайно предоставить общий доступ к конфиденциальной информации, записав ее на более низкий уровень безопасности. В качестве примера представьте, что занятой и беспечный армейский генерал (который имеет допуск к совершенно секретной информации) открыл письмо с информацией о целях (которому была присвоена классификация «секретно»), которое затем будет отправлено всем секретарям на всех базах по всему миру. Он попытался дополнить письмо информацией, что США нападет на Кубу. При этом модель Bell-LaPadula будет приведена в действие и не позволит этому генералу записать такую информацию в это письмо, поскольку его допуск выше классификации письма.

Точно также, если секретарь попытается прочитать письмо, которое доступно только генералам и выше, модель Bell-LaPadula остановит эту попытку. Допуск секретаря ниже классификации объекта (письма), что нарушает простое правило безопасности модели. Все это относится к сохранению секретности.

ПРИМЕЧАНИЕ. Очень важно, чтобы MAC-операционная система и MAC-база данных следовали этим правилам. В Домене 09 мы рассмотрим, как база данных должна следовать этим правилам, используя многоэкземплярность (polyinstantiation).

ПРЕДУПРЕЖДЕНИЕ. Вы должны понимать правило Bell-LaPadula, называемое Дискреционным свойством безопасности (Discretionary Security Property — ds-property), которое является еще одним правилом этой модели. Это правило основано на именовании субъектов и объектов. Оно указывает, что определенное разрешение позволяет субъекту передавать разрешения на свой страх и риск. Эти разрешения хранятся в матрице доступа. Это просто означает, что механизмы мандатного и дискреционного управления доступом могут быть реализованы в одной операционной системе одновременно.

Правила, которые нужно знать. Основными правилами модели Bell-LaPadula, которые вы должны понимать, являются следующие:

• Простое правило безопасности. Субъект не может читать данные из объекта, находящегося на более высоком уровне безопасности (правило «Не читать сверху»).
• Правило *- свойства. Субъект не может записывать данные в объект, находящийся на более низком уровне безопасности (правило «Не записывать вниз»).
• Строгое правило *-свойства. Чтобы субъект мог читать и записывать данные в объект, его допуск и классификация объекта должны совпадать.

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

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

• Аксиома *-целостности (*-integrity axiom). Субъект не может записывать данные в объект, находящийся на более высоком уровне целостности (это называют «не записывать вверх» (no write up));
• Простая аксиома целостности (simple integrity axiom). Субъект не может читать данные, находящиеся на более низком уровне целостности (это называют «не читать снизу» (no read down)).
• Свойство вызова (Invocation property). Субъект не может запрашивать обслуживание (вызов) у другого субъекта, находящегося на более высоком уровне целостности.

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

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

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

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

Bell-LaPadula vs. Biba. Модель Bell-LaPadula используется для обеспечения конфиденциальности. Модель Biba используется для обеспечения целостности. Модели Bell-LaPadula и Biba являются моделями информационных потоков, поскольку они в основном рассматривают процессы перехода данных с одного уровня на другой. Bell-LaPadula использует уровни безопасности, а Biba использует уровни целостности. Для экзамена CISSP важно знать правила Biba и Bell-LaPadula. Эти правила звучат очень просто и их просто запомнить – слово «простое» используется в отношении чтения, а «*» — в отношении записи. Поэтому вам нужно помнить только направления чтения и записи в каждой модели.

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

Ссылки по теме: 

• Security Models
  
• Course study materials for Introduction to Security, University of Cambridge, Dr. Markus Kuhn, principal lecturer (academic year 2003–2004)
  
• Chapter 3.3, “Models of OS Protection,” by Fred Cohen
  

Модель Clark-Wilson была разработана позднее модели Biba и использует несколько иной подход для защиты целостности информации. Эта модель использует следующие элементы:

• Пользователи (user) – активные агенты
• Процедуры преобразования (TP – transformation procedure) – запрограммированные абстрактные операции, такие как чтение, запись и изменение
• Ограниченные элементы данных (CDI – constrained data item) – могут управляться только TP
• Неограниченные элементы данных (UDI – unconstrained data item) – могут управляться пользователями посредством команд чтения и записи
• Процедуры проверки целостности (IVP – Integrity verification procedure) – запускаются периодически для проверки непротиворечивости CDI внешней действительности.

Когда приложение использует модель Clark-Wilson, оно разделяет данные на одно подмножество, которое должно быть максимально защищено (CDI), и подмножества, для которых такая защита не требуется (UDI). Пользователи не могут напрямую изменять критичные данные CDI. Вместо этого пользователи (субъекты) должны пройти аутентификацию в соответствующей части программного обеспечения, а программные процедуры (TP) выполнят необходимые операции от имени этих пользователей. Например, если Кэти нужно обновить информацию, содержащуюся в базе данных компании, она не может сделать этого без использования специального программного обеспечения, управляющего этими действиями. Сначала Кэти должна аутентифицироваться в соответствующей программе, которая является интерфейсом к базе данных, а затем программа будет управлять тем, что Кэти может и что не может делать с информацией в этой базе данных. Это называют тройкой доступа (access triple): субъект (пользователь), программа (TP) и объект (CDI). Пользователь не может вносить изменения в CDI без использования TP.

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

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

В некоторых случаях системе может потребоваться перенести данные UDI в данные CDI. Например, когда Кэти обновляет свой клиентский профиль через веб-сайт, чтобы указать свой новый адрес проживания, эта информация должна быть отправлена банковскому программному обеспечению, ответственному за почтовую информацию в банковских счетах. Банк не хочет, чтобы Кэти напрямую взаимодействовала с банковским программным обеспечением, поэтому применяется компонент программного обеспечения (TP), ответственный за копирование таких данных и обновление почтового адреса клиента. На этом этапе TP меняет статус данных с UDI на CDI. Эта концепция показана на Рисунке 3-17.

Рисунок 3-17. Субъект не может внести изменения в CDI без использования TP

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

Модель состоит из конструкций, математических формул и т.п. Модель предоставляет платформу, которая может использоваться для обеспечения конкретных характеристик в программном обеспечении (конфиденциальность, целостность и т.д.). Таким образом, модель не обуславливает, какие правила целостности должно реализовывать IVP; она просто предоставляет платформу, а производители выбирают правила целостности. Производители реализуют те правила целостности, которые нужны большинству их заказчиков. Поэтому если производитель разрабатывает приложение для финансовой компании, в состав UDI могут входить профили клиентов, которые позволено обновлять, а в состав CDI – информация о банковском счете, обычно хранящаяся на мейнфрейме. Данные UDI не требуется очень сильно защищать, они могут быть размещены на той же системе или на другой системе. Пользователь может иметь доступ к данным UDI без использования TP, однако когда пользователю нужно получить доступ к CDI, он обязан использовать TP. Таким образом, разработчики продукта определяют, какой тип данных будет рассматриваться как UDI, а какой тип данных является CDI, и разрабатывают TP для управления и дирижирования тем, как программное обеспечение будет обеспечивать целостность значений CDI.

В банковских приложениях IVP может гарантировать, что CDI содержит правильное значение. Например, если Кэти имеет 200 000 руб. на своем счете и кладет на него еще 50 000 руб., CDI для ее счета должен теперь иметь значение 250 000 руб. IVP гарантирует согласованность данных. Поэтому после того, как Кэти выполнит эту транзакцию и IVP проверит целостность CDI (новое значение остатка на банковском счете является правильным), тогда CDI будет считаться находящимся в согласованном (правильном) состоянии. Только TP является компонентом, позволяющим изменить состояние CDI. В нашем примере TP могут быть процедуры программного обеспечения, выполняющие операции пополнения счета, снятия денег со счета и их перевода. Использование TP для изменения CDI называют правильной транзакцией.

Правильная транзакция (well-formed transaction) – это последовательность операций, которые выполняются для перевода данных из одного согласованного состояния в другое. Если Кэти переводит деньги со своего текущего счета на свой депозитный счет, эта транзакция состоит из двух частей – списания суммы с одного счета и зачисления на другой. Гарантируя правильность и целостность нового значения остатка на текущем и депозитном счетах, IVP поддерживает внутреннюю и внешнюю согласованность. Модель Clark-Wilson также описывает, как реализовать разделение обязанностей в архитектуре приложения. Возвращаясь к нашему примеру с банковским программным обеспечением, если клиенту нужно снять более 1 000 000 руб., приложение должно требовать авторизации этой операции супервизором (например, начальником операционного отдела). Это является защитной мерой против потенциального мошенничества. Эта модель предоставляет правила, которым должны следовать разработчики для правильной реализации разделения обязанностей в процедурах своего программного обеспечения.

Ниже приведены три основных цели моделей целостности:

• Предотвращение выполнения изменений неуполномоченными пользователями
• Предотвращение выполнения некорректных изменений уполномоченными пользователями (разделение обязанностей)
• Обеспечение внутренней и внешней согласованности (правильные транзакции)

Модель Clark-Wilson учитывает все три эти цели (посредством тройки доступа, разделения обязанностей и аудита). Эта модель обеспечивает целостность, используя правильные транзакции (посредством тройки доступа) и разделение обязанностей. Модель Biba учитывает только первую цель.

Внутренняя и внешняя согласованность обеспечивается IVP, гарантирующими значения всех CDI согласуются со входными значениями, изменившими их состояние. Так, если Кэти имеет 250 000 руб. на своем счету и снимает 200 000 руб., то результирующее значение в CDI будет 50 000 руб.

ПРИМЕЧАНИЕ. Матрица контроля доступа рассматривалась в Домене 02. Это еще одна модель, часто используемая в операционных системах и приложениях.

Модель Bell-LaPadula сосредоточена на предотвращении утечки информации с высокого уровня безопасности на более низкий. Модель Biba сосредоточена на предотвращении утечки информации с низкого уровня целостности на более высокий. Обе эти модели построены на модели информационных потоков (information flow model). Модель информационных потоков может учитывать любые информационные потоки, а не только переходы информации с одного уровня безопасности (целостности) на другой.

В модели информационных потоков данные рассматриваются как хранящиеся отдельно или разделенные на группы. В модели Bell-LaPadula эти группы основаны на уровнях безопасности. Помните, что системы MAC основаны на модели Bell-LaPadula. Системы MAC используют метки для каждого субъекта и объекта. Метка субъекта указывает на уровень допуска субъекта и его категории «должен знать». Метка объекта указывает на его классификацию и категорию. Если вы в армии и имеете допуск к совершенно секретной информации, это не означает, что вы можете получить доступ ко всей военной совершенно секретной информации. Информация разделяется по двум факторам – классификация и категории «должен знать». Ваш допуск должен «доминировать» над классификацией объекта, а ваш профиль безопасности должен содержать одну из категорий, перечисленных в метке объекта, что реализует принцип «должен знать». Таким образом, Bell-LaPadula – это модель информационных потоков, которая гарантирует, что информация не может перейти из одной группы в другую способом, угрожающим конфиденциальности данных. Biba делит данные на основе уровней целостности. Это также модель информационных потоков, которая управляет потоком информации способами, обеспечивающими защиту целостности наиболее доверенной информации.

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

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

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

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

Существует два типа скрытых каналов: по памяти и по времени. В скрытом канале по памяти (covert storage channel) процессы могут взаимодействовать через некое пространство хранения информации в системе. При этом один процесс записывает данные в определенное место (любой вид памяти, хранилища информации), а другой – напрямую или не напрямую – читает их. Например, система A заражена троянской программой, которая установила программное обеспечение, способное взаимодействовать с другим процессом ограниченным способом. Система A имеет очень критичный файл (File 2), который представляет большой интерес для конкретного атакующего. Программное обеспечение, установленное троянской программой, имеет доступ к этому файлу на чтение и ему нужно отправить его содержимое атакующему, причем это будет происходить только по одному биту за раз. Это программное обеспечение будет взаимодействовать с атакующим посредством блокировки определенного файла (File 3). Когда атакующий попытается получить доступ к File 3 и выявит, что он заблокирован этой программой, он сделает вывод, что первый бит критичного файла – «1». Когда в следующий раз атакующий попытается получить доступ к File 3, он окажется незаблокирован. Атакующий интерпретирует это как следующее значение, являющееся «0». Это будет продолжаться до тех пор, пока все данные критичного файла не будут отправлены атакующему. В этом примере программное обеспечение, установленное троянской программой, является «передатчиком». Оно может получить доступ к критичному файлу и воспользоваться другим файлом на жестком диске для отправки сигналов атакующему.

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

Другой способ атаки через скрытый канал по памяти может осуществляться посредством создания файла. Система может быть скомпрометирована и на нее может быть установлено программное обеспечение, которое может создавать и удалять файлы в определенной директории и иметь доступ на чтение критичного файла. Когда это программное обеспечение увидит, что первый бит данных критичного файла является «1», оно создаст файл с именем Temp в определенной директории. Атакующий будет пытаться создать в этой же директории файл с таким же именем. Если атакующий получит сообщение об ошибке, говорящее, что такой файл уже существует в этой директории, он будет знать, что первый бит критичного файла – «1». Атакующий будет пытаться создать такой же файл снова и, если система позволит ему сделать это, значит вредоносное программное обеспечение, установленное в системе, удалило этот файл, говоря, что следующим битом является «0».

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

ПРИМЕЧАНИЕ. Открытый канал – это коммуникационный канал, который был разработан специально для коммуникационных целей. Процессам следует взаимодействовать через открытые каналы, а не через скрытые.

В скрытых каналах по времени (covert timing channel) один процесс передает информацию другому, получив сигнал в виде использования системных ресурсов. Два процесса взаимодействуют друг с другом, используя один и тот же общий ресурс, которым является время. Например, если один процесс обратился к диску 30 раз за 30 секунд, это является сигналом для другого процесса выполнить определенные вредоносные действия, на которые он был заранее запрограммирован. Еще один пример. Предположим, что процесс А является частью вредоносного программного обеспечения, установленного троянской программой. В многозадачной системе каждый процесс имеет возможность взаимодействия с процессором. Когда эта возможность предоставляется процессу А, он отвергает ее, что соответствует «1» для атакующего. В следующий раз процесс А использует доступ к процессору, что соответствует «0» для атакующего. Представьте, что это разновидность азбуки Морзе, использующая некоторый вид системных ресурсов.

Контрмеры

Поскольку все операционные системы имеют некоторые виды скрытых каналов, не всегда реально освободиться от всех из них. Число допустимых скрытых каналов обычно зависит от рейтинга уровня гарантий системы. Система, которая имеет рейтинг EAL 6 по Общим критериям, содержит меньше скрытых каналов, чем система с рейтингом EAL 3, поскольку рейтинг EAL 6 представляет собой более высокий уровень гарантий обеспечения конкретного уровня защиты, по сравнению с рейтингом EAL 3. Немногие пользователи могут обеспечить противодействие таким каналам, более правильно, чтобы такие каналы были учтены при проектировании и разработке системы.

ПРИМЕЧАНИЕ. В Оранжевой книге скрытые каналы в операционных системах не учитываются, пока уровень безопасности не опускается ниже уровня B2. Системы на уровнях ниже В2 хранят и обрабатывают достаточно критичную информацию, чтобы атакующие нашли любые пути для доступа к этой информации, в том числе посредством скрытых каналов.

Ссылки по теме:

• “Secure Databases: An Analysis of Clark-Wilson Model in a Database Environment,” by Xiaocheng Ge, Fiona Polack, and Rйgine Laleau
  
• “Access Control: Theory and Practice”
  
• “New Thinking About Information Technology Security,” by Marshall D. Abrams, PhD and Michael V. Joyce (first published in Computers & Security, Vol. 14, No. 1, pp. 57–68)
  

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

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

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

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

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

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

Сетка (lattice) – это математическая конструкция, построенная на основе понятия группы. Стандартное определение сетчатой модели (lattice model) звучит следующим образом: это «структура, состоящая из конечного, частично упорядоченного множества с определенной самой верхней границей и самой нижней границами операторов множества».

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

Вспомним модель MAC, которая рассматривалась в Домене 02, а затем затрагивалась и в этом Домене. В этой модели субъекты и объекты имеют метки. Метка каждого субъекта содержит допуск и категории «должен знать», к которым этот субъект имеет доступ. Предположим, что Кэти имеет уровень допуска «совершенно секретно» и она формально имеет доступ к разделам «Ирак» и «Корея» в соответствии со своими категориями «должен знать». Таким образом, ее метка – СС {Ирак, Корея}. Таблица 3-1 показывает различные файлы в системе в соответствии с этим сценарием. Эта система основана на модели MAC, т.е. операционная система принимает решения о возможности доступа на основе содержимого меток безопасности.

Таблица 3-1. Элементы управления доступом

Кэти пытается получить доступ к файлу В, поскольку ее допуск выше классификации файла В, она может читать этот файл, но не записывать в него (помните, в Bell-LaPadula субъект с более высоким уровнем может «читать снизу», но не «записывать вверх»). Это относится к «частично упорядоченному множеству с определенной самой верхней границей и самой нижней границами операторов множества». Множество – это субъект (Кэти) и объект (файл). Это частично упорядоченное множество, т.к. не все атрибуты управления доступом полностью эквивалентны. Система должна выбрать между чтением, записью, полным доступом, изменением и всеми другими видами разрешений доступа, используемыми этой операционной системой. Таким образом, «частично упорядоченное» означает, что система должна применять самый ограниченный вариант доступа к этому множеству. В качестве «самой верхней границы» система берет одно утверждение управления доступом (Кэти может читать файл), а другое утверждение управления доступом (Кэти не может записывать в файл) считается «самой нижней границей». Поскольку запрет записи – это более ограниченный вариант, чем разрешение чтения, самой верхней границей Кэти для этого файла будет чтение, а самой нижней границей – запрет записи. Рисунок 3-18 иллюстрирует границы доступа. Это просто более сложный способ сказать, что «самое большее, что Кэти может делать с этим файлом, это читать его. А самое меньшее – она не может записывать в него».

Рисунок 3-18. Границы доступа в сетчатой модели

Давайте изобразим самую верхнюю и самую нижнюю границы уровня доступа для Кэти и файла С. Допуск Кэти совпадает с классификацией файла С. В соответствии с моделью Bell-LaPadula в этом случае нужно применять строгое правило *-свойства (субъект имеет доступ на чтение и запись к объекту на том же уровне безопасности). Поэтому самая верхняя граница – это запись, а самая нижняя – чтение.

Посмотрим на метку безопасности файла D – она имеет категорию {Иран}, которая отсутствует в метке безопасности Кэти. Это означает, что у Кэти нет необходимой категории «должен знать» для доступа к этому файлу. Самая верхняя и самая нижняя границы разрешений доступа Кэти в этом случае будут соответствовать уровню «Нет доступа».

Так зачем же описывать эту достаточно простую концепцию таким сложным образом? Во-первых, здесь эта модель описана самыми простыми из возможных терминов, чтобы вам было проще понять ее назначение. Сложность в этой концепции появляется, если представить все взаимодействия субъект-объект, происходящие в рамках операционной системы каждую секунду. К тому же это формальная модель, т.е. она может доказать математически обеспечение определенного уровня защиты, при правильном следовании всем ее правилам. Изучение этой модели похоже на изучение основ химии. Студент сначала изучает, из чего состоит атом (протоны, нейтроны и электроны) и как эти элементы взаимодействуют друг с другом. Это легкая часть. Затем студент переходит к органической химии и должен понять, как все эти элементы работают вместе в сложной органической системе. Затем студент переходит к квантовой физике и изучает, что отдельные атомы в действительности имеют несколько различных субатомных частиц (кварки, лептоны и мезоны). В этой книге, вы изучаете только базовые компоненты этой модели.

Модель Brewer and Nash, также называемая моделью «Китайской стены», создана для обеспечения управления доступом, который может динамически изменяться в зависимости от предыдущих действий пользователя. Основной целью модели является защита от конфликтов интересов, вызванных попытками получения доступа пользователями. Например, большая маркетинговая компания реализует продвижение и предоставляет маркетинговые материалы двум банкам. При этом сотрудники этой компании, работающие над проектом для банка А не должны видеть маркетинговую информацию, относящуюся к банку Б, поскольку это может привести к конфликту интересов, т.к. банки конкурируют между собой. Если менеджер проекта для банка А сможет увидеть маркетинговые материалы для банка В, он сможет обеспечить наилучшее продвижение банка А, напрямую привлекая его клиентов. Это может повредить репутации маркетинговой компании, в которой сотрудники ведут себя настолько безответственно.

Этой компании следует внедрить продукт, который отслеживает доступ к информации представителей обеих этих групп и предотвращает конфликт интересов. На Рисунке 3-19 мы видим, что когда пользователь получает доступ к информации банка А, система автоматически запрещает ему доступ к информации банка В. Права доступа изменяются динамически на основе авторизации пользователей, их деятельности, предыдущих запросов на доступ.

Рисунок 3-19. Модель «Китайская стена» реализует динамическое управление доступом

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

Помните, что все вышеописанное является моделями, поэтому они не очень конкретны. Каждый производитель должен сам принимать решения как выполнять то или иное правило, определенное в выбранной модели. Модели Bell-LaPadula и Biba не определяют, как оцениваются и изменяются рейтинги безопасности и целостности, а также не предоставляют способа делегирования и передачи прав доступа. Модель Graham-Denning учитывает эти вопросы и определяет набор базовых прав в терминах команд, которые определенный субъект может выполнять над объектом. Эта модель имеет восемь команд защиты прав или правил, определяющих каким образом эта функциональность должна выполняться безопасным образом.

• Как безопасно создать объект
• Как безопасно создать субъект
• Как безопасно удалить объект
• Как безопасно удалить субъект
• Как безопасно прочитать права доступа
• Как безопасно предоставить права доступа
• Как безопасно удалить права доступа
• Как безопасно передать права доступа

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

Модель Harrison-Ruzzo-Ulman связана с правами доступа субъектов и целостностью этих прав. Субъект может выполнять только конечный набор операций над объектом. Пока безопасность достаточно проста, системе не сложно разрешить или запретить выполнение операций при условии, что одна команда ограничена одной операцией. Например, если субъект отправляет команду X, которая требует выполнения только операции Y, это позволяет системе достаточно просто принять решение о разрешении или запрете этой операции. Но если субъект отправляет команду M, для выполнения которой нужно выполнить операции N, B, W и P — системе гораздо более сложно решить, следует ли разрешать эту команду.

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

• Модель Bell-LaPadula. Это модель конфиденциальности, описывающая допустимые информационные потоки и формализующая военную политику безопасности. Это первая математическая модель многоуровневой политики безопасности, которая определяет концепцию безопасного состояния и необходимые режимы доступа.
• Простое правило безопасности. Субъект не может читать данные более высокого уровня безопасности, чем его допуск («не читать сверху»);
• Правило *-свойства. Субъект не может записывать данные в объект меньшего уровня безопасности, чем его допуск («не записывать вниз»);
• Строгое правило *-свойства. Субъект может выполнять функции чтения-записи только в отношении объекта, находящегося на том же уровне безопасности.

• Модель Biba. Эта модель защищает целостность информации в рамках системы и происходящих в ней действий. Она учитывает первую цель целостности.
• Простая аксиома целостности. Субъект не может читать данные с более низкого уровня целостности («не читать снизу»).
• Аксиома *-целостности. Субъект не может изменять объект на более высоком уровне целостности («не записывать вверх»).

• Модель Clark-Wilson. Это модель целостности, реализованная для защиты целостности данных и обеспечения того, чтобы выполнялись только корректные транзакции. Она учитывает все три цели целостности.
• Субъекты могут получить доступ к объектам только посредством авторизованных программ (тройка доступа).
• Реализация разделения обязанностей.
• Требуется ведение аудита.

• Модель матрицы контроля доступа. Это модель, которая принимает решения о предоставлении доступа на основе ACL объектов и таблиц разрешений субъектов.
• Модель информационных потоков. Это модель, в которой информация ограничена в своих потоках и может передаваться между сущностями только способами, которые не могут нарушить политику безопасности.
• Модель невлияния. Эта модель гласит, что команды и действия, выполняющиеся на одном уровне безопасности, не могут быть замечены и не могут оказать влияние на субъекты или объекты на другом уровне безопасности.
• Модель Brewer and Nash. Эта модель позволяет динамически изменять права доступа для защиты от конфликта интересов. Также известна как модель «Китайская стена».
• Модель Graham-Denning. Эта модель показывает, как следует создавать и удалять субъекты и объекты. Она также учитывает, как назначать отдельные права доступа.

Ссылки по теме:

• Various Papers on Models
  
• “A Lattice Model of Secure Information Flow,” by Dorothy E. Denning (first published in Communications of the ACM, Vol. 19, No. 5, pp. 236–243 (May 1976)
  
• Course syllabus for Security, University of Cambridge, Dr. Ross Anderson, principal lecturer (Jan. 1999)

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

Разграничение прав доступа — важнейший элемент обеспечения безопасности информационной системы, однако сама по себе безопасность не самоцель, хотя об этом не всегда помнят. Если на одном компьютере разместить исключительно секретные материалы и физически отрезать его от сети, то проблемы с безопасностью будут решены. В ряде случаев так и поступают, однако выделять по компьютеру на каждую категорию секретности неразумно — иногда требуется, не покидая защищенную систему, иметь доступ ко всей информации, в том числе и несекретной. Каким образом, запуская в защищенной среде таких разных ОС, как Astra Linux Special Edition и SELinux/SEPGSQL, приложение, использующее СУБД PostgreSQL, обеспечить разграничение прав доступа и предоставить пользователю ровно тот уровень секретности, который ему положен? При этом очевидно, что ставить мандатную СУБД поверх немандатной ОС бессмысленно.

Всегда можно представить ситуацию, когда в большой базе данных лишь часть информации секретна и важно обеспечить гранулированность доступности. Например, сотрудники районных отделений полиции получают доступ к данным только о жителях своего района, а на уровне города должна быть доступна информация о любом жителе мегаполиса. Такое разграничение доступа реализуется на уровне записей, или строк таблицы (Row Level Security, RLS), однако оно поддерживается не всеми СУБД.

В современных безопасных системах может быть реализована комбинация дискреционного (избирательного) разграничения доступа (Discretionary Access Control, DAC), ролевого разграничения доступа (Role Based Access Control, RBAC) и мандатного (принудительного, обычно многоуровневого) разграничения доступа (Mandatory Access Control, MAC). Как правило, они реализуются именно в таком порядке: следующий «поверх» предыдущего. То есть ресурс, доступный по правилам мандатного доступа, заведомо доступен по правилам дискреционного доступа, но не наоборот.

Мандатное управление доступом обсуждается редко, мало того, его иногда трактуют искаженно, опираясь на опыт работы с бумажными документами, для которых установлены различные уровни секретности. Перенос представлений о работе с бумажными документами на работу с электронными, на уровни доступа ОС и тем более на СУБД, иногда дезориентирует — сходство обманчиво. Для многоуровневой политики имеется простой принцип «читай вниз, пиши вверх», который не похож на то, что подразумевается в реальном мире. Принцип «Write up, read down. No read up, no write down» (субъект, обладающий определенным уровнем доступа, не может читать информацию, относящуюся к более высокому уровню, но может читать менее секретные документы; субъект, обладающий определенным уровнем доступа, не сможет создавать объекты с более низким уровнем допуска, чем имеет сам, но при этом может писать в более высокоуровневые объекты), входящий в модель Белла — Лападулы, прописан и в отечественных документах, регламентирующих требования к безопасности информационных систем. Первая половина этого принципа очевидна, а про вторую этого сказать нельзя: невозможно представить себе ситуацию из «бумажного» мира, когда сотрудник получает доступ на запись в документ высокой секретности, не имея при этом права (и возможности) его читать. Однако именно так исключается попадание данных, доступных высокоуровневым объектам, в низкоуровневые объекты.

Мандатное разграничение доступа еще называют принудительным контролем доступа: пользователь не может управлять доступом к информации, а сами правила доступа жестко определены политикой безопасности. Наличие разграничения доступа MAC, DAC и RBAC — обязательное требование при защите информации категории «гостайна», однако для разных ОС и СУБД оно может трактоваться по-разному. Например, в мандатном управлении доступа для операционной системы Astra Linux пользователь сам может выбирать уровень секретности из тех, что разрешены ему системным администратором, и этот уровень будет сохраняться на протяжении сессии. Теоретически мандатная система доступа не обязательно должна иметь различные уровни конфиденциальности (секретности или доступа), однако в реальной жизни редко находятся причины использовать немногоуровневую политику: именно она обязательна для систем с обеспечением гостайны.

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

Имеется некоторый набор средств для реализации мандатных ОС, но для российской действительности актуальны две — SELinux [1] и Astra Linux Special Edition [2].

SELinux (Security-Enhanced Linux) представляет собой обычный дистрибутив Linux, скомпилированный с набором модулей (LSM, Linux Security Modules), перехватывающих системные вызовы.

Модули представляют собой «крюки» («хуки»), к которым можно «подвесить» свои обработчики. Код SELinux открыт, и мандатный доступ строится поверх обычной системы доступа Linux — то есть файл, недоступный в Linux, будет недоступен и в SELinux, но не наоборот. При определении доступности файла система сравнивает метки субъекта и объекта, а затем принимает решение о допустимости операции. Метка представляет собой набор полей, содержимое которых может по-разному задаваться в различных политиках безопасности. Для создателей и пользователей мандатных систем наиболее интересна многоуровневая политика защиты (Multi Level Security, MLS), основанная на иерархии уровней секретности (чувствительности) и набора категорий. Пользователь SELinux — это сущность, определенная в политике, отвечающая за конкретный набор ролей и других атрибутов контекста безопасности. Пользователи SELinux отличаются от пользователей Linux, поэтому необходимо сопоставление (mapping) между ними через политику SELinux, позволяющее пользователям Linux наследовать ограничения пользователей SELinux.

Версия Astra Linux Special Edition разработана компанией «РусБИТех» на основе подсистемы PARSEC, целиком реализованной в виде модулей LSM, причем разработчики не декларируют следование модели Белла — Лападулы, а предлагают собственную патентованную «мандатную сущностно-ролевую ДП-модель» (модель логического управления доступом «Д» и информационными потоками «П»). Объекты располагаются в монотонной по доступу иерархии контейнеров (каталог — это контейнер для файлов, таблица базы данных — контейнер для записей). Уровень конфиденциальности контейнера не уступает уровню содержащихся в нем объектов. По умолчанию запись «вверх» в модели безопасности Astra Linux невозможна — можно писать только на свой уровень. Однако, поскольку работать с такой жесткой системой запретов трудно, а в некоторых ситуациях просто невозможно, вводятся средства игнорирования мандатных меток контейнера или объекта. Атрибут «ehole» мандатной метки позволяет игнорировать любые мандатные правила, а бит CCR делает «прозрачными» контейнеры, непрозрачные для нижележащих уровней секретности.

MAC В POSTGRESQL ДЛЯ SELINUX

В среде SELinux для поддержки разграничения доступа MAC для СУБД PostgreSQL имеется расширение sepgsql, которому необходима поддержка в ядре операционной системы, поэтому он может работать только в Linux 2.6.28 и выше. Это расширение работает на базе мандатной системы SELinux, используемой в Red Hat, CentOS, Fedora и др., а также в их российских собратьях: ОС «Синергия-ОС» (РФЯЦ-ВНИИЭФ), ОС «Заря» и ряде других.

При принятии решения о предоставлении доступа к объекту базы данных, sepqsql сверяется с политиками безопасности SELinux, поскольку внутри sepgsql нет самостоятельного механизма назначения, хранения и модификации меток пользователей. Расширение обеспечивает присвоение меток безопасности пользователям и объектам базы данных через внешних «провайдеров», одним из которых является SELinux. Можно назначать метки безопасности схемам, таблицам, столбцам, последовательностям, представлениям и функциям. Когда расширение sepgsql активно, метки безопасности автоматически назначаются поддерживаемым объектам базы в момент их создания в соответствии с политикой безопасности, которая учитывает метку создателя, метку, назначенную родительскому объекту создаваемого объекта, и, в некоторых случаях, имя создаваемого объекта. Для схем родительским объектом является текущая база данных; для таблиц, последовательностей, представлений и функций — схема, содержащая эти объекты; для столбцов — таблица.

Существующая реализация sepgsql имеет ряд особенностей и ограничений, которые необходимо принимать во внимание, но самое важное — это неспособность ограничения доступа на уровне строк. В версиях PostgreSQL 9.5 и 9.6 и во всех версиях Postgres Pro такая возможность предусмотрена.

MAC В POSTGRESQL ДЛЯ ASTRA LINUX

Защищенные версии СУБД PostgreSQL, поставляемые компанией «РусБИТех» вместе с Astra Linux Special Edition v.1.5, собраны со специальными патчами, позволяющими взаимодействовать с мандатной системой PARSEC. Они базируются на стандартных версиях PostgreSQL 9.2 либо PostgreSQL 9.4 и отличаются реализацией мандатного разграничения (в 9.4 более полный функционал и реализована ДП-модель управления доступом и информационными потоками, соответствующая модели безопасности в ОС Astra Linux). СУБД PostgreSQL использует механизмы ОС для того, чтобы пользователь получил те же поля метки мандатного доступа, что и пользователь ОС, вошедший с соответствующими мандатными атрибутами. В сессии возможен только один уровень конфиденциальности, а не диапазон, как в SELinux и sepgsql.

В качестве главного контейнера выбрано табличное пространство pg_global — одно на кластер базы данных. Применение мандатных прав доступа работает на уровне доступа к объектам базы данных и на уровне доступа непосредственно к данным. В отличие от sepgsql, эта реализация поддерживает разграничение на уровне записи: записи рассматриваются как объекты, а содержащие их таблицы — как контейнеры. Метки системных объектов располагаются в записях таблиц системного каталога, непосредственно описывающих защищаемый объект.

«СИНЕРГИЯ-БД»

В реальности встречаются ситуации, когда sepgsql недостаточно, — например, когда требуется защита на уровне строк. В поставку ОС Astra Linux входит защищенная СУБД, привязанная к мандатной системе безопасности ОС Astra Linux. При этом многие потребители нуждаются в защищенной, но платформенно-независимой СУБД. Кроме того, такую комбинацию СУБД и ОС проще сертифицировать: получить сертификат на комбинацию защищенной сертифицированной ОС и защищенной сертифицированной СУБД легче, чем на комплекс, в котором СУБД и ОС тесно взаимосвязаны. В последнем случае при изменении ОС (даже при переходе на другую версию той же ОС) придется заново начинать процесс инспекционного контроля сертифицированного продукта или процедуру сертификации.

Однако абсолютно кросс-платформенное решение невозможно — ОС, созданные даже на основе одного и того же ядра Linux, могут сильно отличаться [3]. Технически задача упростится, если исключить из набора платформ специфические ОС и взять за основу стандартные средства SELinux. Но тогда пришлось бы отказаться от поддержки платформы Astra Linux, популярной на ряде отечественных предприятий.

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

Мандатная СУБД «Синергия-БД», включающая в себя такое ПО промежуточного слоя, обеспечивает достаточную функциональность и приемлемую производительность (потери на уровне 15%). Эта СУБД разработана РФЯЦ-ВНИИЭФ и компанией Postgres Professional и представляет собой кросс-платформенную среду, работающую на отечественных системах «Синергия-ОС» и Astra Linux Special Edition.

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

За основу «Синергии-БД» была взята версия СУБД PostgreSQL 9.5.5, в которой имеются штатные методы аутентификации, настраиваемые через pg_hba.conf. На рис. 1 показан порядок взаимодействия удаленных пользователей с подсистемами безопасности двух разных ОС и «Синергии-БД».

Рис. 1. Политики ОС управляют правами доступа удаленного клиента

Пользователь авторизуется через механизмы СУБД, например PAM (Pluggable Authentication Modules — «подключаемые модули аутентификации») или GSS (Generic Security Services — «общий программный интерфейс сервисов безопасности», например Kerberos), после чего запускается проверка механизма мандатного доступа. Например, если таблица-контейнер «прозрачна», то для любого пользователя она открыта для чтения и записи, но увидит он в ней только те строки, уровень конфиденциальности которых равен его собственному или меньше. Это и есть разделение доступа на уровне строк, отвечающее модели Белла — Лападулы.

На рис. 2 приведена иерархия объектов «Синергии-БД» — если наследуется таблица, то она считается логически входящей в контейнер родительской таблицы. Видно, что доступ к средствам процедурных языков базы данных (и тем более к функциям) определяется на уровне базы данных, а не на глобальном уровне.

Рис. 2. Объекты-контейнеры и содержимое контейнеров в «Синергии-БД»

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

***

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

Литература

1. Андрей Боровский. SELinux — система повышенной безопасности // Открытые системы.СУБД. — 2005. — № 4. — С. 30–37. URL: http: www.osp.ru/os/2005/04/185543 (дата обращения: 18.03.2017).
2. Сергей Муравьев, Сергей Дворянкин, Игорь Насенков. СУБД: проблема выбора // Открытые системы.СУБД. — 2015. — №1. — С. 22–24. URL: https://www.osp.ru/os/2015/01/13045322 (дата обращения: 10.03.2017).
3. Алексей Гриневич, Денис Марковцев, Владимир Рубанов. Проблемы совместимости Linux-систем // Открытые системы.СУБД. — 2007. — № 1. — С. 10–15. URL: https://www.osp.ru/os/2007/01/3999198 (дата обращения: 18.03.2017).

Валерий Попов (v.popov@postgrespro.ru) — руководитель группы информационной безопасности и сертификации, компания Postgres Professional (Москва).

1. Дискреционные политики безопасности

Возможны следующие
подходы к построению дискреционного
управления доступом:

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

2. Система имеет
   одного выделенного субъекта —
   суперпользователя,
   который имеет право устанавливать
   права владения для всех остальных
   субъектов системы.

3. Смешанный вариант
   построения, когда одновременно в системе
   присутствуют как владельцы, устанавливающие
   права доступа к своим объектам, так и
   суперпользователь, имеющий возможность
   изменения прав для любого объекта и
   (или) изменения его владельца.

Именно такой
смешанный вариант реализован в большинстве
операционных систем, например, в
классических UNIX-системах
или в системахWindowsсемействаNT.

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

Исходная политика
избирательного разграничения доступа
к информации (дискреционная модель)
формируется путем задания администратором
набора троек следующего вида:

,

где
— субъект доступа,— объект доступа,— множество прав доступа, которыми
наделен субъектк объекту(например, чтение, запись, исполнение и
т.д.) [7].

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

Табл. 2.1. Дискреционная
матрица доступа

Для матрицы доступа,
представленной в таблице 2.1,
Пользователь_1 имеет права на чтение и
запись в Файл_2. Передавать эти права
другому пользователю он не может, но
может передавать права на чтение файла
1, имеет полные права при работе в файлом
3 и не имеет доступа к лиску CD—RW.

1. Мандатные политики безопасности

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

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

Источник
—
«http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D0%BD%D0%B4%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%BE%D0%BC»

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

1. Вводится множество
атрибутов (уровней) безопасности A,
элементы которого упорядочены с помощью
установленного отношения доминирования.
Например, для России характерно
использование следующего множества
уровней безопасности A={открыто
(О), конфиденциально (К), секретно (С),
совершенно секретно (СС), особая важность
(ОВ)}.

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

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

4. Если субъект
имеет уровень допуска
,
а объект
имеет уровень конфиденциальности
,
то
будет иметь допуск ктогда и только тогда, когда.

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

Пример 2.1

Пусть для компьютерной
системы задано 4 субъекта доступа
S={Administrator,
User1, User2, Guest} и 5 объектов O={File1.dat,
File2.txt,
File3.txt,
CD-ROM,
FDD}. Множество атрибутов безопасности
определено как A={NONCONFIDENTIAL,
CONFIDENTIAL, SECRET, TOP SECRET}.

Пусть уровни
допуска cубъектов
определены следующим образом:

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

Тогда, согласно
правилам исходной мандатной модели:

• субъект Administrator
  будет иметь допуск ко всем объектам;

• субъект User1 будет
  иметь допуск к объектам FDD, CD-ROM, File1.dat,
  File2.txt;

• субъект User2 будет
  иметь допуск к объектам FDD, CD-ROM;

• субъект Guest будет
  иметь допуск только к объекту FDD (flash).

Поставим вопрос,
сможет ли субъект Guest
в качестве злоумышленника получить
доступ к объекту File1.dat
? Путь к этому просматривается такой.
Завербовав пользователя User1, он сможет
получить доступ к информации из объекта
File1.dat
следующим путем. User1
записывает из объекта File1.dat
информацию в объект FDD, что будет ему
разрешено, а субъект Guest
после этого может этой информацией
пользоваться в обход мандатной политики
безопасности за счет приема социальной
инженерии.

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

Белла-ЛаПадулы
(БЛП), который устраняет данный недостаток
исходной мандатной политики безопасности
и осуществляет контроль доступа субъектов
к объектамкомпьютерной системы в зависимости от
уровня допуска субъектаи уровня конфиденциальности объектана основании двух следующих правил:

1. Правило NRU (нет
   чтения вверх).
   Согласно данному правилу субъект
   с уровнем допускаможет
   читать информацию из объектас уровнем безопасноститогда и только тогда, когда.
   Формально данное правило можно записать
   как(рис. 2.1)

2. Правило NWD
   (нет записи вниз).
   Согласно данному правилу субъект
   с уровнем допускаможет
   записывать информацию в объектс уровнем безопасноститогда и только тогда, когда.
   Формально данное правило можно записать
   как(рис. 2.1).

Особой
важности чтение

Совершенно
секретно

Секретно

Конфиденциально

Запись
Открыто

Рис. 2.1. Демонстрация
правил политики безопасности Белла-ЛаПадулы

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

Пример 2.2.

Рассмотрим пример
компьютерной системы, введенной в
примере 2.1.

При ее реализации
в рамках политики БЛП возможно выполнение
следующих операций:

1. Cубъект
Administrator
будет иметь допуск по чтению из всех
объектов, и допуск по записи в объект
File3.txt;

2. Cубъект
User1 будет иметь допуск по чтению из
объектов FDD, CD-ROM, File1.dat,
File2.dat
и допуск по записи в объекты File1.dat,
File2.txt,
File3.txt;

3. Cубъект
User2 будет иметь допуск по чтению из
объектов CD-ROM,
FDD
и допуск по записи в объекты File1.dat,
File2.txt,
File3.txt,
CD-ROM;

4. субъект Guest будет
иметь допуск по чтению из объекта FDD и
допуск по записи во все объекты.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Мандатное управление доступом (англ. Mandatory access control, MAC ) — разграничение доступа субъектов к объектам, основанное на назначении метки конфиденциальности для информации, содержащейся в объектах, и выдаче официальных разрешений (допуска) субъектам на обращение к информации такого уровня конфиденциальности. Также иногда переводится как Принудительный контроль доступа. Это способ, сочетающий защиту и ограничение прав, применяемый по отношению к компьютерным процессам, данным и системным устройствам и предназначенный для предотвращения их нежелательного использования.

Согласно требованиям ФСТЭК мандатное управление доступом или «метки доступа» являются ключевым отличием систем защиты Государственной Тайны РФ старших классов 1В и 1Б от младших классов защитных систем на классическом разделении прав по матрице доступа.

Пример: субъект «Пользователь № 2», имеющий допуск уровня «не секретно», не может получить доступ к объекту, имеющему метку «для служебного пользования». В то же время, субъект «Пользователь № 1» с допуском уровня «секретно» право доступа к объекту с меткой «для служебного пользования» имеет.

Содержание

Особенности [ править | править код ]

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

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

Самое важное достоинство заключается в том, что пользователь не может полностью управлять доступом к ресурсам, которые он создаёт.

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

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

Поддержка в современных операционных системах [ править | править код ]

Изначально такой принцип был воплощён в операционных системах Flask, и других ориентированных на безопасность операционных системах.

Исследовательский проект АНБ SELinux добавил архитектуру мандатного контроля доступа к ядру Linux, и позднее был внесён в главную ветвь разработки в Августе 2003 года.

Мандатная система разграничения доступа реализована в ОС FreeBSD Unix.

В SUSE Linux и Ubuntu есть архитектура мандатного контроля доступа под названием AppArmor.

В сертифицированной в системах сертификации Минобороны России и ФСТЭК России операционной системе специального назначения Astra Linux Special Edition, механизм мандатного разграничения доступа реализован, как и механизм дискреционного разграничения доступа в ядре ОС и СУБД. Решение о запрете или разрешении доступа субъекта к объекту принимается на основе типа операции (чтение/запись/исполнение), мандатного контекста безопасности, связанного с каждым субъектом, и мандатной метки, связанной с объектом.

В сетевые пакеты протокола IPv4 в соответствии со стандартом RFC1108 внедряются мандатные метки, соответствующие метке объекта — сетевое соединение. В защищенных комплексах гипертекстовой обработки данных, электронной почты и в других сервисах, мандатное разграничение реализовано на основе программного интерфейса библиотек подсистемы безопасности PARSEC.

Поддержка в современных системах управления базами данных [ править | править код ]

В СУБД ЛИНТЕР [1] мандатный контроль доступа к данным организуется на уровне таблиц, столбцов записей и отдельных полей записей.

В PostgreSQL в версии 9.2 появилась начальная поддержка SELinux.

Таблица 4.3.1.

Рисунок 4.3.1.

Методы разграничения доступа

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

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

Существуют следующие методы разграничения доступа:

1. Разграничение доступа по спискам.

2. Использование матрицы установления полномочий.

3. Разграничение доступа по уровням секретности и категориям.

4. Парольное разграничение доступа.

При разграничении доступа по спискам задаются соответствия: каждому пользователю – список ресурсов и прав доступа к ним или каждому ресурсу – список пользователей и их прав доступа к данному ресурсу.

Списки позволяют установить права с точностью до пользователя. Здесь нетрудно добавить права или явным образом запретить доступ. Списки используются в подсистемах безопасности операционных систем и систем управления базами данных.

Пример (операционная система Windows 2000) разграничения доступа по спискам для одного объекта показан на рис. 4.3.1.

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

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

Фрагмент матрицы установления полномочий показан в таб. 4.3.1.

Разграничение доступа по уровням секретности и категориям заключается в разделении ресурсов информационной системы по уровням секретности и категориям.

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

При разграничении по категориям задается и контролируется ранг категории пользователей. Соответственно, все ресурсы информационной системы разделяются по уровням важности, причем определенному уровню соответствует категория пользователей. В качестве примера, где используются категории пользователей, приведем операционную систему Windows 2000, подсистема безопасности которой по умолчанию поддерживает следующие категории (группы) пользователей: «администратор», «опытный пользователь», «пользователь» и «гость». Каждая из категорий имеет определенный набор прав. Применение категорий пользователей позволяет упростить процедуры назначения прав пользователей за счет применения групповых политик безопасности.

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

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

Разграничение прав доступа является обязательным элементом защищенной информационной системы. Напомним, что еще в «Оранжевой книге США» были введены понятия:

· произвольное управление доступом;

· принудительное управление доступом.

В ГОСТе Р 50739-95 «Средства вычислительной техники. Защита от несанкционированного доступа к информации» и в документах Гостехкомиссии РФ определены два вида (принципа) разграничения доступа:

· дискретное управление доступом;

· мандатное управление доступом.

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

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

При внимательном рассмотрении можно заметить, что дискретное управление доступом есть ничто иное, как произвольное управление доступом (по «Оранжевой книге США»), а мандатное управление реализует принудительное управление доступом.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Только сон приблежает студента к концу лекции. А чужой храп его отдаляет. 8940 — | 7611 — или читать все.

91.146.8.87 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)
очень нужно

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

Дискреционное разграничение доступа к объектам (Discretionary Access Control — DAC) характеризуется следующим набором свойств:

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

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

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

К достоинствам дискреционного разграничения доступа относятся относительно простая реализация (проверка прав доступа субъекта к объекту производится в момент открытия этого объекта в процессе субъекта) и хорошая изученность (в наиболее распространенных операционных системах универсального назначения типа Microsoft Windows и Unix применяется именно эта модель разграничения доступа).

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

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

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

Отмеченных недостатков во многом лишено мандатное разграничение доступа (Mandatory Access Control — MAC). К основным характеристикам этой модели относится следующее:

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

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

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

К другим достоинствам мандатного разграничения доступа относятся:

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

Отметим недостатки мандатного разграничения доступа к объектам компьютерной системы:

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

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

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

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

Формат сертификата открытого ключа, определенный в рекомендациях Х.509 Международного союза по телекоммуникациям (ITU), позволяет включать в состав сертификата дополнения (расширения, extensions), с помощью которых может быть реализована определенная политика безопасности в компьютерной системе конкретной организации. Каждое дополнение состоит из идентификатора объекта (object identifier) для типа дополнения, признака его критичности и закодированного значения дополнения.

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

Признак критичности дополнения сертификата используется для указания приложению, использующему данный сертификат, на возможность игнорирования информации, содержащейся в дополнении. Значение дополнения задается в виде блоба (bit large object — BLOB) — структуры, состоящей из полей с длиной значения дополнения и самим закодированным значением.

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

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

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

В Руководящем документе ФСТЭК России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации» содержатся следующие требования по разграничению доступа субъектов к защищенным объектам автоматизированных систем:

• • должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа (дискреционное разграничение доступа — классы защищенности 1 Г, 1В, 1Б, 1А);
• • должно осуществляться управление потоками информации с помощью меток конфиденциальности (мандатное разграничение доступа). При этом уровень конфиденциальности накопителей должен быть не ниже уровня конфиденциальности записываемой на них информации (классы защищенности 1В, 1Б, 1А).

Ролевое разграничение доступа (Role-Based Access Control — RBAC) основано на том соображении, что в реальной жизни организации ее сотрудники выполняют определенные функциональные обязанности не от своего имени, а в рамках некоторой занимаемой ими должности (или роли). Реализация ролевого разграничения доступа к объектам компьютерной системы требует разработки набора (библиотеки) ролей, определяемых как набор прав доступа к объектам информационной системы (прав на выполнение над ними определенного набора действий). Этот набор прав должен соответствовать выполняемой работником трудовой функции.

Наряду с пользователями (субъектами доступа) и объектами доступа ролевое разграничение доступа оперирует следующими понятиями:

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

Реализация ролевого разграничения доступа к объектам сводится к следующим шагам:

• • разработчики приложений, в которых над объектами системы выполняются определенные действия, совместно с администратором безопасности компьютерной системы и конструктором ролей составляют список привилегий и множество правил;
• • конструктор ролей разрабатывает библиотеку ролей для данной системы;
• • диспетчер ролей каждому пользователю системы статическим образом присваивает набор возможных для данного пользователя ролей (при этом могут использоваться статические ограничения на назначение ролей);
• • после авторизации пользователя в системе для него создается сессия (при этом могут использоваться динамические ограничения на использование ролей).

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

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

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

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

Разграничение доступа пользователей в ОС 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».

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

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

Механизмы мандатного управления доступом и мандатного контроля целостности реализованы в ядре ОС и затрагивают следующие подсистемы:

• механизмы IPC;
• стек TCP/IP (IPv4, IPv6);
• файловые системы (ФС) ext2/ext3/ext4/XFS;
• сетевые ФС CIFS;
• ФС proc, tmpfs.

В механизме мандатного управления доступом определены следующие термины:

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

Сущностям и субъектам присваиваются следующие мандатные атрибуты:

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

Мандатные атрибуты субъекта/сущности объединяются в мандатный контекст этого субъекта/сущности.

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

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

Принятие решения о запрете или разрешении доступа субъекта к сущности принимается на основе типа операции (чтение/запись/исполнение), мандатного контекста безопасности субъекта и мандатного контекста безопасности сущности.

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

Мандатный контекст безопасности

Мандатный контекст включает в себя:

• метку безопасности;
• дополнительные мандатные атрибуты управления доступом.

PARSEC-привилегии

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

PARSEC-привилегии и их описание приведены в статье: Привилегии PARSEC.

Для настройки КСЗ могут использоваться как PARSEC-, так и Linux-привилегии. Порядок управления привилегиями описан в документе РУСБ.10015-01 97 01-1.

Правила применения мандатного контекста безопасности