11.2.2. Принципи створення захищених систем

В основу технології створення захищених систем, за думкою фахівців, покладено такі п'ять принципів [97].

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

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

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

♦ Принцип адекватності. Для забезпечення реальної здатності протидіяти ата­кам необхідно виключити всі чинники, що спричиняють виникнення вразли­востей, адже саме на їх використанні базуються механізми реалізації атак. За даними досліджень [96, 98] основною причиною появи вразливостей є непо­слідовність у реалізації контролю доступу. Наявні системи містять привілейо­вані засоби та служби, які передають користувачам частину своїх повноважень, оминаючи засоби контролю. Найочевидніший приклад — механізм SUID/SGID у системі UNIX. Будь-яка програмна помилка в таких засобах призводить до появи вразливостей. Відтак переважну більшість причин появи вразливостей можна усунути, реалізувавши в системі контроль доступу на основі універ­сального інтерфейсу та єдиного механізму взаємодії. Також необхідно мінімі­зувати об'єм довіреного коду самих засобів захисту задля зменшення ймовір­ності появи в них помилок.

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

11.2.3. Адміністративні заходи захисту

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

Розрізняють такі основні адміністративні заходи захисту ОС. Постійний контроль коректності функціонування ОС (зокрема, її підсистеми захисту). Для повноти контролю необхідно здійснювати такі заходи:

♦ реєстрація подій у системі (Event Logging);

♦ контроль цілісності файлів, зокрема тих, що містять програмний код ком­понентів ОС;

♦ тестування компонентів ОС на коректність функціонування.

Усі ці заходи неможливі без наявності спеціалізованих компонентів K33 ОС, що реалізують необхідні функції.

Організація й підтримка адекватної політики безпеки. Запроваджена в ОС по­літика безпеки фактично визначає:

• які користувачі мають доступ і до яких компонентів ОС;

• які користувачі мають доступ і до яких об'єктів, що знаходяться під керу­ванням ОС (наприклад, до файлів на диску, зовнішніх носіїв, пристроїв введення-виведення тощо);

• яким чином користувачі ОС ідентифікують себе і які вимоги висунуто до їхніх атрибутів доступу;

• які події потрібно реєструвати в системних журналах.

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

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

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

Постійний контроль за зміненням конфігураційних даних і політики безпе­ки ОС. Фактично йдеться про контроль настроювань засобів захисту та інших компонентів ОС. Ці дані належать до так званої технологічної інформації K33, яка, безумовно, підлягає захисту. Зміни в цій інформації вказують засо­бам захисту ОС на змінення політики безпеки. У разі правильного настрою­вання підсистеми реєстрації подій такі зміни в системі не можуть залишитися непоміченими. Але часто порушник, який змінює технологічні дані, намага-ється «замести сліди» шляхом знищення відповідних записів у журналах реє­страції. Тому необхідно здійснювати постійний контроль за змінами, що від­буваються у системі. Окрім того, слід організувати автоматичне сцовіщення адміністраторів про критичні з точки зору безпеки зміни в системі й такий спосіб зберігання даних реєстрації, який би був стійким до компрометації конкретної системи (наприклад, віддзеркалювати журнали реєстрації на інші комп'ютери або друкувати на принтері записи про найважливіші події).