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

GRANT ... 
... 
WITH GRANT OPTION;

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

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

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

• groupid - имя группы,
• groupmem - имя члена группы,
• reserve - резервный столбец.

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

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

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

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-запросов.

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

Оператор 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пользователь

то в число проверяемых входят также привилегии указанного пользователя.

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

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

• Уровень секретности. Смысл этого компонента зависит от приложения. В частности, возможен традиционный спектр уровней от "совершенно секретно" до "несекретно".
• Категории. Понятие категории позволяет разделить данные на "отсеки" и тем самым повысить надежность системы безопасности. В коммерческих приложениях категориями могут служить "финансы", "кадры", "материальные ценности" и т.п. Ниже назначение категорий разъясняется более подробно.
• Области. Является дополнительным средством деления информации на отсеки. На практике компонент "область" может действительно иметь географический смысл, обозначая, например, страну, к которой относятся данные.

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

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

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

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

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

1. Ограничения

Ограничения могут относиться к  таблицам или отдельным столбцам. Ограничения на столбцы задаются при создании таблицы, в операторах 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 в примере выше). 
Ограничения можно не только накладывать, но и отменять. При этом между ограничениями могут существовать зависимости, и отмена одного из них может потребовать ликвидации других (ссылочных) ограничений, зависящих от первоначального. Рассмотрим следующий пример: