Контроль доступу на основі правил (вихідні коди)

Введення


Ви, можливо, знайомі з функціями контролю доступу, що надаються операційною системою. Вони зазвичай виконують авторизаційні перевірки для системних викликів і операційних запитів до ресурсів, яким у файловій системі присвоєно ім'я. Програмістам звичайно не потрібно перевіряти, чи має користувач, що запустив програму, право на читання файлу даних або установку системного часу. Про це подбає операційна система, і вона ж дасть знати через значення, що повертається, дозволена операція або заборонена. Наприклад, UNIX виконує вимоги, що задаються ID власника файлу, ID групи і правами доступу, пов'язаними з реальною або фактичної ідентифікацією користувача. Хоча така побудова і є простим, воно може бути недостатньо ефективним, змушуючи деякі UNIX-системи розширювати його за допомогою списків контролю доступу та інших механізмів. Інші операційні системи використовують більш складні моделі безпеки. Все ж модель безпеки зазвичай застосовується до файлових об'єктів і призначеним для користувача облікових записів, відомим системі (тим, які з'являються в / etc / passwd чи в NIS).


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


Контроль авторизації для Web-сервісів


Програми повинні іноді посилювати власні вимоги щодо контролю доступу до тих ресурсів, за які вони відповідають, і до облікових записів користувачів, не розпізнаваним операційною системою. Найяскравішим прикладом тому є Web-сервер Apache, який може бути налаштований так, щоб дозволяти або відхиляти HTTP-запити до окремих своїх ресурсів. Записи в секретному файлі паролів створюють облікові записи Web-сервера, які повністю відокремлені від записів, відомих операційній системі. Аналогічно, списки членства в групах створюються спеціально для використання Web-сервером. Адміністратор Apache може використовувати ці імена з директивами Require, Allow і Deny сервера, щоб описати, хто може (або не може) мати доступ до ресурсу. Так як операційна система тут мало чим може допомогти, програмісти Apache реалізували свою власну підсистему авторизації.


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


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


Тим не менш, багатьом серверним додаткам, в тому числі і Web-додатків, потрібні можливості з перевірки авторизації, які виходять далеко за рамки описаних можливостей. Розглянемо додаток на базі Web-сервісу, доступне для виконання будь-кому, але "усвідомлює", що користувачі мають різні можливості або привілеї. Можливо, найпростіший приклад – це програма, у якому тільки певні користувачі можуть мати доступ до адміністративних функцій, – всі інші користувачі не тільки не можуть виконувати ці функції, але навіть не повинні мати можливості їх бачити (їх не повинно бути в меню або, принаймні, вони не повинні бути доступні для вибору). Інший типовий приклад – це додаток з профілями для кожного користувача, які може змінювати лише його власник або, можливо, адміністратор додатки. Часто застосування повинне обмежувати доступ до своїх даних для певних користувачів. Цей вид перевірки авторизації може бути названий тонким контролем доступу, так як він застосовується запущеної програмою практично до будь-яких видів ресурсів, з якими працює програма.


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


Більшість мов програмування, в тому числі і Perl, в цьому відношенні не сильно допомагають. Вони надають простий рівень, що лежить поверх того, що надає система, що лежить в основі. Мова Java ™ включає середовище авторизації, але, звичайно, це не допоможе програмісту Perl або C / C + +.


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


Тонкий контроль авторизації


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


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


При створенні меню може з'явитися код, схожий з Листингом 1.


Лістинг 1. Побудова меню допустимих операцій (невірний спосіб)





