Управління доступом. Основні поняття

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

Ставлення "суб'єкти-об'єкти" можна представити у вигляді матриці доступу, в рядках якої перераховані суб'єкти, у стовпцях - об'єкти, а в клітинах, розташованих на перетині рядків і стовпців, записані додаткові умови (наприклад, час і місце дії) і дозволені види доступу

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

Для систем управління реляційними базами даних об'єкт - це база даних, таблиця, подання, збережена процедура. До таблиць застосовні операції пошуку, додавання, модифікації і видалення даних, у інших об'єктів інші види доступу.

Різноманітність об'єктів і застосовних до них операцій призводить до принципової децентралізації логічного керування доступом. Кожен сервіс має сам вирішувати, чи дозволити конкретному суб'єкту ту чи іншу операцію. Теоретично це узгоджується з сучасним об'єктно-орієнтованим підходом, на практиці ж призводить до значних труднощів. Головна проблема в тому, що до багатьох об'єктів можна отримати доступ за допомогою різних сервісів (можливо, при цьому доведеться подолати деякі технічні труднощі). Так, до реляційних таблиць можна добратися не тільки засобами СУБД, але і шляхом безпосереднього читання файлів або дискових розділів, підтримуваних операційною системою (розібравшись попередньо в структурі зберігання об'єктів бази даних). В результаті при завданні матриці доступу потрібно брати до уваги не тільки принцип розподілу привілеїв для кожного сервісу, але і існуючі зв'язки між сервісами (доводиться піклуватися про узгодженість різних частин матриці). Аналогічна труднощі виникає при експорті / імпорті даних, коли інформація про права доступу, як правило, втрачається (оскільки на новому сервісі вона не має сенсу). Отже, обмін даними між різними сервісами представляє особливу небезпеку з точки зору управління доступом, а при проектуванні і реалізації різнорідної конфігурації необхідно подбати про погоджений розподілі прав доступу суб'єктів до об'єктів і про мінімізацію числа способів експорту / імпорту даних.При прийнятті рішення про надання доступу звичайно аналізується наступна інформація:ідентифікатор суб'єкта (ідентифікатор користувача, мережеву адресу комп'ютера і т.п.). Подібні ідентифікатори є основою довільного (або дискреційного) управління доступом;атрибути суб'єкта (мітка безпеки, група користувача і т.п.). Мітки безпеки - основа примусового (мандатного) управління доступом.

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

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

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

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

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

Зручною надбудовою над засобами логічного керування доступом є обмежуючий інтерфейс, коли користувача позбавляють самої можливості спробувати здійснити несанкціоновані дії, включивши в число видимих ​​йому об'єктів тільки ті, до яких він має доступ. Подібний підхід зазвичай реалізують в рамках системи меню (користувачеві показують лише допустимі варіанти вибору) або за допомогою обмежуючих оболонок, таких як restricted shell в ОС Unix.

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

Рольове керування доступом. При великій кількості користувачів традиційні підсистеми управління доступом стають вкрай складними для адміністрування. Число зв'язків у них пропорційно добутку кількості користувачів на кількість об'єктів. Необхідні рішення в об'єктно-орієнтованому стилі, здатні цю складність знизити.

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

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

Рольовий доступ розвивається більше 10 років (сама ідея ролей, зрозуміло, значно старше) як на рівні операційних систем, так і в рамках СУБД і інших інформаційних сервісів. Зокрема, існують реалізації рольового доступу для Web-серверів. У 2001 році Національний інститут стандартів і технологій США запропонував проект стандарту рольового управління доступом (див. http://csrc.nist.gov/rbac/), основні положення якого ми й розглянемо.

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

Між ролями може бути визначене відношення часткового порядку, зване спадкуванням. Якщо роль r2 є спадкоємицею r1, то всі права r1 приписуються r2, а всі користувачі r2 приписуються r1. Очевидно, що спадкування ролей відповідає спадкоємства класів в об'єктно-орієнтованому програмуванні, тільки правам доступу відповідають методи класів, а користувачам - об'єкти (екземпляри) класів.

Ставлення спадкування є ієрархічним, причому права доступу і користувачі поширюються по рівнях ієрархії назустріч один одному. У загальному випадку спадкування є множинним, тобто в однієї ролі може бути кілька попередниць (і, природно, кілька спадкоємиць, яких ми будемо називати також наступницею).Можна уявити собі формування ієрархії ролей, починаючи з мінімуму прав (і максимуму користувачів), приписуваних ролі "співробітник", з поступовим уточненням складу користувачів і додаванням прав (ролі "системний адміністратор", "бухгалтер" і т.п.), аж до ролі "керівник" (що, втім, не означає, що керівникові надаються необмежені права; як і іншим ролям, у відповідності з принципом мінімізації привілеїв, цієї ролі доцільно дозволити тільки те, що необхідно для виконання службових обов'язків). Фрагмент подібної ієрархії ролей показаний на рис. 10.3.Рис. 10.3. Фрагмент ієрархії ролей.

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

Статичне поділ обов'язків накладає обмеження на приписування користувачів ролям. У простому випадку членство в деякій ролі забороняє приписування користувача певного безлічі інших ролей. У загальному випадку дане обмеження задається як пара "безліч ролей - число" (де безліч складається, принаймні, з двох ролей, а число має бути більше 1), так що ніякої користувач не може бути приписаний вказаною (або більшого) числу ролей із заданої множини. Наприклад, може існувало п'ять бухгалтерських ролей, але політика безпеки допускає членство не більше ніж у двох таких ролях (тут число = 3).При наявності спадкування ролей обмеження набуває дещо складніший вигляд, але суть залишається простою: при перевірці членства в ролях потрібно враховувати приписування користувачів ролям-спадкоємицям.

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

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

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

Інформаційні функції (одержання відомостей про поточну конфігурацію з урахуванням відносини спадкування). Тут проводиться поділ на обов'язкові і необов'язкові функції. До числа перших належать отримання списку користувачів, приписаних ролі, і списку ролей, яким приписано користувач.

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

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