8.7.2Ролеве управління доступом

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

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

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

У 2001 році Національний інститут стандартів і технологій США запропонував проект стандарту ролевого управління доступом, основні положення якого ми і розглянемо.

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

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

Вводиться поняття розділення обов'язків, причому в двох видах: статичному і динамічному.

Статичне розділення обов'язків накладає обмеження на приписування користувачів ролям. У простому випадку членство в деякій ролі забороняє приписування користувача певній множині інших ролей.

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

8.8Протоколювання і аудит

8.8.1 Основні поняття

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

У кожного сервісу свій набір можливих подій, але у будь-якому випадку їх можна розділити на:

• зовнішні (викликані діями інших сервісів);

• внутрішні (викликані діями самого сервісу);

• клієнтські (викликані діями користувачів і адміністраторів).

Аудит - це аналіз накопиченої інформації, що проводиться оперативно, у реальному часі або періодично (наприклад, раз в день). Оперативний аудит з автоматичним реагуванням на виявлені нештатні ситуації називається активним.

Реалізація протоколювання і аудиту вирішує наступні задачі:

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

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

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

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

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

Розумний підхід до згаданих питань стосовно операційних систем пропонується в "Оранжевій книзі", де виділені наступні події:

• вхід в систему (успішний чи ні);

• вихід з системи;

• звернення до віддаленої системи;

• операції з файлами (відкрити, закрити, перейменувати, видалити);

• зміна привілеїв або інших атрибутів безпеки (режиму доступу, рівня благонадійності користувача і т.п.).

При протоколюванні події рекомендується записувати, принаймні, наступну інформацію:

• дата і час події;

• унікальний ідентифікатор користувача - ініціатора дії;

• тип події;

• результат дії (успіх або невдача);

• джерело запиту (наприклад, ім'я терміналу);

• імена об'єктів, що торкнулися (наприклад, відкритих файлів);

• опис змін, внесених до баз даних захисту (наприклад, нова мітка безпеки об'єкту).

Ще одне важливе поняття, що фігурує в "Оранжевій книзі", - вибіркове протоколювання, як відносно користувачів (уважно стежити тільки за підозрілими), так і відносно подій.

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

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