2.5. Ролі програми

Система безпеки SQL Server реалізована на найнижчому рівні — рівні бази даних. Це якнайкращий, найбільш дієвий метод контролю діяльності користувачів незалежно від програм, використовуваних ними для підключення до SQL Server. Проте, зустрічаються ситуації, коли необхідний постійний набір має право для доступу до бази даних із програмою. Особливо це стосується роботи з великими базами даних, що мають безліч складних взаємозв'язаних таблиць з тисячами або мільйонами записів. Найчастіше для роботи з такими базами даних створюються спеціальні програми.

Крім того, може знадобитися, щоб користувачі діставали доступ до бази даних тільки за допомогою певної програми, не даючи можливості безпосередньо звертатися до даних. Наприклад, мобільні користувачі можуть використовувати спеціальну клієнтську програму, за допомогою якої вони оперують даними, встановлюючи зв'язок з сервером через незахищені глобальні комунікації.

SQL Server вирішує перераховані проблеми шляхом використання ролі програми, створюваної на рівні бази даних. Відмінності між стандартними ролями і роллю застосування фундаментальні. Роль застосування не має членів. Користувачі SQL Server або Windows NT не можуть бути додані в цю роль. Роль активізується, коли програма встановлює з'єднання. Користувач, що працює в цей час із програмою, не є членом ролі — тільки його програма використовує встановлене з'єднання.

Перед використанням ролі програми необхідно спочатку створити її. При створенні ролі потрібно вказати її ім'я і пароль для доступу. Створення ролі засобами TRANSACT-SQL виконується за допомогою наступної системної процедури, що зберігається:

sp_addappro1e [ @rolename = ] 'role' . [ (^password = ] 'password'

Перший параметр визначає ім'я, яке матиме створювана роль програми, другий — пароль, який використовуватиметься для активізації ролі.

Створення ролі програми засобами Enterprise Manager виконується за допомогою вікна Database Role Properties — New Role (властивості ролей баз даних — нова роль), яке також використовується для створення звичайних призначених для користувача ролей. Щоб створювана роль була роллю програми, досить встановити перемикач Application role (роль програми) і ввести пароль. Робота з вказаним вікном буде розглянута в одному з наступних розділів цього документу.

Програма може бути спроектоване так, щоб користувач, що працює з ним, повинен був вводити пароль для активізації ролі програми. Проте найчастіше пароль вводиться самою програмою непомітно для користувача. Додатково, для забезпечення максимальної безпеки, пароль може бути зашифрований перед своєю відправкою до SQL Server по мережі.

В процесі підключення програма повинна активізувати роль, передавши пароль, що асоціюється з даною роллю. Для цього програма використовує наступну процедуру, що зберігається.

sp_setapprole [(Еготепате =] 'role' [^password =] (Encrypt N 'password'} | 'password' [.[^encrypt =] 'encrypt_style']

Докладніший огляд параметрів:

• role— ім'я ролі програми, яке визначене в базі даних;

• password— пароль, який програма повинна передати серверу для активізації ролі програми;

• encrypt_style — вживана схема шифрування паролів. Даний параметр може мати два значення: none (шифрування не застосовується) і odbc (шифрування із застосуванням функції ODBC encrypt).

Коли роль програми активізується, всі права доступу, встановлені в межах сеансу для користувача, груп або ролей, втрачаються до закінчення роботи програми. З'єднання отримує права, встановлені для ролі програми в базі даних, в якій ця роль існує. Те, що тимчасове “забуває” прав доступу, привласнених користувачеві, що встановив з'єднання, потрібне для усунення конфліктів доступу. Інакше, якщо користувачеві заборонено читання даних, а програмі необхідно рахувати дані, доступ був би відхилений, оскільки заборона доступу має переваги над наданням доступу.

Оскільки роль програми має права тільки в тій базі даних, в якій вона створена, а всі дозволи для облікових записів, груп і ролей, до яких належить користувач, втрачаються, то доступ до інших баз даних можливий тільки під гостьовим ім'ям guest. Отже, якщо ім'я guest в базі даних не існує, то з'єднання не зможе дістати доступ даним. Якщо ж ім'я guest не видалене з бази даних, з'єднання зможе дістати доступ до об'єктів бази тільки в тому випадку, якщо дозволи явно видані для користувача guest. Перед встановленням з'єднання з використанням ролі програми користувачеві спочатку потрібно дістати доступ до SQL Server. Для цього допустимі обидва режими аутентифікації користувачів.

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