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

   Если требуется удалить ограничение dept_unique, можно воспользоваться следующим оператором:

ALTER TABLE dept
DROP CONSTRAINT dept_unique cascade;

   Слово cascade означает, что следует удалить также все ограничения, прямо или косвенно зависящие от dept_unique. В данном случае будет изъято ограничение empref. Если вместо cascade указать restrict, то есть сделать попытку удалить только ограничение dept_unique, СУБД зафиксирует ошибку. Тем самым обеспечивается целостность системы ограничений.
   В СУБД INGRES делается попытка примирить контроль ограничений и эффективность функционирования. При массовом копировании данных контроль ограничений отключается. Это значит, что необходимо дополнять копирование запуском процедуры глобальной проверки целостности.

3.2 Правила

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

SET NORULES;

Оператор

SET RULES;

позволит затем восстановить работу механизма правил. По умолчанию этот механизм включен.
   Для удаления правил служит оператор

DROP RULE правило;

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

4 Средства поддержания высокой готовности

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

4.1 Кластерная организация сервера баз данных

   Мы будем понимать под кластером конфигурацию из нескольких компьютеров (узлов), выполняющих общее приложение (такое, например, как сервер баз данных). Обычно кластер содержит также несколько дисковых подсистем, совместно используемых узлами-компьютерами, и избыточные связи между компонентами. С внешней точки зрения кластер выглядит как единое целое, а наличие нескольких узлов способствует повышению производительности и устойчивости к отказам.
   В настоящем разделе будет рассмотрена разработка компании Sun Microsystems, Inc - SPARCcluster PDB Server (параллельный сервер баз данных на основе SPARC-кластера).

4.1.1 Аппаратная организация SPARCcluster PDB Server

   В минимальной конфигурации SPARCcluster PDB Server состоит из двух узлов SPARCserver 1000, двух дисковых подсистем SPARCstorage Array и консоли кластера (SPARCclassic). Узлы- компьютеры соединяются между собой посредством быстрого Ethernet (100 Мбит/с), дисковые подсистемы подключаются через оптоволоконные каналы. В более мощной конфигурации вместо SPARCserver 1000 может использоваться SPARCcenter 2000, а число дисковых подсистем способно достигать 32 (до 1 Тб дискового пространства). Каждый узел кластера - это многопроцессорный компьютер, к которому, помимо прочих, подключены накопители на DAT-лентах (или автозагрузчики кассет с такими лентами). Все связи с компьютерами и дисковыми подсистемами продублированы.
   Следующий рисунок поясняет аппаратную организацию SPARCcluster PDB Server.

Рис. 1. Аппаратная организация SPARCcluster PDB Server (на рисунке не показаны связи кластера с внешним миром)

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

4.1.2 Программная организация SPARCcluster PDB Server

   Если рассматривать программную организацию SPARCcluster PDB Server в контексте надежной работы баз данных, необходимо обратить внимание еще на один компонент - фронтальную машину, на которой выполняется какой-либо монитор транзакций, например, TUXEDO. С учетом этого дополнения программная организация приобретает следующий вид.
   Рассмотрим компоненты программного обеспечения SPARCcluster PDB Server.
   Устойчивый к отказам распределенный менеджер блокировок (Fault Tolerant Distributed Lock Manager, FT-DLM) управляет параллельным доступом к базам данных, устанавливая и снимая блокировки. Кроме того, FT-DLM нейтрализует последствия отказов, снимая блокировки, установленные вышедшим из строя узлом. FT-DLM взаимодействует с сервером Oracle для поддержки неблокируемых операций чтения и для блокировки на уровне строк при записи в таблицы. В результате обеспечивается целостность и сериализация транзакций в сочетании с параллельной работой узлов кластера и с параллельным доступом к нескольким дисковым подсистемам.

