Система безопасности уровня базы данных

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

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

Разрешения к объектам назначаются с помощью инструкций GRANT (предоставить), REVOKE (отозвать) и DENY (запретить). Запрет привилегии замещает собой её предоставление, а предоставление привилегии замещает собой её отзыв. Пользователю может быть предоставлено множество разрешений к объекту (индивидуальных, наследованных от роли, обеспеченных принадлежностью к роли public). Если какая-либо из этих привилегий запрещена, для пользователя блокируется доступ к объекту. В противном случае, если какая-либо из привилегий предоставляет разрешение, пользователь получает доступ к объекту.

Разрешения объекта достаточно детализированы; существуют отдельные разрешения для каждого из возможных действий (SELECT, INSERT, UPDATE, RUN и т.д.) над объектом. Некоторые фиксированные роли базы данных также влияют на доступ к объекту, например, управляя возможностью считывать информацию и записывать её в базу данных.

Вполне возможна ситуация, когда пользователь был распознан в SQL Server, но у него нет доступа ни к одной из его баз данных. Также возможно и обратное: пользователю открыт доступ к базам данных, но он не был распознан сервером. Перемещение базы данных и её разрешений на другой сервер без параллельного перемещения регистрационных записей сервера может привести к возникновению таких «осиротевших» пользователей.

Права собственности на объект

Заключительным аспектом в этом обзоре модели безопасности SQL Server является право собственности на объект. Владельцем любого объекта является схема. Схемой по умолчанию является dbo, которую не следует путать с ролью dbo.

В предыдущих версиях владельцами объектов являлись пользователи (точнее, владелец сам представлял собой схему). По сравнению с этим модель SQL Server 2005 в виде база данных-схема-объекты имеет целый ряд преимуществ.

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

Большая часть операций управления системой безопасности выполняется в утилите Management Studio. В программном коде управление системой безопасности выполняется с помощью инструкций DDL GRANT, REVOKE и DENY, а также нескольких хранимых процедур.