Як організувати подвійну парольний захист даних в Oracle









 
  … І одне тільки слово твердить:
"Лімпопо, Лімпопо, Лімпопо!"
 
Корній Чуковський, "Айболить"

Зміст



В основі регламентації доступу до даних в Oracle лежить парольний захист. У найбільш поширеному випадку для роботи з даними у своїй схемі користувач Oracle зобов'язаний вказати пароль. Однак пароль користувача – Всього-на-всього один ешелон захисту. Пароль іноді можна підглянути, або ненавмисно повідомити іншій особі. А чи можна ввести додатковий захист, утруднює несанкціонований доступ? Відповідь позитивна: за допомогою такого поняття, як "роль".

Введення


В основі регламентації доступу до даних в Oracle лежить парольний захист. У найбільш поширеному випадку для роботи з даними у своїй схемі користувач Oracle зобов'язаний вказати пароль. Хоча Oracle і надає можливість зміцнити парольний захист спеціальними засобами ("профіль"), пароль користувача все одно залишається лише одним ешелоном захисту. Пароль іноді можна підглянути, або ненавмисно повідомити іншій особі. А чи можна ввести додатковий захист, утруднює несанкціонований доступ?

У деяких прикладних системах, наприклад, використовується практика "роздвоєного" пароля. Підключитися до системи можуть лише одночасно дві фізичні особи: один знає одну частину пароля, а інший – іншу. Хоча ймовірність змови двох залишається, ризик несанкціонованого доступу істотно знижується. Чи можна в Oracle організувати "роздвоєння" пароля або щось подібне?

Виявляється, можна: за допомогою "ролі". Роль відома фахівцям з Oracle тим, що дозволяє технологічно організувати групову передачу користувачам привілеїв (повноважень) для роботи з об'єктами в БД. Це зручно, а іноді практично безальтернативно, наприклад, якщо користувачів Oracle заведено багато. Рідше помічаються два інших властивості ролі:


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

Приклад


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

CONNECT / AS SYSDBA

CREATE USER adam IDENTIFIED BY eva;

GRANT CREATE SESSION TO adam;

CREATE ROLE tablecreator IDENTIFIED BY say123;

GRANT tablecreator TO adam;

Перевірка:

SQL> CONNECT adam/eva
Connected.
SQL> SELECT * FROM session_roles;

ROLE

TABLECREATOR

Переведемо роль (тільки її) у спочатку відключене стан:

CONNECT / AS SYSDBA

ALTER USER adam DEFAULT ROLE ALL EXCEPT tablecreator;

Конструкція DEFAULT ROLE допускає вказівку також просто ALL, NONE або ж явного перерахування ролей, які ми хочемо зробити спочатку активними для всіх сеансів користувача. У конкретному прикладі з рівним успіхом можна було вказати DEFAULT ROLE NONE, просто наведений варіант більш типовий на практиці.

Знову перевірка:

SQL> CONNECT adam/eva
Connected.
SQL> SELECT * FROM session_roles;

no rows selected

SQL> SET ROLE tablecreator IDENTIFIED BY say123;

Role set.

SQL> SELECT * FROM session_roles;

ROLE

TABLECREATOR

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

Фірма Oracle рекомендує створювати для окремих видів додатків окремі ролі (хоча б і складові, тобто включають у свій склад будь-які інші ролі) і розпоряджатися ними способом, зазначеним вище. Якщо програма буде активізувати роль самостійно, то людина, що запускає додаток, може пароля ролі і не знати, а знання одного тільки пароля користувача Oracle виявиться недостатнім для роботи з базою даних поза програми, наприклад, з SQL * Plus. З іншого боку ми зовсім не зобов'язані повідомляти, додаток, що вживають пароль ролі для її активації, про пароль користувача: тепер він може бути вказаний окремо людиною, що встановлює з'єднання з СУБД. Техніку такого підходу можна опрацювати й розвинути далі.

Динаміка ролі та інші корисні споживчі якості


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

SQL> SELECT * FROM session_privs;

PRIVILEGE

CREATE SESSION

SQL> HOST sqlplus / AS SYSDBA

……………………………………………….
……………………………………………….
Connected to:
Oracle Database 10g Enterprise Edition …………….
With the Partitioning, Oracle Label Security, ………

SQL> GRANT CREATE TABLE TO tablecreator;

Grant succeeded.

SQL> EXIT
Disconnected from Oracle Database 10g …………….
With the Partitioning, Oracle Label Security, ……..

SQL> /

PRIVILEGE

CREATE SESSION
CREATE TABLE

Привілей CREATE TABLE з'явилася в рамках колишнього, продовжує свою роботу, сеансу користувача ADAM.

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


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


Посилання по темі



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


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

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

Ваш отзыв

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

*

*