Реализация политики безопасности средствами СУБД

45.1

Реализация политики безопасности средствами СУБД

Содержание

45.2

Реализация политики безопасности средствами СУБД

Введение

Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом хранения больших массивов информации. Сколько нибудь развитые информационные приложения полага ются не на файловые структуры операционных систем, а на многопользовательские СУБД, выполненные в тех нологии клиент/сервер. В этой связи обеспечение информационной безопасности СУБД, и в первую очередь их серверных компонентов, приобретает решающее значение для безопасности организации в целом. Для СУБД важны все три основных аспекта информационной безопасности конфиденциальность, целостность и доступность. Общая идея защиты баз данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в “Критериях оценки надежных компьютерных систем”. В принципе некоторые СУБД предлагают дополнения, характерные для класса B1, однако практическое применение подобных до полнений имеет смысл, только если все компоненты информационной структуры организации соответствуют категории безопасности B. Достичь этого непросто и с технической, и с финансовой точек зрения. Следует, кроме того, учитывать два обстоятельства. Во первых, для подавляющего большинства коммерческих орга низаций класс безопасности C2 достаточен. Во вторых, более защищенные версии отстают по содержатель ным возможностям от обычных “собратьев”, так что поборники секретности, по сути, обречены на использо вание морально устаревших (хотя и тщательно проверенных) продуктов со всеми вытекающими последстви ями в плане сопровождения.

Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES, Informix и Oracle.

1. Основные понятия информационной безопасности СУБД

Специфика защиты СУБД

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

Кроме того, существуют два специфических сценария атаки на СУБД, для защиты от которых применяются особые методы:

•в первом случае результаты арифметических операций над числовыми полями СУБД округляются в мень шую сторону, а разница суммируется в некоторой другой записи СУБД (как правило, эта запись пред ставляет собой денежную сумму, которая хранится на личном счету хакера в банке, а округляемые чис ловые поля относятся к счетам других клиентов банка);

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

Ниже будут рассмотрены атаки, реализующие данные сценарии.

Идентификация и проверка подлинности пользователей

Обычно в СУБД для идентификации и проверки подлинности пользователей применяются либо соответству ющие механизмы операционной системы, либо SQL оператор CONNECT. Например, в случае СУБД Oracle опе ратор CONNECT имеет следующий вид:

CONNECT пользователь[/пароль] [@база_данных];

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

45.3

Реализация политики безопасности средствами СУБД

Управление доступом

Для иллюстрации вопросов, связанных с управлением доступом, будет использоваться СУБД INGRES.

Основные понятия

Обычно в СУБД применяется произвольное управление доступом, когда владелец объекта передает права до ступа к нему (чаще говорят привилегии) по своему усмотрению. Привилегии могут передаваться субъектам (отдельным пользователям), группам, ролям или всем пользователям.

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

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

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

Основные категории пользователей

Пользователей СУБД можно разбить на три категории:

•администратор сервера баз данных. Он ведает установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей и т.п. Администратор сервера имеет имя ingres. Прямо или косвенно он обладает всеми привилегиями, которые имеют или могут иметь другие пользователи.

•администраторы базы данных. К этой категории относится любой пользователь, создавший базу данных, и, следовательно, являющийся ее владельцем. Он может предоставлять другим пользователям доступ к базе и к содержащимся в ней объектам. Администратор базы отвечает за ее сохранение и восстановле ние. В принципе в организации может быть много администраторов баз данных. Чтобы пользователь мог создать базу и стать ее администратором, он должен получить (вероятно, от администратора сервера) привилегию creatdb.

•прочие (конечные) пользователи. Они оперируют данными, хранящимися в базах, в рамках выделенных им привилегий.

