Файл: Опорный конспект.pdf

електронний цифровий підпис;

механізми управління доступом. Можуть розташовуватися на будь-якій із сторін, що беруть участь в спілкуванні, або в проміжній крапці;

механізми контролю цілісності даних. В рекомендаціях X.800 розрізняються два аспекти цілісності: цілісність окремого повідомлення або поля інформації і цілісність потоку повідомлень або полів інформації. Для перевірки цілісності потоку повідомлень (тобто для захисту від крадіжки, переупорядковування, дублювання і вставки повідомлень) використовуються порядкові номери, тимчасові штампи, криптографічне скріплення або інші аналогічні прийоми;

механізми аутентифікації. Згідно рекомендаціям X.800, аутентифікація може досягатися за рахунок використовування паролів, особистих карток або інших пристроїв аналогічного призначення, криптографічних методів, пристроїв вимірювання і аналізу біометричних характеристик;

механізми доповнення трафіку;

механізми управління маршрутизацією. Маршрути можуть вибиратися статично або динамічно. Крайова система, зафіксувавши неодноразові атаки на певному маршруті, може відмовитися від його використовування. На вибір маршруту здатна вплинути мітка безпеки, асоційована з передаваними даними;

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

Внаступній таблиці зведені сервіси (функції) і механізми безпеки. Таблиця показує, які механізми (по окремості або в комбінації з іншими) можуть використовуватися для реалізації тієї або іншої функції.

100

з’єднання

"+" механізм придатний для реалізації даної функції безпеки; "-" механізм не призначений для реалізації даної функції безпеки.

2.3 Адміністрування засобів безпеки Адміністрування засобів безпеки включає розповсюдження інформації, необхідної для роботи

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

Концептуальною основою адміністрування є інформаційна база управління безпекою. Ця база може не існувати як єдине (розподілене) сховище, але кожна з крайових систем повинна мати свій в розпорядженні інформацію, необхідну для реалізації вибраної політики безпеки.

Згідно рекомендаціям X.800, зусилля адміністратора засобів безпеки повинні розподілятися по трьох напрямах:

адміністрування інформаційної системи в цілому;

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

адміністрування механізмів безпеки.

Серед дій, що відносяться до ІС в цілому, відзначимо забезпечення актуальності політики

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

аудит і безпечне відновлення.

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

Обов’язки адміністратора механізмів безпеки визначаються переліком задіяних механізмів. Типовий список такий:

управління ключами (генерація і розподіл);

управління шифруванням (установка і синхронізація криптографічних параметрів). До управління шифруванням можна віднести і адміністрування механізмів електронного підпису. Управління цілісністю, якщо воно забезпечується криптографічними засобами, також тяжіє до даного напряму;

адміністрування управління доступом (розподіл інформації, необхідної для управління - паролів, списків доступу і т.п.);

управління аутентифікацією (розподіл інформації, необхідної для аутентифікації - паролів, ключів і т.п.);

управління доповненням трафіку (вироблення і підтримка правил, задаючих характеристики доповнюючих повідомлень - частоту відправки, розмір і т.п.);

управління маршрутизацією (виділення довірених шляхів);

управління нотаризацией (розповсюдження інформації про нотаріальні служби, адміністрування цих служб).

Ми бачимо, що адміністрування засобів безпеки в розподіленій ІС має багато особливостей в порівнянні з централізованими системами.

3 Стандарт ISO/IEC 15408 "Критерії оцінки безпеки інформаційних технологій" 3.1 Основні поняття

Ми повертаємося до теми оцінних стандартів, приступаючи до розгляду найповнішого і сучасного серед них - "Критеріїв оцінки безпеки інформаційних технологій" (виданий 1 грудня 1999 року). Цей міжнародний стандарт став підсумком майже десятилітньої роботи фахівців декількох країн, він увібрав в себе досвід існуючих на той час документів національного і міжнаціонального масштабу.

З історичних причин даний стандарт часто називають "Загальними критеріями" (або навіть ОК). Ми також використовуватимемо це скорочення.

101

"загальні критерії" насправді є метастандартом, визначаючим інструменти оцінки безпеки ІС і порядок їх використовування. На відміну від "Оранжевої книги", ОК не містять приречених "класів безпеки". Такі класи можна будувати, виходячи з вимог безпеки, існуючих для конкретної організації и/или конкретної інформаційної системи.

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

