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

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

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

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

Разделы и классы

Критерии делятся на 4 раздела: D, C, B и A, из которых наивысшей безопасностью обладает раздел A. Каждый дивизион представляет собой значительные отличия в доверии индивидуальным пользователям или организациям. Разделы C, B и A иерархически разбиты на серии подразделов, называющиеся классами: C1, C2, B1, B2, B3 и A1. Каждый раздел и класс расширяет или дополняет требования указанные в предшествующем разделе или классе.

D — Минимальная защита

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

C — Дискреционная защита

· C1 — Дискреционное обеспечение секретности.

· Разделение пользователей и данных

· Дискреционное управление доступом, допускающее принудительное ограничение доступа на индивидуальной основе.

· C2 — Управление доступом

· Более чётко оформленное дискреционное управление доступом.

· Индивидуальные учётные записи, вход под которыми возможен через процедуру авторизации.

· Журнал контроля доступа к системе.

· Изоляция ресурсов.

B — Мандатная защита

· B1 — Защита с применением мета-безопасности

· Мандатное управление доступом к выбранными субъектам и объектам.

· Все обнаруженные недостатки должны быть устранены или убраны каким-либо другим способом.

· Маркировка данных

· B2 — Структурированная защита

· Чётко определённая и документированная модель правил безопасности.

· Применение расширенного дискреционного и мандатного управления доступом ко всем объектам и субъектам.

· Скрытые каналы хранения.

· B3 — Домены безопасности

· Соответствие требованиям монитора обращений.

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

· Поддержка администратора системы безопасности.

· Примером подобной системы является XTS-300, предшественница XTS-400.

A — Проверенная защита

A1 — Проверенный дизайн.

· По функциям идентично B3.

· Формализованный дизайн и проверенные техники, включающие высокоуровневую спецификацию.

· Формализованные процедуры управления и распространения.

· Примером подобной системы является SCOMP, предшественница XTS-400.

· Выше A1

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

Классы безопасности

В критериях впервые введены четыре уровня доверия — D, C, B и A, которые подразделяются на классы. Классов безопасности всего шесть — C1, C2, B1, B2, B3, A1 (перечислены в порядке ужесточения требований).

Уровень D

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

Уровень C

Иначе — произвольное управление доступом.

Класс C1

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

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

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

3. доверенная вычислительная база должна поддерживать область для собственного выполнения, защищенную от внешних воздействий;

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

5. защитные механизмы должны быть протестированы (нет способов обойти или разрушить средства защиты доверенной вычислительной базы);

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

Класс C2

В дополнение к C1:

1. права доступа должны гранулироваться с точностью до пользователя. Все объекты должны подвергаться контролю доступа.

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

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

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

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

Уровень B

Также именуется — принудительное управление доступом.

Класс B1

В дополнение к C2:

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

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

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

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

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

Класс B2

В дополнение к B1:

1. снабжаться метками должны все ресурсы системы (например, ПЗУ), прямо или косвенно доступные субъектам.

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

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

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

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

6. должна быть продемонстрирована относительная устойчивость доверенной вычислительной базы к попыткам проникновения.

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

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

9. тесты должны подтверждать действенность мер по уменьшению пропускной способности тайных каналов передачи информации.

Класс B3

В дополнение к B2:

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

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

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

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

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

6. должны существовать процедуры и/или механизмы, позволяющие произвести восстановление после сбоя или иного нарушения работы без ослабления защиты.

7. должна быть продемонстрирована устойчивость доверенной вычислительной базы к попыткам проникновения.

Уровень A

Носит название — верифицируемая безопасность.

Класс A1

В дополнение к B3:

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

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

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

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

Краткая классификация

Такова классификация, введенная в «Оранжевой книге». Коротко её можно сформулировать так:

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

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

· уровень A — верифицируемая безопасность.

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

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