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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GRANT привилегии 
ON объекты 
TO кому;

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

По умолчанию пользователь не имеет никаких прав доступа  к таблицам и представлениям - их необходимо передать с помощью операторов GRANT. 
По отношению к процедуре можно предоставить право на выполнение.  
Права доступа к базе данных как к единому целому может предоставлять ее администратор или пользователь с привилегией security. Эти "права" на самом деле устанавливают ряд ограничений на использование базы данных, то есть по сути являются запретительными. Имеется в виду ограничение на число операций ввода/вывода или число строк, возвращаемых одним запросом, ограничение права создания таблиц и процедур и т.п. По умолчанию пользователь не стесняется количественными лимитами и получает право на создание объектов в базе. Наложение подобных количественных ограничений препятствует монополизации сервера одним клиентом и может использоваться как один из инструментов поддержания высокой готовности. 
Отметим, что при создании базы данных указывается ее статус - общая или личная. Это влияет на подразумеваемые права доступа к базе. По умолчанию право на подключение к общей базе предоставляется всем. Право на подключение к личной базе нужно передавать явным образом. Право на подключение необходимо для выполнения всех прочих операций с базой и содержащимися в ней объектами. 
Обратим внимание на следующее любопытное обстоятельство. По умолчанию все пользователи имеют право создавать процедуры в базах данных. Если бы они при этом автоматически получали права на выполнение, то смогли бы осуществить по существу любую операцию с данными, поскольку выполнение процедуры не требует прав доступа к обрабатываемым объектам. К счастью, для передачи привилегии доступа к объектам, и в, частности, для предоставления права на выполнение процедуры, надо быть не только владельцем объекта, но и администратором базы данных.  
Права доступа к серверу распространяются на все базы данных, обслуживаемые данным серверам. Набор этих прав тот же, что и для отдельных баз данных. 
Привилегии, явно определенные для отдельных баз, имеют приоритет над привилегиями сервера. 
По отношению к событиям имеются две привилегии - RAISE и REGISTER. Первая позволяет возбуждать события, вторая - регистрироваться для их получения. 
Оператор GRANT может содержать необязательную часть, принципиально важную для защиты СУБД. Имеется в виду конструкция

GRANT ... 
... 
WITH GRANT OPTION;

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

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

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

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

CREATE VIEW empview AS 
SELECT name, dept 
FROM employee 
WHERE dept = 'shoe';

Предоставим всем право на выборку из этого представления:

GRANT SELECT 
ON empview 
TO PUBLIC;

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

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

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

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