Детальний контроль доступу і контексти програми. Частина 4, Інтеграція додатків і даних, Бази даних, статті

Частина 3


Тепер приєднаємося різними користувачами і протестуємо функціональність програми.



SQL> @rls_adams

 SQL> – приєднатися як службовець, у якого немає здатності керувати.

SQL> connect rls_adams/rls_adams
Connected.

SQL> set serveroutput on

 SQL> – Спочатку спробуємо стати менеджером
SQL> – Ми не є менеджером, тому стати ним
SQL> – не дозволяється
SQL> exec rls.set_role( “mgr” )
BEGIN rls.set_role( “mgr” ); END;

*
ERROR at line 1:
ORA-20002: Ви не менеджер
ORA-06512: at “RLS.SET_ROLE”, line 53
ORA-06512: at line 1

Таким чином, результат показує, що не можна отримати роль, не призначену для поточного користувача. Щоб переконатися, що ні до яких немає доступу даними, спробуємо тепер запитати що-небудь, і подивимося, що відбудеться:


 SQL> – тепер подивимося, що відбудеться при спробі виконати
SQL> – що-небудь без отримання ролі

SQL> exec rls.hr_app.listEmps
—— КонтекстСессіі ———-
HR_APP_CTX.EMPNO = 7876
—— Дані таблиці Emp, які можна побачити —–
BEGIN rls.hr_app.listEmps; END;

*
ERROR at line 1:
ORA-28112: помилка при виконанні функції політики
ORA-06512: at “RLS.HR_APP”, line 18
ORA-06512: at line 1

З’явилося повідомлення про помилку. Це повідомлення виникло, тому що так написано предикативна функція:


function select_function( p_schema in varchar2,
                         p_object in varchar2 ) return varchar2

is
begin

    if ( g_sel_pred is NULL )
   then

        if ( sys_context( g_app_ctx, “RoleName” ) = “EMP” )
        then
           …
        elsif ( sys_context( g_app_ctx, “RoleName” ) = “MGR” )
        then

        elsif ( sys_context( g_app_ctx, “RoleName” ) = “HR_REP” )
        then

        else
raise_application_error (-20005, “Рольнеустановлена”);
       end if;
   end if;

    return g_sel_pred;
end;

Отриманий результат – це результат виконання raise_application_error в предикатной функції. Кінцевий користувач отримує повідомлення про помилку ORA-28112. Далі, в наступній секції, ми розглянемо, як виявити ці помилки і налагодити їх.


Далі встановимо таку роль, щоб можна було що-небудь зробити, і спробуємо виконати ці ж операції:



 SQL> – Тепер встановимо коректну роль і виконаємо що-небудь

 SQL> exec rls.set_role( “emp” );
PL/SQL procedure successfully completed.

 SQL> – подивимося контекст і дані,
SQL> – які можна бачити – це тільки один запис

SQL> exec rls.hr_app.listEmps
—— КонтекстСессіі ———-
HR_APP_CTX.ROLENAME = EMP
HR_APP_CTX.EMPNO = 7876
—— Дані таблиці Emp, які можна побачити —–
RLS_ADAMS,1100,RESEARCH

PL/SQL procedure successfully completed.

 SQL> – незважаючи на те, що дані “видно” 
SQL> – їх не можна “змінити”.

SQL> exec rls.hr_app.updateSal
0 rows updated

PL/SQL procedure successfully completed.

 SQL> – не можна видалити ніяку інформацію

 SQL> exec rls.hr_app.deleteAll
0 rows deleted

PL/SQL procedure successfully completed.

 SQL> – не можна нічого створити
SQL> exec rls.hr_app.insertNew(20)
BEGIN rls.hr_app.insertNew(20); END;
*
ERROR at line 1:
ORA-28115: порушення політики з опцією перевірки
ORA-06512: at “RLS.HR_APP”, line 44
ORA-06512: at line 1

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


Далі приєднаємося як MGR і подивимося, що відбудеться:



 SQL> – приєднатися як менеджер
SQL> connect rls_jones/rls_jones
Connected.

 SQL> – Включимо можливість виведення на екран з PL / SQL
SQL> set serveroutput on

 SQL> – Для початку спробуємо стати менеджером
SQL> – ми є менеджером, тому що на цей раз нам дозволено
SQL> – статті

SQL> exec rls.set_role( “mgr” )
PL/SQL procedure successfully completed.

 SQL> – подивимося контекст і дані,
SQL> – які можна бачити. На цей раз – більше одного рядка.

