11. Захист БД від несанкціонованого доступу

Поняття захисту інформації торкаються не тільки даних, що зберігаються в БД [4]. Вразливість системи захисту може виникати і в інших її частинах, що, у свою чергу, наражає на загрозу й БД. Отже, захист має охоплювати увесь об’єкт інформаційної діяльності (організації) в цілому: устаткування, програмне забезпечення, що використовується, персонал і дані [2, 4, 6, 7, 21].

Захист БД – це відвертання будь-яких навмисних або ненавмисних загроз за допомогою різних комп'ютерних і некомп'ютерних засобів [4].

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

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

1. Чи є в системі резервне устаткування з розгорнутим програмним забезпеченням.
2. Коли востаннє виконувалося резервне копіювання системи.
3. Час, необхідний на оновлення системи.
4. Чи існує можливість оновлення й уведення в роботу даних, які були зруйновані.

Таблиця 11.1

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

1) викрадення і фальсифікація даних;

2) втрата конфіденційності (порушення таємниці);

3) порушення недоторканності особистих даних;

4) втрата цілісності;

5) втрата доступності.

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

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

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

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

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

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

11.2.1. Авторизація

Авторизація – це надання повноважень, що дозволяють їхньому власнику мати законний доступ до системи або до її об'єктів [4]; встановлення відповідності між повідомленням і його джерелом [22].

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

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

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

11.2.2. Аутентифікація

Аутентифікація – процедура перевірки відповідності наданого ідентифікатора об’єкта комп’ютерної системи на предмет належності його цьому об’єкту; встановлення або підтвердження автентичності [22].

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

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

11.2.3. Механізм представлення даних

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

11.2.4. Засоби підтримки цілісності даних

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

11.2.5. Резервне копіювання

Резервне копіювання – це процедура, яка періодично виконується для одержання копії БД, її файлу журналу та програм на носії, що зберігаються окремо від системи [4].

Існують такі види резервного копіювання:

1) повне(full backup);

2) диференційоване(differential backup);

3) додаткове(incremental backup);

4) пофайлове(file-by-file backup);

5) блочне інкрементальне(block level incremental backup).

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

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

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

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

Ведення журналу – це процедура створення й обслуговування файлу журналу, який містить відомості про всі зміни, внесені в БД із моменту запису останньої резервної копії, і призначений для забезпечення ефективного оновлення системи у разі її відмови [4].

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

Контрольна точка – це момент синхронізації між станом БД та станом журналу виконання трансакцій. У цей момент усі буфери примусово вивантажуються на пристрої вторинної пам'яті [4].

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

11.2.6. Оновлення

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

11.2.7. Шифрування

Шифрування – це кодування даних з використанням спеціального алгоритму, у результаті чого вони стають недоступними для читання будь-якою програмою, що не має ключа дешифрування [4].

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

11.2.8. Допоміжні процедури

Допоміжні процедури мають використовуватися разом з іншими механізмами захисту.

11.2.8.1. Аудит

Аудит – це допоміжна процедура, яка призначена для перевірки повноти залучення передбачених засобів керування й відповідності рівня захищеності БД встановленим вимогам [4].

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

1. Підтримка точності даних, що вводяться.
2. Підтримка точності процедур обробки даних.
3. Запобігання появи й своєчасне виявлення помилок у процесі виконання програм.
4. Коректне тестування, документування й супровід програмних засобів, що розроблені.
5. Попередження несанкціонованої зміни програм.
6. Надання прав доступу і контроль над використанням програм.
7. Підтримка документації в актуальному стані.

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

11.2.8.2. Установлення нового прикладного програмного забезпечення

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

11.2.8.3. Установлення або модернізація системного програмного забезпечення

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

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

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

11.3.1. Класифікація методів некомп'ютерного контролю

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

- заходи забезпечення безпеки й планування захисту від непередбачених обставин;

- контроль за персоналом;

- захист приміщень і сховищ;

- контроль фізичного доступу;

- гарантійні угоди;

- договори на супровід.

11.3.2. Заходи забезпечення безпеки й планування захисту

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

