где 01 – чтение, 10 – запись, 11 – чтение и запись, 00 – нет доступа к объекту данных.

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

1)Решение о доступе основывается на текущем значении ресурса, например, нельзя читать поле «зарплата», если величина зарплаты больше некоторого значения.

2)Доступ к ресурсу разрешается только в рабочее время.

Разнообразие объектов и применимых к ним операций приводит к принципиальной

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

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

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

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

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

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

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

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

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

список "допущенных" субъектов вместе с их правами. Например:

1 элемент списка Имя служащего (Отдел кадров 11, Касса 01);

2 элемент списка Адрес (……)

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

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

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

Достоинством произвольного управления является гибкость.

К сожалению, у «произвольного» подхода есть ряд принципиальных недостатков:

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

Например, при принудительном управлении доступом применяется сравнение меток безопасности субъекта и объекта.

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

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

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

Под протоколированием понимается сбор и накопление информации о событиях, происходящих в информационной системе предприятия.

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

внешние (вызванные действиями других сервисов),

внутренние (вызванные действиями самого сервиса) и

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

К числу регистрируемых событий относятся: вход в систему; выход из системы;

обращение к удаленным системам;

операции с файлами; смена привилегий или иных атрибутов безопасности.

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

Перечислим информацию, которую нужно регистрировать: дату и время;

ID пользователя;

тип события (вход, выход);

результат действия (успех или неудача);

источник запроса;

имена затронутых объектов;

запись изменений в БД защиты; метки безопасности.

Аудит - это анализ накопленной информации, проводимый оперативно, (почти) в реальном времени, или периодически (например, раз в день).