4. Питання безпеки і санкціонування доступу до баз даних

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

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

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

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

скористатися текстовим редактором і виключити частину модуля. Дуже ймовірно, що файл перестане бути цілісним.

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

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

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

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

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

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

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

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

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

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

• механізм уявлень, розглянутий у попередньому розділі і використовуваний для приховування засекречених даних від користувачів, які не володіють правом доступу;

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

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

Привілеї надаються за допомогою пропозиції GRANT (надати), загальний формат якого має вигляд

GRANT привілеї ON об'єкт TO користувачі;

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

До таблиць (уявленням) відносяться привілеї SELECT, DELETE, INSERT і UPDATE [(стовпці)], що дозволяють відповідно зчитувати (виконувати будь-які операції, в яких використовується SELECT), видаляти, додавати або змінювати рядки зазначеної таблиці (зміну можна обмежити конкретними стовпцями). Наприклад, пропозиція

GRANT SELECT, UPDATE (Праця) ON Страви TO cook;

дозволяє користувачеві, який представився системі ідентифікатором cook, використовувати інформацію з таблиці Страви, але змінювати в ній він може тільки значення стовпця Праця.

Якщо користувач USER_1 надав будь-які привілеї іншому користувачеві USER_2, то він може згодом скасувати всі або деякі з цих привілеїв. Скасування здійснюється за допомогою пропозиції REVOKE (скасувати), загальний формат якого дуже схожий на формат пропозиції GRANT:

REVOKE привілеї ON об'єкт FROM користувачі;

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