29.Привілеї в базах даних.

Привілеї – це права користувача на проведення тих чи інших дій над певним об'єктом бази даних.

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

Кожному користувачеві реляційної бази даних присвоюється ідентифікатор – коротке ім'я, що однозначно визначає користувача для СУБД. Ці ідентифікатори є основою системи безпеки. Кожна інструкція SQL виконується в СУБД від імені конкретного користувача. Від його ідентифікатора залежить, чи буде дозволено або заборонено виконання інструкції.

У більшості комерційних реляційних СУБД код користувача створюється для кожного сеансу зв'язку з базою даних. В інтерактивному режимі сеанс починається, коли користувач запускає інтерактивну програму формування запитів, і продовжується до тих пір, поки користувач не вийде з програми.

Пароль служить для підтвердження того, що користувач дійсно має право працювати під введеним ідентифікатором. Ідентифікатори і паролі застосовуються в більшості реляційних СУБД, однак спосіб, яким користувач вводить свій ідентифікатор та пароль, змінюється залежно від СУБД. Наприклад, коли СУБД Oracle працює з інтерактивним SQL-модулем, який називається SQLPLUS, необхідно ввести ім'я користувача і відповідний пароль у командному рядку: SQLPLUS ідентифікатор/пароль.

У багатьох інших СУБД, включаючи Informix, у ролі ідентифікаторів користувачів використовуються імена користувачів, що реєструються в операційній системі мейнфрейму.

У великих виробничих базах даних часто є групи користувачів зі схожими завданнями. У межах кожної групи всі користувачі працюють з однаковими даними і повинні мати ідентичні привілеї. Згідно стандарту ANSI/ISO, з групами користувачів можна вчинити одним з двох способів:

1. Кожному члену групи можна присвоїти один і той же код користувача.

2. Усім членам групи можна присвоїти різні ідентифікатори користувача.

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

1. Привілей SELECT дозволяє отримувати дані з таблиці.

2. Привілей INSERT дозволяє додавати нові записи в таблицю.

3. Привілей DELETE дозволяє видаляти записи з таблиці.

4. Привілей UPDATE дозволяє модифікувати записи у таблиці або псевдотаблиці.

Коли користувач створюєте таблицю за допомогою інструкції CREATE TABLE, він стаєте її власником і отримуєте всі привілеї для цієї таблиці (SELECT, INSERT, DELETE, UPDATE та інші привілеї, які є в СУБД). Інші користувачі спочатку не мають ніяких привілеїв на щойно створену таблицю. Щоб вони отримали доступ до таблиці, власник повинен явно надати їм відповідні привілеї за допомогою інструкції GRANT [5].

У багатьох комерційних СУБД крім привілеїв SELECT, INSERT, DELETE і UPDATE, встановлених стандартом SQL, по відношенню до таблиць можуть бути видані додаткові привілеї. Наприклад, в Oracle та Informix передбачені привілеї ALTER та INDEX. Маючи привілей ALTER для якої-небудь таблиці, користувач може за допомогою інструкції ALTER TABLE модифікувати структуру даної таблиці; маючи привілей INDEX, користувач може за допомогою інструкції CREATE INDEX створити індекс для таблиці

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

У SQL дана проблема може бути вирішена за допомогою VIEW – псевдотаблиці.