Детальний контроль доступу і контексти додатки (Частина 1)
У цій статті розглянуті два нових механізму Oracle8i: детальний контроль доступу (Fine Grained Access Control) і контексти захищених додатків (Secure Application Contexts). При спільному використанні вони забезпечують нові якісні можливості для забезпечення інформаційної безпеки бази даних.
У різних виданнях детальний контроль доступу може бути названий по-різному. Нижче перераховані його синоніми:
Детальний контроль доступу (Fine Grained Access Control - технічна назва)
У двох словах, детальний контроль доступу в Oracle8i - це можливість під час роботи динамічно приєднати предикат (пропозиції where) як до одного, так і до всіх запитам до таблиці або подання. Таким чином, з'явилася можливість процедурної модифікації запиту в процесі виконання. Можна обчислити, хто виконує запит, звідки запит виконується, коли почалося виконання запиту, і сформувати предикат, який відповідає цим критеріям. При використанні Контекстів Додатки можна непомітно через оточення (наприклад, через роль, призначену користувачеві додатки) додати додаткову інформацію, і отримати доступ до неї через процедуру або предикат.
Прикладом детального контролю доступу може служити політика безпеки, яка визначає, які рядки можуть бути доступні різним групам користувачів. Політика безпеки формує предикат, вид якого залежить від поєднаного з базою користувача і групи, до якої він належить. Детальний контроль доступу дозволяє при введенні запиту "select * from emp" різними користувачами перетворити його до наступного вигляду:
Запит динамічно переписується в
Контролер може бачити будь-якого в заданому відділі. Цей приклад знайомить з синтаксисом отримання змінних контексту програми - вбудованою функцією SYS_CONTEXT ().
Є багато причин, щоб використовувати цей механізм. Найбільш поширені з них:
- Легко підтримується. Детальний контроль доступу дозволяє мати тільки одну таблицю і одну збережену керуючу процедуру, які замінять використання безлічі уявлень. Створення безлічі уявлень зазвичай призводить до збільшення числа об'єктів бази даних, так як для кожної групи користувачів потрібне створення окремого подання. Наприклад, в описаному вище прикладі зі службовцями, менеджерами і контролерами в звичайній системі необхідно створити 3 подання бази даних. Якщо буде потрібно ще одна група користувачів, то доведеться додати ще один набір уявлень, яким треба буде керувати і підтримувати. Якщо політика безпеки зміниться (тобто, буде потрібно, щоб менеджери бачили не тільки своїх безпосередніх підлеглих, але і на 2 рівня нижче), необхідно буде перебудувати уявлення бази даних, після чого всі об'єкти, які посилаються на ці уявлення, стануть недійсними.
- Здійснюється на сервері. З огляду на складність управління і підтримки великої кількості уявлень, розробники раз по раз прагнуть закладати логіку додатка в саме додаток. Додатки переглядають, хто приєднаний до бази даних, що він запитує, і виконують відповідний запит. Це захищає дані, але тільки тоді, коли доступ до них здійснюється через цю програму. Це знижує можливість використання засобів виконання запитів і генерації звітів, а також інших засобів обробки даних. Підвищується також ймовірність отримання спотворених даних, так як для того, щоб зробити спотворення, досить підключитися до бази даних через будь-яке інше засіб, відмінне від розглянутого додатки, і зробити запит. Завдяки ж включенню в базу даних логіки безпеки, тобто механізму, який визначає, які дані може бачити користувач, - виможете бути впевнені, що дані будуть захищені незалежно від використовуваного засоби доступу до них, і звернення можна здійснювати за допомогою будь-якого засобу, з якого можливий доступ до даних.
- Заборона на з'єднання з базою даних від імені узагальнених користувачів. Завдяки детальному контролю доступу кожен користувач повинен з'єднуватися з базою даних під своїм ім'ям. У цьому випадку забезпечується повна підзвітність - можна відстежувати дії на рівні користувача. Раніше багато додатків при роботі з різними уявленнями даних для різних користувачів повинні були застосовувати узагальнених користувачів бази даних, відповідно вибраним даними. Наприклад, для наведеного вище випадку службовець / менеджер / контролер в додатку має бути створено три облікових записи. Кожен службовець повинен використовувати обліковий запис "Службовець". Кожен менеджер повинен використовувати обліковий запис "Менеджер". Кожен контролер повинен використовувати обліковий запис "Контролер". Це унеможливлює враховувати дії на рівні справжніх користувачів
- Спрощення розробки програми. Детальний контроль доступу забирає логіку безпеки з логіки додатка. Для підтримки безпеки даних розробник програми може сконцентруватися на самому додатку, а не на логіці низкоуровневого доступу до даних. Так як детальний контроль доступу повністю здійснюється на сервері, то додатки безпосередньо успадковують цю логіку. Раніше розробники програми повинні були вбудовувати логіку в додаток, роблячи додаток все більш складним, спочатку для розробки і особливо складним для його подальшої підтримки. Якщо з програми можливий доступ до даних, причому до одних і тих же даних і з кількох точок прикладання, то найпростіше зміна політики безпеки може торкнутися багато дюжин модулів програми. Завдяки застосуванню детального контролю доступу. зміни в політиці безпеки не впливає на модулі програми.
- Застосування розвинених засобів розробки програми. У багатьох середовищах політика безпеки по початку ще належним чином не визначена і через деякий час може змінитися. Якщо відбувається злиття компаній або інші структурні зміни або вводяться правила секретності, то політику безпеки необхідно змінити. Завдяки тому, що управління доступом здійснюється на рівні, близькому до даних, можна створити умови для розвитку програми з мінімальним впливом, і на нього, і на засоби розробки. Це є однією з причин для того, щоб перейти до автоматичного використання як нової логіки, так і всіх програм та інструментів, що дозволяють здійснювати доступ до бази даних з вбудованою нової логікою.
У Oracle8i існує два типи детального контролю доступу:
Для того, щоб скористатися цією можливістю, розробник, крім стандартних ролей connect і resource, повинен мати такі привілеї:
EXECUTE_CATALOG_ROLE. Дозволяє розробнику виконувати функції і процедури пакета dbms_rls. Інший варіант - можна, приєднавшись як SYS, передати привілей тільки на пакет: grant execute on dbms_rls to<учетная_запись>.
CREATE ANY CONTEXT: Дозволяє розробнику створювати контексти додатки.
Контексти додатки створюються простий SQL-командою
OurApp - це ім'я контексту, а Our_Context_Pkg - це PL / SQL-пакет, через який встановлюються значення контексту. Можливість використання контекстів додатки для детального контролю доступу має велике значення з двох причин:
Забезпечується гарантований спосіб установки змінних простору імен. Встановлювати значення цього контексту може тільки PL / SQL-пакет, пов'язаний з контекстом. В цьому випадку гарантується цілісність значень контексту. Так як контексти призначені для обмеження або дозволу доступу до даних, цілісність значень контексту повинна бути забезпечена.
Якщо потрібно, щоб політика безпеки дозволяла користувачу, не є RLS_ADMIN, бачити тільки такі рядки, "власником" яких він є, то необхідно виконати команду: \
SQL> create function my_security_function (p_schema in varchar2,
2 p_object in varchar2) return varchar2
5 if (user = 'RLS_ADMIN') then
8 return 'owner = USER';
Предикат "where owner = USER" буде динамічно додаватися до всіх запитам по таблиці, з якою пов'язана ця функція, що значно зменшує кількість рядків, доступних користувачеві. Предикат NULL (порожньо) повертається тільки в тому випадку, коли на даний момент до бази даних приєднаний користувач RLS_ADMIN. Порожній повертається предикат виглядає як "1 = 1" або "TRUE".
Для того, щоб пов'язати цю функцію з таблицею, необхідно використовувати PL / SQL-процедуру "dbms_rls.add_policy". Наприклад, є такий таблиця: