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

Табл. 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 сравнимым с временем извлечения строк из базовых таблиц.
   Нетрудно понять, что борьба с получением информации путем логического вывода актуальна не только для медицинских баз данных и что она (борьба) требует кропотливого труда при проектировании модели данных и иерархии привилегий, а также при реализации видимых пользователям представлений.

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

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

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

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

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

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

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

   Проблема защиты коммуникация между сервером и клиентами не является специфичной для СУБД, она присуща всем распределенным системам. Вполне естественно, что и решения здесь ищутся общие, такие, например, как в распределенной вычислительной среде (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, то администратор может быть уверен, что данный пользователь уже не сможет получить доступ ни к одному из системных ресурсов.

Заключение

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

Литература

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.

41