Статьи

Інформаційна безпека в сучасних системах управління базами даних

  1. деякі терміни
  2. користувачі СУБД
  3. Дискреційна захист
  4. мандатна захист

Лілія Козленко

деякі терміни

користувачі СУБД

Дискреційна захист

мандатна захист

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

ля СУБД важливі три основних аспекти інформаційної безпеки - конфіденційність, цілісність і доступність ля СУБД важливі три основних аспекти інформаційної безпеки - конфіденційність, цілісність і доступність. Темою цієї статті є перший з них - засоби захисту від несанкціонованого доступу до інформації. Загальна ідея захисту бази даних складається в дотриманні рекомендацій, сформульованим для класу безпеки C2 в «Критеріях оцінки надійних комп'ютерних систем» 1 .

Політика безпеки визначається адміністратором даних. Однак рішення захисту даних не повинні бути обмежені тільки рамками СУБД. Абсолютний захист даних практично не можна реалізувати, тому зазвичай задовольняються відносної захистом інформації - гарантовано захищають її на той період часу, поки несанкціонований доступ до неї тягне будь-які наслідки. Розмежування доступу до даних також описується в базі даних за допомогою обмежень, і інформація про це зберігається в її системному каталозі. Іноді додаткова інформація може бути запрошена з операційних систем, в оточенні яких працюють сервер баз даних і клієнт, який звертається до сервера баз даних.

деякі терміни

онфіденціальная інформація (sensitive information) - інформація, яка потребує захисту онфіденціальная інформація (sensitive information) - інформація, яка потребує захисту.

Доступ до інформації (access to information) - ознайомлення з інформацією, її обробка (зокрема, копіювання), модифікація, знищення.

Суб'єкт доступу (access subject) - особа або процес, дії якого регламентуються правилами розмежування доступу.

Об'єкт доступу (access object) - одиниця інформації автоматизованої системи, доступ до якої регламентується правилами розмежування доступу. Об'єктами доступу (контролю) в СУБД є практично все, що містить кінцеву інформацію: таблиці (базові або віртуальні), уявлення, а також більш дрібні елементи даних: стовпці і рядки таблиць і навіть поля рядків (значення). Таблиці бази даних та подання мають власника або творця. Їх об'єднує ще й те, що всі вони для кінцевого користувача представляються як таблиці, тобто як щось іменоване, що містить інформацію у вигляді безлічі рядків (записів) однакової структури. Рядки таблиць розбиті на поля іменованими стовпцями.

Правила розмежування доступу (security policy) - сукупність правил, що регламентують права суб'єктів доступу до об'єктів доступу.

Санкціонований доступ (authorized access to information) - доступ до інформації, яка не порушує правил розмежування доступу.

Несанкціонований доступ (unauthorized access to information) - доступ до інформації, який порушує правила розмежування доступу з використанням штатних засобів, що надаються засобами обчислювальної техніки або автоматизованими системами.

Ідентифікатор доступу (access identifier) ​​- унікальний ознака об'єкта або суб'єкта доступу.

Ідентифікація (identification) - присвоєння об'єктам і суб'єктам доступу ідентифікатора і (або) порівняння висунутого ідентифікатора з переліком привласнених ідентифікаторів.

Пароль (password) - ідентифікатор суб'єкта, який є його секретом.

Аутентифікація (authentification) - перевірка приналежності суб'єкту доступу пред'явленого їм ідентифікатора, підтвердження справжності.

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

Рівень повноважень суб'єкта доступу (subject privilege) - сукупність прав доступу суб'єкта доступу (для стислості надалі ми будемо використовувати термін «привілей»).

Порушник правил розмежування доступу (security policy violator) - суб'єкт доступу, який здійснює несанкціонований доступ до інформації.

Модель порушника правил розмежування доступу (security policy violator model) - абстрактне (формалізоване або неформалізовані) опис порушника правил розмежування доступу.

Цілісність інформації (information integrity) - здатність кошти обчислювальної техніки (в даному випадку - інформаційної системи в цілому) забезпечити незмінність інформації в умовах випадкового і (або) навмисного спотворення (руйнування).

Мітка конфіденційності (sensitivity label) - елемент інформації, що характеризує конфіденційність об'єкта.