В последующих разделах будет детально проанализирована система привилегий СУБД INGRES. Здесь мы отме тим только, что администратор сервера баз данных, как самый привилегированный пользователь, нуждается в особой защите. Компрометация его пароля фактически означает компрометацию сервера и всех хранящихся на нем баз данных. Поручать администрирование различных баз данных разным людям имеет смысл только тогда, когда эти базы независимы и по отношению к ним не придется проводить согласованную политику выделения привилегий или резервного копирования. В таком случае каждый из администраторов будет знать ровно столько, сколько необходимо. Можно провести аналогию между пользователем ingres и администраторами баз данных с одной стороны, и суперпользователем операционной системы (root в случае ОС UNIX) и служебными пользо вателями (в ОС UNIX это могут быть bin, lp, uucp и т.д.) с другой стороны. Введение служебных пользователей позволяет администрировать функциональные подсистемы, не получая привилегий суперпользователя. Точно так же информацию, хранящуюся на сервере баз данных, можно разделить на отсеки, так что компрометация администратора одного отсека не означает обязательной компрометации другого.

Виды привилегий

Привилегии в СУБД можно подразделить на две категории: привилегии безопасности и привилегии доступа. Привилегии безопасности позволяют выполнять административные действия. Привилегии доступа, в соот ветствии с названием, определяют права доступа субъектов к определенным объектам.

Привилегии безопасности

Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или всем) во время его создания (оператором CREATE USER) или изменения характеристик (оператором ALTER USER). Таких при вилегий пять:

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

45.4

Реализация политики безопасности средствами СУБД

•createdb право на создание и удаление баз данных. Этой привилегией, помимо администратора серве ра, должны обладать пользователи, которым отводится роль администраторов отдельных баз данных.

•operator право на выполнение действий, которые традиционно относят к компетенции оператора. Име ются в виду запуск и остановка сервера, сохранение и восстановление информации. Помимо админист раторов сервера и баз данных этой привилегией целесообразно наделить также администратора опера ционной системы.

•maintain_locations право на управление расположением баз администраторы сервера баз данных и операционной системы.

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

Привилегии доступа

Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора GRANT и изы маются с помощью оператора REVOKE. Эти привилегии, как правило, присваивает владелец соответствующих объек тов (он же администратор базы данных) или обладатель привилегии security (обычно администратор сервера баз данных). Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с по мощью операторов CREATE GROUP и CREATE ROLE. Для изменения состава группы служит оператор ALTER GROUP. Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен список членов группы. Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE для удаления ролей. Напомним, что со здавать и удалять именованные носители привилегий, а также изменять их характеристики может лишь пользова тель с привилегией security. При совершении подобных действий необходимо иметь подключение к базе данных iidbdb, в которой хранятся сведения о субъектах и их привилегиях. Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они относятся. В СУБД INGRES таких видов пять:

•таблицы и представления

•процедуры

•базы данных

•сервер баз данных

•события

Присваивание привилегий доступа производится с помощью оператора GRANT. В самом общем виде опера тор GRANT имеет следующий формат:

GRANT привилегии ON объекты

TO кому;

Применительно к таблицам и представлениям можно управлять следующими правами доступа: SELECT право на выборку данных

INSERT право на добавление данных DELETE право на удаление данных

UPDATE право на обновление данных (можно указать определенные столбцы, разрешенные для обновления) REFERENCES право на использование внешних ключей, ссылающихся на данную таблицу (можно указать оп ределенные столбцы)

