Защита системы управления базами данных

5.2. Тиражирование  данных

В контексте информационной безопасности тиражирование можно  рассматривать как средство повышения  доступности данных. В Informix OnLine-DS 7.1 поддерживается модель тиражирования, состоящая в полном отображении  данных с основного сервера на вторичные.  
В конфигурации серверов Informix OnLine-DS с тиражированием выделяется один основной и ряд вторичных серверов. На основном сервере выполняется и чтение, и обновление данных, а все изменения передаются на вторичные серверы, доступные только на чтение (рис. 3). В случае отказа основного сервера вторичный автоматически или вручную переводится в режим доступа на чтение и запись (рис. 4).  
После восстановления основного сервера возможен сценарий, при котором этот сервер становится вторичным, а бывшему вторичному, который уже функционирует в режиме чтения-записи, придается статус основного; клиенты, которые подключены к нему, продолжают работу. Таким образом, обеспечивается непрерывная доступность данных. 
Тиражирование осуществляется путем передачи информации из журнала транзакций (логического журнала) в буфер тиражирования основного сервера, откуда она пересылается в буфер тиражирования вторичного сервера. Такая пересылка может происходить либо в синхронном, либо в асинхронном режиме. Синхронный режим гарантирует полную согласованность баз данных - ни одна транзакция, зафиксированная на основном сервере, не останется незафиксированной на вторичном, даже в случае сбоя основного сервера. Асинхронный режим не обеспечивает абсолютной согласованности, но улучшает рабочие характеристики системы.

		Тиражирование
		Основной  сервер		Вторичный  сервер

 

Рис. 3. Тиражирование. Основной сервер доступен на чтение и запись, вторичный - только на чтение.

		Основной  сервер		Стандартный  сервер

 

Рис. 4. Когда основной сервер выходит из строя, вторичный переводится в  режим доступа и на чтение, и  на запись.

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

6. Угрозы, специфичные  для СУБД

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

6.1. Получение информации  путем логических выводов

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

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

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

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

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

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

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

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

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

(Обратим внимание на  то, что строка "Иванов Пневмония" здесь отсутствует.)

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

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

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

6.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. Заключение

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