for (op = 0; op < n_operations; op++) {
if (op == CREATE_OP && is_admin(current_user))
add_operation_to_menu(menu, op);
else if ((op == UPDATE_OP // op == DELETE_OP)
& & (Is_owner (current_page, current_user) / / is_admin (current_user)))
add_operation_to_menu(menu, op);
else
add_operation_to_menu(menu, op);
}

Хоча, на перший погляд, Лістинг 1 може здатися вірним, він помилковий. Той код змусив пройти кілька версій цього документа, перш ніж проблема була виявлена, показуючи, наскільки легко зробити помилки через неуважність під час написання такого виду перевірки. Лістинг 2 є правильним:


Лістинг 2. Побудова меню допустимих операцій (вірний спосіб)





for (op = 0; op < n_operations; op++) {
if (op == CREATE_OP && is_admin(current_user))
add_operation_to_menu(menu, op);
else if ((op == UPDATE_OP // op == DELETE_OP)
& & (Is_owner (current_page, current_user) / / is_admin (current_user)))
add_operation_to_menu(menu, op);
else if (op! = CREATE_OP & & op! = UPDATE_OP & & op! = DELETE_OP)
add_operation_to_menu(menu, op);
}

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


Лістинг 3. Перевірка для операцій з обмеженим доступом





if (op == CREATE_OP && !is_admin(current_user))
raise_exception(“Operation not permitted”)
else if ((op == UPDATE_OP // op == DELETE_OP)
& &! (Is_owner (current_page, current_user) / / is_admin (current_user)))
raise_exception(“Operation not permitted”)

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


Перевірка авторизації на основі правил


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


Ми пропонуємо середу авторизації на основі правил (керовану даними), з наступними можливостями:



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



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


DACScheck: середа авторизації


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


Щоб продемонструвати, як використовувати dacscheck, Давайте знову звернемося до псевдокод, який виконує побудова меню, представлене в Лістингу 2, на цей раз на мові Perl.


Лістинг 4. Використання DACScheck на Perl




                 use DACScheck.pm;

# Повідомляємо dacscheck, які правила слід використовувати
dacscheck_rules(“/usr/local/wiki_app/acls”);

# Будуємо список операцій для меню.
for ($op = 0; $op < $n_operations; $op++) {
# Предметом інтересу, використовуваним для відшукання відповідного правила,
# Є довільно іменоване "/ <username> / menu".
my $object = “/$ENV{“DOCUMENT_ROOT”}/menu”;
my $result = dacscheck_cgi($object);

# Доступ до об'єкту надається, тільки якщо повернуто значення 1.
if ($result == 1) {
add_operation_to_menu($menu, $op);
}
}


Модуль на Perl з назвою DACScheck.pm забезпечує спрощений інтерфейс для dacscheck, Який включає в себе dacscheck_cgi(). Крім присвоєння імені об'єкту функція вказує dacscheck, Що вона виконується в рамках CGI-контексту і повинна використовувати значення REMOTE_USER як позначення для користувача, що робить запит. Apache автоматично присвоює REMOTE_USER, якщо користувач пройшов аутентифікацію.


Кожен ресурс, керований dacscheck, Має відповідне правило. Хоча правила можуть зберігатися і бути доступні різними способами, кожне правило зазвичай зберігається у звичайному текстовому файлі, а правила для взаємопов'язаних ресурсів зазвичай зберігаються в каталогах з загальним коренем. Правило виражається XML-документом, який може включати С-подібні вирази вільного формату. Вирази можуть посилатися на змінні, для яких примірник створюється з контексту виконання, включаючи змінні оточення і аргументи Web-сервісу, а також широкий спектр вбудованих функцій, орієнтованих на обробку рядків і тести на ідентифікацію високого рівня. Від існуючого мови розширень, такого як Tool Command Language (Tcl), було вирішено відмовитися, щоб зберегти цю здатність без ускладнень. Більш складний тест може бути виконаний за допомогою окремої програми, навіть будучи викликаним допомогою HTTP. Правило також може вказувати на інше правило, даючи адміністратору можливість делегувати відповідальність за правила.


Давайте тепер поглянемо на те, як може виглядати правило. Правило повідомляє dacscheck як визначити, чи слід дозволити або відмовити запиту. Ми припускаємо, що користувач вже увійшов в систему і, отже, REMOTE_USER присвоєно значення. Ми також припускаємо, що OP – це аргумент, який вибирає операцію, а PAGE – це аргумент, який ідентифікує власника сторінки Wiki.


Лістинг 5. Приклад файлу правил dacscheck





<acl_rule>
<services>
<service url_expr=”/${Args::PAGE}/menu”/>
</services>

<rule order=”allow,deny”>
<precondition>
<predicate>
${Args::OP} eq “CREATE_OP”
</predicate>
</precondition>

<allow>
dacs_admin()
</allow>
</rule>

<rule order=”allow,deny”>
<precondition>
<predicate>
${Args::OP} eq “UPDATE_OP” or ${Args::OP} eq “DELETE_OP”
</predicate>
</precondition>

<allow>
dacs_admin() or ${Args::PAGE} eq ${Env::REMOTE_USER}
</allow>
</rule>

<rule order=”allow,deny”>
<allow>
user(“any”)
</allow>
</rule>

</acl_rule>


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


Елемент service вказує dacscheck, До якого ресурсу застосовно правило. Цією рядку зіставляється аргумент з dacscheck_cgi().


Це правило контролю доступу складається з трьох елементів rule: Перший вибирається, тільки якщо аргумент OP дорівнює CREATE_OP, Другий вибирається, тільки якщо аргумент OP дорівнює UPDATE_OP або DELETE_OP; А третій вибирається, тільки якщо інші два не вибрані. Атрибут order служить тим же цілям, що і директива Order в Apache: він встановлює режим роботи за замовчуванням і порядок, в якому обробляються елементи allow і deny.


У цьому прикладі, перше правило дозволяє доступ, тільки якщо функція dacs_admin() повертає True. Ця функція шукає ідентифікацію користувача. Друге правило дозволяє доступ для адміністратора та власника сторінки Wiki. Третє правило дозволяє доступ будь-кому, так як була запрошена операція без обмеження доступу.


Якщо політику контролю доступу для Wiki потрібно буде змінити, вам потрібно буде лише змінити правило. Результат досягається негайно і застосовується до всіх посилань на правило. Якщо адміністратору потрібно заборонити доступ до сторінки для запитів, що виходять з певного діапазону IP-адрес, слід додати приблизно такий код:


Лістинг 6. Додаткове правило, для заборони доступу





<rule order=”allow,deny”>
<precondition>
<predicate>
from(“10.0.0/24”)
</predicate>
</precondition>
</rule>

Упорядкування allow,deny за замовчуванням забороняє доступ, тому будь-який запит, витікаючий з IP-адреси в заданому діапазоні, буде заборонений.


Існує безліч ситуацій, коли може застосовуватися така форма перевірки авторизації. Наприклад, ftp-демон (ftpd) Може з успіхом скористатися цією можливістю. Він може бути доопрацьований, щоб застосовувати правила для дозволу або заборони операцій (put, get, cd, І т.д.), на підставі ідентифікації користувача або контекстно залежної інформації, яку можна перевірити за допомогою правил. Наприклад, закачування даних може бути дозволена лише у певні години або доступ до каталогу може бути обмежений тільки для певних користувачів або користувачів, що з'єднуються з певних IP-адрес.


Висновки


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


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


Ще одна споріднена програма – dacstransform, Це утиліта для перетворення документа на основі правил. Використовуючи ті ж самі правила, що й dacscheck, Вона може редагувати, вставляти і заміняти текст у документі з розміткою. Кожне перетворення залежить від правила, яке обчислюється в момент виконання, дозволяючи отримати з розміченого новий документ, що призначений для певного користувача або контексту.


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


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

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

Ваш отзыв

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

*

*