Информационная безопасность систем управления базами данных

Нередко путем логического вывода можно извлечь из базы данных информацию, на получение которой стандартными средствами у пользователя не хватает  привилегий. 
Следуя [3], рассмотрим больничную базу данных, состоящую из двух таблиц. В первой хранится информация о пациентах (анкетные данные, диагноз, назначения и т.п.), во второй - сведения о докторах (расписание мероприятий, перечень пациентов и т.д.). Если пользователь имеет право доступа только к таблице докторов, он, тем не менее, может получить косвенную информацию о диагнозах пациентов, поскольку, как правило, врачи специализируются на лечении определенных болезней. 
Еще один пример - выяснение набора первичных ключей таблицы при наличии только привилегии INSERT (без привилегии SELECT). Если набор возможных значений ключей примерно известен, можно пытаться вставлять новые строки с "интересными" ключами и анализировать коды завершения SQL-операторов. Как мы видели из предыдущего примера, сам факт присутствия определенного ключа в таблице может быть весьма информативным. 
Если для реализации контроля доступа используются представления, и эти представления допускают модификацию, с помощью операций модификации/вставки можно получить информацию о содержимом базовых таблиц, не располагая прямым доступом к ним. 
Основным средством борьбы с подобными угрозами, помимо тщательно проектирования модели данных, является механизм размножения строк. Суть его в том, что в состав первичного ключа, явно или неявно, включается метка безопасности, за счет чего появляется возможность хранить в таблице несколько экземпляров строк с одинаковыми значениями "содержательных" ключевых полей. Наиболее естественно размножение строк реализуется в СУБД, поддерживающих метки безопасности (например, в INGRES/Enhanced Security), однако и стандартными SQL-средствами можно получить удовлетворительное решение. 
Продолжая медицинскую тематику, рассмотрим базу данных, состоящую из одной таблицы с двумя столбцами: имя пациента и диагноз. Предполагается, что имя является первичным ключом. Каждая из строк таблицы относится к одному из двух уровней секретности - высокому (HIGH) и низкому (LOW). Соответственно, и пользователи подразделяются на два уровня благонадежности, которые мы также будем называть высоким и низким. 
К высокому уровню секретности относятся сведения о пациентах, находящихся под надзором правоохранительных органов или страдающих специфическими заболеваниями. На низком уровне располагаются данные о прочих пациентах, а также информация о некоторых "секретных" пациентах с "маскировочным" диагнозом. Части таблицы могут выглядеть примерно так:

Имя	Диагноз
Иванов	СПИД
Петров	Сифилис
Сидоров	Стреляная рана

Таблица. 1. Данные с высоким уровнем секретности

Имя	Диагноз
Ивлев	Рак легких
Иванов	Пневмония
Ярцев	Ожог второй степени
Суворов	Микроинфаркт

Таблица. 2. Данные с низким уровнем секретности

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

Имя	Диагноз
Иванов	СПИД
Ивлев	Рак легких
Иванов	Пневмония
Петров	Сифилис
Сидоров	Стреляная рана
Ярцев	Ожог второй степени
Суворов	Микроинфаркт

Таблица. 3. Данные, доступные пользователю с высоким уровнем секретности

(Обратим внимание на то, что  строка "Иванов Пневмония" здесь  отсутствует.) 
Размножение строк, обеспечивающее необходимую дисциплину доступа, стандартными средствами SQL можно реализовать следующим образом:

CREATE TABLE BaseTable1 ( 
PatientName char (20), 
Disease char (20), 
Level char (10) 
) WITH PRIMARY KEY (PatientName, Level) 
; 
CREATE TABLE BaseTable2 ( 
UserName char (20), 
SecurityLevel char (10) 
) WITH PRIMARY KEY (UserName) 
; 
CREATE VIEW PatientInfo ( 
PatientName, 
Disease 
) AS SELECT PatientName, Disease 
FROM TABLE BaseTable1 
WHERE BaseTable1.Level = ( 
SELECT SecurityLevel FROM BaseTable2 
WHERE UserName = username () 
) OR ( 
BaseTable1.Level = "LOW" 
AND NOT EXISTS ( 
SELECT * FROM BaseTable1 AS X 
WHERE X.PatientName = BaseTable1.PatientName 
AND X.Level = "HIGH" 
) 
) 
;

