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

Комплекс програмно-апаратних засобів й організаційних (процедурних) рішень по захисту інформації від несанкціонованого доступу (НСД) включає 4 підсистеми: керування доступом; реєстрації й обліку; криптографічну; забезпечення цілісності.

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

Забезпечення захисту даних на робочих ЕОМ може бути описане в такий спосіб:

1. Захист змісту даних (data content protection) поєднує функції, процедури й засоби захисту, які попереджають несанкціоноване розкриття конфіденційних даних й інформації в БД.

2. Засоби контролю доступу (access control security service) дозволяють доступ до даних тільки повноважних об'єктів у відповідності зі строго визначеними правилами й умовами.

3. Керування потоком захищених даних (security-consistent flow of data) при передачі з одного сегмента БД в іншій забезпечує переміщення даних разом з механізмами захисту, властивим вихідним даним.

4. Запобігання можливості виявлення (prevention of inference) конфіденційних значень із даних, що містяться в регулярних або статистичних БД, у результаті виявлення статистично достовірної інформації.

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

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

7. Запобігання створення несанкціонованої інформації (presentation of unauthorized information generation) припускає наявність засобів, які попереджають, що об'єкт одержує (генерує) інформацію, що перевищує рівень прав доступу, і здійснює це, використовуючи логічний зв'язок між даними в БД. Слід зазначити, що застосування криптографічних методів здатне істотно підвищити стійкість захисту баз даних від несанкціонованого доступу (НСД).

Для більше повного захисту необхідно ввести наступні рівні:

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

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

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

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

Безпека і санкціонування доступу на SQL

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

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

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

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

Привілеї надаються за допомогою запису 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 користувачі.

Наприклад, можна відібрати в користувача cook право зміни значень стовпця Праця: REVOKE UPDATE (Праця) ON Блюда FROM cook;