11.3.4. Аудит

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

До реалізації підсистеми аудита висувається низка вимог [91].

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

• Жодний суб'єкт в ОС не може редагувати та видаляти окремі записи в журна­лах безпеки (це стосується й самої ОС).

• Лише користувачі-аудитори, які мають відповідний привілей, можуть пере­глядати журнали безпеки. Зауважимо, що в ідеалі аудитори можуть не нале­жати до адміністраторів ОС, точніше, множина адміністраторів і множина аудиторів можуть не перетинатися.

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

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

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

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

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

Щоб аудитори могли реалізувати всі зазначені вимоги, підсистема аудита ОС має надавати їм зручні інтерфейси для роботи з журналами безпекиІ для на­строювання політики аудита.