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

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

S WHERE CITY = LONDON

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

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

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

INSERT INTO S RELATION { TUPLE { S# S# ( S4 ),

SNAME NAME ( Baker ),

STATUS 25,

CITY Rome } } ;

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

INSERT INTO S RELATION { TUPLE {Si Si ( S4 ),

SNAME NAME ( Baker ),

STATUS 25,

CITY Rome,

CLASS CLASS { 3 ) } } ;

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

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

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

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

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

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

16.4. Статистические базы данных

Замечание. Большая часть материала, приведенного в это.м и следующем разделах, в несколько отличной форме сначапа была опубликована в [16.4].

Статистической (в приведенном здесь контексте) называется база данных, в которой допускаются запросы с обобщением данных (суммированием, вычислением среднего значения и т.д.), но не допускаются запросы по отношению к элементарным данным. Например, в статистической базе данных разрешается выдача запроса Какова средняя зарплата программистов? , тогда как выдача запроса Какова зарплата программиста Мэри? запрещена.

Проблема статистических баз данных заключается в том, что иногда с помощью логических заключений на основе выполнения разрешенных запросов можно вывести ответ, который прямо может быть получен только с помощью запрещенного запроса. Как указывается в [16.6], Обобщенные значения содержат следы исходной информации, и она может быть восстановлена злоумышленником после соответствующей обработки этих обобщенных значений. Такой процесс называется логическим выводом конфиден-циачьной инфор.мации\ Следует отметить, что эта проблема, к сожалению, становится все более и более важной по мере того, как использование хранилищ данных (см. главу 21) получает все большее распространение.

Предположим, что в базе данных содержится только одна переменная-отношение, STATS, представленная на рис. 16.2. Предположим также для простоты, что все атрибуты определены на основе примитивных типов данных (т.е. числового и строкового). Далее предположим, что некоторому пользователю U в этой базе данных разрешено выполнять только статистические запросы, но он поставил себе целью узнать размер зарплаты работника по имени Alf. Наконец предположим, что из других источников пользователь и узнал, что работник по имени Alf является мужчиной и программистом. Проанализируем представленные ниже запросы.

1.WITH ( STATS WHERE SEX = М AND

OCCUPATION = Programmer ) AS X :

COUNT ( X )

Результат: 1.

2. WITH ( STATS WHERE SEX = M AND

OCCUPATION = Programmer ) AS X : SUM ( X, SALARY )

Результат: 50 ООО. Глава 16. Защита данных 615

Puc. 16.2. Переменная-отношение STATS

Очевидно, что защита базы данных была нарушена, хотя пользователь U применил только разрешенные ему статистические запросы. Как показано в примере, если пользователь сумеет найти такое логическое выражение, которое позволит ему идентифицировать некоторую личность, то информация о данной личности окажется незащищенной. По этой причине система должна отвергать любые запросы, для которых кардинальность обобщаемого множества окажется менее некоторого установленного минимального значения Ь. Это также означает, что система должна отвергать запросы, кардинальность обобщаемого множества которых превосходит значение N-b (где N- кардинальность исходной переменной-отношения). Дело в том, что можно привести еще один пример нарушения защиты этой базы данных, осуществляемого посредством ввода показанной ниже последовательности запросов 3-6.

3. COUNT ( STATS ) Результат: 12.

4. WITH ( STATS WHERE NOT ( SEX = M AND

OCCUPATION = Programmer ) ) AS X :

COUNT ( X )

Результат: 11; 12 - 11 = 1.

5. SUM ( STATS, SALARY )

Результат: 728 ООО.

6. WITH ( STATS WHERE NOT ( SEX = M AND

OCCUPATION = Programmer ) ) AS X : SUM ( X, SALARY )

Результат: 678 ООО; 728 ООО - 678 ООО = 50 ООО.

К сожалению, можно легко показать, что для исключения нарушений защиты совершенно недостаточно определить допустимость запроса просто по значению кардинальности с обобщаемого им множества, которое должно находиться в диапазоне b < с < N - Ь. Еще раз обра-