banner banner banner
Комплексні системи захисту інформації. Проектування, впровадження, супровід
Комплексні системи захисту інформації. Проектування, впровадження, супровід
Оценить:
 Рейтинг: 0

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


– «модульнiсть» КЗЗ;

– атрибути доступу;

– керування доступом.

Крiм того, КЗЗвiд НСД повинен реалiзувати:

– концепцiю диспетчера доступу;

– реестрацiю дiй користувачiв;

– послуги безпеки (функцii захищеностi);

– гарантii реалiзацii послуг безпеки.

1. Безперервний захист

КЗЗ повинен забезпечити захист iнформацii в ІТС протягом всього перiоду ii iснування. З моменту створення об'екта ІТС (або його iмпорту) до його знищення (або експорту) всi запити на доступ до нього (або вiд нього) повинен контролювати КЗЗ.

Головним аспектом е те, що не повинно iснувати можливостi одержати доступ до об'екта (або вiд об'екта) в обхiд КЗЗ. Для безперервного захисту об'ектiв КЗЗ повинен забезпечувати свою цiлiснiсть i керованiсть.

Другим аспектом е те, що особливе значення набувае визначення дiючих за умовчанням правил, якi визначають початковi умови, за яких починаеться iснування об'екта всерединi ІТС.

2. «Модульнiсть» КЗЗ

КЗЗ повинен мати модульну структуру. На рiвнi розгляду архiтектури ІТС «модульнiсть» означае, що КЗЗ мае бути реалiзований як набiр вiдносно незалежних частин. Кожна з цих частин повинна взаемодiяти з iншими тiльки через добре визначенi iнтерфейси.

На рiвнi розгляду архiтектури КЗЗ «модульнiсть» означае, що КЗЗ мае функцiонувати як сукупнiсть логiчних груп програмного та апаратного забезпечення так, щоб кожна група вирiшувала певнi завдання. Для ПЗ, наприклад, в простiшому випадку пiд цим слiд розумiти, що подiбнi функцii мають бути зосередженi в певних вихiдних файлах.

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

3. Атрибути доступу

Для реалiзацii полiтики безпеки КЗЗ повинен забезпечити iзоляцiю об'ектiв всерединi сфери управлiння та гарантувати розмежування запитiв доступу i керування потоками iнформацii мiж об'ектами. Для цього всi об'екти ІТС повиннi мати атрибути доступу. Атрибути доступу об'екта – це iнформацiя, яка дозволяе КЗЗ iдентифiкувати об'ект i перевiряти легальнiсть запитiв доступу до нього.

Кожний об'ект ІТС повинен мати певний набiр атрибутiв доступу, який включае унiкальний iдентифiкатор та iншу iнформацiю, що визначае його права доступу i/або права доступу до нього. Атрибут доступу – термiн, що використовуеться для опису будь-якоi iнформацii, яка використовуеться при керуваннi доступом i зв'язана з користувачами, процесами або пасивними об'ектами. Вiдповiднiсть атрибутiв доступу i об'екта може бути як явною, так i неявною. Атрибути доступу об'екта е частиною його подання в ІТС.

Коли користувачi або процеси намагаються одержати доступ до пасивних об'ектiв, механiзми, що реалiзують керування доступом, на пiдставi полiтики безпеки i перевiрки атрибутiв доступу можуть «прийняти рiшення» про легальнiсть запиту. Використовуючи набiр атрибутiв доступу вiдповiдно до прийнятоi полiтики безпеки, можна реалiзувати довiрче або адмiнiстративне керування доступом, контроль за цiлiснiстю та iншi види керування доступом.

Для вiдображення функцiональностi ІТС у простiр, в якому не розглядаються права власностi, використовуеться концепцiя матрицi доступу. Проста матриця доступу – це таблиця, яка мiстить iдентифiкатори користувачiв, об'ектiв та видiв доступу до них.

Матриця доступу може бути:

– двомiрною (наприклад, користувачi/об'екти або процеси/об'екти);

– тримiрною (користувачi/процеси/об'екти);

– повною, тобто мiстити вздовж кожноi з осей всi iснуючi iдентифiкатори ІТС.

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

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

Є два види або принципи керування доступом в ІТС: довiрче та адмiнiстративне.

Довiрче керуванням доступом – це таке керування, при якому КЗЗ дозволяе звичайним користувачам управляти потоками iнформацii в системi мiж iншими користувачами i об'ектами свого домену (наприклад, на пiдставi права володiння об'ектами). Тобто визначення повноважень користувачiв не вимагае адмiнiстративного втручання.

Адмiнiстративне керуванням доступом – це таке керування, при якому КЗЗ дозволяе тiльки спецiально уповноваженим користувачам (адмiнiстраторам) управляти потоками iнформацii в системi мiж користувачами i об'ектами.

Прикладом реалiзацii адмiнiстративного керування доступом може служити механiзм, коли у виглядi атрибутiв доступу використовуються мiтки, що вiдображають мiру конфiденцiйностi iнформацii (об'екта) i рiвень допуску користувача. Таким чином, КЗЗ на пiдставi порiвняння мiток об'екта i користувача визначае, чи можна виконати запит користувача.

Система, що реалiзуе адмiнiстративне керування, повинна гарантувати, що потоки iнформацii всерединi системи установлюються адмiнiстратором i не можуть бути змiненi звичайним користувачем. З iншого боку, система, що реалiзуе довiрче керування доступом, дозволяе звичайному користувачу модифiкувати, в т. ч. створювати новi потоки iнформацii всерединi системи.

Створення додаткових потокiв iнформацii може бути зумовлене:

– модифiкацiею атрибутiв доступу користувача, процесу або пасивного об'екта;

– створенням нових об'ектiв (включаючи копiювання iснуючих);

– експортом або iмпортом об'ектiв.

Сталiсть атрибутiв доступу

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

І навпаки, при довiрчому керуваннi доступом звичайний користувач може змiнювати атрибути доступу об'екта, що належить йому.

Створення нових об'ектiв

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

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

Експорт i iмпорт об'ектiв

При адмiнiстративному керуваннi атрибути доступу об'екта мають зберiгатись пiд час його експорту на зовнiшнiй носiй. Додатково повиннi iснувати правила для присвоення атрибутiв доступу iмпортованому об'екту.

І навпаки, при довiрчому керуваннi доступом об'ект може бути експортований без збереження атрибутiв доступу. Додатково може iснувати можливiсть iмпорту звичайним користувачем об'екта з наступним присвоенням йому атрибутiв доступу на розсуд користувача.

Проте, навiть вiдповiдно до полiтики довiрчого керування доступом, атрибути доступу об'екта пiд час виконання деяких операцiй, наприклад, пiд час його резервного копiювання, мають зберiгатися. Якщо об'ект буде коли-небудь вiдновлено з резервноi копii, то його атрибути доступу також мають бути вiдновленi.

5. Концепцiя диспетчера доступу

При реалiзацii КЗЗ використовуеться концепцiя диспетчера доступу, що повинна забезпечити:

– безперервний i повний захист;

– захищенiсть вiд модифiкацii;