Права доступу

Коли користувачі підключаються до SQL Server, дії, які вони можуть виконувати, визначаються правами (дозволами), виданими їх обліковому запису, групі або ролі, в якій вони полягають.

Права в SQL Server можна розділити на три категорії:

· права на доступ до об'єктів баз даних;

· права на виконання команд TRANSACT-SQL;

· неявні права (дозволи).

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

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

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

Необхідно використовувати всі можливості SQL Server, контролюючи права доступу не тільки на рівні таблиць, але і на рівні стовпців. Указуючи права доступу до конкретного стовпця, можна гнучкіше управляти системою безпеки.

Аналогічні рекомендації стосуються дозволів на виконання команд TRANSACT-SQL. Можна спроектувати базу даних таким чином, що виконувати конкретні дії — створення таблиць, уявлень, правил, резервних копій і так далі — будуть строго певні користувачі.

3.2. Права на доступ до об'єктів баз даних

Робота з даними і виконання процедур, що зберігаються, вимагає наявність класу доступу, званого правами на доступ до об'єктів баз даних. Під об'єктами маються на увазі таблиці, стовпці таблиць, уявлення, процедури, що зберігаються. Права на доступ до об'єктів баз даних контролюють можливість виконання користувачами, наприклад, команд SELECT, INSERT, UPDATE і DELETE для таблиць і уявлень. Таким чином, якщо користувачеві необхідно додати нові дані в таблицю, йому слід надати право INSERT (вставка записів в таблицю). Надання ж користувачеві права EXECUTE дозволяє йому виконання яких-небудь процедур, що зберігаються.

Для різних об'єктів застосовуються різні набори прав доступу до них:

· SELECT, INSERT, UPDATE, DELETE, REFERENCES – ці права можуть бути застосовані для таблиці або уявлення;

· SELECT і UPDATE — ці права можуть бути застосовані до конкретного стовпця таблиці або уявлення;

· EXECUTE— це право застосовується тільки до процедур, що зберігаються, і функцій. Нижче приводиться докладніший опис кожного з цих прав.

· INSERT. Це право дозволяє вставляти в таблицю або уявлення нові рядки. Як наслідок, право INSERT може бути видане тільки на рівні таблиці або уявлення і не може бути видано на рівні стовпця.

· UPDATE. Це право видається або на рівні таблиці, що дозволяє змінювати всі дані в таблиці, або на рівні окремого стовпця, що дозволяє змінювати дані тільки в межах конкретного стовпця.

· DELETE. Це право дозволяє видаляти рядки з таблиці або уявлення. Як і право INSERT, право DELETE може бути видане тільки на рівні таблиці або уявлення і не може бути видано на рівні стовпця.

· SELECT. Вирішує вибірку даних. Може видаватися як на рівні таблиці, так і на рівні окремого стовпця.

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

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

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

Потрібно використовувати команду GRANT для управління дозволами користувача на доступ до об'єктів бази даних:

GRANT (ALL [PRIVILEGES] | permiss1on[....n]} {[(column[,...n])] ON {table | view} | ON {table | view}[(column[,...n])] | ON {stored_procedure | extended_procedure} } TO security_account[,...n] [WITH GRANT OPTION] [AS {group | role}]

Призначення параметрів команди GRANT наступне:

· ALL — користувачеві надаються всі доступні дозволи. Цей параметр можуть використовувати тільки учасники ролі sysadmin;

· permission — список доступних дозволів, які надаються користувачеві (SELECT, INSERT, UPDATE, DELETE, EXECUTE). Можна одночасно надавати декілька дозволів, в цьому випадку їх потрібно розділяти комами;

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

· table, view, column, stored_procedure, extended_procedure — як дані параметри виступають імена об'єктів в поточній базі даних, для яких необхідно надати доступ;

· WITH GRANT OPTION— використання даного параметра дозволяє користувачеві, якому надаються права, призначати права на доступ до об'єкту іншим користувачам;

· AS {group | role) — цей необов'язковий параметр дозволяє вказати участь користувача в ролі, яка має можливість надавати права іншим користувачам.

Як приклад команди розглянемо наступну ситуацію. Необхідно надати права на використання команд INSERT і SELECT групі Engineer в таблиці Materials. При цьому потрібно, щоб надалі користувачі цієї групи могли самі надавати аналогічні права. Для цього слід виконати наступну команду:

GRANT SELECT. INSERT

ON Materials

TO Engineer

WITH GRANT OPTION

Згодом користувач Valentin, що є членом групи Engineer, може надати аналогічні права іншому користувачеві Liss:

GRANT SELECT, INSERT ON Materials ' TO Liss AS Engineer

В даному випадку необхідно підтвердити, на якій підставі Valentine надає права, тому застосовується параметр AS.

Потрібно обережно використовувати параметр WITH GRANT OPTION, оскільки при цьому втрачається контроль над наданням прав на доступ іншим користувачам. Краще всього обмежити коло людей, що мають можливість управляти призначенням прав.

Єдине право доступу, яке може бути надане для процедури, що зберігається, — це право на її виконання (EXECUTE). Природно, окрім цього власник процедури, що зберігається, може переглядати і змінювати її код.

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

Щоб надати право на виконання процедури, що зберігається, можна використовувати Enterprise Manager. Для цього потрібно вибрати в лівій панелі Enterprise Manager потрібну базу даних і відкрити в ній каталог Stored Procedures. У правій частині Enterprise Manager буде відображений список процедур, що зберігаються, вже створених в базі даних. Управління правами доступу можна здійснювати у вікні Object Properties (властивості об'єктів). Викликати це вікно можна або за допомогою кнопки Permissions (права) у вікні властивостей процедури, що зберігається, або вибравши в контекстному меню процедури, що зберігається, пункт АН Tasks > Manage Permissions (всі завдання > управління правами).

Щоб дозволити користувачеві виконувати процедуру, що зберігається, потрібно встановити напроти його імені галочку в полі ЕХЕС. Щоб заборонити доступ, потрібно поставити хрестик. Відсутність якого-небудь значка має на увазі неявне відхилення доступу. Детальніше про права доступу буде розказано далі в цьому розділі.

Управління правами доступу до функцій здійснюється аналогічно.

Інший спосіб управління правами доступу полягає в наданні прав конкретному користувачеві за допомогою вікна прав доступу користувача. Для цього слід у вікні Enterprise Manager вибрати необхідну базу даних, а потім каталог Users. Потім клацнути лівою кнопкою миші на вибраному користувачі. У вікні, що з'явилося, клацнути на кнопці Permissions (має рацію) і вказати необхідні права.

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