Мандатная защита

Средства мандатной защиты предоставляются специальными (trusted) версиями СУБД.

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

Для чего же нужна мандатная защита? Средства произвольного управления доступом характерны для уровня безопасности C. Как правило, их, в принципе, вполне достаточно для подавляющего большинства коммерческих приложений. Тем не менее они не решают одной весьма важной задачи — задачи слежения за передачей информации. Средства произвольного управления доступом не могут помешать авторизованному пользователю законным образом получить секретную информацию и затем сделать ее доступной для других, неавторизованных, пользователей. Нетрудно понять, почему это так. При произвольном управлении доступом привилегии существуют отдельно от данных (в случае реляционных СУБД — отдельно от строк реляционных таблиц), в результате чего данные оказываются «обезличенными» и ничто не мешает передать их кому угодно даже средствами самой СУБД; для этого нужно лишь получить доступ к таблице или представлению.

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

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

Использование СУБД с возможностями мандатной защиты позволяет разграничить доступ собственно к данным, хранящимся в информационной системе, от доступа к именованным объектам данных. Единицей защиты в этом случае будет являться, в частности, запись о договоре N, а не таблица или представление, содержащее информацию об этом договоре. Пользователь, который будет пытаться получить доступ к договору, уже никак не сможет обойти метку конфиденциальности. Существуют реализации, позволяющие разграничивать доступ вплоть до конкретного значения конкретного атрибута в конкретной строке конкретной таблицы. Дело не ограничивается одним значением метки конфиденциальности — обычно сама метка представляет собой набор значений, отражающих, например, уровень защищенности устройства, на котором хранится таблица, уровень защищенности самой таблицы, уровень защищенности атрибута и уровень защищенности конкретного кортежа.

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

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

Рассмотрим мандатную защиту подробнее. В качестве примера возьмем мандатную защиту СУБД «Линтер», которая получила признание в весьма специфическом секторе — силовых структурах, как единственная СУБД, имеющая сертификат по второму классу защиты от несанкционированного доступа, что соответствует классу B3 по американскому национальному стандарту.

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

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

В уже упоминавшихся «Критериях оценки надежных компьютерных систем» применительно к системам уровня безопасности B описан механизм меток безопасности, реализованный в рассматриваемых данной лекцией СУБД.

Метка объекта включает следующее:

1. Группа субъекта, который внес данный объект.
2. Уровень доступа на чтение — RAL (Read Access Level).
3. Уровень доступа на запись — WAL (Write Access Level).

Метка субъекта выглядит аналогично:

1. Группа, к которой принадлежит субъект.
2. RAL-уровень субъекта, который представляет собой максимальный RAL-уровень доступной субъекту информации.
3. WAL-уровень субъекта, то есть минимальный RAL-уровень объекта, который может быть создан этим субъектом.

Все пользователи базы данных считаются разбитыми на непересекающиеся группы. Группа описывает область доступных пользователю данных. Для каждой группы существует администратор группы (уровень DBA для группы), созданный администратором системы. При этом пользователи одной группы не видят данных, принадлежащих пользователям другой группы. В этом плане у СУБД «Линтер» имеется особенность: в системе реализовано такое понятие, как «уровень доверия между группами». При этом уровни доверия не могут быть вложенными. Группа представляет собой числовое значение в диапазоне [1-250]. Группа 0 — группа администратора системы. Только администратор системы может создать пользователя в группе, отличной от своей. Все данные, созданные от имени пользователя, помечаются его группой.

Уровни доступа вводятся для проверки прав на осуществление чтения-записи информации. Вводятся следующие уровни доступа:

1. Для пользователя (субъекта):

• RAL — уровень доступа; пользователь может получать (читать) информацию, RAL-уровень которой не выше его собственного уровня доступа;
• WAL — уровень доверия на понижение уровня конфиденциальности; пользователь не может вносить информацию с уровнем доступа (RAL-уровнем) более низким, чем данный WAL-уровень пользователя. Иными словами, пользователь не может сделать доступную ему информацию менее конфиденциальной, чем указано в данном параметре.

1. Для информации:

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

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

Конфигурация, к которой имеет доступ хотя бы один программист, не может считаться безопасной. Поэтому обеспечение информационной безопасности баз данных — дело весьма сложное, и во многом вследствие самой природы реляционных СУБД.

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

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