16.3. Мандатная схема управления доступом

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

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

2. Пользователь i может модифицировать объект j только в том случае, если его уро- вень допуска равен классификационному уровню объекта j ("ограничение звания").

Первое правило достаточно очевидно, тогда как второе требует дополнительных разъяснений. Прежде всего, следует отметить, что иначе второе правило можно сформу- лировать так: "Любая информация, записанная пользователем i, автоматически приобре- тает классификационный уровень, который равен уровню допуска пользователя i". По- добное правило необходимо, например, для того, чтобы предотвратить запись секретных данных, выполняемую пользователем с уровнем допуска "Секретно", в файл с меньшим уровнем классификации, что нарушит всю систему секретности.

Замечание. В отношении только операций собственно "записи" (INSERT) во втором правиле достаточно было бы потребовать, чтобы уровень допуска пользователя i был меньше классификационного уровня объекта j или равен ему, и именно это правило час- то приводится в литературе. Но тогда пользователи могли бы записывать то, что потом сами не смогли бы прочесть! (Хотя бывает так, что кое-кто с трудом может прочесть да- же собственный рукописный текст... Возможно, более слабый вариант второго правила все-таки не совсем нереалистичен.)

Особенно большое внимание методам мандатного управления доступом стало уделяться в начале 1990-х годов. Дело в том, что согласно требованиям Министерства обороны США лю- бая используемая в этом ведомстве СУБД должна непременно поддерживать схему мандат- ного управления доступом. Поэтому разработчикам СУБД пришлось вступить в соперничест- во за скорейшую разработку методов такого управления. Обязательные требования к этой схеме были изложены в двух важных публикациях Министерства обороны, неформально по- лучивших название "Оранжевая" книга (Orange Book) [16.19] и "Сиреневая" книга (Lavender Book) [16.20]. В "оранжевой" книге перечислен набор требований защиты для неко- торой "надежной вычислительной базы" (Trusted Computing Base — ТСВ), а в "сиреневой" книге дается интерпретация этих требований в отношении систем баз данных.

Определенные в [16.19], [16.20] методы мандатного управления доступом на самом де- ле являются частью более общей классификации уровней защиты, которые в очень сжатой форме излагаются ниже. Прежде всего, в этих документах определяется четыре класса безопасности — D, С, В и А. Грубо говоря, класс D среди них наименее безопасен, класс С — более безопасен, чем класс D, и т.д. Говорят, что класс D обеспечивает минимальную, класс С — избирательную, класс В —мандатную и класс А — проверенную защиту.

■ Избирательная защита. Класс С делится на два подкласса, О и С2 (где подкласс С1 менее безопасен, чем подкласс С2), каждый из которых поддерживает избира- тельное управление доступом в том смысле, что управление доступом осуществля- ется по усмотрению владельца данных (точно так, как описано выше, в разделе 16.2).

■ В соответствии с требованиями класса С1 необходимо отделить владение от дос- тупа, т.е. наряду с поддержкой концепции совместного доступа к данным поль- зователям разрешается иметь собственные защищенные данные.

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

■ Мандатная защита. Класс В включает требования к методам мандатного управ- ления доступом и делится на три подкласса — В1, В2 и ВЗ (где В1 является наи- менее, а ВЗ — наиболее безопасным подклассом).

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

• В соответствии с требованиями класса В2 дополнительно требуется поддержка формальных операторов определения требований защиты. Кроме того, необходимо обеспечить обнаружение и исключение каналов утечки информации. Таким кана- лом может быть, например, возможность логического вывода ответа на недопус- тимый запрос из ответа на допустимый запрос (см. раздел 16.4) или возможность раскрытия секретных сведений на основании времени, которое затрачивается на выполнение некоторых допустимых запросов (см. комментарии к [16.12]).

• В соответствии с требованиями класса ВЗ необходимо дополнительно обеспе- чить поддержку контрольного слежения и восстановления данных, а также на- значить администратора защиты системы.

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

