Основые Критерии Защищенности Ас.Основные Компоненты Безопасности Tcsecни. Функциональные Услуги Безопасности По НД ТЗИ 2.5-004-99

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

      1.2.  Класи захищеності комп'ютерних  систем по TCSEC

"Помаранчева  книга" передбачає чотири групи  критеріїв, які відповідають різній  мірі захищеності: від мінімальної  (група D) до формально доведеною  (група А). Кожна група включає  один або декілька класів. Групи  D і А містять по одному класу  (класи D і А відповідно), група  з-класи С1, С2, а група В три  класи -81, В2, ВЗ, що характеризуються  різними наборами вимог захищеності.  Рівень захищеності зростає від  групи D до групи А, а усередині  групи - із збільшенням номера  класу. Посилення вимог здійснюється  з поступовим зсувом акцентів  від положень, опредепяющих наявність  в системі якихось опредепенных  механізмів захисту, до положень  тих, що забезпечують високий  рівень гарантій того, що система  функціонує у відповідності вимогам  попитики безпеки (таблиця. 5.3). Наприклад,  по реалізованих механізмах захисту  класи ВЗ і А1 ідентичні.

Таблиця 1.

 Базові вимоги "Помаранчевої книги" | Класи захищеності |

  | С1 | С2 | В1 | В2 | ВЗ | А1 |

 Політика  безпеки |

1. Дискреційна  політика  безпеки | + | + | + | = | = | = |

2. Мандатна політика  безпеки | - | - | + | + | = | = |

3. Мітки секретності | - | - | + | + | = | = |

4. Цілісність  міток | - | - | + | = | = | = |

5. Робічі мітки | - | - | - | + | = | = |

6. Повторення  міток | - | - | + | = | = | = |

7. Звільнення  ресурсів при повторному використанні  об'єктів | - | + | = | + | = | = |

8. Ізолювання  модулів | - | + | = | = | = | = |

9. Позначка пристроїв  введення/виведення | - | - | + | = | = | = |

10. Позначка  читаного виводу | - | - | + | = | = | = |

 Підзвітність |

11. Ідентифікація  і аутентифікація | + | + | = | = | = | = |

12. Аудит | - | + | + | + | + | = |

13. Захищений  канал (довірена дорога) | - | - | - | + | = | = |

 Гарантії |   |

14. Проектна  специфікація і верифікація | - | - | + | + | + | + |   |

15. Системна  архітектура | + | = | = | + | + | = |   |

16. Цілісність  системи | + | = | = | = | = | = |   |

17. Тестування  системи безпеки | + | + | + | + | + | = |   |

18. Довірене  відновлення після збоїв | - | - | - | - | + | = |   |

19. Управління  конфігурацією системи | - | - | - | + | + | + |   |

20. Довірене  дооснащение системи | - | - | - | + | + | = |   |

21. Довірене  поширення | - | - | - | - | + | = |   |

22. Аналіз прихованих  каналів | - | - | - | + | + | + |   |

 Документація |   |

23. Посібник  користувача | + | = | = | = | = | = |   |

24. Керівництво  по конфігурації системи захисту | + | + | + | + | + | = |   |

25. Документація  по тестуванню | + | = | = | = | = | + |   |

26 Проектна документація | + | = | + | + | = | + |   |

 Примітки. "-"- немає вимог до даного класу; "+"- нові або додаткові вимоги; "="-требования збігаються з  вимогами до СВТ попереднього  класу |   |

  |  |  |  |  |  |  |  |  |  |  |  |  |  |

Розглянемо основні  вимоги класів захищеності по вказаних вище чотирьом категоріям:

• політика безпеки;

• підзвітність;

• гарантії;

• документація.

Центральним об'єктом  дослідження і оцінки по TCSEC є  довірча база обчислень (ТСВ).

         1.3.1. Вимоги до політики безпеки

Вимоги до політики безпеки, системою, що проводиться, підрозділяються  відповідно до основних напрямів політики, що передбачаються "Помаранчевою книгою".

Довільне управління доступом:

Клас C1 - обчислювальна  база повинна управляти доступом іменованих користувачів до іменованих об'єктів. Механізм управління (права  для владельца/группы/прочих, списки управління доступом) повинен дозволяти  специфікувати розділення файлів між  індивідами і групами.

Клас C2 - на додаток  до C1, права доступу повинні гранулюватися  з точністю до користувача. Механізм управління повинен обмежувати поширення  прав доступу - лише авторизований користувач, наприклад власник об'єкту, може надавати права доступу іншим  користувачам. Всі об'єкти повинні  піддаватися контролю доступу.