По умолчанию пользователь не имеет никаких прав доступа к таблицам и представлениям их необходимо передать с помощью операторов GRANT. По отношению к процедуре можно предоставить право на выполне ние. При этом не нужно заботиться о выделении прав доступа к объектам, обрабатываемым процедурой их наличие не обязательно. Таким образом, процедуры баз данных являются удобным средством предоставле ния контролируемого доступа для выполнения строго определенных действий над данными. Права доступа к базе данных как к единому целому может предоставлять ее администратор или пользователь с привилегией security. Эти “права” на самом деле устанавливают ряд ограничений на использование базы данных, то есть по сути являются запретительными. Имеется в виду ограничение на число операций ввода/вывода или чис ло строк, возвращаемых одним запросом, ограничение права создания таблиц и процедур и т.п. По умолча нию пользователь не стесняется количественными лимитами и получает право на создание объектов в базе. Отметим, что при создании базы данных указывается ее статус общая или личная. Это влияет на подразуме ваемые права доступа к базе. По умолчанию право на подключение к общей базе предоставляется всем. Право на подключение к личной базе нужно передавать явным образом. Право на подключение необходимо для выполнения всех прочих операций с базой и содержащимися в ней объектами. Привилегии (которые в дан ном случае точнее было бы назвать ограничениями) QUERY_IO_LIMIT и QUERY_ROW_LIMIT проверяются на основании оценок, выданных оптимизатором запросов. Если оптимизатор предсказывает, что запрос превы сит отведенный лимит числа операций ввода вывода или возвращаемых строк, он (запрос) отвергается. На ложение подобных количественных ограничений препятствует монополизации сервера одним клиентом и может использоваться как один из инструментов поддержания высокой готовности. Обратим внимание на следующее любопытное обстоятельство. По умолчанию все пользователи имеют право создавать процедуры в базах данных. Если бы они при этом автоматически получали права на выполнение, то смогли бы осуще ствить по существу любую операцию с данными, поскольку выполнение процедуры не требует прав доступа к обрабатываемым объектам. К счастью, для передачи привилегии доступа к объектам, и, в частности, для пре доставления права на выполнение процедуры, надо быть не только владельцем объекта, но и администрато ром базы данных. Мы видим, насколько осторожно нужно относиться к предоставлению привилегий выпол

45.5

Реализация политики безопасности средствами СУБД

нения по отношению к новым, непроверенным процедурам. В принципе достаточно одного “троянского коня”, чтобы скомпрометировать всю базу данных. Процедуры являются столь же гибким, но и столь же опасным средством, что и UNIX программы с битом переустановки действующего идентификатора пользователя. От метим, что запретительные привилегии в принципе можно наложить на администратора базы данных или администратора сервера, однако они не будут иметь силы. Тем самым злоумышленник лишен возможности ограничить права доступа администраторов. В частности, он не может создать личную “секретную” базу дан ных, к которой не будет иметь доступ пользователь ingres. Правда, у подобного положения есть и оборотная сторона компрометация пароля. Администратор сервера предоставляет злоумышленнику неограниченные права доступа ко всем базам данных.

Права доступа к серверу распространяются на все базы данных, обслуживаемые данным серверам. Набор этих прав тот же, что и для отдельных баз данных. Привилегии, явно определенные для отдельных баз, имеют при оритет над привилегиями сервера. Здесь мы отметим лишь, что по отношению к событиям имеются две при вилегии RAISE и REGISTER. Первая позволяет возбуждать события, вторая регистрироваться для их полу чения. Оператор GRANT может содержать необязательную часть, принципиально важную для защиты СУБД. Имеется в виду конструкция:

GRANT ...

...

WITH GRANT OPTION;

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

Для отмены привилегий, выданных ранее (как разрешительных, так и запретительных), служит оператор REVOKE.

Получение информации о привилегиях

Важно не только давать и отбирать привилегии, но и иметь информацию о том, какими правами доступа об ладает каждый из субъектов. Подобные данные можно получить с помощью функции dbmsinfo, а также путем анализа содержимого таблиц в базе данных iidbdb. Функция dbmsinfo возвращает права доступа к базе, от носящиеся к текущему подключению. Можно узнать имена действующих группы и роли, значения количествен ных ограничений, наличие привилегий для создания таблиц и процедур и т.п. Таблицы iiusergroup, iirole и iidbprivileges базы данных iidbdb содержат, соответственно, список групп и их состав, перечень ролей вмес те с зашифрованными паролями и сведения о привилегиях доступа к базам данных. Так, таблица iiusergroup состоит из трех столбцов:

•groupid имя группы,

•groupmem имя члена группы,

•reserve резервный столбец.

Средствами SQL из этих таблиц можно извлечь необходимую информацию.

