Компоненти структури безпеки

Фундаментом системи безпеки SQL Server 2000 є облікові записи (login), користувачі (user), ролі (role) і групи (group). Користувач, що підключається до SQL Server, повинен ідентифікувати себе, використовуючи обліковий запис. Після того, як клієнт успішно пройшов аутентифікацію, він дістає доступ до SQL Server. Для діставання доступу до будь-якої бази даних обліковий запис користувача (login) відображається в користувача даної бази даних (user). Об'єкт “користувач бази даних” застосовується для надання доступу до всіх об'єктів бази даних: таблицям, уявленням, процедурам, що зберігаються, і так далі. В користувача бази даних може відображатися:

· обліковий запис Windows;

· група Windows;

· обліковий запис SQL Server.

Подібне відображення облікового запису необхідне для кожної бази даних, доступ до якої хоче отримати користувач. Відображення зберігаються в системній таблиці sysusers, яка є в будь-якій базі даних. Такий підхід забезпечує високий ступінь безпеки, оберігаючи від надання користувачам, що дістали доступ до SQL Server, автоматичного доступу до всіх баз даних і їх об'єктів. Користувачі баз даних, у свою чергу, можуть об'єднуватися в групи і ролі для спрощення управління системою безпеки.

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

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

Користувачі

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

Ім'я користувача може використовуватися для надання доступу, як конкретній людині, так і цілій групі людей (залежно від типу облікового запису).

При створенні бази даних визначаються два стандартні користувачі: dbо і guest.

Якщо обліковий запис (login) не зв'язується явно з користувачем (user), останньому надається неявний доступ з використанням гостьового імені guest. Тобто всі облікові записи, що дістали доступ до SQL Server 2000, автоматично відображаються в користувачів guest у всіх базах даних. Якщо буде видалений з бази даних користувач guest, то облікові записи, що не мають явного відображення облікового запису в ім'я користувача, не зможуть дістати доступу до бази даних. Проте, guest не має автоматичного доступу до об'єктів. Власник об'єкту повинен сам вирішувати, дозволяти користувачеві guest цей доступ чи ні. Зазвичай користувачеві guest надається мінімальний доступ в режимі “тільки читання”.

Для забезпечення максимальної безпеки можна видалити користувача guest з будь-якої бази даних, окрім системних баз даних master і Tempdb. У першій з них guest використовується для виконання системних процедур, що зберігаються, звичайними користувачами, тоді як в другій дозволяє створювати будь-яким користувачам тимчасові об'єкти.

Власник бази даних (DataBase Owner, DBO) — спеціальний користувач, що володіє максимальними правами в базі даних. Будь-який член ролі sysadmin автоматично відображається в користувача dbo. Якщо користувач, що є членом ролі sys admin, створює який-небудь об'єкт, то власником цього об'єкту призначається не даний користувач, а dbo. Наприклад, якщо Liliya, член адміністративної групи, створює таблицю Таblеa, то повне ім'я таблиці буде не Liliya.ТаblеA, а dbo.ТаblеA. В той же час, якщо Liliya, не будучи учасником ролі сервера sysadmin, полягає в ролі власника бази даних db_owner, то ім'я таблиці буде LiIiуа.ТаblеA.

Користувача dbo не можна видалити.

Для пов'язання облікового запису (login) з певним ім'ям користувача (user) можна скористатися наступною процедурою, що зберігається:

sp_adduser [@loginame =] 'login' [,[@name_in_db =] 'user'] [.[@grpname =] 'role']

Нижче дається пояснення використовуваних в ній параметрів:

· login — ім'я облікового запису, який необхідно пов'язати з ім'ям користувача бази даних;

· user — ім'я користувача бази даних, з яким асоціюється даний обліковий запис (у базі даних заздалегідь не повинно існувати користувача з вказаним ім'ям);

