19 мон ГЮІ 2015. 1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації
 Скачать 227.06 Kb.
|
2.2.11 АвтентифікаціяКриптографічному модулю можуть знадобитися механізми автентифікації для автентифікації оператора, що здійснює доступ до модуля і перевірки того, що оператор уповноважений приймати запитувану роль і виконувати послуги в рамках цієї ролі. Наступні види механізмів використовуються для управління доступом до криптографічного модуля [10]. Рольова автентифікація: Якщо криптографічним модулем підтримуються механізми рольової автентифікації, модуль повинен вимагати, щоб одна або декілька ролей явно чи неявно були вибрані оператором і автентифікувати прийняття вибраної ролі (або набору ролей). Криптографічний модуль не повинен автентифікувати особистість оператора. Процедури вибору ролей і автентифікації прийняття обраних ролей можуть бути об'єднані. Якщо криптографічний модуль дозволяє оператору змінювати ролі, то модуль повинен автентифікувати прийняття будь-якої ролі, яка раніше не була автентифікована для цього оператора. Особистісна автентифікація: Якщо криптографічним модулем підтримуються механізми особистісної автентифікації, модуль повинен вимагати, щоб оператор був індивідуально і унікально ідентифікований, а також повинен вимагати, щоб одна або декілька ролей були явно чи неявно вибрані оператором, і повинен автентифікувати особистість оператора і повноваження оператора приймати обрану роль або набір ролей. Процедури автентифікації особистості оператора, вибору ролей і підтвердження повноважень для прийняття обраної ролі можуть бути об'єднані. Якщо криптографічний модуль дозволяє оператору змінювати ролі, то модуль повинен перевірити повноваження ідентифікованого оператора при прийнятті будь-якої ролі, для якої раніше не були підтверджені повноваження. Криптографічний модуль може дозволити автентифікованому оператору виконувати всі послуги, дозволені в межах авторизованої ролі, або може вимагати окремої автентифікації для кожної послуги або для різних наборів послуг. Коли криптографічний модуль скидається, перезавантажується, вимикається, а потім вмикається, модуль повинен вимагати від оператора автентифікуватися. Криптографічним модулем можуть вимагатися різні типи даних автентифікації для виконання підтримуваних механізмів автентифікації, включаючи (але не обмежуючись) володіння або знання пароля, PIN-коду, криптографічного ключа, або еквіваленту; володіння фізичним ключем, токеном, або еквівалентом, або перевірку особистих характеристик (тобто, біометрія). Дані автентифікації в криптографічному модулі повинні бути захищеними від несанкціонованого використання, розкриття, зміни і заміни. Як частина механізму автентифікації можуть бути використані затверджені функції безпеки. Ініціалізація механізмів автентифікації може потребувати особливої уваги. Якщо криптографічний модуль не містить даних автентифікації, необхідних для автентифікації оператора в перший раз, коли здійснюється доступ до модуля, то для керування доступом до модуля та ініціалізації механізмів автентифікації повинні використовуватися інші уповноважені методи (наприклад, процедурні елементи керування або використання заводських даних автентифікації, або даних автентифікації за замовчуванням). Якщо для керування доступом до модуля використовуються дані автентифікації за замовчуванням, то ці дані повинні бути замінені після першої автентифікації. Ці дані автентифікації за замовчуванням не повинні задовольняти вимоги по обнулінню . Механізм автентифікації може бути групою механізмів з різними автентифікаційними властивостями, які в сукупності відповідають вимогам цього розділу. Якщо криптографічний модуль використовує функції безпеки для автентифікації оператора, то ці функції безпеки повинні бути затвердженими функціями безпеки. Модуль повинен реалізовувати затверджений механізм автентифікації, як зазначено в додатку Д стандарту. Стійкість затвердженого механізму автентифікації повинна бути визначена в політиці безпеки (додаток Б до стандарту). Для кожної спроби використання затвердженого механізму автентифікації, модуль повинен задовольняти вимоги щодо сили завдання автентифікації. Для кількох спроб використання затвердженого механізму автентифікації протягом однієї хвилини, модуль повинен задовольняти вимоги щодо сили завдання автентифікації. Затверджений механізм автентифікації повинен задовольнятися реалізацією модуля, а не посилатися на документальні процедури керування або правила безпеки (наприклад, обмеження на розмір пароля). Для програмного модуля Рівня безпеки 2, механізм автентифікації може реалізовувати операційна система. Якщо операційна система реалізує механізм автентифікації, то цей механізм автентифікації повинен відповідати вимогам цього пункту. Відображення даних автентифікації оператору повинне бути приховане в процесі автентифікації (наприклад, відсутність видимого відображення символів при введенні пароля). На місці фактичних даних автентифікації можуть відображатися незначущі символи. Відображення, надане оператору під час спроби автентифікації повинне запобігати ослабленню механізму автентифікації нижче необхідного рівня сили автентифікації. Рівень безпеки 1. Для Рівня безпеки 1 криптографічний модуль не забов'язаний реалізовувати механізми автентифікації для контролю доступу до модуля. Якщо модуль не підтримує механізми автентифікації, то модуль повинен вимагати, щоб оператор явно чи неявно вибрав одну або кілька ролей. Рівень безпеки 2. Для Рівня безпеки 2, криптографічний модуль повинен як мінімум реалізовувати рольову автентифікацію, щоб контролювати доступ до модуля. Рівень безпеки 3. Для Рівня безпеки 3, криптографічний модуль повинен реалізовувати механізм особистісної автентифікації, щоб контролювати доступ до модуля. Рівень безпеки 4. Для Рівня безпеки 4, криптографічний модуль повинен реалізовувати механізм багатофакторної особистісної автентифікації, щоб контролювати доступ до модуля. |