SQL> exec rls.hr_app.listEmps
—— КонтекстСессіі ———-
HR_APP_CTX.ROLENAME = MGR
HR_APP_CTX.EMPNO = 7566
—— Дані таблиці Emp, які можна побачити —–
RLS_SMITH,800,RESEARCH
RLS_JONES,2975,RESEARCH
RLS_SCOTT,3000,RESEARCH
RLS_ADAMS,1100,RESEARCH
RLS_FORD,3000,RESEARCH

PL/SQL procedure successfully completed.

 SQL> – Наступна операція показує, що деякі записи можна 
SQL> – змінити. Потім знову виконаємо listEmps для того, щоб побачити,
SQL> – які рядки змінилися (тільки ті, які підпорядковані безпосередньо)

SQL> exec rls.hr_app.updateSal
2 rows updated

 PL/SQL procedure successfully completed.

 SQL> exec rls.hr_app.listEmps
—— КонтекстСессіі ———-
HR_APP_CTX.ROLENAME = MGR
HR_APP_CTX.EMPNO = 7566
—— Дані таблиці Emp, які можна побачити —–
RLS_SMITH,800,RESEARCH
RLS_JONES,2975,RESEARCH
RLS_SCOTT,9999,RESEARCH
RLS_ADAMS,1100,RESEARCH
RLS_FORD,9999,RESEARCH

PL/SQL procedure successfully completed.

 SQL> – так як ми не є контролером, то, 
SQL> – згідно заданими правилами, не можна нікого видалити

SQL> exec rls.hr_app.deleteAll
0 rows deleted

PL/SQL procedure successfully completed.

 SQL> – так як ми не є контролером, то, 
SQL> – згідно заданими правилами, не можна нікого вкласти
SQL> exec rls.hr_app.insertNew(20)
BEGIN rls.hr_app.insertNew(20); END;
*
ERROR at line 1:
ORA-28115: порушення політики з опцією перевірки
ORA-06512: at “RLS.HR_APP”, line 44
ORA-06512: at line 1

Таким чином, тепер нам, як MGR, можна:




  • Переглядати не тільки свої дані. Видно всіх, хто нам підпорядкований і тих, хто підпорядкований нашим підлеглим і так далі (по ієрархії).
  • Змінювати деякі дані. Точніше, можна змінювати тільки ті записи, які відносяться до наших безпосереднім підлеглим – що й потрібно.
  • Ні над якими даними все ще не можна виконати DELETE або INSERT – що й потрібно

І, нарешті, приєднаємося як контролер і подивимося на поведінку програми при роботі з цією роллю:



 SQL> – приєднатися як контролер
SQL> connect rls_king/rls_king
Connected.

 SQL> – Підключимо можливість виведення на екран з PL / SQL
SQL> set serveroutput on

 SQL> – Для початку, спробуємо стати контролером
SQL> – Тепер ми є контролером, так як
SQL> – стати їм дозволено

SQL> exec rls.set_role( “hr_rep” )
PL/SQL procedure successfully completed.

 SQL> – подивимося контекст і дані,
SQL> – які можна бачити. Цього разу видно всі рядки, так як
SQL> – користувач – контолер.

SQL> exec rls.hr_app.listEmps
—— КонтекстСессіі ———-
HR_APP_CTX.ROLENAME = HR_REP
HR_APP_CTX.EMPNO = 7839
—— Дані таблиці Emp, які можна побачити —–
RLS_CLARK,2450,ACCOUNTING
RLS_KING,5000,ACCOUNTING
RLS_MILLER,1300,ACCOUNTING
RLS_SMITH,800,RESEARCH
RLS_JONES,2975,RESEARCH
RLS_SCOTT,9999,RESEARCH
RLS_ADAMS,1100,RESEARCH
RLS_FORD,9999,RESEARCH
RLS_ALLEN,1600,SALES
RLS_WARD,1250,SALES
RLS_MARTIN,1250,SALES
RLS_BLAKE,2850,SALES
RLS_TURNER,1500,SALES
RLS_JAMES,950,SALES

PL/SQL procedure successfully completed.

 SQL> – наступна операція показує, що можна змінити будь-який запис
SQL> – у кожному відділі, так як користувач для всіх
SQL> – є контролером
SQL> – далі знову запустимо listEmps, щоб побачити, які
SQL> – рядки змінилися (всі)

SQL> exec rls.hr_app.updateSal
14 rows updated

PL/SQL procedure successfully completed.

 SQL> – так як користувач – контролер, то він може
SQL> – видалити кого-небудь згідно заданими правилами
SQL> – При видаленні ВСІХ не видаляється “я”,
SQL> – тобто поточний користувач

SQL> exec rls.hr_app.deleteAll
13 rows deleted

PL/SQL procedure successfully completed.

 SQL> – так як користувач – контролер, то він може 
