Захист баз даних
Роботу підготував Милованов Сергій
ГОУ СПО Жірновскій нафтовий технікум
2005
Вступ
Сучасне життя немислима без ефективного
управління. Важливою категорією є системи обробки інформації, від яких
багато в чому залежить ефективність роботи будь-якого підприємства чи установи. Така
система повинна:
забезпечувати отримання загальних та/або деталізованих
звітів за підсумками роботи;
дозволяти легко визначати тенденції зміни
найважливіших показників;
забезпечувати отримання інформації, критичною по
часу, без істотних затримок;
виконувати точний і повний аналіз даних.
Сучасні СУБД в основному є додатками
Windows, так як дана середу дозволяє більш повно використовувати можливості
персональної ЕОМ, ніж середу DOS. Зниження вартості високопродуктивних
ПК обумовив не тільки широкий перехід до середовищі Windows, де розробник
програмного забезпечення може меншою мірою піклуватися про розподіл
ресурсів, а також зробив програмне забезпечення ПК в цілому і СУБД зокрема
менш критичними до апаратних ресурсів ЕОМ. Серед найбільш яскравих представників
систем управління базами даних можна відзначити: Lotus Approach, Microsoft
Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft
Visual Basic, а також баз даних Microsoft SQL Server і Oracle, що використовуються в
додатках, побудованих за технологією "клієнт-сервер».
Проблема забезпечення захисту інформації є однією
з найважливіших при побудові надійної інформаційної структури установи на базі
ЕОМ. Ця проблема охоплює як фізичний захист даних і системних програм,
так і захист від несанкціонованого доступу до даних, що передаються по лініях зв'язку
і перебувають на накопичувачах, що є результатом діяльності як
сторонніх осіб, так і спеціальних програм-вірусів. Таким чином, в поняття
захисту даних включаються питання збереження цілісності даних і управління доступу
до даних (санкціонування).
Технологічний аспект цього питання пов'язаний з
різними видами обмежень, які підтримуються структурою СУБД і повинні
бути доступні користувачу. До них відносяться:
-обмеження поновлення певних атрибутів з метою
збереження необхідних пропорцій між їхніми старими і новими значеннями;
-обмеження, які потребують збереження значень поля
показника в певному діапазоні;
-обмеження, пов'язані із заданими функціональними
залежностями.
Зазвичай в СУБД в мову маніпулювання даними вже
закладаються необхідні компоненти реалізації зазначених обмежень. Проблема
забезпечення санкціонуванні використання даних є неоднозначною, але
в основному охоплює питання захисту даних від небажаної модифікації або
знищення, а також від несанкціонованого їх читання.
У даній роботі я зачіпаю основні аспекти захисту
баз даних, їх реалізацію на прикладах конкретних СУБД, а так само юридичну
сторону даного питання.
Захист інформації
Поняття захисту інформації
Захист інформації - комплекс заходів, спрямованих
на забезпечення найважливіших аспектів інформаційної безпеки (цілісності,
доступності і, якщо потрібно, конфіденційності інформації та ресурсів,
що використовуються для введення, зберігання, обробки і передачі даних) [1].
Система називається безпечною, якщо вона, використовуючи
відповідні апаратні й програмні засоби, керує доступом до
інформації так, що тільки належним чином авторизовані особи або ж
що діють від їх імені процеси отримують право читати, писати, створювати та
видаляти інформацію.
Очевидно, що абсолютно безпечних систем немає, і тут
мова йде про надійну систему у розумінні «система, якій можна довіряти» (як
можна довіряти людині). Система вважається надійною, якщо вона з використанням
достатніх апаратних і програмних засобів забезпечує одночасну обробку
інформації різного ступеня секретності групою користувачів без порушення прав
доступу.
Основними критеріями оцінки надійності є:
політика безпеки і гарантованість.
Політика безпеки, будучи активним компонентом
захисту (включає в себе аналіз можливих загроз і вибір відповідних заходів
протидії), відображає той набір законів, правил і норм поведінки,
яким користується конкретна організація при обробці, захисту і
розповсюдженні інформації.
Вибір конкретних механізмів забезпечення безпеки
системи здійснюється відповідно до сформульованої політикою безпеки.
гарантованість, будучи пасивним елементом захисту,
відображає міру довіри, який може чинити архітектурі і реалізації
системи (іншими словами, показує, наскільки коректно вибрані механізми,
що забезпечують безпеку системи).
У надійної системи повинні реєструватися всі
відбуваються події, що стосуються безпеки (повинен використовуватися механізм
підзвітності протоколювання, що доповнює аналізом запомненной інформації,
тобто аудитом).
При оцінці ступеня гарантоване, з якою систему
можна вважати надійною, центральне місце займає достовірна (надійна)
обчислювальна база. Достовірна обчислювальна база (ДВІ) являє собою
повну сукупність захисних механізмів комп'ютерної системи, яка
використовується для перетворення в життя відповідної політики безпеки.
Надійність ДВБ залежить виключно від її реалізації
і коректності введених даних (наприклад, даних про благонадійність
користувачів, які визначаються адміністрацією).
Кордон ДВБ утворює периметр безпеки. Компоненти
ДВБ, що знаходяться всередині цієї межі, повинні бути надійними (отже, для
оцінки надійності комп'ютерної системи досить розглянути тільки її ДВБ).
Від компонентів, що перебувають поза периметра безпеки, взагалі кажучи, не
потрібно надійності. Однак це не повинно впливати на безпеку системи. Так
як зараз широко застосовуються розподілені системи обробки даних, то під «периметром
безпеки "розуміється межа володінь певної організації, в
підпорядкуванні якої знаходиться ця система. Тоді за аналогією те, що знаходиться
всередині цього кордону, вважається надійним. За допомогою шлюзовий системи, яка
здатна протистояти потенційно ненадійною, а може бути навіть і
ворожому оточенню, здійснюється зв'язок через цей кордон.
Контроль допустимості виконання суб'єктами
певних операцій над об'єктами, тобто функції моніторингу, виконується
достовірної обчислювальної базою. При кожному зверненні користувача до
програмами чи даними монітор перевіряє допустимість даного звернення
(узгодженість дії конкретного користувача зі списком дозволених для
нього дій). Реалізація монітора звернень називається ядром безпеки, на
базі якої будуються всі захисні механізми системи. Ядро безпеки повинен
гарантувати власну незмінність.
Захист ПК від несанкціонованого доступу
Як показує практика, несанкціонований доступ
(НСД) представляє одну з найбільш серйозних загроз для зловмисного
заволодіння захищається інформацією в сучасних АСОД. Як не здасться
дивним, але для ПК небезпека даної загрози у порівнянні з великими ЕОМ
підвищується, чому сприяють такі об'єктивно існуючі обставини:
1) переважна частина ПК розташовується безпосередньо
в робочих кімнатах фахівців, що створює сприятливі умови для доступу
до них сторонніх осіб;
2) багато ПК служать колективним засобом обробки
інформації, що знеособлює відповідальність, у тому числі і за захист
інформації;
3) сучасні ПК оснащені незнімними накопичувачами на
ЖМД дуже великої місткості, причому інформація на них зберігається навіть у
знеструмленому стані;
4) накопичувачі на ГМД виробляються в такому масовій кількості,
що вже використовуються для поширення інформації так само, як і паперові
носії;
5) спочатку ПК створювалися саме як персональне
засіб автоматизації обробки інформації, а тому й не оснащувалися
спеціально засобами захисту від несанкціонованого доступу.
У силу сказаного ті користувачі, які бажають
зберегти конфіденційність своєї інформації, повинні особливо подбати про
оснащенні використовуваної ПК високоефективними засобами захисту від несанкціонованого доступу.
Основні механізми захисту ПК від НСД можуть бути представлені
наступним переліком:
1) фізичний захист ПК і носіїв інформації;
2) впізнання (аутентифікація) користувачів і використовуваних
компонентів обробки інформації;
3) розмежування доступу до елементів, що захищається інформації;
4) криптографічне закриття захищається інформації,
що зберігається на носіях (архівація даних);
5) криптографічне закриття захищається інформації в
процесі безпосередньої її обробки;
6) реєстрація всіх звернень до захищається інформації.
Нижче викладаються загальний зміст і способи використання перерахованих
механізмів.
Захист інформації в базах даних
У сучасних СУБД підтримується один з двох
найбільш загальних підходів до питання забезпечення безпеки даних:
вибірковий підхід і обов'язковий підхід. В обох підходах одиницею даних
або «об'єктом даних», для яких повинна бути створена система безпеки,
може бути як вся база даних цілком, так і будь-який об'єкт всередині бази даних.
Ці два підходи відрізняються наступними властивостями:
У разі виборчого управління деякий
користувач володіє різними правами (привілеями чи повноваженнями) при
роботі з даними об'єктами. Різні користувачі можуть володіти різними правами
доступу до одного і того ж об'єкту. Виборчі права характеризуються
значною гнучкістю.
У разі виборчого управління, навпаки, кожному
об'єкту даних присвоюється певний класифікаційний рівень, а кожен
користувач володіє деяким рівнем допуску. При такому підході доступом до
визначеного об'єкта даних мають тільки користувачі з відповідним
рівнем допуску.
Для реалізації виборчого принципу передбачені
наступні методи. У базу даних вводиться новий тип об'єктів БД - це
користувачі. Кожному користувачеві в БД присвоюється унікальний ідентифікатор.
Для додаткового захисту кожен користувач крім унікального ідентифікатора
забезпечується унікальним паролем, причому якщо ідентифікатори користувачів у
системі доступні системного адміністратора, то паролі користувачів зберігаються
найчастіше в спеціальному кодованому вигляді і відомі тільки самим
користувачам.
Користувачі можуть бути об'єднані в спеціальні
групи користувачів. Один користувач може входити в кілька груп. У
стандарті вводиться поняття групи PUBLIC, для якої повинен бути визначений
мінімальний стандартний набір прав. За умовчанням передбачається, що кожен
знову створюється користувач, якщо спеціально не вказано інше, відноситься до
групі PUBLIC.
Привілеї або повноваження користувачів або груп --
це набір дій (операцій), які вони можуть виконувати над об'єктами БД.
В останніх версіях ряду комерційних СУБД з'явилося
поняття «ролі». Роль - це пойменований набір повноважень. Існує ряд
стандартних ролей, які визначені в момент встановлення сервера баз даних. І
є можливість створювати нові ролі, групуючи в них довільні
повноваження. Введення ролей дозволяє спростити управління привілеями
користувачів, структурувати цей процес. Крім того, введення ролей не
пов'язане з конкретними користувачами, тому ролі можуть бути визначені й
сконфігуровані до того, як визначені користувачі системи.
Користувачеві може бути призначена один або кілька
ролей.
Об'єктами БД, які підлягають захисту, є всі
об'єкти, що зберігаються в БД: таблиці, представлення, збережені процедури і тригери.
Для кожного типу об'єктів є свої дії, тому для кожного типу об'єктів
можуть бути визначені різні права доступу.
На самому елементарному рівні концепції забезпечення
безпеки баз даних виключно прості. Необхідно підтримувати два
фундаментальних принципи: перевірку повноважень і перевірку автентичності
(аутентифікацію).
Перевірка повноважень заснована на тому, що кожному
користувачеві або процесу інформаційної системи відповідає набір дій,
які він може виконувати по відношенню до певних об'єктів. Перевірка
автентичності означає достовірне підтвердження того, що користувач або
процес, який намагається виконати санкціонована дія, дійсно той, за
кого він себе видає.
Система призначення повноважень має до певної міри
ієрархічний характер. Найвищими правами і повноваженнями володіє
системний адміністратор або адміністратор сервера БД. Традиційно тільки цей
тип користувачів може створювати інших користувачів і наділяти їх
певними повноваженнями.
СУБД в своїх системних каталогах зберігає як опис
самих користувачів, так і опис їх привілеїв по відношенню до всіх
об'єктам.
Далі схема надання повноважень будується за
наступним принципом. Кожен об'єкт в БД має власника - користувача, який
створив цей об'єкт. Власник об'єкта володіє всіма правами-повноваженнями на
даний об'єкт, до того ж він має право надавати іншим користувачам
повноваження по роботі з даним об'єктом або забирати у користувачів раніше
надані повноваження.
У ряді СУБД вводиться наступний рівень ієрархії
користувачів - це адміністратор БД. У цих СУБД один сервер може керувати
безліччю СУБД (наприклад, MS SQL Server, Sybase). В СУБД Oracle застосовується
однобазовая архітектура, тому там вводиться поняття подсхеми - частини загальної
схеми БД і вводиться користувач, що має доступ до подсхеме. У стандарті SQL не
визначена команда створення користувача, але практично у всіх комерційних
СУБД створити користувача можна не тільки в інтерактивному режимі, а й
програмно з використанням спеціальних збережених процедур. Однак для
виконання цієї операції користувач повинен мати право на запуск
відповідної системної процедури.
У стандарті SQL визначені два оператори: GRANT і
REVOKE відповідно надання та скасування привілеїв.
Оператор надання привілеїв має наступний
формат:
GRANT (<список дій | ALL PRIVILEGES)
ON <імя_об'екта> ТО (<ім'я користувача>] PUBLIC
) [WITH GRANT OPTION]
Тут список дій визначає набір дій з
общедопустімого переліку дій над об'єктом даного типу.
Параметр ALL PRIVILEGES вказує, що дозволені всі
дії з допустимих для об'єктів даного типу.
<імя_обьекта> - задає ім'я конкретного об'єкта:
таблиці, представлення, збереженої процедури, тригера.
<ім'я користувача> або PUBLIC визначає, кому
надаються дані привілеї.
Параметр WITH GRANT OPTION є необов'язковим і
визначає режим, при якому передаються не тільки права на зазначені дії,
але й право передавати ці права іншим користувачам. Передавати права в цьому
випадку користувач може тільки в рамках дозволених йому дій.
Розглянемо приклад, нехай у нас існують три
користувача з абсолютно унікальними іменами userl, user2 і user3. Всі вони
є користувачами однієї БД.
User1 створив об'єкт Таb1, він є власником цього
об'єкта і може передати права на роботу з цим об'єктом для інших користувачів.
Припустимо, що користувач user2 є оператором, який повинен вводити
дані в Таb1 (наприклад, таблицю нових замовлень), а користувач user 3 є
великим начальником (наприклад, менеджером відділу), який повинен регулярно
переглядати введені дані.
Для об'єкта типу таблиця повним переліком допустимим
дій є набір з чотирьох операцій: SELECT, INSERT, DELETE, UPDATE.
При цьому операція оновлення може бути обмежена кількома стовпчиками.
Загальний формат оператора призначення привілеїв для
об'єкту типу таблиця буде мати наступний синтаксис:
GRANT
([SELECT] [. INSERT] [, DELETED [. UPDATE (<список стовпців>)]) ON <ім'я таблиці>
ТО (<ім'я користувача> PUBLIC)
[WITH GRANT OPTION
]
Тоді резонно буде виконати наступні призначення:
GRANT INSERT
ON Tab1
ТО user2 GRANT SELECT
ON Tab1
TO user3
Ці призначення означають, що користувач user2 має
право тільки вводити нові рядки в ставлення Таb1> а користувач user3
має право переглядати всі рядкив таблиці Таb1.
При призначення прав доступу на операцію модифікації
можна уточнити, значення яких стовпців може змінювати користувач. Припустимо,
що менеджер відділу має право змінювати ціну на надані послуги.
Припустимо, що ціна задається в стовпці COST таблиці Таb1. Тоді операція
призначення привілеїв користувачеві user3 може змінитися і виглядати наступним
так:
GRANT SELECT. UPDATE
(COST) ON Tab1 TO user3
Якщо наш користувач user1 припускає, що
користувач user4 може заміщати його у разі його відсутності, то він може
надати цьому користувачеві всі права по роботі зі створеною таблицею Таb1.
GRANT ALL
PRIVILEGES
ON Tab1
TO user4 WITH GRANT
OPTION
У цьому випадку користувач user4 може сам призначати
привілеї для роботи з таблицею Таb1 під час відсутності власника об'єкта
користувача user1. Тому у випадку появи нового оператора користувача
user5 він може призначити йому права на введення нових рядків у таблицю командою
GRANT INSERT
ON Tab1 TO user5
Якщо при передачі повноважень набір операцій над
об'єктом обмежений, то користувач, якому передані ці повноваження, може
передати іншому користувачеві тільки ті повноваження, які є у нього, або
частина цих повноважень. Тому якщо користувачеві user4 були делеговані
такі повноваження:
GRANT SELECT. UPDATE. DELETE
ON Tab1
TO user4 WITH GRANT
OPTION,
то користувач user4 не зможе передати повноваження на
введення даних користувачу user5, тому що ця операція не входить у список
дозволених для нього самого.
Крім безпосереднього призначення прав по роботі з
таблицями ефективним методом захисту даних може бути створення уявлень,
які будуть містити тільки необхідні стовпці для роботи конкретної
користувача та надання прав на роботу з даним поданням
користувачеві.
Так як уявлення можуть відповідати підсумковим
запитам, то для цих уявлень неприпустимі операції зміни, і,
отже, для таких уявлень набір допустимих дій обмежується
операцією SELECT. Якщо ж подання відповідають вибірці з базової
таблиці, то для такого подання допустимими будуть всі 4 операції: SELECT,
INSERT, UPDATE і DELETE.
Для скасування раніше призначених привілеїв в стандарті
SQL визначений оператор REVOKE. Оператор скасування привілеїв має наступний
синтаксис:
REVOKE (<список операцій | ALL PRIVILEGES) ON
<імя_об'екта>
FROM (<список користувачів | PUBLIC) (CASCADE | RESTRICT
)
Параметри CASCADE або RESTRICT визначають, яким
чином повинна проводитися скасування привілеїв. Параметр CASCADE скасовує
привілеї не тільки користувача, який безпосередньо згадувався в
операторі GRANT при наданні йому привілеїв, але й усім користувачам,
яким цей користувач присвоїв привілеї, скориставшись параметром WITH
GRANT OPTION.
Наприклад, при використанні операції:
REVOKE ALL
PRIVILEGES - ON Tab1 TO user4 CASCADE
будуть скасовані привілеї і користувача user5,
якому користувач user4 встиг присвоїти привілеї.
Параметр RESTRICKT обмежує скасування привілеїв
тільки користувачеві, безпосередньо згаданому в операторі REVOKE. Але при
наявності делегованих привілеїв цей оператор не буде виконано. Так, наприклад, операція:
REVOKE ALL
PRIVILEGES ON Tab1 TO user4 RESTRICT
не буде виконана, тому що користувач user4
передав частину своїх повноважень користувачу user5.
За допомогою оператора REVOKE можна відібрати всі або
тільки деякі з раніше присвоєних привілеїв по роботі з конкретним
об'єктом. При цьому з опису синтаксису оператора скасування привілеїв видно,
що можна відібрати привілеї одним оператором відразу у декількох користувачів
або у цілої групи PUBLIC.
Тому коректним буде наступне використання
оператора REVOKE:
REVOKE INSERT ON
Tab! TO user2.user4 CASCADE
При роботі з іншими об'єктами змінюється список
операцій, які використовуються в операторах GRANT і REVOKE.
За замовчуванням дію, відповідне запуску
(виконання) збереженої процедури, призначається всім членам групи PUBLIC.
Якщо ви хочете змінити цю умову, то після створення
збереженої процедури необхідно записати оператор REVOKE.
REVOKE EXECUTE ON COUNT_EX TO PUBLIC CASCADE І тепер
ми можемо призначити нові права користувачеві user4.
GRANT EXECUTE ON
COUNT_EX TO user4
Системний адміністратор може дозволити деякого
користувачеві створювати і змінювати таблиці в деякій БД. Тоді він може
записати оператор надання прав наступним чином:
GRANT CREATE TABLE. ALTER TABLE, DROP TABLE ON
OB_LIB TO user1
У цьому випадку користувач user1 може створювати,
змінювати або видаляти таблиці в БД DB_LIB, проте він не може дозволити
створювати або змінювати таблиці в цій БД іншим користувачам, тому що йому
дано дозвіл без права делегування своїх можливостей.
В деяких СУБД користувач може отримати права
створювати БД. Наприклад, у MS SQL Server системний адміністратор може
надати користувачеві main_user право на створення своєї БД на даному
сервер. Це може бути зроблено наступною командою:
GRANT CREATE
DATABASE
ON SERVERJ) TO main
user
За принципом ієрархії користувач main_user, створивши
свою БД, тепер може надати права на створення або зміну будь-яких
об'єктів в цій БД іншим користувачам. У СУБД, які підтримують
однобазовую архітектуру, такі дозволи неприпустимі. Наприклад, у СУБД Oracle
на сервері створюється тільки одна БД, але користувачі можуть працювати на рівні
подсхеми (частини таблиць БД і пов'язаних з ними об'єктів). Тому там вводиться
поняття системних привілеїв. Їх дуже багато, 80 різних привілеїв.
Для того, щоб дозволити користувачеві створювати
об'єкти всередині цієї БД, використовується поняття системної привілею, який
може бути призначена одному або декільком користувачам. Вони видаються тільки
на дії і конкретний тип об'єкта. Тому-якщо ви, як системний
адміністратор, надали користувачеві право на створення таблиць (CREATE TABLE),
то для того щоб він міг створити тригер для таблиці, йому необхідно
надати ще одну системну привілей CREATE TRIGGER. Система захисту в
Oracle вважається однією з найбільш потужних, але це має і зворотний бік - вона
досить складна. Тому завдання адміністрування в Oracle вимагає гарного
знання як семантики принципів підтримки прав доступу, так і фізичної
реалізації цих можливостей.
Реалізація захисту в деяких СУБД
Архітектура захисту Access
Якщо у вас є досвід роботи з захистом, що використовуються
на сервері або великий ЕОМ, структура захисту в Access здасться вам знайомою.
Ви можете вказати користувачів, яким надається або, навпаки, не
дозволяється доступ до об'єктів бази даних. Крім того, ви можете визначити
групи користувачів і встановити дозволи на рівні групи, щоб полегшити
побудова захисту для великого числа користувачів. Користувачеві досить
бути членом групи, щоб отримати права доступу, установлені для неї.
Access зберігає інформацію про захист у двох місцях. Під
час установки програма Setup створить в папці Program FilesMicrosoft
Ofice? ості припускає, що на MS SQL Server
будуть заводитися самостійні login id і відповідні їм паролі.
Змішаний режим використовує інтегровану модель при встановленні з'єднань
по пойменованим каналах або мультіпротоколу і стандартну модель у всіх
інших випадках.
MS SQL Server забезпечує багаторівневу перевірку
привілеїв при завантаженні на сервер. Спочатку ідентифікуються права користувача
на встановлення з'єднання з обраним сервером (login name та пароль) і
виконання адміністративних функцій: створення пристроїв і баз даних,
призначення прав інших користувачів, зміна параметрів настройки сервера і
т.д. Максимальними правами має системний адміністратор. На рівні бази
даних кожен користувач, завантажити на сервер, може мати ім'я
користувача (username) бази і права на доступ до об'єктів всередині неї. Є
змогу відобразити декількох login id на одного користувача бази даних,
а також об'єднувати користувачів у групи для зручності адміністрування і
призначення подібних привілеїв. По відношенню до об'єктів бази даних користувачу
можуть бути призначені права на виконання різних операцій над ними: читання,
додавання, видалення, зміна, декларативна посилальна цілісність (DRI),
виконання збережених процедур, а також права на доступ до окремих полях. Якщо
цього недостатньо, можна вдатися до представлень (views), для яких
сказане залишається справедливим. Нарешті, можна взагалі заборонити користувачеві
безпосередній доступ до даних, залишивши за ним лише права на виконання
збережених процедур, в яких буде прописаний весь сценарій його доступу до бази.
Збережені процедури можуть створюватися з опцією WITH ENCRYPTION, яка шифрує
безпосередній текст процедури, що зберігається зазвичай у syscomments. Права на
виконання деяких команд (створення баз, таблиць, умовчань, правил,
уявлень, процедур, резервне копіювання баз і журналів транзакцій) не
є об'єктно-специфічними, тому вони призначаються системним
адміністратором сервера чи власником (засновником) бази даних при
редагуванні бази даних. Адміністрування користувальницьких привілеїв
зазвичай ведеться в SQL Enterprise Manager, проте в Transact-SQL є
збережені процедури (sp_addlogin, sp_password, sp_revokelogin, sp_addalias,
sp_adduser) і оператори (GRANT, REVOKE), які дозволяють здійснювати
дії зі створення користувачів, призначенням та скасування прав при виконанні
скриптів. Додаткову можливість адміністрування привілеїв надають
розглянуті нами вище SQL-DMO.
Управління доступом
Система безпеки SQL Server має кілька
рівнів безпеки:
• операційна система;
• SQL Server;
• база даних;
• об'єкт бази даних.
З іншого боку механізм безпеки припускає
існування чотирьох типів користувачів:
• системний адміністратор, що має необмежений
доступ;
• власник БД, що має повний доступ до всіх об'єктів
БД;
• власник об'єктів БД;
• інші користувачі, що мають отримувати
дозвіл на доступ до об'єктів БД.
Модель
