GRANT CREATE TABLE TO ivangavrilov
Здесь пользователю ivangavrilov дается разрешение на создание таблиц в текущей БД.
В данном конспекте лекций приведена далеко не полная классификация категорий прав доступа, принятых в SQL Server 2005. Для ознакомления с полной классификацией, а также с детальным синтаксисом операторов GRANT, DENY и REVOKE читателю следует обратиться к документации MSDN Library 2005.
Управление ролями приложения
Роль приложения создается с помощью оператора CREATE APPLICATION ROLE. Синтаксис его следующий:
CREATE APPLICATION ROLE имя_роли
WITH PASSWORD = ‘пароль’
[, DEFAULT_SCHEMA = имя_схемы]
Нетрудно видеть, что для роли приложения задается не только имя, но и пароль, чтобы не все пользователи БД могли активизировать роль приложения. Также можно назначить роли схему по умолчанию. Для модификации роли приложения используется команда ALTER APPLICATION ROLE, для удаления – DROP APPLICATION ROLE. Задать разрешение доступа для роли приложения можно так же, как и для любого другого субъекта, т. е. при помощи команд GRANT, DENY и REVOKE.
Роль приложения не содержит пользователей-членов. Порядок активизации роли приложения следующий.
· приложение соединяется с сервером СУБД под учетной записью пользователя;
· учетная запись отображается на конкретного пользователя БД; таким образом, приложение проходит идентификацию и аутентификацию на уровне СУБД и БД;
· для активизации роли приложения клиентская программа вызывает системную хранимую процедуру sp_setapplrole с передачей имени и пароля в качестве параметров;
· если все введенные данные верны, приложению даются соответствующие разрешения доступа, при этом все права конкретного пользователя аннулируются;
· вызов хранимой процедуры sp_unsetapplrole позволяет пользователю вернуться в свой контекст и работать с БД, пользуясь своими индивидуальными правами.
6.1.2.4. Изменение контекста выполнения команд Transact-SQL
В SQL Server 2005 имеется интересная возможность: пользователь при необходимости может выполнить ту или иную SQL-команду и даже целый набор команд не от своего имени, а от имени другого пользователя, с его правами.
Предположим, конечный пользователь, установивший соединение под учетной записью Login1, желает выполнить некоторое количество команд от имени учетной записи Login2. Для этого ему нужно записать и выполнить команду EXECUTE AS в следующем виде:
EXECUTE AS LOGIN = ‘Login2’
Смена контекста произойдет на уровне сервера. Конечный пользователь временно лишится прав учетной записи Login1, но приобретет права учетной записи Login2.
Можно сменить контекст и на уровне БД. В этом случае ключевое слово LOGIN в записи команды заменяется на USER. Скажем, пользователь User1 желает перейти в контекст User2. Для этого он выполняет следующую команду:
EXECUTE AS USER = ‘User2’
Чтобы вернуться обратно из «чужого» контекста в «свой», необходимо выполнить команду REVERT без параметров.
Нетрудно заметить, что переход в контекст другого пользователя очень напоминает активизацию роли приложения, а главное, ее результат: права текущего субъекта заменяются правами другого субъекта. Вместо роли приложения, в принципе, можно использовать специального пользователя. При необходимости другие пользователями могут переходить в его контекст, используя команду EXECUTE AS, а затем возвращаться в свой контекст. Это практически то же самое, что последовательно воспользоваться процедурами sp_setapplrole и sp_unsetapplrole.
Для того чтобы субъект имел право переходить в контекст другого субъекта, ему предварительно должно быть выдано разрешение, обозначаемое в SQL словом IMPERSONATE.
Если обратиться к приведенным выше примерам, то:
· учетная запись Login1 должна обладать правом IMPERSONATE на учетную запись Login2;
· пользователь User1 должен обладать правом IMPERSONATE на объект пользователя User2.
Право IMPERSONATE выдается так же, как и другие права – с помощью команды GRANT. В следующем примере право IMPERSONATE выдается учетной записи Login1:
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.