SQL> – вставити кого-небудь згідно заданими правилами

SQL> exec rls.hr_app.insertNew(20)
PL/SQL procedure successfully completed.

 SQL> – подивимося на результат змінити, видалити
SQL> – і подальшої вставки

SQL> exec rls.hr_app.listEmps
—— КонтекстСессіі ———-
HR_APP_CTX.ROLENAME = HR_REP
HR_APP_CTX.EMPNO = 7839
—— Дані таблиці Emp, які можна побачити —–
RLS_KING,9999,ACCOUNTING
,1111,RESEARCH
PL/SQL procedure successfully completed.

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


Обробка помилок та налагодження


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


Під час розробки процедур детального контролю доступу можуть з’явитися чотири основних коду помилок Oracle:




  • ORA-28110: функція політики або пакет <імя_функциі> містить помилки. Це означає, що пов’язаний з політикою пакет або функція містять помилки і не можуть бути скомпільовані. Помилки можна побачити, якщо виконати “show errors function <імя_функциі>” або “show errors package body <Имя_Пакета>“.
  • ORA-28112: помилка при виконанні функції політики. Виникає, якщо помилка з’являється під час виконання предикатной функції. Це може статися, наприклад, коли при виконанні пропозиції SELECT INTO, знаходиться всередині PL / SQL-функції, рядка не знайдені, і для цієї ситуації немає обробника винятків. Функція поширює виняток NO_DATA_FOUND назад в точку виклику (в ядро ​​бази даних), і база даних ініціює помилку ORA-28112.
  • ORA-28113: предикат політики містить помилки. Ця помилка виникає, коли предикативна функція успішно повертає умова where, але при його додаванні до SQL-запиту всередині нього виявляються помилки. Наприклад, в тому випадку, коли повертається умова where типу “x = 5”, а таблиця, з якої воно асоціюється, не має стовпчика “x”, буден отриманий код помилки ORA-28113.
  • ORA-28106: вхідна значення аргументу # 2 невірно. Ця помилка виникає при зверненні до dbms_session.set_context, якщо ім’я атрибута не є правильним ідентифікатором Oracle. Імена атрибутів контексту додатки повинні бути правильними ідентифікаторами (тобто їх можна використовувати для призначення імен стовпців таблиць або PL / SQL-змінних). Необхідно лише змінити ім’я атрибута. Наприклад, в меню можуть використовуватися атрибути ‘SEL’, ‘INS’, ‘UPD’ і ‘DEL’ замість ‘SELECT’, ‘INSERT’ і так далі, тому що ‘SELECT’ не є правильним ім’ям ідентифікатора Oracle.

При написанні предикатних функцій я часто користуюся однією утилітою – це пакет ‘debug’. Цей пакет, автором якого є Крістофер Бек (Christopher Beck) з Oracle, дозволяє вставити в код пропозиції команду ‘print’. Крім того, цей пакет дозволяє широко використовувати пропозиції типу:



create function foo …
as
   …
begin
debug.f (‘Входвпроцедуру foo’);
     if ( some_condition ) then
         l_predicate := ‘x=1’;
     end if; 

 Debug.f (‘Переходквозвратупредіката “% s”‘, l_predicate);
     return l_predicate;
end;

Таким чином, робота процедури debug.f схожа на с-функцію printf, а сама вона використовує пакет UTL_FILE. На сервері бази даних вона створює керовані програмістом файли трасування. Файли трасування містять налагодження пропозиції, які можна використовувати для перегляду виконаних дій при виконанні коду. Так як програмний код знаходиться в ядрі бази даних, налагодження може виявитися складною. Наявність файлів трасування може заощадити багато часу. Скрипти, які можна завантажити (див. далі в цьому ж розділі) містять налагоджувальний пакет та коментарі з його встановлення і використання.


“За” і “Проти”


Існує багато за цю можливість і зовсім небагато проти. Фактично, складно взагалі знайти хоча одне проти цієї можливості. Як би там не було, вони перераховані нижче:





















За

Проти


Спрощує розробку програми – Переносить управління доступом з програми на рівень даних.



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


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



Допускає значні зміни політики безпеки без впливу на клієнтські програми.



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



Добре працює. Використання контекстів програми дозволяє скористатися перевагами розділяється SQL.



Скрипти


Для того, щоб отримати всі скрипти, які використовуються в цій статті, завантажте tar-файл. Будь ласка, неодмінно прочитайте файл README.TXT, що входить до складу архіву. Tar-файл можна відкрити під Windows за допомогою WinZip версії 6.0 і вище.


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


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

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

Ваш отзыв

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

*

*