У документі про заходи безпеки рекомендується відображати:

- сферу ділових процесів організації, для якої вони встановлюються;

- відповідальність і обов'язки окремих працівників;

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

- процедури, які повинні обов'язково виконуватися.

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

- відомості про те, хто є головною відповідальною особою і як можна встановити з нею контакт;

- інформацію про те, хто й на якій підставі ухвалює рішення стосовно виникнення надзвичайної ситуації;

- технічні вимоги до передачі керування резервним службам.

У ці вимоги входять:

- відомості про розташування альтернативних сайтів;

- відомості про необхідне додаткове устаткування;

- відомості про необхідність додаткових ліній зв'язку.

- організаційні вимоги до персоналу, який передає керування резервним службам;

- відомості про наявність страховки на випадок даної конкретної ситуації.

Будь-який план захисту від невизначених обставин повинен періодично переглядатися й тестуватися на предмет його виконуваності.

11.3.3. Захист приміщень, сховищ і контроль за роботою персоналу

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

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

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

11.3.4. Контроль фізичного доступу

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

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

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

11.3.5. Гарантійні договори

Гарантійні договори – це юридичні угоди відносно програмного забезпечення, що вкладені між розроблювачами програм та клієнтами, на підставі яких деяка третя фірма забезпечує зберігання вихідного тексту програм, що розроблені для клієнта. Це одна з форм страховки клієнта на випадок, якщо компанія-розроблювач відійде від справ. У цьому випадку клієнт одержить право забрати вихідні тексти програм у третьої фірми, замість того щоб залишитися з прикладною програмою, що позбавлена усякого супроводу. Дана область юриспруденції вважається однією з тих, у яких дуже часто допускаються помилки й різні недооцінки. На думку деяких авторів, 95% усіх гарантійних договорів по програмному забезпеченню не досягає своєї початкової мети. Щоб уникнути помилок, при укладенні подібних угод необхідно ретельно продумувати наступне:

- тип матеріалів, що поміщаються на зберігання;

- процедури оновлення й підтримки актуальності цих матеріалів;

- відомості про використання програмного забезпечення від сторонніх виробників;

- необхідність проведення верифікації матеріалів, що зберігаються;

- умови, за яких матеріали можуть бути передані клієнтові;

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

11.3.6. Договори на супровід

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

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

1. Запобігання виконання запитів, що працюють із незначною кількістю записів БД.
2. Випадкове внесення додаткових рядків до основного набору даних, що оброблені запитом. У результаті відповідь буде містити певну помилку й дозволить лише оцінити правильне значення.
3. Використання для відповідей на запити тільки випадкових наборів вихідних даних.
4. Зберігання історичних відомостей про виконання та відхилення будь-яких запитів, що використовують значну кількість вихідних даних, оброблених попереднім запитом.

11.5.1. Базові моделі управління доступом

11.5.1.1. Мандатна модель

Мандатна модель базується на основі секретного документообігу, що використовується у державних установах [23]. У моделі рівні допуску, які встановлені для кожного об’єкта і користувача, чітко визначені та упорядковані за зростаючою секретністю. Діють два основних правила:

1. Користувач може читати тільки ті об’єкти, що мають рівень допуску не вищий від його.
2. Користувач може змінювати тільки ті об’єкти, що мають однаковий з ним рівень допуску.

Перше правило зрозуміле. Друге правило доповнює перше. Воно запобігає навмисному або ненавмисному розкриттю тайн для користувачів з нижчими рівнями допуску.

Така організація допуску до об’єктів має деякі недоліки:

1. Модель не має механізму обмеження допуску до об’єктів одного рівня секретності для випадку, якщо два користувачи з одноковими рівнями допуску виконують різні обов’язки, та не мають знати щодо діяльності один до одного.
2. Суттєве обмеження комунікативних можливостей між користувачами, які мають різні рівні допуску. З одного боку, користувач не має зворотного зв’язку зі своїми колегами, що мають більш високий рівень допуску. Він ніколи не дізнається, чи отримали його інформацію, яку він виклав для них на своєму рівні доступу. З іншого боку, коментарі користувачів ніколи не дійдуть до тих, хто має нижчий рівень доступу.