Использование представлений для управления доступом

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

Приведем пример создания представления, содержащего два столбца исходной таблицы и включающего в себя только строки с определенным значением одного из столбцов:

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’;

45.6

Реализация политики безопасности средствами СУБД

но в ответ просто получат результат из нуля строк, а не код ответа, свидетельствующий о нарушении прав досту па. Это принципиально важно, так как лишает злоумышленника возможности получить список отделов косвен ным образом, анализируя коды ответов, возвращаемые после обработки SQL запросов.

Иерархия прав доступа

Оператор GRANT и другие средства управления доступом СУБД позволяют реализовать следующие виды ог раничения доступа:

•операционные ограничения (за счет прав доступа SELECT, INSERT, UPDATE, DELETE, применимых ко всем или только некоторым столбцам таблицы);

•ограничения по значениям (за счет механизма представлений);

•ограничения на ресурсы (за счет привилегий доступа к базам данных).

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

На иерархию привилегий можно посмотреть и с другой точки зрения. Каждый пользователь, помимо, собствен ных, имеет привилегии PUBLIC. Кроме этого, он может входить в различные группы и запускать приложения с определенными ролями. Как соотносятся между собой права, предоставленные различным именованным но сителям привилегий? Иерархия авторизации выглядит для СУБД INGRES следующим образом:

•роль (высший приоритет)

•пользователь

•группа

•PUBLIC (низший приоритет)

Для каждого объекта, к которому осуществляется доступ, INGRES пытается отыскать в иерархии привилегию, относящуюся к запрашиваемому виду доступа (SELECT, EXECUTE и т.п.). Например, при попытке доступа к таб лице с целью обновления, INGRES проверяет привилегии роли, пользователя, группы и всех пользователей. Если хотя бы на одном уровне иерархии привилегия UPDATE имеется, запрос передается для дальнейшей об работки. В противном случае используется подразумеваемое право доступа, которое предписывает отверг нуть запрос. Рассмотрим подробнее трактовку ограничений на ресурсы. Пусть, например, на всех четырех уровнях иерархии специфицированы свои ограничения на число результирующих строк запроса (привиле гия QUERY_ROW_LIMIT):

Если пользователь в момент начала сеанса работы с СУБД задал и роль, и группу, будет использовано ограни чение, накладываемое ролью (1700). Если бы привилегия QUERY_ROW_LIMIT для роли отсутствовала, или пользователь не задал роль в начале сеанса работы, пользователь смог бы получать результаты не более чем из 1500 строк и т.п. Если бы привилегия QUERY_ROW_LIMIT вообще не была специфицирована ни на одном уровне иерархии, СУБД воспользовалась бы подразумеваемым значением, которое в данном случае означает отсутствие ограничений на число результирующих строк.

Обычно используемая роль и группа задаются, соответственно, как аргументы опций R и G в командной строке запуска приложения.

Пример:

QBF Gaccounting company_db

Если опция G отсутствует, применяется подразумеваемая группа пользователя, если таковая имеется. Наконец, если в командной строке sql задана опция uпользователь, то в число проверяемых входят также привилегии указанного пользователя.

Метки безопасности и принудительный контроль доступа

Выше были описаны средства произвольного управления доступом, характерные для уровня безопасности C. Как уже указывалось, они в принципе достаточны для подавляющего большинства коммерческих приложений. Тем не менее, они не решают одной весьма важной задачи задачи слежения за передачей информации. Средства про извольного управления доступом не могут помешать авторизованному пользователю законным образом получить секретную информацию и затем сделать ее доступной для других, неавторизованных пользователей. Нетрудно понять, почему это так. При произвольном управлении доступом привилегии существуют отдельно от данных (в случае реляционных СУБД отдельно от строк реляционных таблиц). В результате данные оказываются “обезли ченными”, и ничто не мешает передать их кому угодно даже средствами самой СУБД. В “Критериях оценки надеж ных компьютерных систем”, применительно к системам уровня безопасности B, описан механизм меток безопас ности, реализованный в версии INGRES/Enhanced Security (INGRES с повышенной безопасностью). Применять эту версию на практике имеет смысл только в сочетании с операционной системой и другими программными компо нентами того же уровня безопасности. Тем не менее, рассмотрение реализации меточной безопасности в СУБД INGRES интересно с познавательной точки зрения, а сам подход, основанный на разделении данных по уровням