Багаторівневий захист (multilevel secure) - захист, що забезпечує розмежування доступу суб'єктів з різними правами доступу до об'єктів різних рівнів конфіденційності.

користувачі СУБД

ользователей СУБД можна розділити на три групи: ользователей СУБД можна розділити на три групи:

  1. Прикладні програмісти - відповідають за створення програм, що використовують базу даних.

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

  2. Кінцеві користувачі бази даних - працюють з БД безпосередньо через термінал або робочу станцію. Як правило, кінцеві користувачі мають строго обмежений набір привілеїв маніпулювання даними. Цей набір може визначатися при конфігуруванні інтерфейсу кінцевого користувача і не змінюватися. Політику безпеки в даному випадку визначає адміністратор безпеки або адміністратор бази даних (якщо це одне і те ж посадова особа).
  3. Адміністратори баз даних - утворюють особливу категорію користувачів СУБД. Вони створюють самі бази даних, здійснюють технічний контроль функціонування СУБД, забезпечують необхідну швидкодію системи. В обов'язки адміністратора, крім того, входить забезпечення користувачам доступу до необхідних їм даними, а також написання (або надання допомоги у визначенні) необхідних користувачеві зовнішніх представлень даних. Адміністратор визначає правила безпеки і цілісності даних.

Дискреційна захист

сучасних СУБД достатньо розвинені засоби дискреційної захисту сучасних СУБД достатньо розвинені засоби дискреційної захисту.

Дискреційне управління доступам (discretionary access control) - розмежування доступу між пойменованими суб'єктами і пойменованими об'єктами. Суб'єкт з певним правом доступу може передати це право будь-якого іншого суб'єкта.

Дискреційна захист є багаторівневою логічної захистом.

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

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

CONNECT [[logon] [AS {SYSOPER | SYSDBA}]] користувач / пароль [@ база_данних] CONNECT TO база_данних USER користувач USING пароль

У цих пропозиціях відображений необхідний набір атрибутів, а також показано відмінність синтаксису. Формат атрибута база_данних, як правило, визначається виробником СУБД, так само як і ім'я користувача, що має за замовчуванням системні привілеї (SYSDBA / SYSOPER в разі Oracle).

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

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

Всі суб'єкти контролю системи зберігаються в таблиці повноважень системи і розділені для системи на ряд категорій, наприклад CONNECT, RESOURCE і DBA. Набір таких категорій визначається виробником СУБД. Ми не випадково пропонуємо зазначений порядок розгляду - саме так відбувається наростання можливостей (повноважень) для кожного окремого виду підключення:

  • CONNECT - кінцеві користувачі. За замовчуванням їм дозволено тільки з'єднання з базою даних і виконання запитів до даних, всі їхні дії регламентовані виданими їм привілеями;
  • RESOURCE - привілейовані користувачі, які мають право створення власних об'єктів в базі даних (таблиць, уявлень, синонімів, збережених процедур). Користувач - власник об'єкта має повний набір привілеїв для управління даним об'єктом;
  • DBA - категорія адміністраторів бази даних. Включає можливості обох попередніх категорій, а також можливість вводити (видаляти) в систему (з системи) суб'єкти захисту або змінювати їх категорію.

Слід особливо відзначити, що в деяких реалізаціях адміністративні дії також розділені, що обумовлює наявність додаткових категорій. Так, в Oracle користувач з ім'ям DBA є адміністратором сервера баз даних, а не однієї-єдиної бази даних. В СУБД «Линтер» компанії РЕЛЕКС поняття адміністратора сервера баз даних відсутній, а наявний лише поняття адміністратора конкретної бази даних. У IBM DB2 існує ряд категорій адміністраторів: SYSADM (найвищий рівень; системний адміністратор, що володіє всіма привілеями); DBADM (адміністратор бази даних, що володіє всім набором привілеїв в рамках конкретної бази даних). Привілеї управління сервером баз даних є у користувачів з іменами SYSCTRL (найвищий рівень повноважень управління системою, який застосовується тільки до операцій, що впливає на системні ресурси; безпосередній доступ до даних заборонений, дозволені операції створення, модифікації, видалення бази даних, переклад бази даних або примірники (instance) в пасивний стан (quiesce), створення і видалення табличних просторів), SYSMAINT (другий рівень повноважень управління системою, що включає всі операції підтримки працездатності примірника (Instance); безпосередній доступ до даних цього користувачеві заборонений, дозволені операції зміни конфігураційних файлів бази даних, резервне копіювання бази даних і табличних просторів, віддзеркалення бази даних). Для кожної адміністративної операції в IBM DB2 визначено необхідний набір адміністративних категорій, до яких повинен належати користувач, який виконує той чи інший запит адміністрування. Так, виконувати операції призначення привілеїв користувачам може SYSADM або DBADM, а для того щоб створити об'єкт даних, користувач повинен володіти привілеєм CREATETAB.

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

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

