8.5 Роли приложений
Альтернативный метод предоставления разрешений в базе данных SQL Server 2014 — воспользоваться ролью приложения (application role). Отличием этого метода является то, что разрешения предоставляются не пользователю, а приложению, из которого пользователь подключается к базе данных.
Применение этого способа выглядит так:
пользователь от имени любого логина (которому должен соответствовать какой-нибудь объект пользователя в базе данных с правом CONNECT) подключается к серверу и делает нужную базу данных текущей;
затем пользователь выполняет хранимую процедуру sp_setapprole, чтобы активизировать указанную им роль приложения. При этом в базе данных он получает права этой роли приложения (и теряет свои текущие права);
после того, как необходимость в правах роли приложения закончилась, пользователь может опять переключиться на свою исходную учетную запись (и получить соответствующие ей права). Эта новая возможность SQL Server 2014 обеспечивается при помощи хранимой процедуры sp_unsetapprole.
Чаще всего такие роли используются в тиражируемых приложениях, когда задача вполне может обслуживаться не очень квалифицированным администратором. Преимущества такого подхода очевидны:
гарантируется, что приложение будет обладать необходимыми правами в базе данных;
администратору достаточно создать любой логин и любую учетную запись в базе данных, без необходимости настраивать требуемые разрешения.
Однако у ролей приложений имеются также и недостатки. В первую очередь, они связаны с тем, что пароль роли приложения передается по сети открытым текстом (предусмотрена возможность использования функции ODBC Encrypt, но реальной защиты она не обеспечивает). Как правило, этот пароль можно извлечь и из двоичного кода клиентского приложения.
Стоит ли использовать роли приложений? Все зависит от ситуации. Если приложение будет работать только на одном предприятии и обслуживаться квалифицированным администратором, то проще использовать обычные средства предоставления разрешений. Если же приложение будет устанавливаться на десятках и сотнях предприятий и за квалификацию администратора вы поручиться не можете, то применение роли приложения может быть очень удачным решением. Часто в качестве альтернативы разработчики требуют предоставлять всем пользователям права владельца базы данных, а иногда и системного администратора сервера, что, конечно, является намного большим злом.
Создание роли приложения производится точно так же, как и создание обычных ролей — из контейнера Имя_базы_данных | Security | Roles | Application Roles. Главное отличие заключается в том, что назначить пользователей этой роли невозможно, зато ей нужно будет указать пароль, который будет использоваться при активизации. Команда Transact-SQL на создание роли приложения может выглядеть так:
Достарыңызбен бөлісу: |