Важливо відзначити, що вимоги можуть параметризуватися, як і вважається бібліотечним функціям.

Як і "Оранжева книга", ОК містять два основні види вимог безпеки:

функціональні, відповідні активному аспекту захисти, що пред’являються до функцій безпеки і реалізовуючих їх механізмів;

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

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

Дуже важливо, що безпека в ОК розглядається не статично, а в прив’язці до життєвого циклу об’єкту оцінки. Виділяються наступні етапи:

визначення призначення, умов вживання, цілей і вимог безпеки;

проектування і розробка;

випробування, оцінка і сертифікація;

упровадження і експлуатація.

ВОК об’єкт оцінки розглядається в контексті середовища безпеки, яка характеризується певними умовами і загрозами.

У свою чергу, загрози характеризуються наступними параметрами:

джерело загрози;

метод дії;

вразливі місця, які можуть бути використані;

ресурси (активи), які можуть постраждати.

Вразливі місця можуть виникати через недолік в:

вимогах безпеки;

проектуванні;

експлуатації.

Слабкі місця по можливості слід усунути, мінімізувати або хоча б постаратися обмежити

можливий збиток від їх навмисного використовування або випадкової активізації.

З погляду технології програмування в ОК використаний застарілий бібліотечний (не об’єктний) підхід. Щоб, проте, структурувати простір вимог, в "Загальних критеріях" введена ієрархія клас-

семейство-компонент-елемент.

Класи визначають саме загальне, "наочне" угрупування вимог (наприклад, функціональні вимоги підзвітності).

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

Елемент - неподільна вимога.

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

Як указувалося вище, за допомогою бібліотек можуть формуватися два види нормативних документів: профіль захисту і завдання по безпеці.

Профіль захисту (ПЗ) є типовим набором вимог, яким винні задовольняти продукти и/или системи певного класу (наприклад, операційні системи на комп’ютерах в урядових організаціях).

102

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

Вище ми відзначали, що в ОК немає готових класів захисту. Сформувати класифікацію в термінах "Загальних критеріїв" - значить визначити дещо ієрархічно впорядкованих (що містять вимоги, що посилюються) профілів захисту, в максимально можливому ступені використовуючих стандартні функціональні вимоги і вимоги довір’я безпеки.

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

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

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

3.2 Функціональні вимоги

Функціональні вимоги згруповані на основі виконуваної ними ролі або обслуговуваній меті безпеки. Всього в "Загальних критеріях" представлено 11 функціональних класів, 66 сімейств, 135 компонентів. Це, звичайно, значно більше, ніж число аналогічних єств в "Оранжевій книзі".

Перерахуємо класи функціональних вимог ОК:

ідентифікація і аутентифікація;

захист даних користувача;

захист функцій безпеки (вимоги відносяться до цілісності і контролю даних сервісів безпеки і реалізовуючих їх механізмів);

управління безпекою (вимоги цього класу відносяться до управління атрибутами і параметрами безпеки);

аудит безпеки (виявлення, реєстрація, зберігання, аналіз даних, що зачіпають безпеку об’єкту оцінки, реагування на можливе порушення безпеки);

доступ до об’єкту оцінки;

приватность (захист користувача від розкриття і несанкціонованого використовування його ідентифікаційних даних);

використовування ресурсів (вимоги до доступності інформації);

криптографічна підтримка (управління ключами);

зв’язок (аутентифікація сторін, що беруть участь в обміні даними);

довірений маршрут/канал (для зв’язку з сервісами безпеки).

Опишемо докладніше два класи, демонструючі особливості сучасного підходу до ІБ. Клас "Пріватность" містить 4 сімейства функціональних вимог.

Анонімність. Дозволяє виконувати дії без розкриття ідентифікатора користувача іншим користувачам, суб’єктам и/или об’єктам. Анонімність може бути повною або вибірковою. В останньому випадку вона може відноситися не до всіх операцій и/или не до всіх користувачів (наприклад, у уповноваженого користувача може залишатися можливість з’ясування ідентифікаторів користувачів).

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

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

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

103