CREATE USER IDENTIFIED користувач BY пароль

Підсистема безпеки IBM DB2 може використовувати ідентифікатори користувачів операційної системи; її синтаксис SQL не містить пропозиції, аналогічного пропозицією CREATE USER. Microsoft SQL Server може використовувати аутентифікацію як бази даних, так і операційної системи. Але ми не станемо тут обговорювати переваги і недоліки обраних виробниками способів аутентифікації - всі вони дозволяють будувати коректні схеми визначення автентичності користувачів. Використання додаткових засобів аутентифікації в рамках інформаційної системи не забороняється.

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

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

При використанні збережених процедур слід звертати особливу увагу на те, від імені якого користувача виконується дана процедура, що зберігається в кожному конкретному випадку. Так, в Oracle до недавнього часу збережені процедури виконувалися від імені власника збереженої процедури, а не від імені користувача, який виконав її виклик. Поточна версія Oracle надає можливість вказати, під чиїм ім'ям буде виконуватися викликана процедура, що зберігається, користувач же повинен мати тільки привілей EXECUTE для даної процедури. У «Линтер», наприклад, виконання збережених процедур завжди походить від імені користувача, що викликав процедуру.

Привілеї конкретного користувача можуть бути призначені адміністратором явно і неявно, наприклад через роль. Роль - це ще один можливий іменований носій привілеїв. З роллю не асоціюють перелік допустимих користувачів - замість цього ролі захищають паролями, якщо, звичайно, така можливість підтримується виробником СУБД. Ролі зручно використовувати, коли той чи інший набір привілеїв необхідно видати (або відібрати) групі користувачів. З одного боку, це полегшує адміністратору управління привілеями, з іншого - вносить певний порядок в разі необхідності змінити набір привілеїв для групи користувачів відразу. Потрібно особливо відзначити, що при виконанні процедур і інтерактивних запитів може існувати залежність набору привілеїв користувача від того, як вони були отримані: явно або через роль. Мають місце і реалізації, наприклад в Oracle, де в збережених процедурах використовуються привілеї, отримані користувачем явно. Якщо використовувана вами реалізація володіє подібним властивістю, то зміна привілеїв у групи користувачів слід реалізувати як набір команд або як адміністративну процедуру (в залежності від уподобань адміністратора).

Пропозиції управління привілеями:

Якщо суб'єкт = користувач, то привілей призначається йому явно. Якщо суб'єкт = роль, то для управління привілеями використовуються відповідно:

GRANT ROLE імя_ролі [ON об'єкт] TO суб'єкт [WITH GRANT OPTION] REVOKE ROLE імя_ролі [ON об'єкт] FROM суб'єкт

Призначення привілеї всім користувачам системи здійснюється наступним чином:

GRANT привілей [ON об'єкт] TO PUBLIC

У цьому випадку кожен новий створений користувач автоматично отримає такий привілей. Скасування привілеї здійснюється так:

REVOKE прівілей [ON об'єкт] FROM PUBLIC

Необходимо мати на увазі, что деякі реализации, например IBM DB2, Використовують групи Користувачів, певні в операційній системе. Тому слід звертати увагу на особливості реалізації аналогів ролей в СУБД. Потрібно з'ясувати, чи містить реалізація SQL-пропозиції виду:

CREATE ROLE імя_ролі DROP ROLE імя_ролі

При управлінні доступом до таблиць і уявленнями набір привілеїв в реалізації СУБД визначається виробником.

Привілеї вибірки і модифікації даних:

SELECT - привілей на вибірку даних;

INSERT - привілей на додавання даних;

DELETE - привілей на видалення даних;

UPDATE - привілей на оновлення даних (можна вказати певні стовпці, дозволені для поновлення).

Привілеї зміни структури таблиць:

ALTER - зміна фізичної / логічної структури базової таблиці (зміна розмірів і числа файлів таблиці, введення додаткового стовпця і т.п.);

INDEX - створення / видалення індексів на стовпці базової таблиці;

ALL - всі можливі дії над таблицею.

У реалізаціях можуть бути присутніми інші різновиди привілеїв, наприклад: CONTROL (IBM DB2) - комплексна привілей управління структурою таблиці, REFERENCES - привілей створення зовнішніх ключів, RUNSTAT - виконання збору статистичної інформації по таблиці і інші.

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

Подання (view) - це сформована вибірка кортежів, що зберігаються в таблиці (таблицях). До подання можна звертатися точно так же, як і до таблиць, за винятком операцій модифікації даних, оскільки деякі типи уявлень є немодіфіціруемих. Часто в реалізаціях view зберігається як текст, що описує запит вибірки, а не власне вибірка даних; вибірка ж створюється динамічно на момент виконання пропозиції SQL, що використовує view. Але розмежувати доступ, наприклад, до двох документах, які задовольняють одного й того ж умові вибірки, вже не можна. Це пов'язано з тим, що навіть якщо ввести окремий атрибут, який буде зберігати інформацію про мітку конфіденційності документа, то засобами SQL можна буде отримати вибірку даних без урахування атрибута даної мітки. Фактично це означає, що або сам сервер баз даних повинен надати більш високий рівень захисту інформації, або доведеться реалізувати даний рівень захисту інформації за допомогою жорсткого обмеження операцій, які користувач може виконати за допомогою SQL. На деякому рівні таке розмежування можна реалізувати за допомогою збережених процедур, але не повністю - в тому сенсі, що саме ядро ​​СУБД дозволяє розірвати зв'язок «захищається Ц мітка конфіденційності».

мандатна захист

редства мандатної захисту надаються спеціальними (trusted) версіями СУБД редства мандатної захисту надаються спеціальними (trusted) версіями СУБД.

Мандатний управління доступом (mandatory access control) - це розмежування доступу суб'єктів до об'єктів даних, засноване на характеризується міткою конфіденційності інформації, яка міститься в об'єктах, і на офіційний дозвіл (допуск) суб'єктів звертатися до інформації такого рівня конфіденційності.

Для чого ж потрібна мандатна захист? Засоби довільного управління доступом характерні для рівня безпеки C. Як правило, їх, в принципі, цілком достатньо для переважної більшості комерційних додатків. Проте вони не вирішують одну важливу завдання - завдання стеження за передачею інформації. Засоби довільного управління доступом не можуть перешкодити авторизованому користувачеві законним чином отримати секретну інформацію і потім зробити її доступною для інших, неавторизованих, користувачів. Неважко зрозуміти, чому це так. При довільному управлінні доступом привілеї існують окремо від даних (в разі реляційних СУБД - окремо від рядків реляційних таблиць), в результаті чого дані виявляються «знеособленими» і ніщо не заважає передати їх кому завгодно навіть засобами самої СУБД; для цього потрібно лише отримати доступ до таблиці або подання.

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

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

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

За винятком атрибута власності (логічна захист), що розбиває дані (таблиці) на власні (що належать даному суб'єкту) і чужі, фізичний захист розбиває дані більш тонко. Але чи можна обійтися без фізичного захисту або, принаймні, спробувати, реалізувавши, наприклад, складний набір збережених процедур. В общем-то деяку подобу такого захисту піддається реалізації в разі, коли мітки додаються в таблицю в якості додаткового атрибута, доступ до таблиць забороняється взагалі і ні один додаток не може виконати інтерактивний SQL-запит, а тільки збережену процедуру і т.п. Ряд реалізацій подібного рівня захисту використовує виклик набору процедур з вельми абстрактними (що дуже бажано) іменами. Система реалізації захисту інформації в даному випадку досить складна і передбачає певний рівень довіри до адміністратора безпеки, так як він має право змінювати структуру бази даних, а значить, і збережені процедури, подання. Фізично ж адміністратор безпеки в даному випадку не ізольований від управління секретними даними.

Крім того, захищені СУБД дозволяють розмежувати доступ до інформаційної системи з тих чи інших робочих станцій для тих чи інших зареєстрованих користувачів, визначити режими роботи, накласти обмеження по часу роботи тих чи інших користувачів з тих чи інших робочих станцій. У разі реалізації даних опцій на прикладному рівні завдання, як правило, зводиться до створення сервера додатків, який займається відстеженням, «хто і звідки прийшов». Окремий комплекс серверних додатків (зазвичай - збережених процедур, якщо в СУБД відсутня мандатна захист) забезпечує аудит.

Розглянемо мандатну захист докладніше. Як приклад візьмемо мандатну захист СУБД «Линтер», яка отримала визнання в досить специфічному секторі - силових структурах, як єдина СУБД, що має сертифікат за другим класом захисту від несанкціонованого доступу, що відповідає класу B3 по американському національному стандарту.

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

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

У вже згадуваних «Критеріях оцінки надійних комп'ютерних систем» стосовно до систем рівня безпеки B описаний механізм міток безпеки, реалізований в розглянутих цією статтею СУБД.

Мітка об'єкта включає наступне:

  1. Група суб'єкта, який вніс даний об'єкт.
  2. Рівень доступу на читання - RAL (Read Access Level).
  3. Рівень доступу на запис - WAL (Write Access Level).

Мітка суб'єкта виглядає аналогічно:

  1. Група, до якої належить суб'єкт.
  2. RAL-рівень суб'єкта, який являє собою максимальний RAL-рівень доступною суб'єкту інформації.
  3. WAL-рівень суб'єкта, тобто мінімальний RAL-рівень об'єкта, який може бути створений цим суб'єктом.

Всі користувачі бази даних вважаються розбитими на непересічні групи. Група описує область доступних користувачеві даних. Для кожної групи існує адміністратор групи (рівень DBA для групи), створений адміністратором системи. При цьому користувачі однієї групи не бачать даних, що належать користувачам іншої групи. У цьому плані у СУБД «Линтер» є особливість: в системі реалізовано таке поняття, як «рівень довіри між групами». При цьому рівні довіри не можуть бути вкладеними. Група являє собою числове значення в діапазоні [1-250]. Група 0 - група адміністратора системи. Тільки адміністратор системи може створити користувача в групі, відмінною від своєї. Всі дані, створені від імені користувача, позначаються його групою.

Рівні доступу вводяться для перевірки прав на здійснення читання-запису інформації. Вводяться такі рівні доступу:

  1. Для користувача (суб'єкта):
  • RAL - рівень доступу; користувач може отримувати (читати) інформацію, RAL-рівень якої не вище його власного рівня доступу;
  • WAL - рівень довіри на зниження рівня конфіденційності; користувач не може вносити інформацію з рівнем доступу (RAL-рівнем) нижчим, ніж даний WAL-рівень користувача. Іншими словами, користувач не може зробити доступну йому інформацію менш конфіденційної, ніж зазначено в даному параметрі.
  1. Для інформації:
  • RAL - рівень читання; користувач може отримувати (читати) інформацію, RAL-рівень якої не вище його власного RAL-рівня (може читати менше конфіденційні дані);
  • WAL - рівень цінності або рівень доступу на запис (модифікацію, видалення); користувач може модифікувати (видаляти) інформацію, WAL-рівень якої не вище його RAL-рівня.

Створити користувача з довільними рівнями може тільки адміністратор системи. Решта адміністратори (DBA) можуть створювати користувачів (або змінювати рівень користувачам) лише в межах відведених їм рівнів. Користувач може примусово позначити вводяться дані, вказавши в списку атрибутів рівні доступу для відповідних записів і полів (при виконанні операторів INSERT або UPDATE). За замовчуванням вносяться дані успадковують рівні користувача, який вносить / змінює дані. Об'єкти, що захищають: користувачі, таблиці, стовпці, записи (вноситься при виконанні INSERT), поля записів (змінюються при виконанні UPDATE). Рівні, як і групи, не можна використовувати в разі, якщо вони не створені спеціальними запитами.

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

Крім систематичного застосування арсеналу засобів, описаних вище, необхідно використовувати адміністративні та процедурні заходи, зокрема регулярне зміна паролів користувачів, запобігання доступу до фізичних носіїв інформації тощо

КомпьютерПресс 3'2002


Для чого ж потрібна мандатна захист?

Новости