45.7

Реализация политики безопасности средствами СУБД

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

•Уровень секретности. Смысл этого компонента зависит от приложения. В частности, возможен традици онный спектр уровней от “совершенно секретно” до “несекретно”.

•Категории. Понятие категории позволяет разделить данные на “отсеки” и тем самым повысить надеж ность системы безопасности. В коммерческих приложениях категориями могут служить “финансы”, “кад ры”, “материальные ценности” и т.п. Ниже назначение категорий разъясняется более подробно.

•Области. Является дополнительным средством деления информации на отсеки. На практике компонент “область” может действительно иметь географический смысл, обозначая, например, страну, к которой относятся данные.

Каждый пользователь СУБД INGRES/Enhanced Security характеризуется степенью благонадежности, которая также определяется меткой безопасности, присвоенной данному пользователю. Пользователь может полу чить доступ к данным, если степень его благонадежности удовлетворяет требованиям соответствующей мет ки безопасности. Более точно:

•уровень секретности пользователя должен быть не ниже уровня секретности данных;

•набор категорий, заданных в метке безопасности данных, должен целиком содержаться в метке безопас ности пользователя;

•набор областей, заданных в метке безопасности пользователя, должен целиком содержаться в метке безопасности данных.

Рассмотрим пример. Пусть данные имеют уровень секретности “конфиденциально”, принадлежат категории “финансы” и относятся к областям “Россия” и “СНГ”. Далее, пусть степень благонадежности пользователя ха рактеризуется меткой безопасности с уровнем секретности “совершенно секретно”, категориями “финансы” и “кадры”, а также областью “Россия”. Такой пользователь получит доступ к данным. Если бы, однако, в мет ке пользователя была указана только категории “кадры”, в доступе к данным ему было бы отказано, несмотря на его “совершенно секретный” уровень.

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

Отметим, что механизм меток безопасности не отменяет, а дополняет произвольное управление доступом. Пользователи по прежнему могут оперировать с таблицами только в рамках своих привилегий, но даже при наличии привилегии SELECT им доступна, вообще говоря, только часть данных.

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

Специальная привилегия, DOWNGRADE, позволяет изменять метки безопасности, ассоциированные с данны ми. Подобная возможность необходима, например, для коррекции меток, по тем или иным причинам оказав шихся неправильными. Представляется естественным, что СУБД INGRES/Enhanced Security допускает не только скрытое, но и явное включение меток безопасности в реляционные таблицы. Появился новый тип данных, security label, поддерживающий соответствующие операции сравнения. INGRES/Enhanced Security первая СУБД, получившая сертификат, эквивалентный аттестации на класс безопасности B1. Вероятно, метки безопас ности постепенно войдут в стандартный репертуар систем управления базами данных.

2. Реализация информационной безопасности СУБД

Поддержание целостности данных в СУБД

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

Ограничения

Ограничения могут относиться к таблицам или отдельным столбцам. Ограничения на столбцы задаются при создании таблицы, в операторах CREATE TABLE Табличные ограничения относятся к группе столбцов и могут задаваться как при создании таблицы, так и позже, посредством оператора ALTER TABLE. Следующий пример содержит именованное ограничение, связывающее значения в двух столбцах:

CREATE TABLE dept (dname char(10), budget money,

expenses money,

CONSTRAINT check_amount CHECK (budget > 0 and expenses <= budget));

{Бюджет должен быть положительным, а расходы не должны выходить за рамки бюджета}

45.8

Реализация политики безопасности средствами СУБД