Рис. 2. Программная организация SPARCcluster PDB Server (узлы кластера работают под управлением ОС Solaris версии 2.4 или выше)

   Распределенность менеджера блокировок означает, что на каждом узле кластера работает свой экземпляр FT-DLM и что FT-DLM умеет динамически реконфигурировать себя (как при выходе узлов из строя, так и при добавлении новых узлов). В результате выход из строя одного узла не означает краха всего сервера баз данных - сервер жив, пока работает хотя бы один менеджер блокировок.
   В рассматриваемом контексте основное назначение распределенного менеджера томов - поддержка зеркалирования дисков с тем важным дополнением, что устройства, составляющие пару, могут принадлежать разным дисковым подсистемам.
   Подсистема обнаружения и нейтрализации отказов постоянно отслеживает доступность ресурсов, составляющих кластер. При обнаружении неисправности запускается процесс реконфигурации, изолирующий вышедший из строя компонент при сохранении работоспособности кластера в целом (с выходом из строя диска справляется менеджер томов).
   Подсистема управления кластером состоит из трех инструментов с графическим интерфейсом: консоли кластера, менеджера томов и менеджера сервера Oracle. Их интеграция обеспечивает централизованное оперативное управление всеми ресурсами кластера.

4.1.3 Нейтрализация отказа узла

   Рассмотрим, как в SPARCcluster PDB Server реализована нейтрализация самого неприятного из отказов - отказа узла. Программное обеспечение предпринимает при этом следующие действия:

        Подсистема обнаружения отказов выявляет вышедший из строя узел.

        Создается новая конфигурация кластера, без отказавшего узла. Этот процесс занимает 1 - 2 минуты, в течение которых обработка транзакций приостанавливается.

        Менеджер блокировок производит восстановление: а

                    Подтвержденные транзакции от отказавшего узла (транзакции, об успешном завершении которых другие узлы кластера не успели узнать) накатываются вперед и деблокируются. а

                    Неподтвержденные транзакции от отказавшего узла откатываются и также деблокируются.

   В этот период транзакции обрабатываются исправными узлами, но, вероятно, несколько медленнее, чем обычно.

        Монитор транзакций повторно направляет в кластер неподтвержденные транзакции.

        Вышедший из строя узел ремонтируется и вновь запускается.

        Создается новая конфигурация кластера, включающая в себя отремонтированный узел.

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

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

   В контексте информационной безопасности тиражирование можно рассматривать как средство повышения доступности данных. Стала легендой история про бакалейщика из Сан-Франциско, который после разрушительного землетрясения восстановил свою базу данных за 16 минут, перекачав из другого города предварительно протиражированную информацию.
   Развитые возможности тиражирования предоставляет СУБД INGRES. Им посвящена статья [2]. Здесь мы рассмотрим возможности другого популярного сервера СУБД - Informix OnLine Dynamic Server (OnLine-DS) 7.1. В отличие от предыдущего раздела, речь пойдет об обычных (а не кластерных) конфигурациях.
   В Informix OnLine-DS 7.1 поддерживается модель тиражирования, состоящая в полном отображении данных с основного сервера на вторичные.
   В конфигурации серверов Informix OnLine-DS с тиражированием выделяется один основной и ряд вторичных серверов. На основном сервере выполняется и чтение, и обновление данных, а все изменения передаются на вторичные серверы, доступные только на чтение (рис. 3). В случае отказа основного сервера вторичный автоматически или вручную переводится в режим доступа на чтение и запись (рис. 4). Прозрачное перенаправление клиентов при отказе основного сервера не поддерживается, но оно может быть реализовано в рамках приложений.
   После восстановления основного сервера возможен сценарий, при котором этот сервер становится вторичным, а бывшему вторичному, который уже функционирует в режиме чтения-записи, придается статус основного; клиенты, которые подключены к нему, продолжают работу. Таким образом, обеспечивается непрерывная доступность данных.
   Тиражирование осуществляется путем передачи информации из журнала транзакций (логического журнала) в буфер тиражирования основного сервера, откуда она пересылается в буфер тиражирования вторичного сервера. Такая пересылка может происходить либо в синхронном, либо в асинхронном режиме. Синхронный режим гарантирует полную согласованность баз данных - ни одна транзакция, зафиксированная на основном сервере, не останется незафиксированной на вторичном, даже в случае сбоя основного сервера. Асинхронный режим не обеспечивает абсолютной согласованности, но улучшает рабочие характеристики системы.

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

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

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

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

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

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

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