4.3.5 Роли приложений

Роль приложения (application role) используется для предоставления разрешений не пользователю, а приложению, из которого пользователь подключается к этому приложению.

Принцип работы роли приложения:

1. Создать роль приложения и присвоить ей разрешения

2. Пользователи открывают приложение и регистрируются в SQL Server

3. Для включения роли приложение выполняет хранимую процедуру sp_setapprole (которая добавляется в приложение на этапе разработки).

4. После включения роли приложения SQL Server интерпретирует пользователей как приложение, предоставляя им разрешения роли приложения.

5. Для отключения роли приложения используется хранимая процедура sp_unsetapprole.

Преимущества использования роли приложения:

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

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

Недостаток роли приложения:

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

Создание роли приложения производится:

• из контейнера Имя_Базы_Данных  Security  Roles  Application Roles. Этой роли невозможно назначить пользователей, зато ей потребуется указать пароль, который будет использоваться при активизации.

• С помощью команды Transact-SQL CREATE APPLICATION ROLE 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.

4.3.6 Управление схемами базы данных

Каждая БД после создания имеет одну схему, которая называется dbo, являющуюся схемой по умолчанию при создании объектов БД. Пользователю можно назначить схему по умолчанию. В эту схему SQL Server будет по умолчанию помещать объекты, которые создает пользователь. Кроме того, искать объекты, к которым обращается пользователь (например, в случае запроса вида SELECT * FROM Table1), SQL Server также будет в первую очередь в его схеме по умолчанию.

Для создания схемы можно воспользоваться:

• Графическим интерфейсом Management Studio - контейнер Имя_Базы_ДанныхSecuritySchemas

• Командой CREATE SCHEMA CREATE SCHEMA SchemaName

При создании схемы можно явно указать, кто будет являться владельцем схемы (owner_name), а также создать в схеме таблицу или представление при помощи команд CREATE TABLE или CREATE VIEW. Либо определить разрешения на объекты схемы для пользователей или ролей, используя конструкции GRANT\REVOKE\DENY.

Изменение и удаление схемы

• Графический интерфейс Management Studio - контейнер Имя_Базы_ДанныхSecuritySchemas

• Команда ALTER SCHEMA – изменение схемы

• Команда DROP SCHEMA - удаление схемы

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