· role — цей параметр визначає роль, в яку даний користувач буде включений (докладніше про ролі буде розказано пізніше). Процедура sp_grantdbaccess, що зберігається, дозволяє відобразити обліковий запис Windows NT в ім'я користувача:

sp_grantdbaccess [@loginame =] 'login' [,[@name_in_db =] 'user']

Параметри означають наступне:

· login — ім'я облікового запису користувача або групи користувачів Windows NT, яким необхідно надати доступ до бази даних. Ім'я повинне забезпечуватися посиланням на домен, в якому обліковий запис визначений. Вказаному обліковому запису не обов'язково повинен бути наданий персональний доступ до SQL Server. Цілком можливо, що з'єднання з сервером встановлюється унаслідок членства в групі Windows NT, яка має доступ до сервера;

· user — ім'я користувача бази даних, з яким асоціюється даний обліковий запис.

Користувач, який створює об'єкт в базі даних, наприклад таблицю, процедуру, що зберігається, або уявлення, стає власником об'єкту. Власник об'єкту (database object owner) має всі права доступу до створеного ним об'єкту. Щоб користувач міг створити об'єкт, власник бази даних (dbo) повинен надати користувачеві відповідні права. Повне ім'я створюваного об'єкту включає ім'я користувача, що створив його. Якщо користувач хоче звернутися до таблиці, використовуючи тільки її ім'я і не указуючи власника, SQL Server застосовує наступний алгоритм пошуку:

1. Шукається таблиця, створена користувачем, що виконує запит;

2. Якщо таблиця не знайдена, то шукається таблиця, створена власником бази даних (dbo).

Допустимо, користувач Liss намагається звернутися до таблиці Liliya.TableA, просто використовуючи ім'я TablеА. Оскільки таблиця, створена Liliya, не відповідає ні першому, ні другому критерію пошуку, то таблиця TableA знайдена не буде і користувач отримає повідомлення про помилку. Для діставання доступу до таблиці необхідно ввести ім'я, що включає власника об'єкту, тобто Liliya.TableA.

Власник об'єкту не має ніякого спеціального пароля або особливих прав доступу. Він неявно має повний доступ, але повинен явно надати доступ іншим користувачам.

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