Клас B3 - на додаток  до C2, обов'язково повинні використовуватися  списки управління доступом з вказівкою  дозволених режимів. Має бути можливість явної вказівки користувачів або  їх груп, доступ яких до об'єкту заборонений.

(Примітка. Оскільки  класи B1 і B2 не згадуються, вимоги  до них в плані добровільного  управління доступом ті ж, що  і для C2. Аналогічно, вимоги до  класу A1 ті ж, що і для  B3.)

Повторне використання об'єктів:

Клас C2 - при виділенні  об'єкту, що зберігається, з пулу ресурсів обчислювальної бази необхідно ліквідовувати  всі сліди попередніх використань.

Мітки безпеки:

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

Клас B2 - на додаток  до B1, позначатися повинні всі  ресурси системи, наприклад ПЗП, прямо або побічно доступні суб'єктам.

Цілісність міток  безпеки:

Клас B1 - мітки  повинні адекватно відображати  рівні секретності суб'єктів і  об'єктів. При експорті інформації мітки  повинні перетворюватися в точну  і однозначно трактуючу зовнішню виставу, супроводжуючу дані. Кожен  пристрій ввода/вывода (у тому числі  комунікаційний канал) повинен трактуватися як однорівневе або багаторівневе. Всі зміни трактування і асоційованих рівнів секретності повинні протоколюватися.

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

Примусове управління доступом:

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

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

Клас B2 - на додаток  до B1, всі ресурси системи (у тому числі ПЗП, пристрої ввода/вывода) повинні  мати мітки безпеки і служити  об'єктами примусового управління доступом.

         1.3.2. Вимоги до підзвітності

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

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

Клас C2 - на додаток  до C1, кожен користувач системи повинен  унікальним чином ідентифікуватися. Кожна реєстрована дія повинна  зв'язуватися з конкретним користувачем.

Клас B1 - на додаток  до C2, обчислювальна база повинна  підтримувати мітки безпеки користувачів.

Надання надійної дороги:

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

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

Аудит:

Клас C2 - обчислювальна  база повинна створювати, підтримувати і захищати журнал реєстраційної  інформації, що відноситься до доступу  до об'єктів, контрольованих базою. Має  бути можливість реєстрації наступних  подій:

   * використання  механізму ідентифікації і аутентифікації;

   * внесення  об'єктів до адресного простору  користувача, наприклад відкриття  файлу, запуск програми;

   * видалення  об'єктів; 

   * дії  системних операторів, системних  адміністраторів, адміністраторів  безпеки; 

   * інші  події, що зачіпають інформаційну  безпеку. 

Кожен реєстраційний  запис повинен включати наступні поля:

   * дата  і час події; 

   * ідентифікатор  користувача; 

   * тип  події; 

   * результат  дії (успіх або невдача).

Для подій идентификации/аутентификации реєструється також ідентифікатор  пристрою, наприклад терміналу. Для  дій з об'єктами реєструються імена  об'єктів.

Системний адміністратор  може вибирати набір реєстрованих подій  для кожного користувача.

Клас B1 - на додаток  до C2, повинні реєструватися операції видачі на друк і асоційовані зовнішні представлення міток безпеці. При  операціях з об'єктами, окрім імен, реєструються їх мітки безпеки. Набор  реєстрованих подій може розрізнятися залежно від рівня секретності  об'єктів.

Клас B2 - на додаток  до B1, має бути можливість реєструвати  події, пов'язані з організацією таємних каналів з пам'яттю.

Клас B3 - на додаток  до B2, має бути можливість реєстрації появи або накопичення подій, що несуть загрозу політиці безпеки  системи. Адміністратор безпеки  повинен негайно сповіщатися  про спроби порушення політики безпеки, а система, в разі продовження  спроб, повинна присікати їх найменш  хворобливим способом.

         1.3.3. Вимоги до гарантованості

Архітектура системи:

Клас C1 - обчислювальна  база повинна підтримувати область  для власного виконання, захищену від  зовнішніх дій, зокрема від зміни  команд і даних, і від спроб  стеження за ходом роботи. Ресурси, контрольовані базою, можуть складати певну підмножину всіх суб'єктів  і об'єктів системи.

Клас C2 - на додаток  до C1, обчислювальна база повинна  ізолювати ресурси, що захищаються, в тій мірі, як це диктується вимогами контролю доступу і підзвітності.

Клас B1 - на додаток  до C2, обчислювальна база повинна  забезпечувати взаємну ізоляцію процесів шляхом розділення їх адресних просторів.