В настоящее время некоторые коммерческие СУБД поддерживают мандатную схему защиты уровня В1. Кроме того, они обычно поддерживают избирательную схему защиты уровня С2.

Терминология. СУБД, в которых поддерживается мандатная схема защиты, часто на- зывают системами с многоуровневой защитой [16.13], [16.16], [16.21] (см. следующий подраздел). В этом же смысле иногда используется термин надежная система [16.17], [16.19], [16.20].

Многоуровневая защита

Допустим, что требуется применить идеи мандатной схемы управления доступом к переменной-отношению поставщиков S. Для определенности и простоты будем считать, что единицей данных, на уровне которой требуется контролировать доступ, является от- дельный кортеж этой переменной-отношения. Тогда каждый кортеж должен быть отме- чен соответствующим классификационным уровнем, например так, как показано на рис. 16.1. (Здесь значение 4 в столбце CLASS означает уровень "Совершенно секретно", 3 — "Секретно", 2 — "Для служебного пользования".)

s#	SNAME	STATUS	CITY	CLASS
SI	Smith	20	London	2
S2	Jones	10	Paris	3
S3	Blake	30	Paris	2
S4	Clark	20	London	4
S5	Adams	30	Athens	3

Рис. 16.1. Переменная-отношение S с присвоенными значениями классификационного уровня

Теперь предположим, что пользователи 01 и U2 имеют уровни доступа 3 ("Секретно") и 2 ("Для служебного пользования") соответственно. Тогда переменная-отношение S для этих пользователей будет выглядеть по-разному! Запрос на выборку сведений обо всех поставщиках со стороны пользователя 01 возвратит четыре кортежа с данными о по- ставщиках с номерами 'SI', 'S2', 'S3' и 'S5'. Аналогичный запрос со стороны пользо- вателя 02 возвратит два кортежа с данными о поставщиках с номерами 'S1' и 'S3'. Бо- лее того, в результатах выполнения обоих запросов будут отсутствовать сведения о по- ставщике с номером ' S4'.

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

S WHERE CITY = 'LONDON'

Система модифицирует этот запрос и приводит его к следующему виду.

S WHERE CITY = 'LONDON' AND CLASS < <уровень доступа пользователя?

Аналогичные соображения будут справедливы и по отношению к операциям об- новления. Например, пользователь 01 не знает о существовании кортежа для постав- щика с номером 'S4', а потому приведенная ниже команда INSERT может показаться ему вполне законной.

INSERT INTO S RELATION { TOPLE { S# S# ( 'S4' ),

SNAME NAME ( 'Baker' ),

STATUS 25,

CITY 'Rome' } } ;

Система не должна отвергать команду INSERT, поскольку в этом случае пользователь 01 в конечном счете узнает о существовании поставщика с номером 'S4'. Такую коман- ду система примет, но модифицирует ее и приведет к следующему виду.

INSERT INTO S RELATION { TOPLE {Si SI ( 'S4' ),

SNAME NAME ( 'Baker' ),

STATUS 25,

CITY 'Rome',

CLASS CLASS ( 3 ) } } ;

Обратите внимание, что в данном случае первичным ключом для переменной-отношения поставщиков является уже не атрибут {SI}, а комбинация атрибутов {SI,CLASS}.

Замечание. Для простоты предполагается, что существует только один потенциаль- ный ключ, который в этом случае можно рассматривать как первичный ключ.

Еще о терминологии. Модифицированная указанным образом переменная-отношение поставщиков является примером многоуровневой переменной-отношения. Та особен- ность, что "одни и те же" данные по-разному выглядят для разных пользователей, назы- вается полиреализацией. В приведенном выше примере с оператором INSERT запрос на извлечение данных о поставщике с номером ' S4' возвратит разные результаты для поль- зователя с правом доступа к совершенно секретным материалам и для пользователя U1,

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

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

Вопрос. Как вы думаете, не нарушают ли эти идеи упомянутый выше принцип ин- формации! Обоснуйте свой ответ.