Тому на практиці мандатну модель використовують сумісно з іншими моделями.

11.5.1.2. Дискреційна модель

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

Для наочності надання повноважень використовують матрицю доступу. Рядки матриці відповідають користувачам або їх групам, а стовпці – об’єктам, або групам об’єктів, до яких надається доступ. Кожна чарунка матриці містить набір прав, які відповідний користувач має відносно відповідного об’єкта. Користувач, який створив об’єкт, як правило, має усю повноту повноважень на дії, що можливо виконати над цим об'єктом.

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

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

На практиці, навіть при зменшенні розмірності матриці доступу, продумати політику безпеки, тобто грамотно розподілити повноваження між користувачами системи, дуже складно. Методи та засоби, які дозволяють це зробити описані в спеціальній літературі [1, 3, 4].

11.5.1.3. Ролева модель

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

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

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

З простоти організації ролевої моделі випливає ряд недоліків:

1. Прийняття ролі користувача відносно всіх об'єктів системи призводить до необхідності розподілу сфер керування або до впливу користувачів на бізнес-процеси шляхом утворення низки однотипних ролей, які стосуються адміністративно самостійних одиниць організації. Таким чином, ролей «керівник підрозділу» буде створено стільки, скільки однотипних підрозділів має структура організації. А в межах підрозділу можуть бути й інші ролі. Одним зі шляхів виходу із даної ситуації є розподіл системи на домени та використання окремої ролевої моделі для кожного домену. Деякі автори такий підхід вважають більш надійним.
2. Звуження меж застосовування ролевої моделі до рамок систем, в яких не передбачено використання авторських матеріалів в документах. Цей недолік випливає з відсутності можливості визначення «хазяїна об’єкта».
3. Дії, які можуть виконувати користувачі, стосуються без винятку всіх об'єктів системи. Таким чином «вилучати» із системи будь-який об’єкт може будь-хто, незалежно від того, створював або використовував він цей об’єкт чи ні. Те саме стосується «утворення» та «корегування» об’єкта, що може стати несподіваним для колег, сферу діяльності яких це торкає безпосередньо. Вихід із цієї ситуації в рамках ролевої моделі – диференціація елементарних операцій, в назву яких додається необхідний ідентифікатор об'єкта. Наприклад: «вилучення договору», «вилучення накладної» і таке інше.

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

11.5.2. Реалізація дискреційної моделі доступу до об’єктів БД

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

Привілей доступу – це можливість виконувати визначений вид дій над конкретними об'єктами БД, яка надана користувачу [4].

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

Привілеї доступу можуть установлюватися як системним адміністратором (наприклад, за замовченням в Interbase – це користувач з іменем SYSDBA), так і користувачем, якому системний адміністратор надав таке право. Наприклад, для БД «БІБЛІОТЕКА» – це користувач з іменем S. Кожний об'єкт, що створений у середовищі SQL, має свого власника. Власник об'єкта є єдиною персоною, яка знає про його існування й має право виконувати з ним будь-які операції. Надання й скасування користувачам привілеїв у SQL реалізується операторами GRANT і REVOKE відповідно [10, 14, 15]. Оператор GRANT має такий формат:

Після пропозиції GRANT визначаються привілеї доступу з набору, встановленого в стандарті ISO: SELECT – право вибирати дані з таблиці; INSERT – право вставляти в таблицю нові рядки; UPDATE – право змінювати дані в таблиці; DELETE – право вилучати рядки з таблиці; REFERENCES – право посилатися на стовпці зазначеної таблиці в описах вимог підтримки цілісності даних; USAGE – право використовувати домени, перевірки, набори символів і трансляції. Якщо користувачу дається весь <список привілеїв>, то замість їхнього перерахування вказується пропозиція ALL [PRIVILEGES].

