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

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

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

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

субъект/объект	Имя служащего	Адрес	Данные об окладе
Отдел кадров
Касса
Отдел сбыта
….	…	Аij	….

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

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

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

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

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

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

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

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

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

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

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

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

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

гибкость.

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

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

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

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

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

Дата добавления: 2014-01-06