Всем пользователям предоставляется  доступ только к представлению PatientInfo. Пользователи с низким уровнем благонадежности увидят только информацию, выдаваемую первой конструкцией WHERE:

WHERE BaseTable1.Level = ( 
SELECT SecurityLevel FROM BaseTable2 
WHERE UserName = username () )

поскольку для них поле SecurityLevel имеет значение "LOW". В формирование представления для благонадежных пользователей внесут вклад обе конструкции WHERE, причем в случае совпадения имен менее секретные записи будут заслонены более секретными (конструкция NOT EXISTS). 
Мы видим, что в отличие от систем с меточной безопасностью, стандартные SQL-серверы предоставляют довольно тяжеловесные средства для реализации механизма размножения строк. Тем не менее, эти средства не так плохи, как может показаться на первый взгляд. Можно надеяться, что оптимизатор SQL-запросов, входящий в комплект любой современной СУБД, сделает время доступа к представлению PatientInfo сравнимым с временем извлечения строк из базовых таблиц. 
Нетрудно понять, что борьба с получением информации путем логического вывода актуальна не только для медицинских баз данных и что она (борьба) требует кропотливого труда при проектировании модели данных и иерархии привилегий, а также при реализации видимых пользователям представлений.

2. Агрегирование данных

Агрегирование - это метод получения  новой информации путем комбинирования данных, добытых легальным образом  из различных таблиц. Агрегированная информация может оказаться более  секретной, чем каждый из компонентов, ее составивший. В качестве примера  можно рассмотреть базу данных, хранящую параметры всех комплектующих, из которых  будет собираться ракета, и инструкцию по сборке. Данные о каждом виде комплектующих необходимы поставщикам, инструкция по сборке (вставьте деталь A в отверстие B) - сборочному производству. 
Информация об отдельных частях сама по себе не является секретной (какой смысл скрывать материал, размеры и количество гаек?). В то же время анализ всей базы позволяет узнать, как сделать ракету, что может считаться государственной тайной. 
Повышение уровня секретности данных при агрегировании вполне естественно - это следствие закона перехода количества в качество. Бороться с агрегированием можно за счет тщательного проектирования модели данных и максимального ограничения доступа пользователей к информации.

3. Покушения на высокую готовность (доступность)

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

Рисунок. 5. Конфигурация прикладной или инструментальной среды клиент-сервер, использующей Informix-DCE/Net.

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

7. Защита коммуникаций между сервером и клиентами

Проблема защиты коммуникация между  сервером и клиентами не является специфичной для СУБД, она присуща  всем распределенным системам. Вполне естественно, что и решения здесь  ищутся общие, такие, например, как в  распределенной вычислительной среде (Distributed Computing Environment, DCE) концерна OSF. Разработчикам СУБД остается "погрузить" свои программные продукты в эту среду, что и сделала компания Informix, реализовав Informix- DCE/Net [4]. 
Informix-DCE/Net открывает доступ к сервисам DCE для всех инструментальных средств Informix, а также любых приложений или инструментальных комплексов от независимых поставщиков, которые используют интерфейс ODBC (рис. 5). 
Ключевым компонентом в реализации взаимодействий клиент-сервер в среде DCE является сервис безопасности. Основные функции, предоставляемые этим сервисом, - аутентификация, реализуемая средствами Kerberos, авторизация (проверка полномочий) и шифрование. 
Informix-DCE/Net использует все средства обеспечения безопасности, имеющиеся в DCE. Например, для каждого приложения клиент-сервер администратор может задать один из пяти уровней защиты:

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

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

8. Заключение

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

9. Литература

1. Ладыженский Г.М. Системы управления базами данных - коротко о главном. - Jet Infosystems, 1995.
2. Ладыженский Г.М. Тиражирование данных в СУБД INGRES. - Jet Infosystems, 1994.
3. Polk T.W., Bassham L.E. Security Issues in the Database Language SQL. - NIST Special Publication 800-8.
4. G. Chung. Informix-DCE/NET Technical White Paper. - Informix Systems Journal, Vol. 1, Number 3, July-August 1995.
5. Manola F.A. A Personal View on DBMS Security. - in DATABASE SECURITY: Status and Prospects. C.E. Landwehr (Editor). Elsevier science Publishers B.V. (North Holland). IFIP, 1988, p. 23- 34.
6. Castano S., Fugini M., Martella G., Samarati P. Database Security. - Addison-Wesley, 1995.