Книга: Безопасность информационных систем. Учебное пособие

4.2. Модели безопасности и их применение

4.2. Модели безопасности и их применение

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

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

Хорошая модель безопасности обладает свойствами абстрактности, простоты и адекватности моделируемой системе.

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

Доступ к информации — ознакомление с информацией, ее обработка, в частности, копирование, модификация или уничтожение информации.

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

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

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

Модель дискреционного доступа (DAC)

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

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

При запросе субъектом доступа к объекту система ищет субъекта в списке прав доступа объекта. Система разрешит доступ субъекта к объекту, если субъект присутствует в списке и имеет разрешенный требуемый тип доступа. Иначе доступ не предоставляется.

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

Такая модель реализована в операционных системах Windows и Linux.

В Linux для каждого файла (все ресурсы в операционной системе Linux представимы в виде файлов, в том числе устройства ввода-вывода) устанавливаются разрешения доступа для трех категорий субъектов: владелец файла, члены той же группы, что и владелец, и все остальные пользователи. Для каждой из этих категорий устанавливаются права на чтение (r), запись (w) и выполнение (x). Набор прав доступа объекта может быть представлен в виде символьной строки. Например, запись «rwxr-xr-» означает, что владелец файла может делать с ним все, что угодно; члены его группы могут читать и исполнять файл, но не могут записывать, а прочим пользователям доступно только чтение.

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

Модель безопасности белла-ЛаПадулы

Одна из наиболее известных моделей безопасности – модель Белла-ЛаПадулы (модель мандатного управления доступом). В ней определено множество понятий, связанных с контролем доступа. Даются определения субъекта, объекта и операции доступа, а также математический аппарат для их описания. Эта модель в основном известна двумя основными правилами безопасности: одно относится к чтению, а другое – к записи данных (Рис. 2).

Рис. 2. Модель безопасности Белла-ЛаПадулы

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

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

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

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

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

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

Ролевая модель контроля доступа (RBAC)

Ролевой метод управления доступом контролирует доступ пользователей к информации на основе типов их активностей в системе

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

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

Для формального определения модели RBAC используются следующие соглашения:

S = субъект – человек или автоматизированный агент.

R = роль – рабочая функция или название, определяется на уровне авторизации.

P = разрешения – утверждения режима доступа к ресурсу.

SE = сессия – Соответствие между S, R и/или P.

SA = назначение субъекта (Subject Assignment). SA ? S ? R. При этом субъекты назначаются связям ролей и субъектов в отношении «многие ко многим» (один субъект может иметь несколько ролей, а одну роль могут иметь несколько субъектов).

PA = назначение разрешения (Permission Assignment). PA ? P ? R. При этом разрешения назначаются связям ролей в отношении «многие ко многим».

RH = частично упорядоченная иерархия ролей (Role Hierarchy). PH ? R ? R.

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

Основные достоинства ролевой модели:

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

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

3. Разделение обязанностей.

RBAC широко используется для управления пользовательскими привилегиями в пределах единой системы или приложения. Список таких систем включает в себя Microsoft Active Directory, SELinux, FreeBSD, Solaris, СУБД Oracle, PostgreSQL 8.1, SAP R/3 и множество других, эффективно применяющих RBAC.

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

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

Конкретное воплощение модели разграничения доступа находят в системе разграничения доступа (СРД). СРД – это совокупность реализуемых правил разграничения доступа в средствах вычислительной техники или автоматизированных системах.

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

Основными требованиями к реализации диспетчера доступа являются:

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

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

3. Требование формальной проверки правильности функционирования.

4. Минимизация используемых диспетчером ресурсов.

База данных защиты строится на основе матрицы доступа или одного из ее представлений.

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

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

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

1. Списки управления доступом (access control lists, ACL). Для каждого объекта задан список субъектов, имеющих ненулевые полномочия доступа к ним (с указанием этих полномочий). В результате серьезно экономится память, поскольку из матрицы доступа исключаются все нулевые значения, составляющие большую ее часть. Списки управления доступом имеют недостатки:

• неудобство отслеживания ограничений и зависимостей по наследованию полномочий субъектов;

• неудобство получения сведений об объектах, к которым имеет какой-либо вид доступа субъект;

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

2. Списки полномочий субъектов. Аналогично ACL с той лишь разницей, что для каждого субъекта задан список объектов, доступ к которым разрешен с указанием полномочий доступа. Такое представление называется профилем субъекта. Оба представления имеют практически идентичные достоинства и недостатки.

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

Оглавление книги