Після пропозиції ТО обов'язково наводиться список об'єктів або список користувачів, яким надаються привілеї доступу до таблиці або представлення даних, ім'я яких зазначені після пропозиції ON [TABLE], або дозволу на виконання збережуваної процедури (EXECUTE ON PROCEDURE Ім'я). Список користувачів формується з імен, які зареєстровані в СКБД. Список об'єктів може містити збережувані процедури, тригери й представлення даних, що визначені всередині БД. Пропозиція PUBLIC надає привілей не тільки всім існуючим користувачам, але і всім тим, які будуть визначені в БД згодом.

Фраза WITH GRANT OPTION дозволяє всім наведеним у списку користувачам передавати іншим усі надані їм відносно зазначеного об'єкта привілеї. Якщо ці користувачі також передадуть власні повноваження іншим користувачам з фразою WITH GRANT OPTION, то останні, у свою чергу, також одержать право передавати свої повноваження іншим користувачам. Якщо ця фраза не буде зазначена, одержувач привілею не зможе передати свої права іншим користувачам. Таким чином, власник об'єкта може чітко контролювати, хто одержав право доступу до об'єкта і які повноваження йому надані.

Конструкція GROUP ім'я групи користувачів UNIX надає можливість давати привілеї доступу до таблиць і представлень даних користувачам, що визначені на рівні операційної системи UNIX. Ця опція додана виключно до прикладних програм-клієнтів, що працюють під керуванням цієї операційної системи. Вона не є стандартною для SQL. Ім'я групи повинне бути визначене в /etc/group. З іншими особливостями роботи оператора GRANT можна ознайомитися в документації СКБД.

Оператор REVOKE має такий формат:

Усі параметри ідентичні за змістом параметрам оператора GRANT, крім параметра GRANT OPTION FOR, який вилучає право видачі привілеїв у користувачів зі <списку користувачів>. Привілей може відкликати тільки той, хто його надав. Якщо користувач утрачає привілеї певного виду, то призначені йому привілеї всіх інших видів залишаються у силі.

Наявність операторів CREATE ROLE та DROP ROLE в СКБД не вказує на присутність елементів ролевої моделі доступу до об'єктів БД (дивись <ролеві привілеї> синтаксису оператора GRANT). Ці оператори використовують для утворення груп користувачів, які мають однакові повноваження. Це цілковито укладається в рамки дискреційної моделі. Формат операторів для вибраної вами СКБД треба дивитись у відповідній документації. Наприклад у СКБД Interbase він такий:

CREATE ROLE <ім'я ролі>;

DROP ROLE <ім'я ролі>.

1. Які виникають проблеми у разі обмеження механізмами захисту даних, що вбудовані у СКБД?
2. Від яких факторів залежить швидкість відновлення БД після негативного втручання?
3. Які потенційні загрози БД Вам відомі?
4. Які комп’ютерні засоби контролю застосовуються для захисту БД?
5. Які комп’ютерні засоби контролю використовуються при наданні прав та визначенні користувача?
6. За допомогою якого механізму комп’ютерного контролю можливо обмежити доступ користувача до даних?
7. Які механізми захисту стосуються безпосередньо БД?
8. У чому полягає особливість застосування допоміжних процедур, які відповідають за захист БД?
9. Як класифікуються некомп’ютерні засоби контролю?
10. Яка існує різниця між заходами безпеки та планування захисту від непередбачених обставин?
11. Які некомп’ютерні засоби захисту приміщень та контролю за роботою персоналу Вам відомі?
12. Які Вам відомі юридичні заходи, що забезпечують захист даних?
13. Які особливості захисту інформації статистичних БД?
14. Дайте визначення відомих Вам базових моделей керування доступом до даних.
15. Які особливості захисту має мандатна модель керування доступом до даних?
16. У якій моделі керування доступом до даних і яким чином застосовуються матриця доступу?
17. Які прийоми використовуються для скорочення розмірності матриці доступу?
18. Які переваги та недоліки ролевої моделі доступу до даних Вам відомі?
19. Яким чином компенсуються недоліки ролевої моделі?
20. Які можливості встановлення та скасування привілеїв доступу на рівні СКБД Вам відомі?