5.4. Роли приложений

Роли приложений (application roles) SQL Server 2005, CREATE APPLICATION ROLE, SP_SETAPPROLE, SP_UNSETAPPROLE

Альтернативный метод предоставления разрешений в базе данных SQL Server 2005 — воспользоваться ролью приложения (application role). Отличием этого метода является то, что разрешения предоставляются не пользователю, а приложению, из которого пользователь подключается к базе данных.

Применение этого способа выглядит так:

q      пользователь от имени любого логина (которому должен соответствовать какой-нибудь объект пользователя в базе данных с правом CONNECT) подключается к серверу и делает нужную базу данных текущей;

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

q      после того, как необходимость в правах роли приложения закончилась, пользователь может опять переключиться на свою исходную учетную запись (и получить соответствующие ей права). Эта новая возможность SQL Server 2005 обеспечивается при помощи хранимой процедуры sp_unsetapprole.

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

q      гарантируется, что приложение будет обладать необходимыми правами в базе данных;

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

Однако у ролей приложений имеются также и недостатки. В первую очередь, они связаны с тем, что пароль роли приложения передается по сети открытым текстом (предусмотрена возможность использования функции ODBC Encrypt, но реальной защиты она не обеспечивает). Как правило, этот пароль можно извлечь и из двоичного кода клиентского приложения.

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

Создание роли приложения производится точно так же, как и создание обычных ролей — из контейнера Имя_базы_данных | Security | Roles | Application Roles. Главное отличие заключается в том, что назначить пользователей этой роли невозможно, зато ей нужно будет указать пароль, который будет использоваться при активизации. Команда Transact-SQL на создание роли приложения может выглядеть так:

CREATE APPLICATION ROLE AppRole1 WITH PASSWORD = 'password';

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

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

-- Объявляем переменную appCookie.

-- Она потребуется для возвращения к исходным правам

DECLARE @appCookie varbinary(8000);

-- Активизируем роль приложения

EXEC sp_setapprole 'AppRole1', 'password', 'none', TRUE, @appCookie OUTPUT;

-- Проверяем

SELECT USER_NAME();

-- Возвращаемся к исходным правам

EXEC sp_unsetapprole @appCookie;

-- Проверяем еще раз

SELECT USER_NAME();

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

Получить учебные материалы по этому курсу