Визначення, мета, завдання та види захисту інформації 6 страница

6) вибір апаратного і програмного забезпечення для реалізаці функцій ЗІ.

Для формального доведення у пунктах 3 і 5 можуть використову ватися математичні методи, якщо сама ПБ була визначена достатнь строго, можливо, у термінах деякої формальної мови. Популярні підх~ ди до формалізації ґрунтуються на станах системи або на її діях. У пі ході, який ґрунтується на станах, функціонування системи розгляд ється як послідовність станів, де стан - це набір значень множин змінних. Підхід, який ґрунтується на діях, розглядає діяльність си стеми у вигляді набору реакцій на події. Ці два різних підходи певному сенсі еквівалентні. Дії можуть бути змодельовані зміною стан а стани можуть бути представлені класами еквівалентності послідо ностей дії. Однак описані підходи звичайно базуються на різних фо мальних теоріях. Моделювання станів у більшості випадків грун ється на логіці, а специфікації представляються формулами в деяк' логічній системі. При моделюванні дії звичайно користуються алге рою, а специфікаціями є об'єкти, з якими оперують алгебраїчни методами. Основою доведень, які проводяться в п. З і 5, як правило, набір теорем. Однак проводити подібний аналіз для кожної систе складно і дорого. Крім того, методика проведення аналізу держави систем - конфіденційна інформація. Вихід було знайдено в тому, * умови теорем, які доводять підтримку ПБ, формулюються без дов дення у вигляді стандарту. Саме такий підхід уперше застосува.і американці 1983 року, опублікувавши відкрито проект стандарту з в електронних системах обробки даних («Оранжева книга»), де ефо мульовано вимоги гарантованої підтримки двох класів політик - ди креційної та мандатної. Пізніше цей метод було застосовано в 1987 для опису гарантовано захищених розподілених мереж, у я підтримуються ті самі політики, а в 1991 p.- для опису вимог гар товано захищених баз даних. Цей же шлях використали канадц європейські держави, створивши свої стандарти з ЗІ. В Україні так розроблено стандарт захисту, аналогічний канадському. Наведені вище підходи до формалізації політики ЗІ дають можливість проана­лізувати розроблені стандарти на повноту і коректність.

4.2. Види політик безпеки