sp_changeobjectowner [ @objname = ] 'object', [ (Pnewowner = ] 'owner'

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

2.3. Ролі сервера

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

У SQL Server реалізовано два види стандартних ролей: на рівні сервера і на рівні баз даних. При установці SQL Server 2000 створюється 9 фіксованих ролей сервера і 9 фіксованих ролей бази даних. Ці ролі не можна видалити, крім того, не можна модифікувати права їх доступу. Не можна надати користувачеві права, які мають фіксовані ролі сервера, іншим способом, окрім як включенням його в потрібну роль.

У попередніх версіях SQL Server для адміністрування сервера можна було використовувати тільки обліковий запис sa або його аналог. Інакше кажучи, можна було дати або всі права, або ніяких. Тепер в SQL Server ця проблема вирішена шляхом додавання ролей сервера (server role), які дозволяють надати операторам сервера тільки ті права, які адміністратор порахує можливим надати. Ролі сервера не мають відношення до адміністрування баз даних. Можна включити будь-який обліковий запис SQL Server (login) або обліковий запис Windows NT в будь-яку роль сервера.

Стандартні ролі сервера (fixed server role) і їх права приведені в табл. 1.

Таблиця 1

Вбудована роль сервера	Призначення
Sysadmin	Може виконувати будь-які дії в SQL Server
Serveradmin	Виконує конфігурацію і виключення сервера
Setupadmin	Управляє зв'язаними серверами і процедурами, що автоматично запускаються при старті SQL Server
Securityadmin	Управляє обліковими записами і правами на створення бази даних, також може читати журнал помилок
Processadmin	Управляє процесами, запущеними в SQL Server
Dbcreator	Може створювати і модифікувати бази даних
Diskadmin	Управляє файлами SQL Server
Bulkadmin(Bulk Insert administrators)	Ця роль не існувала в SQL Server 7.0. Члени ролі Bulkadmin можуть вставляти дані з використанням засобів масивного копіювання, не маючи безпосереднього доступу до таблиць

2.4. Ролі баз даних

Ролі бази даних (database role) дозволяють об'єднувати користувачів в одну адміністративну одиницю і працювати з нею як із звичайним користувачем. Можна призначити права доступу до об'єктів бази даних для конкретної ролі, при цьому всі члени цієї ролі автоматично наділяються однаковими правами. Замість того щоб надавати доступ кожному конкретному користувачеві, а згодом постійно стежити за змінами, можна просто включити користувача в потрібну роль. Якщо співробітник переходить в інший відділ, потрібно просто видалити його з однієї ролі і додати в іншу. Можна створити необхідну кількість ролей, які охоплювали б все різноманіття дій з базою даних. Пізніше, при зміні функцій членів однієї з ролей, досить змінити права доступу для цієї ролі, а не встановлювати нові права для кожного користувача.

У роль бази даних можна включати:

користувачів SQL Server;

ролі SQL Server

користувачів Windows NT;

групи Windows NT, яким заздалегідь наданий доступ до потрібної бази даних.

Засоби Enterprise Manager дозволяють додавати в роль бази даних тільки користувачів бази даних (user). Потрібно використовувати процедуру sp_addrolemember, що зберігається, щоб задіяти всі можливості SQL Server 2000:

sp_addrolemember [@ro1ename =] 'role', [@membername =] 'security_account'

Тут параметри означають наступне:

· role— назва ролі SQL Server в поточній базі даних;

· security_account — ім'я того об'єкту системи безпеки, який необхідно включити в роль. Як такий об'єкт можуть виступати як облікові записи SQL Server, так і користувачі і групи Windows NT, яким наданий доступ до сервера баз даних.

При створенні бази даних для неї визначаються стандартні ролі бази даних, які, так само як і стандартні ролі сервера, не можуть бути змінені або видалені. Стандартні ролі баз даних (fixed database role) і їх права приведені в табл. 2.

Таблиця 2

Вбудована роль баз даних	Призначення
db__owner	Має всі права в базі даних
db_accessadmin	Може додавати або видаляти користувачів
db_securityadmin	Управляє всіма дозволами, об'єктами, ролями і членами ролей
db_ddladmin	Може виконувати будь-які команди DDL, окрім GRANT, DENY і REVOKE
db_backupoperator	Може виконувати команди DBCC, CHECKPOINT і BACKUP
db_datareader	Може проглядати будь-які дані в будь-якій таблиці БД
db_datawriter	Може модифікувати будь-які дані в будь-якій таблиці БД
db_denydatareader	Забороняється проглядати дані в будь-якій таблиці
dbjjenydatawriter	Забороняється модифікувати дані в будь-якій таблиці

Окрім вказаних вище ролей існує ще одна — public. Ця роль має спеціальне призначення, оскільки її членами є всі користувачі, що мають доступ до бази даних. Не можна явно встановити членів цієї ролі, тому що всі користувачі і так автоматично є її членами. Цю роль слід використовувати для надання мінімального доступу користувачам, для яких права доступу до об'єктів не визначені явно. Якщо в базі даних дозволений користувач guest, то встановлений для publiс доступ матимуть всі користувачі, що дістали доступ до SQL Server. Роль public є у всіх базах даних, включаючи системні бази даних master, tempdb, msdb, model, і не може бути видалена.

Групи Windows NT можуть бути використані аналогічно ролям SQL Server. Можна створити один обліковий запис (login) для групи Windows NT і включати відповідних користувачів замість ролі в групу Windows NT. Вибір методу адміністрування залежить від вас.

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. Для цього допустимі обидва режими аутентифікації користувачів.

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

Дата добавления: 2014-01-05