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

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

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

Отношение «субъекты — объекты» можно представить в виде матрицы доступа, в строках которой перечислены субъекты, в столбцах — объекты, а в клетках, расположенных на пересечении строк и столбцов, записаны дополнительные условия (например, время и место действия) и разрешен­ные виды доступа. Фрагмент матрицы представлен в табл.9.1:

Таблица 9.1. Фрагмент матрицы доступа

Примечание:"о" — обозначает разрешение на передачу прав доступа другим пользователям, "г" - чтение, "w" — запись, "е" — выполнение, "а" — добавление информации.

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

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

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

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

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

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

• атрибуты субъекта (метка безопасности, группа пользователя и т.п.); метки безопасности — основа принудительного (мандат­ного) управления доступом.

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

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

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

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

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

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

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