Слідуючи швидше історичною, ніж наочній логіці, ми переходимо до розгляду технічної специфікації X.800, що з’явилася небагато чим пізніше за "Оранжеву книгу", але вельми повно і глибоко тією, що потрактувала питання інформаційної безпеки розподілених систем.
Рекомендації X.800 - документ досить обширний. Ми зупинимося на специфічних мережних функціях (сервісах) безпеки, а також на необхідних для їх реалізації захисних механізмах.
Виділяють наступні сервіси безпеки і виконувані ними ролі:
Аутентифікація. Даний сервіс забезпечує перевірку автентичності партнерів по спілкуванню і перевірку автентичності джерела даних. Аутентифікація партнерів по спілкуванню використовується при встановленні з’єднання і, мабуть, періодично під час сеансу. Вона служить для запобігання таких загроз, як маскарад і повтор попереднього сеансу зв’язку. Аутентифікація буває односторонньою (звичайно клієнт доводить свою автентичність серверу) і двосторонньою (взаємної).
Управління доступом. Забезпечує захист від несанкціонованого використовування ресурсів, доступних по мережі.
Конфіденційність даних. Забезпечує захист від несанкціонованого отримання інформації. Окремо згадаємо конфіденційність трафіку (це захист інформації, яку можна одержати, аналізуючи мережні потоки даних).
Цілісність даних підрозділяється на підвиди залежно від того, який тип спілкування використовують партнери - зі встановленням з’єднання або без нього, чи захищаються всі дані або тільки окремі поля, чи забезпечується відновлення у разі порушення цілісності.
Неотказуємость (неможливість відмовитися від досконалих дій) забезпечує два види послуг: неотказуемость з підтвердженням автентичності джерела даних і неотказуемость з підтвердженням доставки. Побічним продуктом неотказуемости є аутентифікація джерела даних.
В наступній таблиці вказані рівні еталонної семирівневої моделі OSI, на яких можуть бути реалізовані функції безпеки. Відзначимо, що прикладні процеси, у принципі, можуть узяти на себе підтримку всіх захисних сервісів.
|
Таблиця 5.1. Розподіл функцій безпеки по рівнях еталонної семирівневої моделі OSI |
|
|||||||
|
Функції безпеки |
Рівень |
|
||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
|
|
|
Аутентифікація |
- |
- |
+ |
+ |
- |
- |
+ |
|
|
Керування доступом |
- |
- |
+ |
+ |
- |
- |
+ |
|
|
Конфіденційність з’єднання |
+ |
+ |
+ |
+ |
- |
+ |
+ |
|
|
Конфіденційність зовні з’єднання |
- |
+ |
+ |
+ |
- |
+ |
+ |
|
|
Виборча конфіденційність |
- |
- |
- |
- |
- |
+ |
+ |
|
|
Конфіденційність трафіку |
+ |
- |
+ |
- |
- |
- |
+ |
|
|
Цілісність з відновленням |
- |
- |
- |
+ |
- |
- |
+ |
|
|
Цілісність без відновленн |
- |
- |
+ |
+ |
- |
- |
+ |
|
|
Виборча цілісність |
- |
- |
- |
- |
- |
- |
+ |
|
|
Цілісність зовні з’єднання |
- |
- |
+ |
+ |
- |
- |
+ |
|
|
Невідмовність |
- |
- |
- |
- |
- |
- |
+ |
|
"+" даний рівень може надати функцію безпеці;
"-" даний рівень не підходить для надання функцію безпеки.
Для реалізації сервісів (функцій) безпеки можуть використовуватися наступні механізми і їх комбінації:
шифрування;
електронний цифровий підпис;
механізми управління доступом. Можуть розташовуватися на будь-якій із сторін, що беруть участь в спілкуванні, або в проміжній крапці;
механізми контролю цілісності даних. В рекомендаціях X.800 розрізняються два аспекти цілісності: цілісність окремого повідомлення або поля інформації і цілісність потоку повідомлень або полів інформації. Для перевірки цілісності потоку повідомлень (тобто для захисту від крадіжки, переупорядковування, дублювання і вставки повідомлень) використовуються порядкові номери, тимчасові штампи, криптографічне скріплення або інші аналогічні прийоми;
механізми аутентифікації. Згідно рекомендаціям X.800, аутентифікація може досягатися за рахунок використовування паролів, особистих карток або інших пристроїв аналогічного призначення, криптографічних методів, пристроїв вимірювання і аналізу біометричних характеристик;
механізми доповнення трафіку;
механізми управління маршрутизацією. Маршрути можуть вибиратися статично або динамічно. Крайова система, зафіксувавши неодноразові атаки на певному маршруті, може відмовитися від його використовування. На вибір маршруту здатна вплинути мітка безпеки, асоційована з передаваними даними;
механізми нотаризации. Служать для завірення таких комунікаційних характеристик, як цілісність, час, осіб відправника і одержувачів. Завірення забезпечується надійною третьою стороною, володіючою достатньою інформацією. Звичайно нотаризация спирається на механізм електронного підпису.
В наступній таблиці зведені сервіси (функції) і механізми безпеки. Таблиця показує, які механізми (по окремості або в комбінації з іншими) можуть використовуватися для реалізації тієї або іншої функції.
|
Таблиця 5.2. Взаємозв’язок функцій і механізмів безпеки |
|
||||||||
|
Функції |
Механізми |
|
|||||||
|
Шифрування |
Електронний підпис |
Керування доступом |
Цілісність |
Аутентифіккація |
Доповнення трафіку |
Керування маршрутизацією |
Нотаризація |
|
|
|
Аутентифікація партнерів |
+ |
+ |
- |
- |
+ |
- |
- |
- |
|
|
Аутентифікація джерела |
+ |
+ |
- |
- |
- |
- |
- |
- |
|
|
Керування доступом |
- |
- |
+ |
- |
- |
- |
- |
- |
|
|
Конфіденційність |
+ |
- |
+ |
- |
- |
- |
+ |
- |
|
|
Виборча конфіденційність |
+ |
- |
- |
- |
- |
- |
- |
- |
|
|
Конфіденційність трафіку |
+ |
- |
- |
- |
- |
+ |
+ |
- |
|
|
Цілісність з’єднання |
+ |
- |
- |
+ |
- |
- |
- |
- |
|
|
Цілісність зовні з’єднання |
+ |
+ |
- |
+ |
- |
- |
- |
- |
|
|
Невідмовність |
- |
+ |
- |
+ |
- |
- |
- |
+ |
|
"+" механізм придатний для реалізації даної функції безпеки;
"-" механізм не призначений для реалізації даної функції безпеки.
Адміністрування засобів безпеки включає розповсюдження інформації, необхідної для роботи сервісів і механізмів безпеки, а також збір і аналіз інформації про їх функціонування. Прикладами можуть служити розповсюдження криптографічних ключів, установка значень параметрів захисту, ведення реєстраційного журналу і т.п.
Концептуальною основою адміністрування є інформаційна база управління безпекою. Ця база може не існувати як єдине (розподілене) сховище, але кожна з крайових систем повинна мати свій в розпорядженні інформацію, необхідну для реалізації вибраної політики безпеки.
Згідно рекомендаціям X.800, зусилля адміністратора засобів безпеки повинні розподілятися по трьох напрямах:
адміністрування інформаційної системи в цілому;
адміністрування сервісів безпеки;
адміністрування механізмів безпеки.
Серед дій, що відносяться до ІС в цілому, відзначимо забезпечення актуальності політики безпеки, взаємодію з іншими адміністративними службами, реагування на події, що відбуваються, аудит і безпечне відновлення.
Адміністрування сервісів безпеки включає визначення об’єктів, що захищаються, вироблення правил підбору механізмів безпеки (за наявності альтернатив), комбінування механізмів для реалізації сервісів, взаємодію з іншими адміністраторами для забезпечення злагодженої роботи.
Обов’язки адміністратора механізмів безпеки визначаються переліком задіяних механізмів. Типовий список такий:
управління ключами (генерація і розподіл);
управління шифруванням (установка і синхронізація криптографічних параметрів). До управління шифруванням можна віднести і адміністрування механізмів електронного підпису. Управління цілісністю, якщо воно забезпечується криптографічними засобами, також тяжіє до даного напряму;
адміністрування управління доступом (розподіл інформації, необхідної для управління - паролів, списків доступу і т.п.);
управління аутентифікацією (розподіл інформації, необхідної для аутентифікації - паролів, ключів і т.п.);
управління доповненням трафіку (вироблення і підтримка правил, задаючих характеристики доповнюючих повідомлень - частоту відправки, розмір і т.п.);
управління маршрутизацією (виділення довірених шляхів);
управління нотаризацией (розповсюдження інформації про нотаріальні служби, адміністрування цих служб).
Ми бачимо, що адміністрування засобів безпеки в розподіленій ІС має багато особливостей в порівнянні з централізованими системами.
Ми повертаємося до теми оцінних стандартів, приступаючи до розгляду найповнішого і сучасного серед них - "Критеріїв оцінки безпеки інформаційних технологій" (виданий 1 грудня 1999 року). Цей міжнародний стандарт став підсумком майже десятилітньої роботи фахівців декількох країн, він увібрав в себе досвід існуючих на той час документів національного і міжнаціонального масштабу.
З історичних причин даний стандарт часто називають "Загальними критеріями" (або навіть ОК). Ми також використовуватимемо це скорочення.
"загальні критерії" насправді є метастандартом, визначаючим інструменти оцінки безпеки ІС і порядок їх використовування. На відміну від "Оранжевої книги", ОК не містять приречених "класів безпеки". Такі класи можна будувати, виходячи з вимог безпеки, існуючих для конкретної організації и/или конкретної інформаційної системи.
З точки програміста зору ОК можна вважати набором бібліотек, що допомагають писати змістовні "програми" - завдання по безпеці, типові профілі захисту і т.п. Програмісти знають, наскільки хороша бібліотека спрощує розробку програм, підвищує їх якість. Без бібліотек, "з нуля", програми не пишуть вже дуже давно; оцінка безпеки теж вийшла на зіставний рівень складності, і "Загальні критерії" надали відповідний інструментарій.