цКЮБМЮЪ ЯРПЮМХЖЮ яКСВЮИМЮЪ ЯРПЮМХЖЮ
йюрецнпхх:
юБРНЛНАХКХюЯРПНМНЛХЪаХНКНЦХЪцЕНЦПЮТХЪдНЛ Х ЯЮДдПСЦХЕ ЪГШЙХдПСЦНЕхМТНПЛЮРХЙЮхЯРНПХЪйСКЭРСПЮкХРЕПЮРСПЮкНЦХЙЮлЮРЕЛЮРХЙЮлЕДХЖХМЮлЕРЮККСПЦХЪлЕУЮМХЙЮнАПЮГНБЮМХЕнУПЮМЮ РПСДЮоЕДЮЦНЦХЙЮоНКХРХЙЮоПЮБНоЯХУНКНЦХЪпЕКХЦХЪпХРНПХЙЮяНЖХНКНЦХЪяОНПРяРПНХРЕКЭЯРБНрЕУМНКНЦХЪрСПХГЛтХГХЙЮтХКНЯНТХЪтХМЮМЯШуХЛХЪвЕПВЕМХЕщЙНКНЦХЪщЙНМНЛХЙЮщКЕЙРПНМХЙЮ
тАБЛИЦА 5. фРАГМЕНТ МАТРИЦЫ ДОСТУПА.
|
|
Тема логического управления доступом — одна из сложнейших в области информационной безопасности. Причина в том, что само понятие объекта (а тем более видов доступа) меняется от сервиса к сервису. Для операционной системы в число объектов входят файлы, устройства и процессы. Применительно к файлам и устройствам обычно рассматриваются права на чтение, запись, выполнение (для программных файлов), иногда на удаление и добавление. Отдельным правом может быть возможность передачи полномочий доступа другим субъектам (так называемое право владения). Процессы можно создавать и уничтожать. Современные операционные системы могут поддерживать и другие объекты. Например, в ОС Solaris имеются отображения со своими видами доступа.
Для систем управления реляционными базами данных объект — это база данных, таблица, представление, хранимая процедура. К таблицам применимы операции поиска, добавления, модификации и удаления данных, у других объектов иные виды доступа. И список этот можно продолжать до бесконечности.
Разнообразие объектов и применимых к ним операций приводит к принципиальной децентрализации логического управления доступом. Каждый сервис должен сам решать, позволить ли конкретному субъекту конкретную операцию. Теоретически это согласуется с современными объектно-ориентированными воззрениями, на практике же приводит к значительным трудностям. Главная проблема в том, что ко многим объектам можно получить доступ с помощью разных сервисов (возможно, при этом придется преодолеть некоторые технические трудности). Так, до реляционных таблиц можно добраться не только средствами СУБД, но и путем непосредственного чтения файлов или дисковых разделов, поддерживаемых операционной системой (разобравшись предварительно в структуре хранения объектов базы данных). В результате при задании матрицы доступа нужно принимать во внимание не только разумность распределения привилегий для каждого сервиса, но и существующие связи между сервисами (приходится заботиться о согласованности разных частей матрицы). Аналогичная трудность возникает при экспорте/импорте данных, когда информация о правах доступа, как правило, теряется (поскольку на новом сервисе она не имеет смысла). Следовательно, обмен данными между различными сервисами представляет особую опасность с точки зрения управления доступом, а при проектировании и реализации разнородной конфигурации необходимо позаботиться о согласованном распределении прав доступа субъектов к объектам и о минимизации числа способов экспорта/импорта данных.
Контроль прав доступа производится разными компонентами программной среды — ядром операционной системы, дополнительными средствами безопасности, системой управления базами данных, посредническим программным обеспечением (таким как монитор транзакций) и т.д. Тем не менее, можно выделить общие критерии, на основании которых решается вопрос о предоставлении доступа, и общие методы хранения матрицы доступа.
При принятии решения о предоставлении доступа обычно анализируется следующая информация:
· Идентификатор субъекта (идентификатор пользователя, сетевой адрес компьютера и т.п.). Подобные идентификаторы являются основой произвольного управления доступом (см. Разд. Произвольное управление доступом).
· Атрибуты субъекта (метка безопасности, группа пользователя и т.п.). Метки безопасности - основа принудительного управления доступом (см. Разд. Метки безопасности и Разд. Принудительное управление доступом). В последнее время все большее распространение в системах управления базами данных получает понятие роли. В самом общем виде роль можно трактовать как атрибут, который субъект может получить, пройдя процедуру дополнительной аутентификации. На практике роли ассоциируют с приложениями (например, ввод данных о зарплате или генерация годового отчета) и защищают разделяемыми (то есть общими для нескольких субъектов) паролями. Последнее обстоятельство снижает реальную ценность роли как механизма безопасности.
· Место действия (системная консоль, надежный узел сети и т.п.).
· Время действия (большинство действий целесообразно разрешать только в рабочее время).
· Внутренние ограничения сервиса (число пользователей, записанное в лицензии на программный продукт, сумма, которую разрешается выдавать наличными и т.п.).
Матрицу доступа, ввиду ее разреженности (большинство клеток — пустые), неразумно хранить в виде двумерного массива. В принципе можно представлять ее по строкам, поддерживая для каждого субъекта перечень доступных ему объектов, однако, поскольку объекты гораздо динамичнее субъектов (они чаще создаются и уничтожаются), подобный подход чрезмерно усложняет администрирование. Практичнее хранить матрицу по столбцам, то есть для каждого объекта поддерживать список " допущенных" субъектов вместе с их правами. Элементами списков могут быть имена групп и шаблоны субъектов, что служит существенным подспорьем администратору. Некоторые проблемы возникают только при удалении субъекта, когда приходится устранять его имя из всех списков доступа; впрочем, операция эта нечастая.
Списки доступа — исключительно гибкое средство. С их помощью легко выполнить требования класса безопасности C2 о гранулярности прав с точностью до пользователя. Посредством списков несложно добавить права или явным образом запретить доступ (например, чтобы наказать нескольких членов группы пользователей). Безусловно, списки являются лучшим средством произвольного управления доступом [13].
Ограниченная форма списков доступа реализована в ОС UNIX. В UNIX-списке всегда три элемента: владелец, группа владельца и прочие пользователи. Теоретически, создав достаточно большое число групп, можно и при ограниченной форме добиться индивидуальной гранулярности прав, но на практике это, конечно, нереально (да и не особенно нужно).
Подавляющее большинство операционных систем и систем управления базами данных реализуют именно произвольное управление доступом. Основное достоинство произвольного управления — гибкость. Вообще говоря, для каждой пары (субъект, объект) можно независимо задавать права доступа (особенно легко это делать, если используются списки управления доступом). К сожалению, у " произвольного" подхода есть ряд принципиальных недостатков. Рассредоточенность управления доступом ведет к тому, что надежными должны быть многие пользователи, а не только системные операторы или администраторы. Рассеянность или некомпетентность владельца секретной информации может открыть ее (информацию) всем прочим пользователям. Следовательно, произвольность управления должна быть дополнена жестким контролем за проведением избранной политики безопасности.
Второй недостаток, который представляется основным, состоит в том, что права доступа существуют отдельно от данных. Ничто не мешает пользователю, имеющему доступ к секретной информации, записать ее в доступный всем файл. Подобная " отделенность" прав и данных существенно осложняет проведение несколькими системами согласованной политики безопасности и, главное, делает практически невозможным эффективный контроль согласованности.
Имеется третий, функциональный способ представления матрицы доступа, когда ее вообще не хранят в явном виде, а каждый раз вычисляют содержимое соответствующих клеток. Например, при принудительном управлении доступом применяется сравнение меток безопасности субъекта и объекта, в защитных надстройках над операционными системами класса MS-DOS запрашивается пароль, при использовании шифрования необходимо знать секретный ключ (иначе информацию не удастся прочитать). Из соображений построения эшелонированной обороны целесообразно сочетать применение списков управления доступом (в полной или ограниченной форме) и функционального представления (обычно основанного на шифровании информации).
Удобной надстройкой над средствами логического управления доступом является ограничивающий интерфейс, когда пользователя лишают самой возможности попытаться совершить несанкционированные действия, включив в число видимых ему объектов только те, к которым он имеет доступ. Подобный подход обычно реализуют в рамках системы меню (пользователю показывают лишь допустимые варианты выбора) или посредством ограничивающих оболочек, таких как restricted shell в ОС UNIX. Вне всяких сомнений, лучше совсем не вводить в искушение, чем потом долго рассказывать про мучения грешников в аду.
В заключение раздела хотелось бы еще раз подчеркнуть важность управления доступом не только на уровне операционной системы, но и в рамках других сервисов, входящих в состав современных приложений, а также, насколько это возможно, на " стыках" между сервисами. Здесь на первый план выходят существование единой политики безопасности организации, а также квалифицированное и согласованное системное администрирование.