ВИБОРЧА СХЕМА УПРАВЛІННЯ ДОСТУПОМ

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

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

AUTHORITY SA3

GRANT RETRIEVE { S#, SNAME, CITY }, DELETE ON S

TO Jim, Fred, Mary

2 У сучасній версії мови Tutorial D [33] навмисно не передбачено жодних коштів визначення повноважень, однак використовується в даному розділі гіпотетичний мову можна розглядати ка до витри ж анний в ду х е яз ика T u t o r i a l D

Цей приклад ілюструє той факт, що в загальному випадку повноваження доступу включають чотири описаних нижче компонента

1 Імя (у даному прикладі SA3, suppliers authority three – повноваження постачальника з номером 3) Встановлювані повноваження будуть зареєстровані в системному каталозі під цим імям

2 Одна або кілька привілеїв, що задаються в конструкції GRANT

3 Задається в конструкції ON імя змінної відносини, до якої застосовуються повноваження

4 Безліч користувачів (точніше, ідентифікаторів користувачів),яким надаються зазначені привілеї стосовно зазначеної змінної відносини, що задається за допомогою фрази ТО

Нижче наводиться загальний синтаксис оператора визначення повноважень

AUTHORITY &ltauthority name&gt GRANT  &ltprivilege   commalist&gt ON &ltrelvar name&gt

TO &ltuser ID commalist&gt

Пояснення У наведеному вище визначенні сенс таких параметрів, як імя повноваження&ltauthority  name&gt,  імя змінної відносини&ltrelvar  name&gt  і розділений комами список ідентифікаторів користувачів&ltuser  ID  commalist&gt, зрозумілий без додаткових коментарів Додамо тільки, що значення ALL в даному контексті може застосовуватися для позначення відразу всіх відомих користувачів Як елементи списку в параметрі  &ltprivilege&gt з позначенням повноваження дозволяється застосовувати наступні значення

RETRIEVE  [                                                                                {    &ltattribute name commalist&gt   }    ]   • INSERT  [  {                                                                                &ltattribute name commalist&gt    }    ] DELETE

UPDATE  [  {                                                                                &ltattribute name  commalist&gt    }    ] ALL

Сенс привілеїв RETRIEVE (вибірка, без уточнення), INSERT (вставка, без уточнення), DELETE (видалення) і UPDATE (оновлення, без уточнення) очевидний без додаткових пояснень (можливо, що це не зовсім так слід зазначити, що привілей RETRIEVE потрібно також просто для вказівки відповідного обєкта, наприклад, у визначенні подання або в обмеженні цілісності, а також для вибірки як такої) Якщо з ключовим словом RETRIEVE заданий розділений комами список атрибутів &ltattribute  name  commalist&gt, то цей привілей поширюється тільки на зазначені атрибути Розділені комами списки імен атрибутів у визначеннях привілеїв INSERT і UPDATE мають той же зміст Специфікація ALL є скороченою записом надання всіх привілеїв – RETRIEVE (по всіх атрибутів), INSERT (по вcем атрибутам), DELETE і UPDATE (по всіх атрибутів)

Примітка Для простоти тут ігнорується проблема застосування деяких особливих привілеїв для виконання спільних реляційних операцій привласнення Ми також обмежимо розгляд операціями маніпулювання даними, хоча на практиці, безумовно, існує багато інших операцій, для яких слід було б перевіряти наявність відповідних повноважень (наприклад, визначення і видалення змінних

відносини, а також визначення і видалення самих повноважень) Детальний опис цих операцій виключено для економії місця

Що станеться, якщо користувач спробує виконати з обєктом операцію, не маючи на це необхідних повноважень У простому випадку досить просто відкинути цю спробу (безумовно, надавши користувачу відповідне діагностичне повідомлення) На практиці такий варіант застосовується найбільш часто, тому його можна розуміти як використовуваний за замовчуванням Однак у більш складних ситуаціях

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

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

Безумовно, необхідно також передбачити спосіб скасування існуючих повноважень, як показано нижче

DROP  AUTHORITY  &ltauthority name&gt   

Для простоти викладу припустимо, що при видаленні деякої змінної відносини автоматично видаляються і всі повноваження, надані по відношенню до неї

Нижче представлено кілька прикладів визначення повноважень більшість цих прикладів не потребує додаткових пояснень

1&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp AUTHORITY  EX1

GRANT RETRIEVE (Р #, PNAME, WEIGHT) ON P

TO Jacques, Anne, Charley

Користувачі Jacques, Anne і Charley отримують право доступу до зазначеного вертикальному подмножеству даних в базовій змінної відносини Р Таким чином, це – приклад надання повноважень, що не залежать від значень даних

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp AUTHORITY  EX2

GRANT RETRIEVE, DELETE, UPDATE (SNAME, STATUS) ON LS

TO Dan, Misha

Згадувана тут змінна відносини LS є поданням (з даними про постачальників з Лондона див рис 104 в розділі 10) Користувачі Dan і Misha отримують доступ до горизонтальному подмножеству даних в базовій змінної відносини S Це – приклад надання повноважень, залежних від значень даних Зверніть увагу на те, що хоча користувачі Dan і Misha можуть видалити (DELETE) деякі кортежі постачальників (через подання LS), вони не можуть вставити (INSERT) їх, а також не мають права оновлювати (UPDATE) атрибут s # або CITY

3&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp VAR SSPPO VIEW

(S JOIN SP JOIN (P WHERE CITY = Oslo) { P# } )

{ ALL BUT P#, QTY }

AUTHORITY EX3

GRANT RETRIEVE ON SSPPO TO Lars

Це ще один приклад повноважень, що залежать від значень даних: користувач Lars отримує доступ до інформації про постачальників, але тількипротих, котррие поставляють деталі, що зберігаються в Осло

4&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp VAR  SSQ  VIEW

SUMMARIZE SP PER S { S# } ADD SUM (QTY) AS SQ

AUTHORITY EX4

GRANT RETRIEVE ON SSQ TO Fidel

;

Користувач Fidel отримує право переглядати підсумкові дані по кожному постачальнику, але не має доступу до даних про кожній поставці окремо Таким чином, користувач Fidel зможе переглядати в базі тільки результати статистичної обробки даних

5&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp AUTHORITY   EX5

GRANT RETRIEVE, UPDATE    (STATUS) ON S

WHEN DAY () IN (Мої, Tue, Wed, Thu, Fri)

AND NOW () &gt TIME    09:00:00

AND NOW () &lt TIME 17:00:00′

TO  ACCOUNTING

Тут синтаксис визначення повноважень AUTHORITY розширений для включення конструкції WHEN, що дозволяє задати деякі контекстні елементи управління Додатково передбачається, що в системі передбачені два нуль-арних оператора(Так називаються оператори, які не мають явно заданих операндів), які називаються DAY () і NOW О і мають очевидну інтерпретацію Визначення повноважень ЕХ5 гарантує, що значення статусу постачальника може бути змінено будь-яким користувачем з групи ACCOUNTING (працівники бухгалтерського відділу) тільки в робочі дні та в робочий час Це – приклад так званого контекстнозавісімого повноваження, оскільки надійшов запит на доступ буде чи не буде порушувати встановлені обмеження залежно від стану контексту (у даному випадку це комбінація дня тижня і часу діб)

Нижче наведені приклади інших вбудованих функцій, які можуть бути корисні при визначенні контекстно-залежних повноважень

■ TODAY () Повертає поточну дату

■ USER () Повертає ідентифікатор користувача, який видав запит

■ TERMINAL () Повертає ідентифікатор терміналу, з якого надійшов запит

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

На закінчення необхідно відзначити наступне: вище передбачалося, хоча явно ніде не стверджувалося, що користувачі можуть виконувати тільки ті дії, які їм дозволено виконувати наданими повноваженнями При такому підході до організації захисту все, що не дозволено явним чином, неявно заборонено

Модифікація запиту

Для ілюстрації деяких представлених вище ідей доцільно описати аспекти захисту даних, реалізовані в прототипі системи University Ingres, а також особливості використовуваного в ній мови запитів QUEL У цій реалізації був прийнятий досить цікавий підхід до вирішення проблем захисту, що полягає в тому, що будь-який запит на мові QLJEL перед виконанням автоматично модифікувався таким чином, щоб запобігти будь-які можливі порушення встановлених обмежень захисту Як приклад припустимо, що користувачеві і дозволено зчитувати дані лише про тих деталях, які зберігаються в Лондоні Це обмеження задається наступним виразом

DEFINE PERMIT RETRIEVE ON P TO U WHERE PCITY = &quotLondon&quot

(Оператор DEFINE PERMIT буде докладно описаний нижче) Тепер припустимо, що користувач і вводить наведений нижче запит на мові QUEL

RETRIEVE (РР #, PWEIGHT) WHERE PCOLOR = Red

Використовуючи наведене вище дозвіл (PERMIT), яке зберігається в системному каталозі і визначає права доступу користувача і до змінної відносини р, система автоматично перетворює Наведений вище запит в запит наступного виду

RETRIEVE (РР #, PWEIGHT) WHERE PCOLOR = Red AND PCITY = London

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

Коротко описаний вище процес модифікації запиту повністю ідентичний методу, використовуваному для реалізації уявлень [1012], а також (особливо у випадку прототипу системи Ingres) обмежень цілісності [923] Таким чином, важлива перевага даного підходу полягає в тому, що його можна реалізувати досить просто (в основному завдяки тому, що необхідний для цього програмний код вже присутній в системі) Інша його перевага – порівняно висока ефективність, так як збільшення витрат, повязаних з реалізацією обмежень захисту, відбувається в основному під час компіляції, а не під час прогону програми Ще одна перевага даного підходу полягає в тому, що при його використанні відсутні певні незручності, властиві підходу, описаному раніше, коли для одного користувача було потрібно задавати різні привілеї при зверненні до різних частин однієї і тієї ж змінної відносини (див розділ 176, де дано пояснення до сказаного)

Єдиний недолік цього підходу полягає в тому, що не всім обмеженням захисту можна надати таку просту форму В якості найпростішого контрпримера припустимо, що користувачеві U заборонений доступ до змінної відносини Р Тоді

будь-яка досить проста модифікована форма наведеного вище визначення повноважень на вибірку даних RETRIEVE неодмінно створить ілюзію, що змінної відносини Р просто не існує В результаті система обовязково видасть повідомлення про помилку приблизно такого змісту: Вам не дозволено доступ до зазначеної змінної відносини. (Або, ймовірно, система просто приховає істину

і повідомить: Такий змінної відношення не існує.) Але найкращий спосіб полягає в тому, щоб повідомити користувачеві: Або такої змінної відносини

не існує, або ви не маєте права доступу до неї .

У загальному вигляді синтаксис оператора визначення повноважень DEFINE PERMIT виглядає наступним чином

DEFINE  PERMIT «operation name  commalist&gt

ON &ltrelvar name&gt   [   (   &ltattribute name commalist&gt   )

] TO  &ltuser ID&gt

[  AT &ltterminal  ID commalist&gt  ]

[  FROM &lttime&gt TO &lttime&gt  ]

[  ON &ltday&gt TO  &ltday&gt  }

[  WHERE  &ltbool  exp&gt  ]

Таким чином, концептуально синтаксис оператора визначення повноважень DEFINE PERMIT дуже схожий на синтаксис оператора визначення повноважень AUTHORITY, за винятком того, що він забезпечує застосування додаткових умов в конструкції WHERE (всі конструкції AT, FROM і ON можуть бути замінені конструкцією WHEN) Нижче наведено приклад подібного визначення

DEFINE PERMIT RETRIEVE, APPEND, REPLACE ON S ( S#, CITY ) TO Joe AT TTA4

FROM 9:00 TO 17:00

ON Sat TO Sun

WHERE SSTATUS &lt 50

AND SS# = SPP#

AND SPP# = PP# AND PCOLOR = &quotRed&quot

ПриміткаОператори додавання (APPEND) І заміни (REPLACE) мови QUEL

є аналогами операторів вставки (INSERT) та оновлення (UPDATE), відповідно

Контрольний журнал

Важливо розуміти, що непереборних систем захисту не буває Наполегливий потенційний порушник завжди зможе подолати всі встановлені системи контролю, особливо якщо він розраховує отримати за це достатньо високу винагороду Тому при роботі з дуже важливими даними або при виконанні відповідальних операцій виникає необхідність організаціїконтрольного журналу (Audit trail), в який вноситься інформація про всі події, що відбуваються в системі Припустимо, наприклад, що виявлена ​​суперечливість отриманих результатів, а це може свідчити про зловмисне спотворенні інформації, що зберігається в базі даних У цьому випадку для прояснення ситуації можуть використовуватися записи контрольного журналу, які дозволять або підтвердити той факт, що всі процеси перебувають під контролем, або виявити втручання і розпізнати порушника

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

■ сам запит (вихідний текст запиту)

■ номер терміналу, з якого була затребувана операція

■ імя користувача, затребувані операцію

■ дата і час запуску операції

■ змінні відносини, кортежі і атрибути, залучені в процес виконання операції

■ вихідні значення змінюваних даних (старі значення)

■ модифіковані значення даних (нові значення)

Як уже згадувалося, навіть сам факт, що в системі ведеться контрольний журнал, в певних ситуаціях здатний відлякати потенційного порушника

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*