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

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

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

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

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

1. WITH { STATS WHERE SEX = 'M' AND

OCCUPATION = 'Programmer' ) AS X :

COUNT ( X )

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

2. WITH ( STATS WHERE SEX = 'M' AND

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

Результат: 50 000. |

NAME	SEX	CHILDREN	OCCUPATION	SALARY	TAX	AUDITS
Alf	M	3	Programmer	50K	10K	3
Be a	F	2	Physician	130K	20K	0
Cary	F	0	Programmer	56K	18K	1
Dawn	F	2	Builder	60K	12K	1
Ed	M	2	Clerk	44K	4K	0
Fay	F	1	Artist	30K	OK	0
Guy	M	0	Lawyer	190K	OK	0
Hal	M	3	Homemaker	44k	2k	0
Ivy	F	4	Programmer	64K	10K	1
Joy	F	1	Programmer	60K	2-K	1

Рис. 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 - Ь. Еще раз обра-

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

SEX = 'М' AND OCCUPATION = 'Programmer'

Теперь рассмотрим приведенную ниже последовательность запросов 7-10.

7. WITH ( STATS WHERE SEX = 'M' ) AS X : COUNT ( X j

Результат: 4,

8. WITH ( STATS WHERE SEX = 'M' AND NOT

{ OCCUPATION = 'Programmer' ) ) AS X :

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

На основании запросов 7 и 8 пользователь U может сделать вывод, что существует только один мужчина-программист, следовательно, его зовут 'Alf' (поскольку поль- зователь U уже знает из других источников, что сотрудник по имени 'Alf является мужчиной и программистом). Зарплата этого сотрудника может быть определена сле- дующим образом.

9. WITH ( STATS WHERE SEX = 'M' ) AS X : SUM ( X, SALARY )

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

10. WITH ( STATS WHERE SEX = 'M' AND NOT

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

Результате: 278 000; 328 000-278 000 = 50 ООО. |

Логическое выражение SEX = 'M' AND OCCUPATION = 'Programmer' называется тре- кером (охотником) за индивидуальными данными (individual tracker) для человека по имени 'Alf [16.6], поскольку оно позволяет отыскать индивидуальную информацию о человеке по имени 'Alf. В общем случае, если пользователю известно некоторое логи- ческое выражение BE, идентифицирующее некоторого человека I, и если логическое вы- ражение BE может быть выражено в виде ВЕ1 AND ВЕ2, логическое выражение ВЕ1 AND NOT ВЕ2 является трекером за индивидуальными данными человека по имени I (при ус- ловии, что в системе разрешено использовать выражения ВЕ1 и BEl AND NOT ВЕ2, т.е. оба они приводят к результату, кардинальность (с) которого находится в диапазоне b < с < N - Ь). Причина этого заключается в том, что определенное с помощью BE множество идентично разнице между множеством, определенным с помощью ВЕ1, и множеством, определенным с помощью BEl AND NOT ВЕ2, что наглядно представлено на рис. 16.3.

set ( BE ) = set ( BEl AND BE2 )

= set (BEl) - set (BEl AND NOT BE2)

Множество, идентифицированное булевым выражением ВЕ1

Множество, идентифицированное булевым выражением

_B£f .

AND Множество, идентифицированное

NOT булевым выражением

ВЕ2 BE1ANDBE2

-т.е. {1}

[Множество, идентифицированное || булевым выражением ВЕ2

Рис. 16.3. Трекер за индивидуальными данными ВЕ1 AND ЮТ ВЕ2

В [16.6] упомянутые здесь идеи обобщены и показано, что практически для лю- бой статистической базы данных всегда может быть определен общий трекер (в от- личие от множества индивидуальных трекеров). Общий трекер (general tracker) — это логическое выражение, которое может быть использовано для поиска ответа на любой запрещенный запрос, т.е. запрос, включающий недопустимое логическое вы- ражение. (В противоположность этому индивидуальный трекер работает только на основе запросов, включающих конкретные запрещенные выражения.) Фактически оказывается, что любое логическое выражение с результирующим набором данных с кардинальностью с в диапазоне 2Ь < с < N - 2Ь является общим трекером (здесь b должно быть меньше, чем N/4, что обычно всегда выполняется на практике). Как только такой трекер будет найден, сразу же можно будет получить ответ на запрос, включающий запрещенное логическое выражение BE, что наглядно показано в сле- дующем примере. (Для определенности рассмотрим случай, в котором кардиналь- ность результирующего множества логического выражения BE меньше Ь. Случай, когда b больше N - Ь, обрабатывается аналогично.) Обратите внимание, что по оп- ределению Т является общим трекером тогда и только тогда, когда NOT Т также яв- ляется общим трекером.

Пример. Предположим снова, что b = 2; тогда общим трекером будет любое логиче- ское выражение с кардинальностью результирующего множества с в диапазоне 4 < с < 6. Еще раз предположим, что пользователю 0 известно из внешних источников, что со- трудник по имени 'hit' является мужчиной и программистом, т.е. запрещенное логиче- ское выражение BE выглядит так, как показано ниже.

SEX = 'М' AND OCCUPATION = 'Programmer'

Допустим также, что пользователь U хочет узнать размер зарплаты сотрудника 'Alf'. В этом случае общий трекер придется применить дважды: сначала, чтобы удо- стовериться, что BE действительно идентифицирует сотрудника по имени 'Alf (этапы 2-4), а затем непосредственно для того, чтобы определить размер зарплаты сотрудни- ка 'Alf (этапы 5-7).

Этап 1. Попробуем найти выражение для общего трекера Т. В качестве первого приближения выберем следующее выражение.

AUDITS = О

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

WITH ( STATS WHERE AUDITS = 0 ) AS X : COUNT { X )

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

WITH { STATS WHERE NOT ( AUDITS = 0 ) ) AS X : COUNT ( X )

Результат: 5; 5 + 5 = 10.

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

Этап 3. Найдем результат сложения общего количества сотрудников в базе данных с количеством сотрудников, для которых удовлетворяется неразрешенное выраже- ние BE, для чего используем выражения BE OR Т и BE OR NOT Т.

WITH ( STATS WHERE ( SEX = 'M' AND

OCCUPATION = 'Programmer' OR AUDITS = 0 ) AS X :

COUNT { X ) Результат: 6.

WITH ( STATS WHERE ( SEX = 'M' AND

OCCUPATION = 'Programmer' OR NOT ( AUDITS = 0 ) ) AS X :

COUNT ( X )

Результат: 5; 6 + 5 = 11.

Этап 4. Из полученных выше результатов можно сделать заключение, что количе- ство сотрудников, которые удовлетворяют логическому выражению BE, равно еди- нице (результат этапа 3 минус результат этапа 2), т.е. логическое выражение BE единственным образом идентифицирует сотрудника по имени 'Alf.

Теперь на этапах 5 и 6 повторим запросы, использованные на этапах 2 и 3, но вме- сто функции COUNT укажем функцию SUM.

Этап 5. С помощью выражений Т и NOT Т найдем размер зарплаты всех сотрудников.

WITH ( STATS WHERE AUDITS = 0 ) AS X : SUM { X, SALARY )

Результат: 438 000.

WITH ( STATS WHERE NOT ( AUDITS = 0 } ) AS X : SUM { X, SALARY )

Результат: 290 000; 438 000 + 290 000 = 728 000.

Этап 6. Найдем размер зарплаты сотрудника по имени 'Alf плюс размер зарпла- ты всех сотрудников, используя выражения BE OR Т и BE OR NOT Т.

WITH ( STATS WHERE ( SEX = 'M' AND

OCCUPATION = 'Programmer' OR AUDITS = 0 ) AS X : SUM ( X, SALARY )

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

WITH j STATS WHERE { SEX = 'M' AND

OCCUPATION = 'Programmer' OR NOT { AUDITS = 0 ) ) AS X : SUM ( X, SALARY )

Результат: 290 000; 488 000 + 290 000 = 778 000.

Этап 7. Найдем размер зарплаты сотрудника по имени 'Alf, вычитая из общей суммы (полученной на этапе 5) результат, полученный на этапе 6.

Результат: 50 000. |

Принцип действия общего трекера схематически представлен на рис. 16.4.

set ( BE ) = ( set ( BE OR Т ) + set ( BE OR NOT T ) ) - set ( T OR NOT T )

Множество, идентифицированное выражением Г		Множество, идентифицированное выражением NOT Т
	Множество, идентифицированное	булевым выражением BE —т.е. (1)

Рис. 16.4. Принцип функционирования общего трекера Т

Если исходное предположение оказалось неверным (т.е. Т не является общим трекером), тогда одно или оба выражения ( BE OR Т ) и ( BE OR NOT Т ) могут оказаться недопусти- мым. Например, если кардинальности для результирующих наборов для выражений BE и Т равны р и q соответственно, где р < q и b < q < 2b, то кардинальность результирующего множества для ( BE OR Т ), которая не может превышать значение р + q, может оказаться меньше Ь. В такой ситуации необходимо выбрать другой вариант выражения для общего тре- кера и повторить попытку. В [16.6] предполагается, что на практике не так уж сложно найти подходящее выражение для общего трекера. В приведенном здесь частном примере исходный вариант сразу оказался общим трекером (кардинальность его результирующего набора дан- ных равна 5) и оба запроса на этапе 3 также оказались допустимыми.

Обобщим полученные результаты. "Практически всегда" существует выражение, яв- ляющееся общим трекером, найти которое так же легко, как и использовать. Действи- тельно, выражение для общего трекера достаточно быстро можно просто угадать путем перебора нескольких вариантов [16.6]. Даже в тех случаях, когда выражение для общего трекера не существует, могут быть найдены, как показано в [16.6], специфические треке- ры, предназначенные для конкретных запросов. Трудно избежать общего заключения, что безопасность статистических баз данных остается насущной проблемой.

Что в таком случае можно сделать? Некоторые варианты решения этой проблемы уже предлагались в литературе, но все же пока нельзя сказать определенно, является ли какой-либо из них удовлетворительным во всех отношениях. Например, в одном из вариантов предлагается организовать "обмен данными" ("data swapping"), т.е. об- мен значениями атрибутов между кортежами, осуществляемый таким образом, что- бы поддерживалась лишь статистическая точность. При этом даже если злоумыш- леннику удастся идентифицировать отдельное значение (например, некоторое зна- чение зарплаты), то у него не будет способа узнать, какому именно кортежу (в на- шем примере — сотруднику) оно принадлежит. Сложность этого подхода заключа- ется в необходимости отыскать множество тех записей, между которыми можно бу- дет организовать обмен значениями соответствующим образом. Подобные затруд- нения имеют место и при использовании большинства других методов. В данный момент, видимо, придется согласиться с выводами Деннинга [16.6] о том, что "методы нарушения защиты данных просты и не связаны с большими расходами. Поэтому требование обеспечения полной секретности конфиденциальной информа- ции несовместимо с требованием возможности вычисления точных статистических показателей для произвольных подмножеств данных в базе. По крайней мере одно из этих требований должно быть снято прежде, чем можно будет поверить в гаран- тии обеспечения секретности".