ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 04.05.2024

Просмотров: 48

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

"+" даний рівень може надати функцію безпеці;

"-" даний рівень не підходить для надання функцію безпеки.


2.2 Мережні механізми безпеки

Для реалізації сервісів (функцій) безпеки можуть використовуватися наступні механізми і їх комбінації:

  • шифрування;

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

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

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

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

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

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

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

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

Таблиця 5.2. Взаємозв’язок функцій і механізмів безпеки

Функції

Механізми

Шифрування

Електронний підпис

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

Цілісність

Аутентифіккація

Доповнення трафіку

Керування маршрутизацією

Нотаризація

Аутентифікація партнерів

+

+

-

-

+

-

-

-

Аутентифікація джерела

+

+

-

-

-

-

-

-

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

-

-

+

-

-

-

-

-

Конфіденційність

+

-

+

-

-

-

+

-

Виборча конфіденційність

+

-

-

-

-

-

-

-

Конфіденційність трафіку

+

-

-

-

-

+

+

-

Цілісність з’єднання

+

-

-

+

-

-

-

-

Цілісність зовні з’єднання

+

+

-

+

-

-

-

-

Невідмовність

-

+

-

+

-

-

-

+


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

3 Стандарт iso/iec 15408 "Критерії оцінки безпеки інформаційних технологій"

3.1 Основні поняття

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

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

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

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

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

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

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

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

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

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

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

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

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

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