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

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

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 и другие средства управления доступом СУБД позволяют реализовать следующие виды ограничения доступа:

· операционные ограничения (за счет прав доступа 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пользователь

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