Ссылочные ограничения отвечают за целостность связей между таблицами. Подобное ограничение требует, чтобы каждому значению в столбце или группе столбцов одной таблицы соответствовало ровно одно значе ние в другой таблице. Название ограничения объясняется тем, что такие значения играют роль ссылок меж ду таблицами в реляционной модели.

Приведем пример ссылочного ограничения:

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 правило;

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

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

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

В коммерческих приложениях высокая готовность аппаратно программных комплексов является важнейшим фактором. Применительно к СУБД средства поддержания высокой готовности должны обеспечивать нейтрали

45.9

Реализация политики безопасности средствами СУБД

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

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

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

В настоящем разделе будет рассмотрена разработка компании Sun Microsystems, Inc SPARCcluster PDB Server (параллельный сервер баз данных на основе SPARC кластера).

Аппаратная организация SPARCcluster PDBServer

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

Рисунок 1 поясняет аппаратную организацию SPARCcluster PDB Server.

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

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

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

45.10

Реализация политики безопасности средствами СУБД

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

Подсистема управления кластером состоит из трех инструментов с графическим интерфейсом: консоли кла стера, менеджера томов и менеджера сервера Oracle. Их интеграция обеспечивает централизованное опера тивное управление всеми ресурсами кластера.

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

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

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

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

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

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

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

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

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

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

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

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

SPARCcluster PDB Srever

Рис. 2. Программная организация SPARCcluster PDB Server

(узлы кластера работают под управлением ОС Solaris версии 2.4 или выше)

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

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

45.11

Реализация политики безопасности средствами СУБД

мы рассмотрим возможности другого популярного сервера СУБД Informix OnLine Dynamic Server (OnLine DS) 7.1. В отличие от предыдущего раздела, речь пойдет об обычных (а не кластерных) конфигурациях. В Informix OnLine DS 7.1 поддерживается модель тиражирования, состоящая в полном отображении данных с основного сервера на вторичные.

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

Тиражирование

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

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

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

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

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

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

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

45.12

Реализация политики безопасности средствами СУБД

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

Мы рассмотрим несколько угроз, возникающих при использовании злоумышленником средств языка SQL.

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

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

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

Еще один пример выяснение набора первичных ключей таблицы при наличии только привилегии INSERT (без привилегии SELECT). Если набор возможных значений ключей примерно известен, можно пытаться встав лять новые строки с “интересными” ключами и анализировать коды завершения SQL операторов. Как мы ви дели из предыдущего примера, сам факт присутствия определенного ключа в таблице может быть весьма ин формативным.

Если для реализации контроля доступа используются представления, и эти представления допускают моди фикацию, с помощью операций модификации/вставки можно получить информацию о содержимом базовых таблиц, не располагая прямым доступом к ним.

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

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

К высокому уровню секретности относятся сведения о пациентах, находящихся под надзором правоох ранительных органов или страдающих специфическими заболеваниями.

На низком уровне располагаются данные о прочих пациентах, а также информация о некоторых “секретных” пациентах с “маскировочным” диагнозом. Части таблицы могут выглядеть примерно так, как это отображено в таблицах 1 и 2.

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

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

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

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

45.13

Реализация политики безопасности средствами СУБД

•Защита пересылаемых данных только при установлении соединения клиента с сервером.

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

•Подтверждение подлинности источника данных. Проверяется, что все поступающие на сервер данные по лучены от определенного клиента.

•Подтверждение подлинности источника и целостности данных. Проверяется, что отправленные данные не были изменены.

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

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

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

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

Удаленные вызовы процедур (RPC) DCE

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

3. Анализ защищенности баз данных

