Надежда Вьюкова, Владимир Галатенко
АО "Инфосистемы Джет"
1. Введение
Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим
инструментом хранения больших массивов информации. Сколько-нибудь развитые
информационные приложения полагаются не на файловые структуры операционных систем, а на
многопользовательские СУБД, выполненные в технологии клиент/сервер. В этой связи обеспечение
информационной безопасности СУБД, и в первую очередь их серверных компонентов,
приобретает решающее значение для безопасности организации в целом.
Для СУБД важны все три основных аспекта информационной безопасности - конфиденциальность,
целостность и доступность [6]. Общая идея защиты баз данных состоит в
следовании рекомендациям, сформулированным для класса безопасности C2 в "Критериях оценки
надежных компьютерных систем". В принципе некоторые СУБД предлагают дополнения,
характерные для класса B1, однако практическое применение подобных дополнений имеет смысл,
только если все компоненты информационной структуры организации соответствуют категории
безопасности B. Достичь этого непросто и с технической, и с финансовой точек зрения. Следует,
кроме того, учитывать два обстоятельства. Во-первых, для подавляющего большинства
коммерческих организаций класс безопасности C2 достаточен. Во-вторых, более защищенные
версии отстают по содержательным возможностям от обычных "собратьев", так что поборники
секретности по сути обречены на использование морально устаревших (хотя и тщательно
проверенных) продуктов со всеми вытекающими последствиями в плане сопровождения.
Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES, Informix и
Oracle.
2. Идентификация и проверка подлинности пользователей
Обычно в СУБД для идентификации и проверки подлинности пользователей применяются либо
соответствующие механизмы операционной системы, либо SQL-оператор CONNECT. Например, в
случае СУБД Oracle оператор CONNECT имеет следующий вид:
CONNECT пользователь[/пароль] [@база_данных];
Так или иначе, в момент начала сеанса работы с сервером баз данных, пользователь
идентифицируется своим именем, а средством аутентификации служит пароль. Детали этого
процесса определяются реализацией клиентской части приложения.
Обратим внимание на следующее обстоятельство. Некоторые операционные системы, такие как
UNIX, позволяют во время запуска программы менять действующий идентификатор пользователя.
Приложение, работающее с базой данных, как правило, имеет привилегии, значительно
превосходящие привилегии обычных пользователей. Естественно, что при этом приложение
предоставляет тщательно продуманный, строго фиксированный набор возможностей. Если
пользователь сумеет тем или иным способом завершить приложение, но сохранить подключение к
серверу баз данных, ему станут доступны по существу любые действия с данными.
3. Управление доступом
Для иллюстрации вопросов, связанных с управлением доступом, будет использоваться СУБД
INGRES.
Обычно в СУБД применяется произвольное управление доступом, когда владелец объекта
передает права доступа к нему (чаще говорят - привилегии) по своему усмотрению. Привилегии
могут передаваться субъектам (отдельным пользователям), группам, ролям или всем
пользователям.
Группа - это именованная совокупность пользователей. Объединение субъектов в группы
облегчает администрирование баз данных и, как правило, строится на основе формальной или
фактической структуры организации. Каждый пользователь может входить в несколько групп.
Когда пользователь тем или иным способом инициирует сеанс работы с базой данных, он может
указать, от имени какой из своих групп он выступает. Кроме того, для пользователя обычно
определяют подразумеваемую группу.
Роль - это еще один возможный именованный носитель привилегий. С ролью не ассоциируют
перечень допустимых пользователей - вместо этого роли защищают паролями. В момент начала
сеанса с базой данных можно специфицировать используемую роль (обычно с помощью флагов
или эквивалентного механизма) и ее пароль, если таковой имеется.
Привилегии роли имеют приоритет над привилегиями пользователей и групп. Иными словами,
пользователю как субъекту не обязательно иметь права доступа к объектам, обрабатываемым
приложениям с определенной ролью.
Отметим, что в СУБД Oracle под ролью понимается набор привилегий. Такие роли служат
средством структуризации привилегий и облегчают их модификацию.
Совокупность всех пользователей именуется как PUBLIC. Придание привилегий PUBLIC -
удобный способ задать подразумеваемые права доступа.
Пользователей СУБД можно разбить на три категории:
Привилегии в СУБД можно подразделить на две категории: привилегии безопасности и
привилегии доступа. Привилегии безопасности позволяют выполнять административные действия.
Привилегии доступа, в соответствии с названием, определяют права доступа субъектов к
определенным объектам.
3.3.1. Привилегии безопасности
Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или
всем) во время его создания (оператором CREATE USER) или изменения характеристик
(оператором ALTER USER). Таких привилегий пять:
3.3.2. Привилегии доступа
Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора
GRANT и изымаются с помощью оператора REVOKE. Эти привилегии, как правило, присваивает
владелец соответствующих объектов (он же - администратор базы данных) или обладатель
привилегии security (обычно администратор сервера баз данных).
Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с
помощью операторов CREATE GROUP и CREATE ROLE.
Для изменения состава группы служит оператор ALTER GROUP.
Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен
список членов группы.
Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE - для удаления
ролей.
Напомним, что создавать и удалять именованные носители привилегий, а также изменять их
характеристики может лишь пользователь с привилегией security. При совершении подобных
действий необходимо иметь подключение к базе данных iidbdb, в которой хранятся сведения о
субъектах и их привилегиях.
Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они
относятся. В СУБД INGRES таких видов пять:
GRANT привилегии
ON объекты
TO кому;
Применительно к таблицам и представлениям можно управлять следующими правами доступа:
SELECT | - право на выборку данных |
INSERT | - право на добавление данных |
DELETE | - право на удаление данных |
UPDATE | - право на обновление данных (можно указать определенные столбцы, разрешенные для обновления) |
REFERENCES | - право на использование внешних ключей, ссылающихся на данную таблицу (можно указать определенные столбцы) |
GRANT ...
...
WITH GRANT OPTION;
Подобный оператор GRANT передает не только указанные в нем привилегии, но и права на
их дальнейшую передачу. Очевидно, что использование конструкции WITH GRANT OPTION
ведет к децентрализации контроля над привилегиями и содержит потенциальную угрозу
безопасности данных.
Для отмены привилегий, выданных ранее (как разрешительных, так и запретительных), служит
оператор REVOKE.
3.3.3. Получение информации о привилегиях
Важно не только давать и отбирать привилегии, но и иметь информацию о том, какими правами
доступа обладает каждый из субъектов. Подобные данные можно получить с помощью функции
dbmsinfo, а также путем анализа содержимого таблиц в базе данных iidbdb.
Функция dbmsinfo возвращает права доступа к базе, относящиеся к текущему подключению.
Можно узнать имена действующих группы и роли, значения количественных ограничений,
наличие привилегий для создания таблиц и процедур и т.п.
Таблицы iiusergroup, iirole и iidbprivileges базы данных iidbdb содержат соответственно, список
групп и их состав, перечень ролей вместе с зашифрованными паролями и сведения о привилегиях
доступа к базам данных. Так, таблица iiusergroup состоит из трех столбцов:
СУБД предоставляют специфическое средство управления доступом - представления.
Представления позволяют сделать видимыми для субъектов определенные столбцы базовых
таблиц (реализовать проекцию) или отобрать определенные строки (реализовать селекцию). Не
предоставляя субъектам прав доступа к базовым таблицам и сконструировав подходящие
представления, администратор базы данных защитит таблицы от несанкционированного доступа и
снабдит каждого пользователя своим видением базы данных, когда недоступные объекты как бы
не существуют.
Приведем пример создания представления, содержащего два столбца исходной таблицы и
включающего в себя только строки с определенным значением одного из столбцов:
CREATE VIEW empview AS
SELECT name, dept
FROM employee
WHERE dept = 'shoe';
Предоставим всем право на выборку из этого представления:
GRANT SELECT
ON empview
TO PUBLIC;
Субъекты, осуществляющие доступ к представлению empview, могут пытаться запросить
сведения об отделах, отличных от shoe, например:
SELECT *
FROM empview
WHERE dept = 'toy';
но в ответ просто получат результат из нуля строк, а не код ответа, свидетельствующий о
нарушении прав доступа. Это принципиально важно, так как лишает злоумышленника
возможности получить список отделов косвенным образом, анализируя коды ответов,
возвращаемые после обработки SQL-запросов.
Оператор GRANT и другие средства управления доступом СУБД позволяют реализовать
следующие виды ограничения доступа:
роль | 1700 |
пользователь | 1500 |
группа | 2000 |
PUBLIC | 1000 |
QBF -Gaccounting company_db
Если опция -G отсутствует, применяется подразумеваемая группа пользователя, если таковая
имеется.
Наконец, если в командной строке sql задана опция
-uпользователь
то в число проверяемых входят также привилегии указанного пользователя.
Выше были описаны средства произвольного управления доступом, характерные для уровня
безопасности C. Как уже указывалось, они в принципе достаточны для подавляющего
большинства коммерческих приложений. Тем не менее, они не решают одной весьма важной
задачи - задачи слежения за передачей информации. Средства произвольного управления доступом
не могут помешать авторизованному пользователю законным образом получить секретную
информацию и затем сделать ее доступной для других, неавторизованных пользователей.
Нетрудно понять, почему это так. При произвольном управлении доступом привилегии
существуют отдельно от данных (в случае реляционных СУБД - отдельно от строк реляционных
таблиц). В результате данные оказываются "обезличенными", и ничто не мешает передать их кому
угодно даже средствами самой СУБД.
В "Критериях оценки надежных компьютерных систем", применительно к системам уровня
безопасности B, описан механизм меток безопасности, реализованный в версии INGRES/Enhanced
Security (INGRES с повышенной безопасностью). Применять эту версию на практике имеет смысл
только в сочетании с операционной системой и другими программными компонентами того же
уровня безопасности. Тем не менее, рассмотрение реализации меточной безопасности в СУБД
INGRES интересно с познавательной точки зрения, а сам подход, основанный на разделении
данных по уровням секретности и категориям доступа, может оказаться полезным при
проектировании системы привилегий многочисленных пользователей по отношению к большим
массивам данных.
В СУБД INGRES/Enhanced Security к каждой реляционной таблице неявно добавляется столбец,
содержащий метки безопасности строк таблицы. Метка безопасности состоит из трех
компонентов:
4. Поддержание целостности данных в СУБД
Для коммерческих организаций обеспечение целостности данных по крайней мере не менее важно,
чем обеспечение конфиденциальности. Конечно, неприятно, когда кто-то подглядывает за суммами
на счетах клиентов, но гораздо хуже, когда в процессе перевода денег со счета на счет часть суммы
исчезает в неизвестном направлении.
Известно, что главными врагами баз данных являются не внешние злоумышленники, а ошибки
оборудования, администраторов, прикладных программ и пользователей. Защита от подобных
ошибок - главная тема этого раздела.
С точки зрения пользователя СУБД, основными средствами поддержания целостности данных
являются ограничения и правила.
Ограничения могут относиться к таблицам или отдельным столбцам. Ограничения на столбцы
задаются при создании таблицы, в операторах CREATE TABLE
Табличные ограничения относятся к группе столбцов и могут задаваться как при создании
таблицы, так и позже, посредством оператора ALTER TABLE.
Следующий пример содержит именованное ограничение, связывающее значения в двух
столбцах:
CREATE TABLE dept (
dname char(10),
budget money,
expenses money,
CONSTRAINT check_amount CHECK (budget > 0 and expenses <= budget)
);
{Бюджет должен быть положительным, а расходы не должны выходить за рамки
бюджета}
Ссылочные ограничения отвечают за целостность связей между таблицами. Подобное
ограничение требует, чтобы каждому значению в столбце или группе столбцов одной таблицы
соответствовало ровно одно значение в другой таблице. Название ограничения объясняется тем,
что такие значения играют роль ссылок между таблицами в реляционной модели.
Приведем пример ссылочного ограничения:
CREATE TABLE emp (
ename char(10),
edept char(10) references dept(dname)
);
{Ни один работник не должен числиться в неизвестном отделе}
Ограничения всех видов накладываются владельцем таблицы и влияют на исход последующих
операций с данными. Перед завершением выполнения SQL-оператора производится проверка
имеющихся ограничений. При обнаружении нарушений СУБД сигнализирует о ненормальном
завершении и аннулирует внесенные оператором изменения.
Отметим, что для наложения ссылочного ограничения необходимо обладать привилегией
REFERENCES по отношению к таблице, на которую делается ссылка (dept в примере выше).
Ограничения можно не только накладывать, но и отменять. При этом между ограничениями могут
существовать зависимости, и отмена одного из них может потребовать ликвидации других
(ссылочных) ограничений, зависящих от первоначального. Рассмотрим следующий пример:
CREATE TABLE dept (
name char(10) NOT NULL,
location char(20),
CONSTRAINT dept_unique UNIQUE(name)
);
CREATE TABLE emp (
name char(10),
salary decimal(10,2),
edept char(10) CONSTRAINT empref REFERENCES dept(name)
);
Если требуется удалить ограничение dept_unique, можно воспользоваться следующим
оператором:
ALTER TABLE dept
DROP CONSTRAINT dept_unique cascade;
Слово cascade означает, что следует удалить также все ограничения, прямо или косвенно
зависящие от dept_unique. В данном случае будет изъято ограничение empref. Если вместо cascade
указать restrict, то есть сделать попытку удалить только ограничение dept_unique, СУБД
зафиксирует ошибку. Тем самым обеспечивается целостность системы ограничений.
В СУБД INGRES делается попытка примирить контроль ограничений и эффективность
функционирования. При массовом копировании данных контроль ограничений отключается. Это
значит, что необходимо дополнять копирование запуском процедуры глобальной проверки
целостности.
Правила позволяют вызывать выполнение заданных действий при определенных изменениях базы
данных. Обычно действие - это вызов процедуры. Правила ассоциируются с таблицами и
срабатывают при изменении этих таблиц.
В отличие от ограничений, которые являются лишь средством контроля относительно простых
условий, правила позволяют проверять и поддерживать сколь угодно сложные соотношения между
элементами данных в базе.
Как и в случае ограничений, проверка правил отключается при массовых операциях копирования.
Администратор базы данных может также явным образом отменить проверку правил,
воспользовавшись оператором
SET NORULES;
Оператор
SET RULES;
позволит затем восстановить работу механизма правил. По умолчанию этот механизм
включен.
Для удаления правил служит оператор
DROP RULE правило;
СУБД обеспечивает автоматическое удаление правил в тех случаях, когда удаляется
соответствующая таблица. Тем самым поддерживается целостность системы таблиц и правил.
В контексте информационной безопасности важно отметить, что создать правило, ассоциируемое с
таблицей, может владелец этой таблицы, имеющий право на выполнение соответствующей
процедуры. Пользователь, действия которого вызывают срабатывание правила, должен обладать
лишь необходимыми правами доступа к таблице. Тем самым правила неявно расширяют
привилегии пользователей. Подобные расширения нуждаются в строгом административном
контроле, поскольку даже незначительное изменение правила или ассоциированной процедуры
может кардинально повлиять на защищенность данных. Ошибка же в сложной системе правил
вообще чревата непредсказуемыми последствиями.
5. Средства поддержания высокой готовности
В коммерческих приложениях высокая готовность аппаратно-программных комплексов является
важнейшим фактором. Применительно к СУБД средства поддержания высокой готовности
должны обеспечивать нейтрализацию аппаратных отказов, особенно касающихся дисков, а также
восстановление после ошибок обслуживающего персонала или прикладных программ.
Подобные средства должны с самого начала закладываться в архитектуру комплекса. Например,
необходимо использовать тот или иной вид избыточных дисковых массивов. Конечно, это сделает
аппаратно-программное решение более дорогим, но зато убережет от возможных убытков во
время эксплуатации.
Мы будем понимать под кластером конфигурацию из нескольких компьютеров (узлов),
выполняющих общее приложение (такое, например, как сервер баз данных). Обычно кластер
содержит также несколько дисковых подсистем, совместно используемых узлами-компьютерами, и
избыточные связи между компонентами. С внешней точки зрения кластер выглядит как единое
целое, а наличие нескольких узлов способствует повышению производительности и устойчивости к
отказам.
В настоящем разделе будет рассмотрена разработка компании Sun Microsystems, Inc -
SPARCcluster PDB Server (параллельный сервер баз данных на основе SPARC-кластера).
5.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.
Подобная аппаратная архитектура обеспечивает устойчивость к отказам (никакой одиночный
отказ не вызывает остановки работы кластера в целом). В то же время избыточные компоненты
(компьютеры, дисковые подсистемы) отнюдь не ограничиваются ролью горячего резерва - они
полностью задействованы в процессе обычной работы.
Вся аппаратура устроена так, что допускает замену в горячем режиме, без остановки других
компонентов кластера.
5.1.2. Программная организация SPARCcluster PDB Server
Если рассматривать программную организацию SPARCcluster PDB Server в контексте надежной
работы баз данных, необходимо обратить внимание еще на один компонент - фронтальную
машину, на которой выполняется какой-либо монитор транзакций, например, TUXEDO. С учетом
этого дополнения программная организация приобретает следующий вид.
Рассмотрим компоненты программного обеспечения SPARCcluster PDB Server.
Устойчивый к отказам распределенный менеджер блокировок (Fault Tolerant Distributed Lock
Manager, FT-DLM) управляет параллельным доступом к базам данных, устанавливая и снимая
блокировки. Кроме того, FT-DLM нейтрализует последствия отказов, снимая блокировки,
установленные вышедшим из строя узлом. FT-DLM взаимодействует с сервером Oracle для
поддержки неблокируемых операций чтения и для блокировки на уровне строк при записи в
таблицы. В результате обеспечивается целостность и сериализация транзакций в сочетании с
параллельной работой узлов кластера и с параллельным доступом к нескольким дисковым
подсистемам.
Распределенность менеджера блокировок означает, что на каждом узле кластера работает свой
экземпляр FT-DLM и что FT-DLM умеет динамически реконфигурировать себя (как при выходе
узлов из строя, так и при добавлении новых узлов). В результате выход из строя одного узла не
означает краха всего сервера баз данных - сервер жив, пока работает хотя бы один менеджер
блокировок.
В рассматриваемом контексте основное назначение распределенного менеджера томов - поддержка
зеркалирования дисков с тем важным дополнением, что устройства, составляющие пару, могут
принадлежать разным дисковым подсистемам.
Подсистема обнаружения и нейтрализации отказов постоянно отслеживает доступность ресурсов,
составляющих кластер. При обнаружении неисправности запускается процесс реконфигурации,
изолирующий вышедший из строя компонент при сохранении работоспособности кластера в
целом (с выходом из строя диска справляется менеджер томов).
Подсистема управления кластером состоит из трех инструментов с графическим интерфейсом:
консоли кластера, менеджера томов и менеджера сервера Oracle. Их интеграция обеспечивает
централизованное оперативное управление всеми ресурсами кластера.
5.1.3. Нейтрализация отказа узла
Рассмотрим, как в SPARCcluster PDB Server реализована нейтрализация самого неприятного из
отказов - отказа узла. Программное обеспечение предпринимает при этом следующие
действия:
В контексте информационной безопасности тиражирование можно рассматривать как средство
повышения доступности данных. Стала легендой история про бакалейщика из Сан-Франциско,
который после разрушительного землетрясения восстановил свою базу данных за 16 минут,
перекачав из другого города предварительно протиражированную информацию. Рис. 3. Тиражирование. Основной сервер доступен на
чтение и запись, вторичный - только на чтение.
Побочный положительный эффект тиражирования - возможность вынести преимущественно на
вторичный сервер ресурсоемкие приложения поддержки принятия решений. В этом случае они
могут выполняться с максимальным использованием средств параллельной обработки, не
подавляя приложений оперативной обработки транзакций, сосредоточенных на основном сервере.
Это также можно рассматривать как фактор повышения доступности данных. 6. Угрозы, специфичные для СУБД
Главный источник угроз, специфичных для СУБД, лежит в самой природе баз данных. Основным
средством взаимодействия с СУБД является язык SQL - мощный непроцедурный инструмент
определения и манипулирования данными. Хранимые процедуры добавляют к этому репертуару
управляющие конструкции. Механизм правил дает возможность выстраивать сложные, трудные
для анализа цепочки действий, позволяя попутно неявным образом передавать право на
выполнение процедур, даже не имея, строго говоря, полномочий на это. В результате
потенциальный злоумышленник получает в свои руки мощный и удобный инструментарий, а все
развитие СУБД направлено на то, чтобы сделать этот инструментарий еще мощнее и удобнее.
Нередко путем логического вывода можно извлечь из базы данных информацию, на получение
которой стандартными средствами у пользователя не хватает привилегий. Табл. 1. Данные с высоким уровнем секретности
Табл. 2. Данные с низким уровнем секретности
Обратим внимание на то, что сведения о пациенте по фамилии Иванов присутствуют на обоих
уровнях, но содержат разные диагнозы. Табл. 3. Данные, доступные пользователю с высоким уровнем
секретности
(Обратим внимание на то, что строка "Иванов Пневмония" здесь отсутствует.) CREATE TABLE BaseTable1 ( Всем пользователям предоставляется доступ только к представлению PatientInfo.
Пользователи с низким уровнем благонадежности увидят только информацию, выдаваемую
первой конструкцией WHERE: WHERE BaseTable1.Level = ( поскольку для них поле SecurityLevel имеет значение "LOW". В формирование представления
для благонадежных пользователей внесут вклад обе конструкции WHERE, причем в случае
совпадения имен менее секретные записи будут заслонены более секретными (конструкция NOT
EXISTS).
Агрегирование - это метод получения новой информации путем комбинирования данных, добытых
легальным образом из различных таблиц. Агрегированная информация может оказаться более
секретной, чем каждый из компонентов, ее составивший. В качестве примера можно рассмотреть
базу данных, хранящую параметры всех комплектующих, из которых будет собираться ракета, и
инструкцию по сборке. Данные о каждом виде комплектующих необходимы поставщикам,
инструкция по сборке (вставьте деталь A в отверстие B) - сборочному производству.
Если пользователю доступны все возможности SQL, он может довольно легко затруднить работу
других пользователей (например, инициировав длительную транзакцию, захватывающую большое
число таблиц). Современные многопотоковые серверы СУБД отражают лишь самые
прямолинейные атаки, состоящие, например, в запуске в "часы пик" операции массовой загрузки
данных. Настоятельно рекомендуется не предоставлять пользователям непосредственного SQL-
доступа к базе данных, используя в качестве фильтров серверы приложений. Выбор подобной
архитектуры разумен и по многим другим соображениям.
В качестве любопытной угрозы, специфичной для реляционных СУБД, упомянем ссылочные
ограничения. Строго говоря, наложение такого ограничения препятствует удалению строк из
таблицы, содержащей первичные ключи, хотя в современных версиях SQL можно запросить так
называемое каскадное удаление. Впрочем, искажение прочих ограничений на таблицы и их
столбцы по-прежнему остается опасным средством покушения на доступность данных. 7. Защита коммуникаций между сервером и клиентами
Проблема защиты коммуникация между сервером и клиентами не является специфичной для
СУБД, она присуща всем распределенным системам. Вполне естественно, что и решения здесь
ищутся общие, такие, например, как в распределенной вычислительной среде (Distributed
Computing Environment, DCE) концерна OSF. Разработчикам СУБД остается "погрузить" свои
программные продукты в эту среду, что и сделала компания Informix, реализовав Informix-
DCE/Net [4]. 8. Заключение
Конфигурация, к которой имеет доступ хотя бы один программист, не может считаться
безопасной. Поэтому обеспечение информационной безопасности баз данных - дело весьма
сложное во многом в силу самой природы реляционных СУБД. 9. Литература
Развитые возможности тиражирования предоставляет СУБД INGRES. Им посвящена статья [2]. Здесь мы рассмотрим возможности другого популярного сервера СУБД -
Informix OnLine Dynamic Server (OnLine-DS) 7.1. В отличие от предыдущего раздела, речь пойдет
об обычных (а не кластерных) конфигурациях.
В Informix OnLine-DS 7.1 поддерживается модель тиражирования, состоящая в полном
отображении данных с основного сервера на вторичные.
В конфигурации серверов Informix OnLine-DS с тиражированием выделяется один основной и ряд
вторичных серверов. На основном сервере выполняется и чтение, и обновление данных, а все
изменения передаются на вторичные серверы, доступные только на чтение (рис.
3). В случае отказа основного сервера вторичный автоматически или вручную переводится в
режим доступа на чтение и запись (рис. 4). Прозрачное перенаправление
клиентов при отказе основного сервера не поддерживается, но оно может быть реализовано в
рамках приложений.
После восстановления основного сервера возможен сценарий, при котором этот сервер становится
вторичным, а бывшему вторичному, который уже функционирует в режиме чтения-записи,
придается статус основного; клиенты, которые подключены к нему, продолжают работу. Таким
образом, обеспечивается непрерывная доступность данных.
Тиражирование осуществляется путем передачи информации из журнала транзакций (логического
журнала) в буфер тиражирования основного сервера, откуда она пересылается в буфер
тиражирования вторичного сервера. Такая пересылка может происходить либо в синхронном,
либо в асинхронном режиме. Синхронный режим гарантирует полную согласованность баз данных
- ни одна транзакция, зафиксированная на основном сервере, не останется незафиксированной на
вторичном, даже в случае сбоя основного сервера. Асинхронный режим не обеспечивает
абсолютной согласованности, но улучшает рабочие характеристики системы.
Тиражирование
Основной
серверВторичный
сервер
Основной
серверСтандартный
сервер
Мы рассмотрим несколько угроз, возникающих при использовании злоумышленником средств
языка SQL.
Следуя [3], рассмотрим больничную базу данных, состоящую из двух таблиц. В
первой хранится информация о пациентах (анкетные данные, диагноз, назначения и т.п.), во
второй - сведения о докторах (расписание мероприятий, перечень пациентов и т.д.). Если
пользователь имеет право доступа только к таблице докторов, он, тем не менее, может получить
косвенную информацию о диагнозах пациентов, поскольку, как правило, врачи специализируются
на лечении определенных болезней.
Еще один пример - выяснение набора первичных ключей таблицы при наличии только привилегии
INSERT (без привилегии SELECT). Если набор возможных значений ключей примерно известен,
можно пытаться вставлять новые строки с "интересными" ключами и анализировать коды
завершения SQL-операторов. Как мы видели из предыдущего примера, сам факт присутствия
определенного ключа в таблице может быть весьма информативным.
Если для реализации контроля доступа используются представления, и эти представления
допускают модификацию, с помощью операций модификации/вставки можно получить
информацию о содержимом базовых таблиц, не располагая прямым доступом к ним.
Основным средством борьбы с подобными угрозами, помимо тщательно проектирования модели
данных, является механизм размножения строк. Суть его в том, что в состав первичного ключа,
явно или неявно, включается метка безопасности, за счет чего появляется возможность хранить в
таблице несколько экземпляров строк с одинаковыми значениями "содержательных" ключевых
полей. Наиболее естественно размножение строк реализуется в СУБД, поддерживающих метки
безопасности (например, в INGRES/Enhanced Security), однако и стандартными SQL-средствами
можно получить удовлетворительное решение.
Продолжая медицинскую тематику, рассмотрим базу данных, состоящую из одной таблицы с
двумя столбцами: имя пациента и диагноз. Предполагается, что имя является первичным ключом.
Каждая из строк таблицы относится к одному из двух уровней секретности - высокому (HIGH) и
низкому (LOW). Соответственно, и пользователи подразделяются на два уровня благонадежности,
которые мы также будем называть высоким и низким.
К высокому уровню секретности относятся сведения о пациентах, находящихся под надзором
правоохранительных органов или страдающих специфическими заболеваниями. На низком уровне
располагаются данные о прочих пациентах, а также информация о некоторых "секретных"
пациентах с "маскировочным" диагнозом. Части таблицы могут выглядеть примерно так:
Имя Диагноз Иванов СПИД Петров Сифилис Сидоров Стреляная рана
Имя Диагноз Ивлев Рак легких Иванов Пневмония Ярцев Ожог второй степени Суворов Микроинфаркт
Мы хотим реализовать такую дисциплину доступа, чтобы пользователи с низким уровнем
благонадежности могли манипулировать только данными на своем уровне и не имели
возможности сделать какие-либо выводы о присутствии в секретной половине сведений о
конкретных пациентах. Пользователи с высоким уровнем благонадежности должны иметь доступ к
секретной половине таблицы, а также к информации о прочих пациентах.
Дезинформирующих строк о секретных пациентах они видеть не должны:
Имя Диагноз Иванов СПИД Ивлев Рак легких Иванов Пневмония Петров Сифилис Сидоров Стреляная рана Ярцев Ожог второй степени Суворов Микроинфаркт
Размножение строк, обеспечивающее необходимую дисциплину доступа, стандартными средствами
SQL можно реализовать следующим образом:
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"
)
)
;
SELECT SecurityLevel FROM BaseTable2
WHERE UserName = username () )
Мы видим, что в отличие от систем с меточной безопасностью, стандартные SQL-серверы
предоставляют довольно тяжеловесные средства для реализации механизма размножения строк.
Тем не менее, эти средства не так плохи, как может показаться на первый взгляд. Можно надеяться,
что оптимизатор SQL-запросов, входящий в комплект любой современной СУБД, сделает время
доступа к представлению PatientInfo сравнимым с временем извлечения строк из базовых
таблиц.
Нетрудно понять, что борьба с получением информации путем логического вывода актуальна не
только для медицинских баз данных и что она (борьба) требует кропотливого труда при
проектировании модели данных и иерархии привилегий, а также при реализации видимых
пользователям представлений.
Информация об отдельных частях сама по себе не является секретной (какой смысл скрывать
материал, размеры и количество гаек?). В то же время анализ всей базы позволяет узнать, как
сделать ракету, что может считаться государственной тайной.
Повышение уровня секретности данных при агрегировании вполне естественно - это следствие
закона перехода количества в качество. Бороться с агрегированием можно за счет тщательного
проектирования модели данных и максимального ограничения доступа пользователей к
информации.
Informix-DCE/Net открывает доступ к сервисам DCE для всех инструментальных средств Informix,
а также любых приложений или инструментальных комплексов от независимых поставщиков,
которые используют интерфейс ODBC (рис. 5).
Ключевым компонентом в реализации взаимодействий клиент-сервер в среде DCE является сервис
безопасности. Основные функции, предоставляемые этим сервисом, - аутентификация, реализуемая
средствами Kerberos, авторизация (проверка полномочий) и шифрование.
Informix-DCE/Net использует все средства обеспечения безопасности, имеющиеся в DCE.
Например, для каждого приложения клиент-сервер администратор может задать один из пяти
уровней защиты:
Сервис аутентификации DCE, поддерживаемый Informix-DCE/Net, существенно улучшает
характеристики безопасности распределенной среды, упрощая в то же время деятельность как
пользователей, так и администраторов. Достаточно иметь единое входное имя и пароль для DCE,
чтобы обращаться к любой погруженной в эту среду базе данных. При запуске приложения
Informix-DCE/Net запрашивает аутентификационную информацию пользователя у DCE, и
подключает его к требуемой базе.
Наличие единой точки администрирования входных имен и прав доступа к базам данных и
приложениям способствует упорядочению общей ситуации с безопасностью. Например, если
уничтожается входное имя DCE, то администратор может быть уверен, что данный пользователь
уже не сможет получить доступ ни к одному из системных ресурсов.
Помимо систематического применения всего арсенала средств, описанных в настоящей работе,
необходимо использование административных и процедурных мер. Только тогда можно
рассчитывать на успех в деле обеспечению информационной безопасности современных серверов
баз данных.