Добаеление пользователей к роли

Сама возможность определять роли является очень привлекательной, но роли остаются бесполезными до тех пор, пока в состав членов этих ролей не введены пользователи. Для добавления пользователя к роли достаточно применить системную хранимую процедуру sp addrolemember, указав имя базы данных и идентификатор учетной записи:

sp addrolemember [©rolename =] <role name>, [©membername =] <Login ID>

Параметры этой хранимой процедуры в основном не требуют пояснений, поэтому перейдем непосредственно к рассмотрению примера.

Начнем с проверки того, имеет ли учетная запись с идентификатором TestAccount доступ к таблице Territories: SELECT * FROM Territories

1Сак и следовало ожидать, попытка обратиться к этой таблице была отвергнута (поскольку права доступа еще отсутствуют): Server: Msg 22 9, Level 14, State 5, Line 1

SELECT permission denied on object Territories, database Northwind, owner dbo .

После этого перейдем к дальнейшим действиям и введем пользователя Windows с идентификатором TestAccount в состав членов роли OurTestRole: USE NorthwindSecure

EXEC sp addrolemember OurTestRole, [ARISTOTLE\TestAccount]

После этой попытки появляется сообщение, что команда выполнена успешно: ARISTOTLE\TestAccount added to role OurTestRole.

Теперь мы можем попытаться снова вызвать на выполнение оператор SELECT. На этот раз результаты становятся вполне приемлемыми (должно быть получено примерно 53 строки).

Удаление пользователя из состава членов роли

Очевидно, что с любой командой создания должна быть связана команда удаления, а возможность добавления пользователя к роли должна быть уравновешена возможностью его исключения из состава членов роли.

Операция исключения пользователя из состава членов роли выполняется почти по такому же принципу, как и операция добавления, если не считать того, что для исключения пользователя используется другая системная хранимая процедура, sp droprolemember, в следующей форме:

sp droprolemember [©rolename =] <role name>, [©membername =] <security account>

Итак, вернемся к условиям рассматриваемого примера и удалим учетную запись TestAccount из состава членов роли базы данных OurTestRole: USE NorthwindSecure

EXEC sp droprolemember OurTestRole, [ARISTOTLE\TestAccount]

После этого должно появиться еще одно подтверждение, что операция удаления выполнена успешно. Затем снова попытаемся вызвать на выполнение оператор SELECT: SELECT * FROM Territories

1Сак и следовало ожидать, снова появляется сообщение об ошибке, свидетельствующее о том, что пользователь не имеет прав доступа.

Таким образом, можно добавлять и удалять пользователей, регулируя состав членов любой роли, независимо от того, является ли роль определяемой пользователем или фиксированной, а также относится ли она к категории роли сервера или базы данных. В любом случае операции добавления и удаления пользователей из состава роли выполняются почти одинаково.

Следует отметить, что все описанные операции могут быть осуществлены с помощью программы Enterprise Manager. Чтобы модифицировать права, связанные с ролью, достаточно щелкнуть на элементе Roles узла Databases и откорректировать права доступа с помощью переключателей. Если требуется добавить пользователя к роли, перейдите к свойствам учетной записи этого пользователя, выберите вкладку с определениями ролей Server или Database, а затем установите флажки рядом со всеми ролями, которые должны быть назначены конкретному пользователю.

Удаление ролей

Задача удаления роли является такой же простой, как и ее добавление. Для этого применяется следующий синтаксис: EXEC sp droprole <role name>

После выполнения оператора удаления учетная запись становится недоступной.

Роли приложения

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

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

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

Следует отметить, что назначение ролей приложения не подлежит отмене; это означает, что после определения некоторой роли приложения как активной для данного конкретного соединения становится невозможным возврат к собственным параметрам безопасности пользователя для этого соединения. Для того чтобы пользователь снова мог возвратиться к заданным для него параметрам безопасности, он должен закрыть соединение и зарегистрироваться снова.

Процесс ввода в действие роли приложения состоит из описанных ниже этапов.

1. Пользователь регистрируется в приложении (скорее всего, с использованием окна регистрации, предусмотренного в приложении).

2. Проводится проверка доступа к учетной записи, и пользователь получает назначенные ему права доступа.

3. В приложении выполняется системная хранимая процедура sp setapprole с предоставлением имени роли и пароля.

4. Осуществляется проверка роли приложения, и соединение переключается на контекст этой роли приложения (все права, предоставленные перед этим пользователю, отменяются, поскольку с этого момента ему назначаются права роли приложения).

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

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

Создание ролей приложения

Для создания роли приложения можно воспользоваться новой системной хранимой процедурой sp addapprole. Эта хранимая процедура также является довольно несложной в использовании; синтаксис этой процедуры выглядит следующим образом:

sp addapprole [©rolename =] <role name>, [©password =] <password >

Хранимая процедура sp addapprole во многом аналогична другим хранимым процедурам, описанным в этой главе, в том, что ее параметры в основном не требуют пояснений, поэтому перейдем непосредственно к ее использованию и создадим для себя необходимую роль приложения: ЕХЕС sp addapprole OurAppRole, password

На этом вся работа по созданию роли приложения заканчивается.