Серед ПБ найбільш відомі дискреційна, мандатна та рольо­ва. Перші дві досить давно відомі і досліджені [6, 7], а рольова політика (недавнім досягненням теорії та практики захисту інформації [32].

Основою дискреційної політики безпеки (ДПБ) є дискреційне управління доступом (Discretionary Access Control - DAC), яке визнача­ється двома властивостями:

• всі суб'єкти і об'єкти повинні бути однозначно ідентифіковані;

• права доступу суб'єкта до об'єкта системи визначаються на основі деякого зовнішнього відносно системи правила.

Назва пункту є дослівним перекладом терміна Discretionary policy, ще один варіант перекладу - розмежувальна політика. Ця політика -одна з найпоширеніших у світі, в системах по умовчанню мається на увазі саме ця політика.

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

Існує декілька варіантів задання матриці доступу.

1.Листи можливостей (privilege list, profile): для кожного суб'єк­та створюється лист (файл) усіх об'єктів, до яких він має доступ.

2.Листи контролю доступу (access control list): для кожного об'єкта створюється список усіх суб'єктів, що мають доступи до нього.

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

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

1. Один із найсуттєвіших недоліків цього класу політик - те, що вони
ін- витримують атак за допомогою «Троянського коня». Це, зокрема,
- іпачає, що СЗІ, яка реалізує ДПБ, погано захищає від проникнення

ірусів у систему й інших засобів прихованої руйнівної дії.

2. Наступна проблема ДПБ - автоматичне визначення прав. Так як
(і(> (ктів багато і їх кількість безперервно змінюється, то задати за-
піл легідь вручну перелік прав кожного суб'єкта на доступ до об'єктів
неможливо. Тому матриця доступу різними способами агрегується,
■ иприклад, як суб'єкти залишаються тільки користувачі, а у відпові-
ді^ клітину матриці вставляються формули функцій, обчислення
имі\ визначає права доступу суб'єкта, породженого користувачем, до
■ 'єкта. Звичайно, ці функції можуть змінюватися з часом. Зокрема

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

4.При використанні ДПБ виникає питання визначення правил по­ширення прав доступу й аналізу їх впливу на безпеку АС. У загаль­ному випадку при використанні ДПБ перед органом, який її реалізує і який при санкціонуванні доступу суб'єкта до об'єкта керується деяким набором правил, стоїть задача, яку алгоритмічно розв'яза­ти неможливо: перевірити, призведуть його дії до порушень без­пеки чи ні.

Отже, матриця доступів не є тим механізмом, який дозволив би реалізувати ясну і чітку СЗІ в АС. Більш досконалою ПБ виявилася мандатна ПБ.

Основу мандатної (повноважної) політики безпеки (МПБ) ста­новить мандатне управління доступом (Mandatory Access Control -МАС), яке передбачає, що:

• всі суб'єкти і об'єкти повинні бути однозначно ідентифіковані;

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

• кожному об'єкту системи присвоєна мітка секретності, яка ви­значає цінність інформації, що міститься в ньому - його рівень секретності в АС;

• кожному суб'єкту системи присвоєна мітка секретності, яка визначає рівень довіри до нього в АС - максимальне значення мітки секретності об'єктів, до яких суб'єкт має доступ; мітка секретності суб'єкта називається його рівнем доступу.

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

Цінність інформаційних об'єктів часто дуже важко визначити. Однак досвід показує, що в будь-якій АС майже завжди для будь-якої пари об'єктів X та Y можна сказати, який із них більш цінний. Тобтй можна вважати, що таким чином фактично визначається деяка однозначна функція с(Х), яка дозволяє для будь-яких об'єктів X і я сказати, що коли Y більш цінний об'єкт, ніж X, то с(У) > с(Х). I HaenaJ ки, з огляду на однозначність, якщо с(У) > с(Х), то Y - більш цінний об'єкт, ніжХ. Тоді потік інформації від Хдр /дозволяється, якщо с(Х) < c(Y), і не дозволяється, якщо с(Х) > с(У).

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

МПБ в сучасних системах захисту на практиці реалізується ман­датним контролем. Він реалізується на найнижчому апаратно-про­грамному рівні, що дозволяє досить ефективно будувати захищене середовище для механізму мандатного контролю. Пристрій мандат­ного контролю називають монітором звернень. Мандатний контроль ще називають обов'язковим, оскільки його має проходити кожне звернення суб'єкта до об'єкта, якщо вони знаходяться під захистом СЗІ. Організується він так: кожний об'єкт має мітку з інформацією Про свій рівень секретності; кожний суб'єкт також має мітку з інформацією про те, до яких об'єктів він має право доступу. Мандат­ний контроль порівнює мітки і приймає рішення про допуск.

Найчастіше МПБ описують у термінах, поняттях і визначеннях Властивостей моделі Белла-Лападула [5]. У рамках цієї моделі дово-Ьиться важливе твердження, яке вказує на принципову відмінність кистем, що реалізують мандатний захист, від систем з дискреційним Ьахистом: якщо початковий стан системи безпечний і всі переходи Системи зі стану до стану не порушують обмежень, сформульова­них ПБ, то будь-який стан системи безпечний.

Наведемо ряд переваг МПБ порівняно з ДПБ.

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

2.Правила МПБ більш ясні і прості для розуміння розробниками і Користувачами АС, що також є фактором, який позитивно впливає на рівень безпеки системи.

3.МПБ стійка до атак типу «Троянський кінь».

4.МПБ допускає можливість точного математичного доведення, то дана система в заданих умовах підтримує ПБ.

\ Однак МПБ має дуже серйозні вади - вона складна для практич­ної реалізації і вимагає значних ресурсів обчислювальної системи. Це ■ ов'язано з тим, що інформаційних потоків у системі величезна кпи.кість і їх не завжди можна ідентифікувати. Саме ці вади часто Ііінажають її практичному використанню.

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

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

Розглянемо ще один вид ПБ - рольову ПБ. Рольову політику безпеки (РПБ) (Role Base Access Control - RBAC) не можна віднести ані до дискреційної, ані до мандатної, тому що керування доступом у ній здійснюється як на основі матриці прав доступу для ролей, так і за допомогою правил, які регламентують призначення ролей користува­чам та їх активацію під час сеансів [32]. Отже, рольова модель є цілком новим типом політики, що базується на компромісі між гнучкістю керування доступом, яка є характерною для ДПБ, і жорст­кістю правил контролю доступу, яка притаманна МПБ.

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

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

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

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

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

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

У моделі РПБ визначаються такі множини:

U- множина користувачів;

R - множина ролей;

Р - множина повноважень на доступ до об'єктів, що подається, наприклад, у вигляді матриці прав доступу;

S - множина сеансів роботи користувачів із системою.

Для перелічених множин визначаються такі відношення:

PAczPxR- відображає множину повноважень на множину ролей, встановлюючи для кожної ролі набір наданих їй пов­новажень;

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

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

user. З¹—> U— для кожного сеансу s ця функція визначає користу­вача и, який здійснює цей сеанс роботи з системою: user{s) = и;

roles: S—+R - для кожного сеансу s ця функція визначає набір ро­лей з множини R, що можуть бути одночасно досту­пні користувачу и в цьому сеансі: roles(s) = {r \ (user(s), г) є UA}; permissions: S —* Р - для кожного сеансу s ця функція задає набір доступних у ньому повноважень, який визначається як сукупність повноважень усіх ролей, що беруть участь у цьому сеансі: permissions(s) = {р \ (р, г) є РА}. Як критерій безпеки рольової моделі використовується таке пра­вило: система вважається безпечною, якщо будь-який користувач системи, що працює в сеансі s, може здійснити дії, які вимагають повноважень р тільки в тому випадку, колир є permissions^).

З формулювання критерію безпеки моделі РПБ випливає, що управління доступом здійснюється головним чином не за допомогою призначення повноважень ролям, а шляхом задання відношення UA, яке призначає ролі користувачам, і функції roles, що визначає доступ­ний у сеансі набір ролей. Тому численні інтерпретації рольової моде­лі відрізняються видом функцій user, roles і permission, а також обмеженнями, що накладаються на відношення РА та UA. Як прикла­ди розглядається рольова політика управління доступом з ієрархіч­ною організацією ролей, а також кілька типових обмежень на відно­шення РА та UA і функції user та roles, що найчастіше зустрічаються на практиці.

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

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

Крім того, РПБ може використовуватися одночасно з іншими ПБ, коли повноваження ролей, що призначаються користувачам, контро­люються ДПБ або МПБ, що дає змогу будувати багаторівневі схеми контролю доступу.

5 МЕХАНІЗМИ ЗАХИСТУ ІНФОРМАЦІЇ ВІД НЕСАНКЦІОНОВАНОГО ДОСТУПУ

5.1. Керування доступом

Доступ до інформації (access to information) - вид взає­модії двох об'єктів КС, унаслідок якого створюється потік інформації під одного об'єкта до іншого і/або відбувається зміна стану системи. Доступ характеризується типом та атрибутами [1-3].

Тип доступу (access type) - сутність доступу до об'єкта, що харак­теризує зміст здійснюваної взаємодії, а саме: проведені дії, напрям потоків інформації, зміни в стані системи (наприклад, читання, запис, запуск на виконання, видалення, дозапис).

Атрибут доступу (tag, access mediation information) - будь-яка по­в'язана з об'єктом КС інформація, яка використовується для керу­вання доступом.

Кожному доступу передує запит на доступ. Запит на доступ (access request) - звернення одного об'єкта КС до іншого з метою отримання певного типу доступу.

Керування доступом (access control) - це сукупність заходів із ви­значення повноважень і прав доступу, контролю за додержанням ПРД. Воно включає питання обмеження доступу, розмежування доступу, розподіл доступу (привілеїв), контроль та облік доступу.

Існує чотири основні способи керування доступом:

• фізичний, коли суб'єкти звертаються до фізично різних об'єктів;

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

• логічний, коли суб'єкти отримують доступ до спільного об'єкта в рамках однієї ОС;

• криптографічний, коли права доступу визначаються наявністю ключа розшифрування.

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

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

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

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

• технічне обслуговування АС у процесі експлуатації має вико­нуватися окремим персоналом без доступу до інформації, що підлягає захисту;

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

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

• реєстрація і документування технологічної та оперативної інфор­мації повинні бути розділені.

Розмежування доступу користувачів повинно відбуватися за та­кими параметрами:

• за видом, характером, призначенням, ступенем важливості та секретності інформації;

• за способами її обробки: зчитувати, записувати, модифікувати, виконати команду;

• за ідентифікатором термінала;

• за часом обробки тощо.

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

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

Контроль та облік доступу реалізується за допомогою такої по­слуги, як реєстрація. Реєстрація (audit, auditing) - це процес розпізна­вання, фіксування й аналізу дій і подій, що пов'язані з дотриманням політики безпеки інформації. Використання засобів перегляду й ана­лізу журналів, а особливо засобів настроювання механізмів фіксування подій, повинно бути прерогативою спеціально авторизованих корис­тувачів. Часто [ 12] сам процес реєстрації підрозділяється на протоко­лювання та аудит. Під протоколюванням розуміється збір і нагрома­дження інформації про події, що відбуваються в інформаційній си­стемі. Аудит - це аналіз накопиченої інформації. Оскільки в норматив­них документах України [17-20] визначено тільки поняття реєстрації, далі буде використовуватися саме воно. Опис усього, що пов'язано з реєстрацією, який наводиться нижче, цілком відповідає [17-20].

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

• Для жодного з рівнів послуги не встановлюється ніякого фіксованого набору контрольованих подій [12], оскільки для кожної КС їх перелік може бути специфічним. Критична для безпеки подія визначається як гака, що пов'язана зі звертанням до якої-небудь послуги безпеки чи від­булася в результаті виконання якої-небудь функції СЗІ, чи що-небудь інше, що хоча прямо і не обумовлено функціонуванням механізмів, які реалізують послуги безпеки, але може призвести до порушення полі­тики безпеки. Остання група подій визначається як така, що маєфункції забезпечення безпеки інформації повинні виконуватися спеціальним підрозділом в організації (власнику АС, обчислю­вальної мережі і т. п.) - службою безпеки;

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

• реєстрація і документування технологічної та оперативної інфор­мації повинні бути розділені.

Розмежування доступу користувачів повинно відбуватися за та­кими параметрами:

• за видом, характером, призначенням, ступенем важливості та секретності інформації;

• за способами її обробки: зчитувати, записувати, модифікувати, виконати команду;

• за ідентифікатором термінала;

• за часом обробки тощо.

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

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

Контроль та облік доступу реалізується за допомогою такої по­слуги, як реєстрація. Реєстрація (audit, auditing) - це процес розпізна­вання, фіксування й аналізу дій і подій, що пов'язані з дотриманням політики безпеки інформації. Використання засобів перегляду й ана­лізу журналів, а особливо засобів настроювання механізмів фіксування подій, повинно бути прерогативою спеціально авторизованих корис­тувачів. Часто [ 12] сам процес реєстрації підрозділяється на протоко­лювання та аудит. Під протоколюванням розуміється збір і нагрома­дження інформації про події, що відбуваються в інформаційній си­стемі. Аудит - це аналіз накопиченої інформації. Оскільки в норматив­них документах України [17-20] визначено тільки поняття реєстрації, далі буде використовуватися саме воно. Опис усього, що пов'язано з реєстрацією, який наводиться нижче, цілком відповідає [17-20].

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

Для жодного з рівнів послуги не встановлюється ніякого фіксованого набору контрольованих подій [12], оскільки для кожної КС їх перелік може бути специфічним. Критична для безпеки подія визначається як гака, що пов'язана зі звертанням до якої-небудь послуги безпеки чи від­булася в результаті виконання якої-небудь функції СЗІ, чи що-небудь інше, що хоча прямо і не обумовлено функціонуванням механізмів, які реалізують послуги безпеки, але може призвести до порушення полі­тики безпеки. Остання група подій визначається як така, що має непря­ме відношення до безпеки. Для з'ясування ступеня небезпеки таких по­дій часто є необхідним їх аналіз у контексті інших подій, що відбулися.

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

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

• політика реєстрації в СЗІ визначає перелік подій, що реєструються;

• СЗІ здійснює реєстрацію подій, що мають безпосереднє чи не­пряме відношення до безпеки;

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

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

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