Сервер аутентифікації Kerberos. 7 страница

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

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

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

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

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

8.6. Рольове керування доступом

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

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

Право доступу 1 Право доступу 2 ••• Право доступу М

 

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

Рольовий доступ розвивається більше 10 років (сама ідея ролей, зрозуміло, є значно старшою) як на рівні операційних систем, так і у рамках СУБД й інших інформаційних сервісів. Зокрема, існують реалізації рольового доступу для Web-серверів.

У 2001 році Національний інститут стандартів і технологій США запропонував проект стандарту рольового керування доступом (див. http://csrc.nist.gov/rbac/), основні положення якого ми й розглянемо.

Рольове керування доступом оперує наступними основними поняттями: • користувач (людина, інтелектуальний автономний агент і т.п.);

* сеанс роботи користувача;

* роль (звичайно визначається відповідно до організаційної структури);

* об'єкт (сутність, доступ до якої розмежовується; наприклад, файл ОС або таблиця СУБД);

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

* право доступу (дозвіл виконувати певні операції над певними об'єктами).

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

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

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

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

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

Рис. 8.3. фрагмент ієрархії ролей

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

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

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

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

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

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

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

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

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

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

8.7. Керування доступом в Java-середовищі

Java - це об'єктно-орієнтована система програмування, тому й керування доступом у ній спроектоване й реалізовано в об'єктному стилі. Із цієї причини розглянути Java-середовище для нас дуже важливо. Докладно про Java-технологію й безпеку Java-середовища розказано в статті А. Таранова й В. Цишевского "Java у три роки" (Jet Info, 1998, 11-12). З дозволу авторів далі використовуються її фрагменти.

Насамперед, зупинимося на еволюції моделі безпеки Java. В JDK 1.0 була запропонована концепція "пісочниці" (sandbox) - замкненого середовища, у якій виконуються потенційно ненадійні програми (апплети, що надійшли по мережі). Програми, що розташовуються на локальному комп'ютері, уважалися абсолютно надійними, і їм було доступно все, що доступно віртуальній Java-машині.

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

Щоб упоратися із цією проблемою, в JDK 1.1 увели розподіл джерел (точніше, розповсюджувачів) апплетів на надійні й ненадійні (джерело визначалося по електронному підпису). Надійні апплети прирівнювалися в правах до "рідного" коду. Зроблене послаблення вирішило проблеми тих, кому прав не вистачало, але захист залишився неешелонованим й, отже, неповним.

В JDK 1.2 сформувалася модель безпеки, використовувана й в Java 2. Від моделі "пісочниці" відмовилися. Сформувалися три основні поняття:

* джерело програми;

* право й сукупність;

* політика безпеки.

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

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

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

* Java-програми виступають не від імені користувача, що їх запустив, а від імені джерела програми. (Це досить глибоке й прогресивне трактування, якщо її правильно розвинути, див. наступний розділ);

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

* механізми безпеки забезпечені об'єктною обгорткою.

Досить важливим поняттям у моделі безпеки JDK. 1.2 є контекст виконання. Коли віртуальна Java-машина перевіряє права доступу об'єкта до системного ресурсу, вона розглядає не тільки поточний об'єкт, але й попередні елементи стеку викликів. Доступ надається тільки тоді, коли потрібним правом володіють усі об'єкти в стеці. Розроблювачі Java називають це реалізацією принципу мінімізації привілеїв.

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

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

Розробники Java усвідомлювали цю проблему. Щоб упоратися з нею, вони ввели поняття привілейованого інтервалу програми. При виконанні такого інтервалу контекст ігнорується. Привілейована програма відповідає за себе, не цікавлячись передісторією. Аналогом привілейованих програм є файли з бітами переустановки ідентифікатора користувача/групи в ОС Unix, що зайвий раз підтверджує традиційність підходу, реалізованого в JDK 1.2. Відомі загрози безпеки, які привносять подібні файли. Тепер цей не найкращий засіб ОС Unix перейшов до Java.

8.8. Можливий підхід до керування доступом у розподіленому об'єктному середовищі

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

* традиційні моделі (дискреційна й мандатна);

* модель "пісочниця" (запропонована для Java-середовища й близької їй системі Safe-Tel);

* модель фільтрації (використана в міжмережевих екранах).

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

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

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

Кожен контейнер дозволяє опитати набір ДЕ об'єктів-компонентів, що задовольняють деякій умові. Результат, що повертає, у загальному випадку залежить від зухвалого об'єкта.

Об'єкти ізольовані один від одного. Єдиним видом міжоб'єктної взаємодії є виклик методу.

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

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

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

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

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

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

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

Структуруємо сукупність всіх ПРД, виділивши чотири групи правил:

* політика безпеки контейнера;

* обмеження на викликуваний метод;

* обмеження на зухвалий метод;

* обмеження, що накладають добровільно.

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

Нехай метод МІ об'єкта 01 у крапці PI свого виконання повинен викликати метод М об'єкта О. Правила, яким повинен задовольняти М, можна розділити на три наступні підгрупи:

* правила, що описують вимоги до формальних параметрів виклику;

* правила, що описують вимоги до семантики М;

* реалізаційні правила, що накладають обмеження на можливі реалізації М;

* правила, що накладають обмеження на викликуваний об'єкт О.

Метод М об'єкта О. потенційно доступний для виклику, може висувати до

зухвалого об'єкта наступні групи вимог:

• правила, що описують вимоги до фактичних параметрів виклику;

• правила, що накладають обмеження на зухвалий об'єкт.

Можна виділити три різновиди предикатів, що відповідають семантиці й/або особливостям реалізації методів:

* твердження про фактичні параметри виклику методу М у крапці Р1;

* предикат, що описує семантику методу М;

* предикат, що описує особливості реалізації методу М.

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

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

 

Розділ 9. Протоколювання й аудит, шифрування, контроль цілісності

 

9.1. Протоколювання й аудит. Основні поняття

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

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

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

* забезпечення підзвітності користувачів й адміністраторів;

* забезпечення можливості реконструкції послідовності подій;

* виявлення спроб порушень інформаційної безпеки;

* надання інформації для виявлення й аналізу проблем. Протоколювання вимагає для своєї реалізації здорового глузду. Які події

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

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

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

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

* звертання до вилученої системи;

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

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

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

* дата й час події;

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

тип події;

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

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

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

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

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

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

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

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

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

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

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

9.2. Активний аудит. Основні поняття

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

Завдання активного аудиту - оперативно вияшіяти підозрілу активність і надавати засоби для автоматичного реагування на неї.

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

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

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

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

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

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

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

Переваги сигнатурного методу - висока продуктивність, невелика кількість помилок другого роду, обгрунтованість рішень. Основний недолік -невміння виявляти невідомі атаки й варіації відомих атак.

Основні переваги статистичного підходу - універсальність й обґрунтованість рішень, потенційна здатність виявляти невідомі атаки, тобто мінімізація кількості помилок першого роду. Мінуси полягають у відносно високій частці помилок другого роду, поганій роботі у випадку, коли неправомірне поводження є типовим, коли типова поведінка плавно змінюється від легального до неправомірного, а також у випадках, коли типового поводження немає (як показує статистика, таких користувачів приблизно 5-10%).

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

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