7 Декабря 1998 г. Атланта. Компания Internet Security Systems, Inc. (ISS), ведущий поставщик средств адаптивного управления безопасностью сети, объявила о выходе системы анализа защищенности баз дан ных Database Scanner 1.0, предоставляющей новое решение для защиты наиболее важной информации, хранящейся в таких системах управления базами данных (DBMS), как SQL Server компании Microsoft и Sybase Adaptive Server компании Sybase. Система Database Scanner вновь продемонстрировала лидирующее по ложение компании ISS на рынке средств анализа защищенности, делая компанию ISS единственным по ставщиком решений по анализу защищенности на всех уровнях информационных систем (сетевом, опера ционном и прикладном). Появление на рынке системы Database Scanner это результат приобретения ком панией ISS технологии DbSecure, о чем было объявлено 28 октября 1998 года. “По мере того как количе ство важной информации, хранимой в системах управления базами данных, продолжает нарастать, эти хра нилища данных предприятия быстро становятся еще одной ключевой областью, которую необходимо учи

45.15

Реализация политики безопасности средствами СУБД

тывать с точки зрения безопасности”, сказал Том Нунан, президент компании ISS. “С появлением системы Database Scanner компания ISS обеспечит полный спектр исчерпывающих и независимых решений по адап тивному управлению безопасностью сети, которые могут обнаруживать и реагировать на весь диапазон рисков безопасности предприятия”. “С помощью Database Scanner организации теперь могут легко и не дорого защитить свои сервера баз данных, используя наиболее передовую технологию анализа защищен ности”, сказал Эндрю Завевский (Andrew Zavevsky), президент компании AZ Databases, которая предос тавляет консультационные услуги по вопросам создания и организации баз данных. “В дополнение к все стороннему обнаружению уязвимостей, система Database Scanner, с помощью создаваемых отчетов, не толь ко описывает проблему, но и предоставляет подробнейшие инструкции по ее устранению”.

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

Система Database Scanner позволяет централизованно, быстро и легко сканировать удаленные базы данных с целью обнаружения уязвимостей, характерных для баз данных, полностью анализируя все риски безопасности, связанные с настройкой подсистем аутентификации, авторизации и целостности системы. К числу основных проверок, реали зуемых системой Database Scanner, можно отнести:

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

•Контроль паролей и пользователей выполняется автоматический анализ надежности паролей, отсле живаются “устаревшие” пользователи, которые по прежнему имеют возможность работы с БД.

•Контроль конфигурации БД проверяются функции, которые могут вызвать возможные повреждения, и рекомендуются различные изменения конфигурации, такие, как: репликация, периодическое обновле ние, регистрация доступа к базе данных, использование хранимых процедур, применение задач уведом ления (alert) и запуска по расписанию (schedule), трассировка и использование различных сетевых про токолов.

•Контроль инсталляции указывается расположение обновлений (hotfix и service pack), и пользователи информируются о том, какие обновления по прежнему необходимо инсталлировать.

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

Также осуществляются проверки на наличие потенциально опасных “троянских коней” программ, которые могут незаметно устанавливаться и использоваться для сбора важных данных. После завершения анализа защищенности система Database Scanner с помощью большого числа графических отчетов предоставляет оценку защищенности базы данных.

Кроме того, отчеты системы Database Scanner содержат описание действий администратора по коррекции и устранению обнаруженных проблем. Совместное применение систем анализа защищенности сетевых про токолов и сервисов TCP/IP (Internet Scanner 528 уязвимостей), операционных систем (System Security Scanner более 450 уязвимостей) и систем управления базами данных (Database Scanner более 100 уяз вимостей) является уникальным по своей эффективности, надежности и защищенности решением для лю бых предприятий, использующих в своей деятельности информационные системы.

4. Обзор средств управления корпоративными СУБД

Согласно исследованиям консалтинговой фирмы Gartner Group, в организациях, входящих в число Fortune 1000, работу распределенной базы данных обеспечивают в среднем пять типов серверов СУБД. К такой “разношер стности” используемых баз данных приводят слияния компаний и несогласованные действия различных де партаментов корпораций по построению единой информационной среды.

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

Заключение

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

45.16

Реализация политики безопасности средствами СУБД

Таблица 5.

Характеричстика средств управления базами данных в масштабе предприятия

примечание: оценки выставлялись по пятибальной системе

45.17