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

І навпаки, при дов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;

– невеликi розмiри.

Це означае, що диспетчер доступу мае бути завжди активним i повинен контролювати всi запити на доступ до будь-якого захищеного об'екта, який пiддаеться впливу. Диспетчер доступу мае бути захищений вiд модифiкацii, що для програмно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 ІТС.