К.т.н. Мелешко О.О.; студенти Морозов Р.С., Уваров Ю.А.

Національний авіаційний університет, Київ, Україна

Огляд засобів гарантування безпеки в базах даних. Способи розмежування доступу в СУБД Oracle та Informix

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

Вступ. При зберіганні даних в будь-якій системі управління базами даних (СУБД) одним з головних завдань користувача є забезпечення безпеки цих даних. Проблема безпеки особливо гостро стоїть в реляційних базах даних, оскільки інтерактивний SQL дозволяє легко отримати до них доступ.

Постановка проблеми. Як сказано в [7] очевидним завданням, яке треба вирішувати при багатокористувацькому доступі до даних, – це розмежування доступу. Вимоги, що висуваються до системи безпеки в типовій реляційній базі даних, досить різноманітні. Наприклад, доступ до даних окремої таблиці повинен бути дозволений одним користувачам і заборонений іншим або одним користувачам повинно бути дозволено змінювати дані в деякій таблиці, а іншим – здійснювати тільки вибірку даних з неї, також до низки таблиць доступ повинен здійснюватися за окремими стовпцями і певним користувачам повинно бути заборонено звернення до деякої таблиці за допомогою інтерактивного SQL, але дозволено користуватися прикладними програмами, що змінюють цю таблицю.

Саме тому метою нашої статті став огляд можливих схем забезпечення безпеки в реляційних базах даних.

Принципи захисту даних, що застосовуються в SQL. За реалізацію системи безпеки відповідає СУБД. Мова SQL є фундаментом системи безпеки реляційної СУБД: вимоги, що пред'являються до системи захисту інформації в базі даних, формулюються за допомогою інструкцій SQL [8]. З захистом даних в SQL пов'язані три основні концепції:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Права на рівні бази даних в СУБД Oracle та Informix. Згідно з [6] та [7] є три категорії прав на рівні бази даних. Це право на адміністрування (DBA), право на управління ресурсами (RESOURCE), право на доступ (CONNECT). Деякі користувачі можуть взагалі не мати будь-яких прав, пов'язаних з конкретною базою даних.

1. Користувач, який має право на доступ (CONNECT), має можливість отримувати і модифікувати дані в базі. Він може модифікувати ті об'єкти, якими володіє [6]. Будь-який користувач, що має право доступу, може робити наступне: виконувати оператори SELECT, INSERT, DELETE, UPDATE, якщо це йому дозволено на рівні об'єкта (таблиці) або створювати нову псевдотаблицю (VIEW), якщо він має право на вибірку за необхідними таблицями, також створювати синоніми і тимчасові таблиці та індекси за тимчасовими таблицями, навіть змінювати або видаляти ті об'єкти, якими володіє та керувати правами інших користувачів на об'єкти, якими володіє [7].

2. Користувач, який має право на управління ресурсами (RESOURCE), на додаток до тих прав, які мають користувачі з правом на доступ, може створювати нові об'єкти. Наприклад, такий користувач може створити таблицю, тригер, індекс і т.д. Як тільки він створює якийсь об'єкт, він стає його власником [4].

3. Право на адміністрування бази даних (DBA) на додаток до тих прав, які мають користувачі з правом на управління ресурсами, має наступні можливості: видаляти базу даних та будь-які об'єкти незалежно від того, хто ними володіє; роздавати і змінювати права доступу інших користувачів до бази даних в цілому і до окремих об'єктів [7].

Якщо користувач має право на базу даних, це не означає автоматично, що він має можливість отримувати будь-яку інформацію з будь-якої таблиці. Наявність права на рівні бази даних означає можливість підключитися до бази даних. Всі подальші дії з вмістом бази даних проводяться відповідно до прав на рівні об'єктів (таблиць і процедур) [3]. Для процедур існує єдиний тип прав доступу – виконувати її. Якщо база даних знаходиться не в режимі ANSI, то при створенні процедури, що зберігається, всі користувачі автоматично отримують право на її виконання. Якщо ж база даних знаходиться в режимі ANSI, то треба явно вказати, які користувачі мають право її виконувати. Право на виконання називається EXECUTE. Передача та відбір цього права аналогічні передачі і відбору прав на рівні таблиці [1].

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

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

Література

1.     Informix. Энциклопедия пользователя, Джон Мак-Hилли и дp. – Киев: Изд-во ДиаСофт, 1998. – 800 с.

2.     INFORMIX. Учебное пособие, П.А.Петин, Ю.А.Шестаков, В.В.Шульженко, – Киев: ANTEC, 1996.

3.     Oracle 10g. Настольная книга администратора баз данных, Кевин Луни, Боб Брила, – М:. Издательство "Лори", 2008. – 752 с.

4.     Oracle для профессионалов, Пер. с англ./Том Кайт, – СПб.: ООО "ДиаСофтЮП", 2003. – 672 с.

5.     SQL: Полное руководство, Джеймс Р. Грофф, Пол Н. Вайнберг, – 2-е изд., перераб. и доп. – К.: Издатель­ская группа BHV, 2001. – 816 с, ил.

6.     Администрирование Oracle 9i, О. А. Головаш, С. В. Глушаков, Ю. В. Третьяков,  – Харьков: Фолио, 2003. – 695 с. – (Учебный курс).

7.     Введение в СУБД Informix, А.Ю.Грачев, – Москва: "Диалог-МИФИ", 2000. – 272 стр.

8.     Грофф Д.Р., Вайнберг П.Н. SQL: Полное руководство. – Киев: BMV, "Ирина", 2001. – 816 с.

9.     Стасышин В.М. Доступ к базам данных: Учеб. пособие. – Новосибирск, НГТУ, 2001. – 94 c.