1.4. Многозначность

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

На рис. 21-6 показан пример многозначного отношения, где для сотрудников военного учреждения указаны наряду с их реальными званиями и видами деятельности также фальшивые данные для прикрытия. На рис. 21-7 показано применение двух правил Белл-ЛаПадула в многозначной базе данных.

Рис. 21-6 Многозначность

Одно из направлений исследований - проблема многозначной целостности, возникшая в СУБД SeaView в связи с введением многозначности. Если не входить в детали, то правила многозначной целостности в SeaView включают функциональный и многозначный компоненты и сужают набор допустимых вариантов многозначного кортежа до подмножества вариантов, удовлетворяющих ограничениям многозначной целостности. Поскольку, по мнению некоторых специалистов, принятые в SeaView правила слишком ограничительны, то в статье "Polyinstantiation Integrity in Multilevel Relations" ("Целостность многозначности в многоуровневых отношениях") были предложены способы ослабления данной модели целостности. В этой статье описаны различные типы многозначных кортежей и сценарии, при помощи которых база данных должна поддерживать каждый экземпляр кортежа. В статье также предлагается удалить из модели многозначной целостности ту часть, которая касается многозначных зависимостей.

Рис. 21-7 Многозначность и свойства Белл-ЛаПадула

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

В отсутствие многозначности отношение с многоуровневой защитой, показанное на рис. 21-8(a), следовало бы обрабатывать следующим образом. База данных может маскировать значения, недоступные пользователю или процессу по соображениям безопасности, и такое маскирование обычно осуществляется при помощи пустых значений (null values, рис. 21-8(b)).

Рис. 21-8 Маскированные представления данных с целью обеспечения секретности

Напомним, что каждый кортеж существует в единственном экземпляре, поэтому непривилегированный процесс может попытаться записать неклассифицированные данные в столбцы кортежа, содержащие как бы пустые значения (рис. 21-9). В связи с этим в СУБД с многоуровневой защитой возникает проблема обработки таких операций, поскольку на самом деле значение столбца непустое, и замещать его нельзя. Естественно, что подобные попытки должны отвергаться средствами системы безопасности.

Рис. 21-9 Попытка модификации маскированных объектов

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

Допустим, что СУБД с многоуровневой защитой симулирует выполнение подобных модификаций, чтобы не раскрывать скрытый канал. Но что будет, если пользователь, только что изменивший некоторые данные, попытается выполнить запрос или приложение, которое обращается к этим данным, а ему ответят, что они отсутствуют? Значит, мы опять создаем косвенный канал.

А что если попытаться поддерживать в СУБД с многоуровневой защитой нечто вроде журнала таких модификаций и использовать его для последующих выборок? Знакомая идея, и неудивительно - ведь мы только что говорили о многозначности. Даже если мы предусмотрим какое-нибудь специфическое решение для реализации многозначности, например хранить два экземпляра кортежей, - это всего лишь одна из реализаций. Важно, что многозначность - это существенное свойство данных с многоуровневой защитой¹⁴⁾, а как она будет реализована - это вопрос второстепенный, не имеющий отношения к самой идее по-разному представлять информацию для пользователей разных уровней благонадежности; хотя способы реализации многозначности остаются важным направлением для исследовательской работы.

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

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

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