- •1 Галузь використання
- •2 Нормативні посилання
- •3 Визначення
- •4 Позначення і скорочення
- •5 Побудова і структура критеріїв захищеності інформації
- •Критерії
- •6 Критерії конфіденційності
- •6.1 Довірча конфіденційність
- •6.2 Адміністративна конфіденційність
- •6.3 Повторне використання об'єктів
- •6.4 Аналіз прихованих каналів
- •6.5 Конфіденційність при обміні
- •7 Критерії цілісності
- •7.2 Адміністративна цілісність
- •7.3 Відкат
- •8 Критерії доступності
- •8.1 Використання ресурсів
- •8.2 Стійкість до відмов
- •8.3 Гаряча заміна
- •8.4 Відновлення після збоїв
- •9 Критерії спостереженості
- •9.1 Реєстрація
- •9.2 Ідентифікація і автентифікація
- •9.3 Достовірний канал
- •9.4 Розподіл обов'язків
- •9.5 Цілісність комплексу засобів захисту
- •9.6 Самотестування
- •9.7 Ідентифікація і автентифікація при обміні
- •9.8 Автентифікація відправника
- •9.9 Автентифікація отримувача
- •10 Критерії гарантій
- •10.1 Архітектура
- •10.2 Середовище розробки
- •10.3 Послідовність розробки
- •10.4 Середовище функціонування
- •10.5 Документація
- •10.6 Випробування комплексу засобів захисту
- •Додаток а Функціональні послуги
- •А.1 Критерії конфіденційності
- •А.1.1 Довірча конфіденційність
- •А.1.2 Адміністративна конфіденційність
- •А.1.3 Повторне використання об'єктів
- •А.1.4 Аналіз прихованих каналів
- •А.1.5 Конфіденційність при обміні
- •А.2 Критерії цілісності
- •А.2.2 Адміністративна цілісність
- •А.2.3 Відкат
- •А.3 Критерії доступності
- •А.3.1 Використання ресурсів
- •А.3.2 Стійкість до відмов
- •А.3.3 Гаряча заміна
- •А.3.4 Відновлення після збоїв
- •А.2 Критерії спостереженості
- •А.2.1 Реєстрація
- •А.2.2 Ідентифікація і автентифікація
- •А.2.3 Достовірний канал
- •А.2.4 Розподіл обов'язків
- •А.2.5 Цілісність комплексу засобів захисту
- •А.2.6 Самотестування
- •А.2.7 Ідентифікація і автентифікація при обміні
- •А.2.8 Автентифікація відправника
- •А.2.9 Автентифікація одержувача
- •Додаток б Гарантії і процес оцінки
- •Б.1 Архітектура
- •Б.2 Середовище розробки
- •Б.3 Послідовність розробки
- •Б.4 Середовище функціонування
- •Б.5 Документація
- •Б.6 Випробування комплексу засобів захисту
9.9 Автентифікація отримувача
Ця послуга дозволяє забезпечити захист від відмови від одержання і дозволяє однозначно встановити факт одержання певного об'єкта певним користувачем. Рівні даної послуги ран жируються на підставі можливості підтвердження результатів перевірки незалежною третьою стороною.
НП-1: Базова автентифікація отримувача |
НП-2: Автентифікація отримувача з підтвердженням |
Політика автентифікації одержувача, що реалізується КЗЗ, повинна визначати множину властивостей і атрибутів об'єкта, що передається, користувача-одержувача і інтерфейсного процесу, а також процедури, які дозволяли б однозначно встановити, що даний об'єкт був одержаний певним користувачем |
|
— |
Додатково повинні бути визначені ті властивості, атрибути і процедури, які можуть використовуватися незалежною третьою стороною для однозначного підтвердження факту одержання об'єкта |
Встановлення одержувача має виконуватися на підставі затвердженого протоколу автентифікації |
|
— |
Використовуваний протокол автентифікації повинен забезпечувати можливість однозначного підтвердження незалежною третьою стороною факту одержання об'єкта |
НЕОБХІДНІ УМОВИ: НИ-1 |
|
10 Критерії гарантій
Критерії гарантій включають вимоги до архітектури КЗЗ, середовища розробки, послідовності розробки, середовища функціонування, документації і випробувань КЗЗ. В цих критеріях вводиться сім рівнів гарантій, які є ієрархічними. Вимоги викладаються за розділами. Для того, щоб КС одержала певний рівень гарантій (якщо вона не може одержати більш високий), повинні бути задоволені всі вимоги, визначені для даного рівня в кожному з розділів.
10.1 Архітектура
Вимоги до архітектури забезпечують гарантії того, що КЗЗ у змозі повністю реалізувати політику безпеки.
Вимоги |
Г-1 |
Г-2 |
Г-3 |
Г-4 |
Г-5 |
Г-6 |
Г-7 |
КЗЗ повинен реалізовувати політику безпеки. Всі його компоненти повинні бути чітко визначені |
+ |
= |
= |
= |
= |
= |
= |
КЗЗ повинен складатися з добре визначених і максимально незалежних компонентів. Кожний з компонентів повинен бути спроектований відповідно до принципу мінімуму повноважень |
- |
- |
+ |
= |
= |
= |
= |
Критичні для безпеки компоненти КЗЗ повинні бути захищені від не критичних для безпеки за рахунок використання механізмів захисту, які надаються програмно-апаратними засобами більш низького рівня |
- |
- |
- |
+ |
= |
= |
= |
З боку Розробника мають бути вжиті зусилля, спрямовані на виключення з КЗЗ компонентів, що не є критичними для безпеки. Мають бути наведені підстави для включення до КЗЗ будь-якого елемента, який не має відношення до захисту |
- |
- |
- |
- |
+ |
= |
= |
Розробка ПЗ переважно має бути спрямована на мінімізацію складності КЗЗ. КЗЗ має бути спроектований і структурований так, щоб використовувати повний і концептуально простий механізм захисту з точно визначеною семантикою. Цей механізм повинен відігравати центральну роль в реалізації внутрішньої структури КЗЗ. Під час розробки КЗЗ значною мірою повинні бути задіяні такі підходи як модульність побудови і приховання (локалізація) даних |
- |
- |
- |
- |
+ |
= |
= |
* В таблицях використовуються такі позначення: “-” — вимога відсутня; “+” — вимога з'являється; “=“ — вимога зберігається.