Затверджую
| Вид материала | Документы |
- Затверджую затверджую голова Кримського Голова Державної податкової Республіканського, 117.84kb.
- “Затверджую”, 639.38kb.
- Юрія Федьковича «затверджую», 585.95kb.
- Володимира Даля "затверджую", 183.23kb.
- Затверджую: Проректор з навчальної роботи, 59.36kb.
- «Затверджую», 21.74kb.
- Юрія Федьковича " затверджую, 825.92kb.
- Юрія Федьковича " затверджую, 245.34kb.
- Юрія Федьковича " затверджую, 501.24kb.
- Затверджую прийнятий на засіданні, 1283.44kb.
6.1.6 Сервіс „Керування безпекою”
6.1.6.1 Опис сервісу
Специфікація сервісу здійснюється з врахуванням рівня функціональної послуги безпеки „Розподіл обов’язків адміністраторів” (підпункт 5.2.4.4), а також охоплює аспекти керування безпекою в межах інших функціональних послуг безпеки.
Сервіс „Керування безпекою” включає наступні логічно відокремлені функціональні компоненти:
- підтримка в системі ролей користувачів;
- механізм „Групова політика”;
- керування функціями безпеки ОЕ.
6.1.6.1.1 Підтримка в системі ролей користувачів
Роль користувача визначається трьома способами:
- присвоєнням відповідному обліковому запису користувача певних повноважень;
- включенням користувача у групу безпеки користувачів, яка має певні повноваження;
- присвоєнням обліковому запису групи безпеки користувачів, в яку включено користувача, певних повноважень.
Група безпеки користувачів ОЕ є іменованою сукупністю облікових записів користувачів, яка дозволяє призначати повноваження і права доступу для групи користувачів, а не індивідуально для кожного користувача. ОЕ дозволяє уповноваженим користувачам створювати власні групи безпеки або використовувати вбудовані групи.
В ОЕ за умовчанням передбачені вбудовані групи безпеки користувачів які наведені у табл.17.
Таблиця 17
| Група безпеки | Повноваження |
| Адміністратори | Членство у цій групі надає найбільші повноваження, зокрема, право на зміну власних повноважень |
| Оператори архіву | Членство у цій групі надає можливість архівувати та відновлювати файли з архіву незалежно від встановлених на них прав доступу |
| Досвідчені користувачі | Членство у цій групі дає можливість:
Члени цієї групи мають більше повноважень, ніж члени групи „Користувачі”, та менше, ніж члени групи „Адміністратори”. Досвідчені користувачі можуть виконувати будь-які задачі в межах ОЕ, окрім задач, які зарезервовано для групи „Адміністратори”. Досвідчені користувачі не можуть додавати себе в групу „Адміністратори”. Вони не мають доступу до даних інших користувачів на томі NTFS, якщо не мають на це відповідних прав доступу |
| Користувачі | Членство у цій групі надає мінімальні права, які необхідні для виконання прикладних задач. Групі „Користувачі” надано найбільш безпечне середовище для виконання програм. Користувачі не можуть змінювати параметри реєстру на рівні системи, файли системи або програми. Користувачі можуть створювати локальні групи безпеки та керувати ними |
| Гості | Членство у цій групі призначається користувачам, що не мають власного облікового запису, та надає можливість лише завершення роботи робочої станції |
| Реплікатори | Членство у цій групі дає повноваження на реплікацію каталогу |
6.1.6.1.2 Механізм „Групова політика”
В ОЕ підтримується керування політикою безпеки за допомогою механізму „Групова політика”, який дозволяє вповноваженому адміністратору встановити параметри визначеної множини політик безпеки (надалі - параметри групової політики) для:
- окремого користувача;
- групи безпеки користувачів;
- комп'ютерів.
Механізм дозволяє адміністратору домену централізовано керувати всіма клієнтськими комп’ютерами, які входять в домен, шляхом встановленням параметрів групових політик.
Параметри групової політики визначають різні компоненти системного оточення користувача.
Об’єкт групової політики є відокремленим іменованим набором параметрів групової політики. Об’єкти групової політики на рівні домену зберігаються на контролері домену та застосовуються до користувачів, комп’ютерів, виділених мереж (site), доменів, організаційних підрозділів. На кожному клієнтському комп’ютері з ОЕ зберігається локальний об’єкт групової політики.
Множина параметрів групової політики формується як сукупність параметрів окремих політик безпеки ОЕ, а саме:
- політика аудиту – надає можливість дозволяти або забороняти реєстрацію подій, визначати категорії подій, що підлягають аудиту, вказувати тип контрольованої події (успіх/відмова), керувати (створення, видалення та очищення) журналом безпеки. Усі параметри, що визначаються в політиці аудиту, містяться в базі даних служби LSA;
- політика облікових записів – дозволяє встановлювати обмеження на паролі, що використовуються (політика паролів), та параметри блокування облікових записів (політика блокування облікових записів).
Політика паролів визначає наступні параметри:
- максимальний термін дії пароля;
- мінімальний термін дії пароля;
- мінімальну довжину пароля;
- відповідність пароля вимогам складності;
- вимога неповторюваності паролів.
Політика блокування облікових записів визначає наступні параметри:
- часовий проміжок блокування облікового запису;
- граничне значення блокування;
- часовий проміжок, після якого здійснюється обнуління лічильника блокування;
- політика призначення прав користувачів – дозволяє визначати повноваження для користувачів та груп безпеки на вхід в ОЕ та виконання системних задач;
- політика параметрів безпеки – дозволяє визначати такі параметри безпеки, які стосуються цифрового підпису даних, інтерактивного входу в систему, доступу до мережі, встановлення драйверів та інше;
- політика відкритого ключа - дозволяє виконувати наступні задачі:
- настройку комп’ютерів на автоматичну відправку запитів в центр сертифікації підприємства та встановлення виданих сертифікатів;
- створення та розповсюдження списку довіри сертифікатів;
- визначення довірчих центрів сертифікації;
- додавання агентів відновлення шифрованих даних та зміну параметрів політики відновлення зашифрованих даних.
6.1.6.1.3 Керування функціональними компонентами безпеки ОЕ
ОЕ надає можливість адміністраторам або уповноваженим користувачам керувати наступними функціональними компонентами безпеки:
- база даних облікових записів користувачів - дозволяє керувати атрибутами безпеки облікових записів користувачів і груп безпеки користувачів. З всього переліку атрибутів користувачу дозволено змінювати лише пароль. Уповноважений адміністратор при створенні нового облікового запису створює лише початковий пароль, який потім може бути змінений як адміністратором, так і користувачем (підпункт 6.1.9.1.1);
- дискові квоти - надає можливість керувати дисковими квотами на томах NTFS. Дискові квоти використовуються для контролю за використанням дискового простору кожним користувачем і кожним томом (підпункт 6.1.4.1.1);
- очищення пам’яті - надає можливість встановлювати очищення файлу підкачки. Хоча цей файл надійно захищений та відкривається лише операційною системою, існує можливість його використання для атак типу „збирання сміття” (підпункт 6.1.4.1.1);
- пріоритети процесів - надає можливість назначати процесам пріоритети виконання (підпункт 6.1.9.1.1) ;
- відновлення системи - надає можливість при виникненні збоїв, таких як некоректні системні установки, ушкодження драйверів, несумісні застосування керувати засобами відновлення системи (підпункт 6.1.3.1.1);
- відкат - надає можливість керувати відкатом установки драйверів пристроїв та інсталяції ПЗ (підпункт 6.1.3.1.2);
- модернізація ОЕ - надає можливість керувати автоматичним конфігуруванням ОЕ та усіма встановленими на ньому пристроями (підпункт 6.1.5.1).
6.1.6.2 Співставлення сервісу з функціональними вимогами безпеки
| Позначення функції безпеки | Опис функції безпеки | Позначення елемента вимог | Опис елемента вимог |
| КБ–1 | КЗЗ ОЕ визначає ролі адміністратора і звичайного користувача і притаманні їм функції (підпункт 6.1.6.1.1) | 2-НО-1.1 | Політика розподілу обов'язків, що реалізується КЗЗ, повинна визначати ролі адміністратора і звичайного користувача і притаманні їм функції |
| КБ–2 | Політика розподілу обов’язків визначає ролі адміністратора системи (адміністратора безпеки) та інших користувачів, яким притаманні спеціалізовані адміністративні функції і права (підпункт 6.1.6.1.1) | 2-НО-2.1 | Політика розподілу обов'язків повинна визначати мінімум дві адміністративні ролі: адміністратора безпеки та іншого адміністратора |
| КБ–3 | Функції, притаманні кожній із ролей, мінімізовані так, щоб включати тільки ті функції, які необхідні для виконання даної ролі (підпункт 6.1.6.1.1) | 2-НО-2.2 | Функції, притаманні кожній із ролей, повинні бути мінімізовані так, щоб включати тільки ті функції, які необхідні для виконання даної ролі |
| КБ–4 | Користувач має право виступати у певній ролі тільки в разі авторизації під відповідним обліковим записом (табл.17, підпункт 6.1.6.1.1) | 2-НО-3.1 | Користувач повинен мати можливість виступати в певній ролі тільки після того, як він виконає певні дії, що підтверджують прийняття їм цієї ролі |
| КБ–5 | Тільки адміністратор або користувач, якому надані відповідні повноваження, може змінювати встановлені обмеження на обсяги ресурсів (квоти) (перелік 2), 4) підпункту 6.1.6.1.3) | 1-ДР-3.1 | Запити на зміну встановлених обмежень повинні оброблятися КЗЗ тільки в тому випадку, якщо вони надходять від адміністраторів або від користувачів, яким надані відповідні повноваження |
| КБ–6 | Тільки адміністратор або уповноважений користувач можуть ініціювати процедури, які застосовуються в ОЕ для модернізації КС (перелік 7) підпункту 6.1.6.1.3) | 1-ДЗ-2.1 | Адміністратор або користувачі, яким надані відповідні повноваження, повинні мати можливість провести модернізацію (upgrade) КС |
| КБ–7 | Тільки адміністратор або уповноважений користувач мають право використовувати засоби відновлення системи після відмови КС або переривання обслуговування (перелік 5) підпункту 6.1.6.1.3) | 1-ДВ-3.1 | Після відмови КС або переривання обслуговування КЗЗ повинен перевести КС до стану, із якого повернути її до нормального функціонування може тільки адміністратор або користувачі, яким надані відповідні повноваження |
| КБ–8 | Тільки адміністратори та уповноважені користувачі мають засоби перегляду і аналізу журналу безпеки (підпункт 6.1.6.1.2) | 2-НР-4.2 | Адміністратори і користувачі, яким надані відповідні повноваження, повинні мати в своєму розпорядженні засоби перегляду і аналізу журналу реєстрації |
| КБ–9 | Тільки адміністратори та уповноважені користувачі мають можливість ініціювати автоматизовані засоби відкату операцій над захищеним об’єктом за певний проміжок часу (перелік 6) підпункту 6.1.6.1.3) | 1-ЦО-2.1 | Повинні існувати автоматизовані засоби, які дозволяють авторизованому користувачу або процесу відкатити або відмінити певний набір (множину) операцій, виконаних над захищеним об'єктом за певний проміжок часу |
| КБ–10 | Зміну прав доступу до об'єкта можуть здійснити (підпункт 6.1.6.1.2):
| 2-КД-3.1 1-ЦД-3.1 | Запити на зміну прав доступу до об'єкта повинні оброблятися КЗЗ на підставі атрибутів доступу користувача, що ініціює запит, і об'єкта |
| КБ–11 | Тільки адміністратор або уповноважений користувач можуть встановлювати рівень захищеності при обміні шляхом керування політикою безпеки мережного трафіка (підпункт 6.1.6.1.2) | 2-КВ-4.1 2-ЦВ-5.1 | Запити на призначення або зміну рівня захищеності (при обміні) повинні оброблятися КЗЗ тільки в тому випадку, якщо вони надходять від адміністраторів або користувачів, яким надані відповідні повноваження |
6.1.7 Сервіс „Захист КЗЗ”
6.1.7.1 Опис сервісу
Специфікація сервісу здійснюється з врахуванням рівня функціональних послуг безпеки „КЗЗ з гарантованою цілісністю” (підпункт 6.2.4.5) та „Самотестування при старті” (підпункт 6.2.4.6). Сервіс „Захист КЗЗ” включає наступні логічно відокремлені функціональні компоненти щодо:
- захист при старті;
- розподілу доменів;
- контролю доступу до об'єктів;
- захисту файлів Windows;
- перевірці цифрових підписів системних файлів;
- обмеження ПЗ.
6.1.7.1.1 Захист при старті
Захист ОЕ при старті базується на завантаженні ОС під контролем КЗЗ. ОЕ контролює процес завантаження та ініціалізації системних сервісів та зупиняє систему при виникненні критичних проблем.
6.1.7.1.2 Розподіл доменів
КЗЗ підтримує домен для власного безпечного виконання і забезпечує ізоляцію процесів користувачів. Домени безпеки підтримуються апаратними засобами робочої станції та ПЗ ядра ОС.
ОЕ використовує наступні можливості апаратного забезпечення підтримки доменів:
- привілейовані режими виконання процесора;
- захист сегментів пам’яті;
- захищений виклик процедур.
Ядро ОС виконується в привілейованих режимах процесора з доступом до всіх команд процесора та всього адресного простору пам’яті. Програми режиму користувача виконуються в непривілейованих режимах, що забезпечує використання процесом користувача тільки непривілейованих команд та тих сегментів пам’яті, які виділені даному процесу. Перехід з режиму користувача до режиму ядра можливий тільки через переривання, які генеруються апаратними засобами захисту, або через звернення програм користувача до ядра ОС. В будь-якому з цих випадків керування процесором передається ядру ОС. Процес, який виконується в режимі користувача, має доступ тільки до свого адресного простору, що виключає для нього можливість прямих звернень до коду та даних ядра та інших процесів користувача.
ПЗ ядра ОС забезпечує ізоляцію всіх процесів режиму користувача за допомогою контексту виконання, контексту безпеки та обмеження виділеного процесам адресного простору (використання механізму віртуального адресного простору). Структури даних, які зберігають критичні дані виконання процесу (атрибути процесів, контекст виконання і контекст безпеки), зберігаються в захищеній пам'яті режиму ядра.
6.1.7.1.2 Контроль доступу до об'єктів
Механізм доступу процесів до об'єктів в більшості випадків заснований на використанні дескрипторів об'єктів. Одержання дескриптора об’єкта процесом, якій запитує доступ до об’єкта, як правило відбувається при відкритті або створенні об'єкта. КЗЗ забезпечує підтвердження доступу перед створенням нового дескриптора об’єкта. Дескриптори можуть бути також успадковані від батьківських процесів або прямо скопійовані (при наявності відповідних прав доступу) з іншого процесу. Дескриптор об’єкта завжди має маску призначеного доступу, асоційовану з ним. Дана маска доступу визначає, які права доступу до об'єкта будуть надані процесу. КЗЗ забезпечує звернення до маски доступу дескриптора при кожній спробі використання об’єкта. У деяких випадках, таких як взаємодія зі службою каталогу, доступ до об'єктів здійснюється безпосередньо по імені без проміжного етапу одержання дескриптора об'єкта.
6.1.7.1.3 Захист файлів Windows
Захист файлів Windows (WFP) використовується для запобігання перезапису системних файлів ОЕ, що використовуються як безпосередньо ОС, так і прикладними програмами. До захищених файлів відносяться важливі системні файли, що встановлюються разом із системою Windows (наприклад, файли з розширенням DLL, EXE, OCX, SYS, а також деякі шрифти True Type). Перевірка правильності версій захищених системних файлів виконується за допомогою цифрового підпису цих файлів та файлів-каталогів (.cat), що були створені в процесі цифрового підписування системних файлів і використовуються для відстеження їх коректності.
Захист файлів ОЕ забезпечується двома способами:
- сервіс захисту системних файлів (WFP Service) - працює в фоновому режимі та активується у випадку отримання повідомлення про зміну файлів, що захищаються. Після отримання повідомлення WFP ідентифікує змінений файл і перевіряє правильність його версії на підставі підпису та списку в файлах-каталогах. Якщо версія є неправильною, новий файл замінюється початковим з папки кешу або джерела установки без повідомлення для користувача. В іншому випадку, видається повідомлення для адміністратора. Крім того, спроба заміни реєструється в системному журналі;
- утиліта командного рядка System File Checker (Sfc.exe) - перевіряє всі файли-каталоги та захищені системні файли. В разі модифікації системного файлу або ушкодження будь-якого із файлів-каталогів він відновлюється із папки кешу, в якій зберігаються резервні копії системних файлів, або з джерела установки ОС. Розмір папки кешу визначається параметром SFCQuota в розділі реєстру HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon. Крім того, за допомогою утиліти виконується перевірка самої папки кешу (за умовчанням – %SystemRoot%\System32\Dllcache) та, в разі виявлення ушкоджень, здійснюється відновлення її вмісту.
Утиліта ініціюється в наступних режимах:
- негайне сканування (ключ \scannow);
- однократне сканування при наступному завантаженні ОС (ключ \scanonce);
- сканування при кожному завантаженні ОС (ключ \scanboot).
6.1.7.1.4 Перевірка цифрових підписів системних файлів
ОЕ захищає свої системні файли та драйвери шляхом створення для таких файлів цифрового підпису. Цифровий підпис Microsoft підтверджує, що даний файл перевірено, він не був змінений або замінений в процесі установки інших програм. Адміністратор регулює політику, параметри якої визначають дії ОЕ щодо драйверів без цифрового підпису:
- ігнорує цифрові підписи драйверів пристроїв;
- попереджує про виявлення драйверу без цифрового підпису (цей режим встановлюється за умовчанням);
- забороняє установку не підписаних драйверів.
Перевірка підпису файлів може виконуватися утилітою „Перевірка підпису файлів” (sigverif.exe). Ця утиліта відшукує системні файли та файли драйверів пристроїв, що не мають цифровий підпис, та зберігає результати пошуку в файл за умовчанням %systemroot%\sigverif.txt.
6.1.7.1.5 Обмеження ПЗ
Політика обмеженого використання програм, що реалізована в ОЕ, дозволяє адміністратору визначити програми, які можна запустити на локальному комп’ютері. Політика захищає систему від запуску небажаних програм, вірусів, „троянських коней” та інших програм, які можуть спричинити конфлікти.
Політика обмеженого використання програм може застосовуватися як в домені, так і для локальних комп’ютерів або користувачів. Політика забезпечує наступні можливості:
- визначення програм, дозволених для запуску на клієнтських комп’ютерах;
- обмеження доступу користувачів до конкретних файлів на комп’ютерах, які мають декілька користувачів;
- визначення користувачів, які мають право додавати до клієнтських комп’ютерів довірених видавців;
- визначення впливу політики на всіх користувачів або тільки на користувачів на клієнтських комп’ютерах;
- заборона запуску файлів, які можуть виконуватись, на локальному комп’ютері, у організаційному підрозділі, вузлі або домені.
6.1.7.1.5.1 Правила політики обмеженого використання програм
Політика обмеженого використання програм складається з двох компонентів:
- заданого за умовчанням правила, згідно якого програми можуть запускатися;
- списку винятків для цього правила.
Політика формується адміністратором, як визначення правила за умовчанням і додаткові правила, які складають винятки для правила за умовчанням.
Правила за умовчанням можуть мати наступні значення:
- заборонено - якщо встановлено за умовчанням значення „Заборонено”, то незалежно від прав доступу ПЗ запускатися не буде. Адміністратор повинен визначити всі правила для кожного застосування;
- необмежено - якщо встановлено за умовчанням значення „Необмежено”, то запуск програм здійснюється відповідно до прав користувачів. Адміністратор визначає винятки або набір програм, які не дозволяється запускати.
Додаткові правила можуть визначатися для застосувань шляхом визначення одного з правил, що наведені в табл. 18.
Таблиця 18
| Додаткове правило | Параметр правила, який використовується |
| Хеш | Криптографічний відбиток файла, що виконується |
| Сертифікат | Сертифікат з цифровим підписом видавця програмного забезпечення для файла .exe |
| Шлях | Шлях до файла .exe: локальний шлях, шлях, відповідно до погодження про універсальне іменування або шлях в реєстрі |
| Зона | Зона Інтернету, з якої потрапив файл, що виконується (якщо файл був завантажений з використанням Microsoft Internet Explorer) |
Якщо для однієї програми встановлені два правила „Заборонено” і „Необмежено”, пріоритет отримує правило „Заборонено”. Додаткові правила мають пріоритет застосування у відповідності до порядку переліку правил в табл. 18.
6.1.7.1.5.2 Параметри політики обмеження ПЗ
Настроювання політики обмеженого використання програм дозволяє визначити окремі важливі параметри, які описані в табл.19.
Таблиця 19
| Параметр | Опис дії параметру |
| Перевірка бібліотек DLL | За умовчанням політики обмеженого використання програм не діють на бібліотеки DLL. Можливо включати бібліотеки DLL до списку файлів для обмеження, щоб забезпечити максимальну безпеку для програм, які запускаються |
| Пропускати Адміністраторів | Встановлення цього параметра дає членам локальної групи „Адміністратори” можливість запускати будь-які програми |
| Визначення файлів, що можуть виконуватися | Правила політики обмеженого використання програм дозволяють визначити типи файлів, що підлягають правилам обмеження ПЗ |
| Довірені видавці | Політикою можна визначити користувачів, яким дозволено обирати довірених видавців. Такими користувачами можуть бути звичайні користувачі, локальні адміністратори або адміністратори підприємств. Також визначається, яку перевірку відкликання сертифікатів слід виконувати перед видачею довіри видавцю |
6.1.7.2 Співставлення сервісу з функціональними вимогами безпеки
| Позначення функції безпеки | Опис функції безпеки | Позначення елемента вимог | Опис елемента вимог |
| ЗКЗЗ–1 | Політика цілісності КЗЗ ОЕ визначає домен для власного виконання та інші домени, які розподіляються за допомогою апаратних засобів робочої станції та ПЗ ядра ОС (підпункт 6.1.7.1.1) | 2-НЦ-1.1 | Політика цілісності КЗЗ повинна визначати домен КЗЗ та інші домени, а також механізми захисту, що використовуються для реалізації розподілення доменів |
| ЗКЗЗ–2.1 | КЗЗ ОЕ за допомогою апаратних засобів робочої станції та ПЗ ядра ОС підтримує домен для власного виконання, що забезпечує його захист від зовнішніх впливів і несанкціонованої модифікації і/або втрати керування (підпункт 6.1.7.1.1) | 2-НЦ-2.1 | КЗЗ повинен підтримувати домен для свого власного виконання з метою захисту від зовнішніх впливів і несанкціонованої модифікації і/або втрати керування |
| ЗКЗЗ–2.2 | Домен КЗЗ додатково (до функції ЗКЗЗ–2.1) захищається політикою обмеження ПЗ, яка протистоїть зовнішнім несанкціонованим модифікаціям і втраті керування КЗЗ шляхом виключення програм та процесів, що не підлягають встановленим правилам безпеки (підпункт 6.1.7.1.5) | ||
| ЗКЗЗ–3 | Всі функції безпеки КЗЗ надаються процесам тільки через звернення до прикладного інтерфейсу ОЕ. Запити на доступ до захищених об'єктів контролюються КЗЗ через застосування дескрипторів безпеки (підпункт 6.1.7.1.2) | 2-НЦ-3.1 | Повинні бути описані обмеження, дотримання яких дозволяє гарантувати, що послуги безпеки доступні тільки через інтерфейс КЗЗ і всі запити на доступ до захищених об'єктів контролюються КЗЗ |
| ЗКЗЗ–4 | Політика самотестувания, описує властивості, процедури та множину тестів, які використовуються для оцінки правильності функціонування КЗЗ (підпункти 6.1.7.1.1, 6.1.7.1.3, 6.1.7.1.4) | 2-НТ-1.1 | Політика самотестувания, що реалізується КЗЗ, повинна описувати властивості КС і реалізовані процедури, які можуть бути використані для оцінки правильності функціонування КЗЗ |
| ЗКЗЗ–5 | Самотестування критичних функцій КЗЗ здійснюється в процесі ініціалізації (завантаження) та функціонування ОЕ. Адміністратор та уповноважений користувача може ініціювати вибіркове тестування КЗЗ у процесі функціонування ОЕ (підпункти 6.1.7.1.1, 6.1.7.1.3, 6.1.7.1.4) | 2-НТ-2.1 | КЗЗ має бути здатним виконувати набір тестів з метою оцінки правильності функціонування своїх критичних функцій. Тести повинні виконуватися за запитом користувача, що має відповідні повноваження, при ініціалізації КЗЗ |
6.1.8 Сервіс "Реєстрація"
6.1.8.1 Опис сервісу
Назва сервісу ”Реєстрація" в термінології Розробника має синонім "аудит", який в подальшому буде використовуватися при специфікуванні сервісу. Специфікація сервісу здійснюється з врахуванням рівня функціональної послуги безпеки "Захищений журнал" (підпункт 6.2.4.1). Сервіс ”Реєстрація" включає наступні логічно відокремлені функціональні компоненти щодо:
- реєстрації подій;
- перегляду журналів аудиту;
- захисту журналу аудиту від переповнення.
6.1.8.1.1. Реєстрація подій
ОЕ забезпечує реєстрацію подій, що підлягають аудиту, в трьох журналах аудиту (табл. 20).
Таблиця 20
| Назва журналу | Призначення журналу |
| Журнал безпеки (Security Log) | Використовується для реєстрації подій, що пов’язані з захистом системи, таких як: вхід/вихід, використання ресурсів, що захищаються, керування обліковими записами та системними політиками |
| Журнал системи (System Log) | Використовується для реєстрації подій операційної системи |
| Журнал застосувань (Application Log) | Використовується для реєстрації подій, що виникають у застосуваннях та системних службах |
Кожний запис в журналах аудиту містить відомості, які описані в табл. 21.
Таблиця 21
| Інформація | Опис |
| Дата події | Дата, що відповідає виникненню події |
| Час події | Час, що відповідає виникненню події |
| Джерело події | Програма, що ініціювала подію. Це може бути як ім’я програми, так і назва компонента системи або застосування |
| Категорія події | Категорія події в залежності від джерела події. Для аудиту подій безпеки категорія відповідає одному із типів подій, для яких в політиці аудиту може бути включений аудит успіхів або відмов (табл.21) |
| Обліковий запис | Ім’я користувача, дії якого призвели до виникнення даної події. Це ім’я відповідає коду процесу користувача, якщо подія була ініційована цим процесом, або коду основного процесу у випадку, якщо користувач не має відношення до події. В деяких випадках запис містить обидва коди |
| Комп’ютер | Ім’я комп’ютера на якому виникла подія |
| Код події | Число, що визначає відповідний тип події. В першому рядку опису міститься назва типу події. Код події та ім’я джерела події можуть бути використані для усунення ушкоджень |
| Тип | Рівень важливості події. В журналах аудиту записи можуть бути одного із п’яти типів (табл.22). У вікні перегляду подій, кожному типу відповідає своя позначка |
Формат та зміст опису події аудиту залежить від типу даної події. Опис зазвичай містить відомості, які відносяться до причини та значення події. В журнали аудиту заносяться події п’яти різних типів (табл. 22). В журналі безпеки реєструються тільки події „Успіх” та „Відмова”.
Таблиця 22
| Тип події | Опис |
| Помилка (Error) | Серйозні ускладнення, такі як втрата даних або втрата функціональності |
| Попередження (Warning) | Події, що в момент запису до журналу не були істотними, але можуть призвести до ускладнень в майбутньому |
| Повідомлення (Information) | Подія, що описує успішне завершення виконання дії додатком, драйвером або службою |
| Аудит успіхів (Success Audit) | Подія, що відповідає успішному завершенню дії, яка пов’язана з підтримкою безпеки системи |
| Аудит відмов (Failed Audit) | Подія, що відповідає неуспішному завершенню дії, яка пов’язана з підтримкою безпеки системи |
Безпосередньо до безпеки має відношення тільки журнал безпеки, який і буде розглядатися в подальшому.
За створення журналу безпеки відповідає служба “Реєстратор подій” (Event Logger).
В ОЕ визначені категорії подій, що пов’язані з безпекою та підлягають аудиту (табл. 23).
Таблиця 23
| Категорія події | Опис |
| Вхід до системи | Аудит кожної спроби користувача увійти до системи або вийти із системи на даному комп’ютері, або підключитися до нього через мережу |
| Подія входу до системи | Аудит кожної спроби користувача увійти в систему або вийти з неї на іншому комп’ютері при умові, що даний комп’ютер використовується для перевірки достовірності облікового запису |
| Керування обліковими записами | Аудит усіх події, що пов’язані з керуванням обліковими записами на комп’ютері. Записи аудиту додатково включають інформацію про змінені атрибути облікового запису. До подій керування обліковими записами відносяться наступні:
|
| Доступ до служби каталогів | Аудит подій доступу користувача до об'єкту каталогу Active Directory, для якого задана власна системна таблиця доступом (SACL) |
| Доступ до об'єктів | Аудит подій спроб доступу до об'єкта (наприклад, файлу, папки, розділу реєстру, принтеру і т.ін.), для якого визначений власний системний список доступу (SACL). Записи аудиту додатково включають інформацію про ім’я об'єкту та тип доступу, що запитується |
| Зміна політики | Аудит кожного факту зміни політики призначення прав користувачів, політики аудиту, прав на виконання загальносистемних операцій та інше. Запис аудиту додатково включають інформацію про нові параметри відповідної політики |
| Використання повноважень | Аудит кожної спроби користувача скористатися належним йому повноваженням |
| Відстеження процесів | Аудит подій запуску, завершення або зміни процесів |
| Системні події | Аудит подій перезавантаження або виключення комп’ютеру, а також подій, що впливають на системну безпеку або на журнал безпеки |
В кожному запису аудиту міститься інформація, яка специфічна для певної категорії подій. Опис даної інформації в залежності від категорії подій наведено в табл. 24.
Таблиця 24
| Категорія події | Опис |
| Системна подія | Записи аудиту додатково містять інформацію про події, які мають відношення до самої операційної системи, наприклад, очищення журналів аудиту |
| Доступ до об’єкта або до служби каталогів | Записи аудиту додатково включають інформацію відносно імені об’єкту та виду доступу, що ним вимагається |
| Використання повноважень | Записи аудиту додатково ідентифікують повноваження суб’єкта |
| Відстеження процесів | Записи аудиту додатково містять інформацію про ідентифікатор процесів |
| Зміна політики та керування обліковим записом | Записи аудиту додатково включають інформацію про нові параметри політики і, відповідно, про змінені атрибути облікового запису |
| Вхід в ОЕ з обліковим записом або подія входу в ОЕ | Записи аудиту додатково включають інформацію про причини неуспішної спроби входу в ОЕ |
| Вхід в ОЕ | Записи аудиту додатково включають інформацію відносно типу входу користувача в ОЕ, а саме:
|
В межах кожної категорії подій можуть визначатися типи подій, що контролюються, тобто вказується, які події відстежувати: успішні чи неуспішні або обидві разом. Для реалізації аудиту подій доступу до об’єктів необхідно додатково визначити, які типи доступу і які користувачі або групи користувачів підлягають контролю. Це визначення здійснюється за допомогою системних списків доступу (SACL – System Access Control List).
Збирання даних про події аудиту безпеки в ОЕ забезпечують дві компоненти: монітор безпеки SRM (Security Reference Monitor) та служба LSA (Local Security Authority). Монітор безпеки SRM виконує функцію генерації даних аудиту подій доступу до об'єкта, використання повноважень та відстеження процесів. Генерація даних аудиту для усіх інших категорій подій безпеки реалізується службами, що функціонують разом з LSA. Єдиним виключенням з даного порядку є випадок самостійної реєстрації службою Event Logger події очищення журналу безпеки.
Служба LSA та монітор безпеки SRM взаємодіють через локальний порт підключення (Local connection port), який використовується для передачі параметрів політики аудиту монітору SRM. У випадку зміни адміністратором політики аудиту служба LSA звертається до своєї власної бази даних і повідомляє про зміни монітор безпеки SRM. Монітор безпеки SRM отримує керуючий прапор, який вказує на те, що аудит дозволений, та дані, які визначають категорію подій, що підлягають аудиту.
6.1.8.1.2 Перегляд журналів аудиту
Утиліта «Перегляд подій» (Event Viewer) використовується для перегляду журналів аудиту. Утиліта надає інтерфейс користувача для перегляду вмісту журналів аудиту, а також надає можливість пошуку і фільтрації конкретних подій. Для журналу безпеки в якості параметрів фільтрації і пошуку подій можуть бути задані: ідентифікатор користувача, тип події, джерело події, категорія події, код події, часовий інтервал, за який необхідно переглянути події, та ім'я комп'ютера.
6.1.8.1.3. Захист журналів аудиту від переповнення
Аудит безпеки адміністратор настроює в залежності від політики безпеки в організації. За умовчанням аудит безпеки вимкнено. Перед застосуванням аудиту визначаються події, які необхідно реєструвати, оскільки аудит значної кількості подій може суттєво знизити продуктивність системи та потребує додатковий дисковий простір для розміщення журналів аудиту.
Адміністратор може встановити для журналу його максимальний розмір, та визначити поведінку системи при досягненні цього розміру:
- видаляти старі повідомлення при необхідності;
- видаляти події, що старіші конкретної кількості днів;
- не видаляти повідомлення (очищення вручну). В випадку переповнення журналу аудиту в залежності від параметрів конфігурування припиняється реєстрація нових подій або завершується робота ОС. Для адміністратора встановлюється відповідне попередження.
У випадку досягнення граничного значення розміру журналу безпеки, реєструється відповідна подія аудиту.
6.1.8.2 Співставлення сервісу з функціональними вимогами безпеки
| Позначення функції безпеки | Опис функції безпеки | Позначення елемента вимог | Опис елемента вимог |
| Р–1 | В ОЕ забезпечується реєстрація визначеної множини подій в журналах аудиту, кожний з яких має своє призначення (підпункт 6.1.8.1.1, табл. 20) | 2-НР-1.1 | Політика реєстрації, що реалізується КЗЗ, повинна визначати перелік подій, що реєструються |
| Р–2 | В ОЕ забезпечується реєстрація у спеціалізованому журналі безпеки подій, що мають безпосереднє відношення до безпеки (підпункт 6.1.8.1.1, табл. 23) | 2-НР-2.1 | КЗЗ повинен бути здатним здійснювати реєстрацію подій, що мають безпосереднє відношення до безпеки |
| Р–3 | Кожний запис в журналі реєстрації містить інформацію про дату, час, джерело, тип і успішність чи неуспішність кожної зареєстрованої події (підпункт 6.1.8.1.1, табл. 21, 22) | 2-НР-3.1 | Журнал реєстрації повинен містити інформацію про дату, час, місце, тип і успішність чи неуспішність кожної зареєстрованої події |
| Р–4 | Для кожної події журнал реєстрації зберігає інформацію щодо унікального ідентифікатора користувача та інформацію про процес та об’єкт, які мають відношення до події (підпункт 6.1.8.1.1, табл. 21, 24) | 2-НР-3.2 | Журнал реєстрації повинен містити інформацію, достатню для встановлення користувача, процесу і/або об'єкта, що мали відношення до кожної зареєстрованої події |
| Р–5 | Тільки адміністратор, уповноважені користувачі та відповідні системні процеси мають доступ до журналу безпеки (підпункт 6.1.8.1.3) | 2-НР-4.1 | КЗЗ повинен забезпечувати захист журналу реєстрації від несанкціонованого доступу, модифікації або руйнування |
| Р–6 | Адміністратори та уповноважені користувачі мають можливість за допомогою відповідного інтерфейсу переглядати та аналізувати журнал безпеки (підпункт 6.1.8.1.2) | 2-НР-4.2 | Адміністратори і користувачі, яким надані відповідні повноваження, повинні мати в своєму розпорядженні засоби перегляду і аналізу журналу реєстрації |
6.1.9 Сервіс „Ідентифікація і автентифікація”
6.1.9.1 Опис сервісу
Специфікація сервісу „Ідентифікація та автентифікація” здійснюється відповідно рівнів функціональних послуг безпеки „Одиночна ідентифікація та автентифікація” (підпункт 6.2.4.2) та „Однонаправлений достовірний канал” (підпункт 6.2.4.3). Автентифікація (authentication) визначається як процедура перевірки відповідності пред’явленого ідентифікатора об’єкта АС на предмет належності ідентифікатора саме цьому об’єкту. ОЕ застосовує автентифікацію при кожному вході користувача (або процесу) в систему незалежно від типу входу в систему. Кожний користувач повинен бути автентифікований до того, як йому буде надане право виконувати будь-які дії в системі. Тому реалізація послуги „Ідентифікація та автентифікація” є необхідною умовою для виконання більшості функціональних послуг безпеки.
Сервіс „Ідентифікація та автентифікація” включає наступні логічно відокремлені функціональні компоненти:
- база даних атрибутів користувачів;
- варіанти входу в систему;
- достовірний канал;
- процес входу в систему і вибір протоколу автентифікації;
- імперсонація.
6.1.9.1.1 База даних атрибутів користувачів
ОЕ підтримує базу даних SAM, в якій визначені облікові записи користувачів та груп користувачів. Інформація в базі даних SAM захищається механізмом контролю доступу та хешуванням паролів. Сама база даних SAM шифрується за допомогою системного ключа.
Кожен обліковий запис в базі представлений набором атрибутів, стислий опис яких наведено в табл. 25.
Таблиця 25
| Атрибут | Опис атрибута |
| Ім’я облікового запису | Використовується для представлення облікового запису в зручному для читання вигляді |
| Ідентифікатор безпеки SID | Ідентифікатор використовується для однозначного представлення облікового запису користувача або групи користувачів в межах системи |
| Пароль | Використовується для автентифікації облікового запису користувача при вході до системи (застосовується лише для облікових записів користувачів) |
| Групи | Використовуються, щоб зв’язати членів групи користувачів з єдиним обліковим записом |
| Повноваження | Використовуються для зв’язку повноважень користувачів або груп користувачів з відповідним обліковим записом |
| Права на вхід до системи | Визначає право користувача щодо варіантів його входу в систему (табл. 26) |
| Керуюча інформація | Використовується для контролю додаткових атрибутів облікового запису, що стосуються безпеки (час дії облікового запису, термін дії пароля та ін.) |
| Інша інформація, що не відноситься до безпеки | Використовується для додаткового опису облікового запису |
Дійсна сукупність атрибутів залежить від типу облікового запису користувача. ОЕ підтримує доменний і локальний типи облікових записів. При застосуванні доменного облікового запису користувач входить до мережі за допомогою пароля або смарт-карти, використовуючи сертифікат, що зберігається в Active Directory. При цьому диспетчер LSA взаємодіє з контролером домену Domain Controller (DC) для перевірки автентичності користувача. Використовуючи доменний обліковий запис для входу в систему, авторизований користувач може отримати доступ до ресурсів, розташованих у домені та у довірених доменах. При застосуванні локального облікового запису користувач входить до системи, використовуючи посвідчення, що зберігається в локальній базі даних SAM. Кожна робоча станція або сервер може зберігати локальні облікові записи користувачів, але ці користувачі зможуть отримувати доступ лише до ресурсів локального комп’ютера.
6.1.9.1.2 Варіанти входу в систему
ОЕ підтримує чотири варіанти входу в систему (табл. 26).
Таблиця 26
| Варіант входу | Опис |
| Інтерактивний (Interactive) | Вхід на локальний комп’ютер, до якого користувач має фізичний доступ. Вхід через Термінал (Terminal Services) та Віддалений Робочий Стіл (Remote Desktop) також вважається інтерактивним, незважаючи на те, що виконується дистанційно |
| Мережний (Network) | Вхід на віддалений комп’ютер через мережу для доступу до його ресурсів. У цьому випадку диспетчер LSA здійснить спробу встановити ідентичність через диспетчер LSA віддаленого комп’ютера на основі атрибутів, що використовувались при вході в систему |
| В якості системної служби (Service) | Вхід в систему в якості Системної служби (Service), яка виконується в контексті безпеки локального чи доменного облікового запису |
| Пакетний (Batch) | Вхід в систему в якості пакетного завдання (Batch job) |
Для кожного типу входу визначено відповідне право, яке призначається обліковому запису користувача або групі користувачів. Це дає можливість контролю способів реєстрації в ОЕ, які доступні для користувача.
6.1.9.1.3 Достовірний канал
З метою захисту ідентифікаційної та автентифікаційної інформації при первинному інтерактивному вході до системи, використовується достовірний канал. Достовірний канал ініціюється одночасним натисканням клавіш Ctrl+Alt+Del, та фіксується функціями безпеки для запобігання перериванню або перехопленню процесом-порушником. Для отримання інформації про користувача задіяна служба WinLogon та модуль Graphical Identification and Authentication (GINA). Основна мета модуля GINA – збір ідентифікаційної та автентифікаційної інформації, що вводиться користувачем, та її передача в певному форматі диспетчеру LSA. Модуль GINA надає інтерфейс, за допомогою якого користувач реєструється в системі (зокрема, стандартне діалогове вікно входу в систему).
6.1.9.1.4 Вхід в систему
Усі запити на вхід в ОЕ обробляються єдиним способом, незалежно від їхнього типу (інтерактивний, мережний вхід у систему, вхід в якості пакетного завдання чи служби).
Основним модулем служб автентифікації є диспетчер LSA. Він являє собою захищений модуль, який перевіряє автентичність користувача. Модель автентифікации реалізована по модульному принципі на основі пакетів автентифікації (Authentication Packages). Модульність архітектури дозволяє абстрагувати основні системні процедури автентифікації від конкретних протоколів і реалізації.
Початок входу в систему починається після натиснення комбінації клавіш Ctrl+Alt+Del (Secure Attention Sequence, SAS). Процес Winlogon звертається до модулю MSGINA (встановлений за умовчанням в ОЕ) для відображення діалогу для входу. Після введення користувачем своїх реквізитів Winlogon передає отриману інформацію в диспетчер LSA. Тобто формується запит на вхід, в якому користувач надає ОЕ необхідну інформацію, таку як ім'я облікового запису користувача, пароль та ім'я домена, у випадку, якщо ОЕ функціонує у складі АС 2 або 3 класу. Диспетчер LSA обробляє запит (вираховує криптографічний хеш пароля користувача) і посилає його у форматі пакета автентифікации для перевірки у відповідну службу. Пакет автентифікации реалізує логіку перевірки параметрів користувача і в кінцевому підсумку приймає рішення про успішну або неуспішну реєстрацію.
6.1.9.1.4.1 Протоколи та пакети автентифікації
Користувач, що запитує автентифікацию за певним протоколом, передає свої параметри диспетчеру LSA, який викликає відповідний пакет автентифікації і передає йому ці параметри. При успішній перевірці саме пакет автентифікації ініціює новий сеанс користувача і формує список ідентифікаторів безпеки, що потім буде включений у маркер доступу автентифікованого користувача. Пакет автентифікації є бібліотекою DLL, що підключається до диспетчера LSA при старті ОЕ.
ОЕ підтримує декілька протоколів для ідентифікації користувачів, що мають облікові записи в системі, включаючи протоколи для автентифікації телефонних підключень, протоколи автентифікації користувачів, що намагаються дістатись мережі через Інтернет. В якості протоколів мережної автентифікації найбільш широко вживаються протоколи Kerberos V5 та NTLM. В ОЕ протокол Kerberos V5 підтримується пакетом Kerberos, протокол NTLM – пакетом MSV1_0.
6.1.9.1.4.1.1 Протокол NTLM
Протокол NTLM використовує для автентифікації механізм “запит/відповідь”. Для отримання нового маркеру доступу, сервер, до ресурсу якого звертається користувач, повинен взаємодіяти з контролером домена для перевірки приналежності. Якщо сервер не входить до домену, протокол NTLM може бути використаний для автентифікації в одноранговій мережі.
NTLM підтримує 3 форми автентифікації:
- LAN Manager (LM) – найменш безпечна форма автентифікації «запит/відповідь». Застосовується при підключенні ОЕ до комп’ютерів, що працюють під керуванням Microsoft Windows for Workgroups, Windows 95, Windows 98;
- NTLM Version 1 – більш безпечна форма автентифікації «запит/відповідь», ніж LAN Manager. Застосовується при підключенні до серверів в доменах Windows NT (NT4 - NT4/SP3);
- NTLM Version 2 – найбільш поширена (з протоколу NTLM) та безпечна форма автентифікації «запит/відповідь». Застосовується при підключенні до серверів в доменах Windows NT (NT4/ SP 4), а також до комп’ютерів під керуванням Windows 2000 Windows чи XP Professional, що підключаються до серверів з Windows NT в домені Windows 2000.
6.1.9.1.4.1.2 Протокол Kerberos
Протокол Kerberos V5 забезпечує взаємну автентифікацію між клієнтом (користувач, комп’ютер чи послуга) та сервером. Робота протоколу Kerberos заснована на припущенні, що перший етап взаємодії між клієнтом та сервером проходить у відкритій мережі. Протокол Kerberos V5 використовує секретний ключ для шифрування даних автентифікації перед передачею по мережі і дешифрування після їх отримання. Дешифрування та наступні кроки (дії) виконуються центром розповсюдження ключів Kerberos Key Distribution Center (KDC), що запущений на кожному контролері домену, як частина Active Directory.
Між протоколами Kerberos V5 та NTLM існують дві основні відмінності.
При застосуванні протоколу NTLM ім’я користувача та пароль пересилаються у хешованому вигляді на сервер, де хешований пароль співствляється з варіантом пароля, що зберігається у відповідній базі даних. В разі позитивного співставлення паролів вхід дозволяється.
Протокол Kerberos вимагає, щоб запит на вхід в систему був частково перетворений за допомогою хешованого пароля. Модифікований запит відсилається контролеру домена, який відшукує пароль у відповідній базі даних та використовує його для зворотного перетворення запиту. В разі позитивного співставлення запитів вхід дозволяється. Таким чином, автентифікаційний сервер AS протоколу Kerberos автентифікує користувача без передачі паролю по мережі.
При використанні протоколу NTLM, в разі звернення до віддаленого ресурсу, користувач повинен пройти процедуру автентифікації в ОС віддаленого комп’ютеру. У випадку Kerberos при взаємодії з ОС віддаленого комп’ютеру, необхідно пройти автентифікацію на відповідному сервері протоколу Kerberos.
6.1.9.1.4.2 Вибір протоколу для автентифікації
Вибір протоколу, який використовується ОЕ для автентифікації користувача, залежить від типу входу в систему (локальний або доменний). Процес входу проходить через декілька етапів:
- після введення користувачем своїх реквізитів диспетчер LSA передає введені дані через інтерфейс SSPI (Security Support Provider Interface) до пакету автентифікації Kerberos, який використовується за умовчанням на клієнтському комп’ютері;
- пакет Kerberos визначає, який тип облікового запису (локальний чи доменний) використовується для спроби входу;
- якщо використовується локальний обліковий запис, пакет Kerberos не приймає спроб виконати автентифікацію - переходить до автентифікації за допомогою протоколу NTLM;
- якщо використовується доменний обліковий запис, пакет Kerberos звертається до KDC для автентифікації користувача;
- якщо KDC не може автентифікувати користувача, повідомлення про помилку передається назад від KDC в пакет Kerberos на клієнтському комп’ютері;
- якщо KDC не знайдено, повідомлення про помилку „No logon server available” передається від пакета Kerberos до диспетчера LSA;
- при отриманні повідомлення про помилку диспетчер LSA через SSPI звертається до пакета автентифікації MSV1_0. Пакет MSV1_0 використовує службу Net Logon для автентифікації за протоколом NTLM для доменних облікових записів чи звертається до SAM для локальних облікових записів.
Якщо жоден з пакетів автентифікації не може автентифікувати користувача, генерується повідомлення про помилку. Після цього користувач має можливість повторити спробу входу в систему. Кількість спроб входу в систему визначається політикою блокування облікового запису.
При успішному результаті перевірки диспетчер LSA формує маркер доступу (підпункт 6.1.1.1.1.3).
6.1.9.1.5 Імперсонація
В ОЕ підтримується можливість імперсонації. Кожен процес має первинний маркер доступу. Зазвичай кожен потік, виконується в межах якого-небудь процесу, використовуючи маркер доступу процесу, який визначає його контекст безпеки. Однак потік може мати два маркери доступу: первинний та імперсонований, що використовується для організації взаємодії з об’єктом припиняється при видаленні імперсонованого маркеру доступу чи завершенні потоку, що має імперсований маркер доступу.
6.1.9.2 Співставлення сервісу з функціональними вимогами безпеки
| Позначення функції безпеки | Опис функції безпеки | Позначення елемента вимог | Опис елемента вимог |
| ІА–1 | В ОЕ КЗЗ підтримує базу даних облікових записів користувачів. Кожний обліковий запис включає наступні атрибути: ідентифікатор користувача, автентифікаційна інформація, повноваження, права на вхід, членство в групах та ін. (підпункт 6.1.9.1.1, табл. 24) | 2-НИ-1.1 | Політика ідентифікації і автентифікації, що реалізується КЗЗ, повинна визначати атрибути, якими характеризується користувач, і послуги, для використання яких необхідні ці атрибути |
| ІА–2 | Кожний користувач ОЕ має ідентифікатор безпеки, який зберігається в його обліковому записі і використовується для його ідентифікації при здійсненні будь- якої дії в системі (підпункт 6.1.9.1.1) | 2-НИ-1.2 | Кожний користувач повинен однозначно ідентифікуватися КЗЗ |
| ІА–3 | Перед виконанням користувачем будь-якої дії під контролем КЗЗ ОЕ, виконується ідентифікація та автентифікація користувача з використанням захищених механізмів автентифікації. Тільки при успішній автентифікації КЗЗ надає користувачу маркер доступу, який дозволяє виконувати контрольовані дії (підпункт 6.1.9.1.4, 6.1.9.1.5) | 2-НИ-2.1 | Перш ніж дозволити будь-якому користувачу виконувати будь-які інші, контрольовані КЗЗ дії, КЗЗ повинен автентифікувати цього користувача з використанням захищеного механізму |
| ІА–4 | КЗЗ ОЕ зберігає автентифікаційні дані в базі даних SAM, доступ до якої можливий тільки через спеціальні системні процедури. Паролі зберігаються в базі даних SAM у хешованому вигляді, а сама база даних зашифрована системним ключом (підпункт 6.1.9.1.1) | 2-НИ-3.1 | КЗЗ повинен забезпечувати захист даних автентифікації від несанкціонованого доступу, модифікації або руйнування |
| ІА–5 | КЗЗ ОЕ реалізує механізм встановлення достовірного зв'язку між користувачем і КЗЗ, який ініціюється одночасним натисканням клавіш Ctrl+Alt+Delete (підпункт 6.1.9.1.3) | 1-НК-1.1 | Політика достовірного каналу, що реалізується КЗЗ, повинна визначати механізми встановлення достовірного зв'язку між користувачем і КЗЗ |
| ІА–6 | При первинному інтерактивному вході до системи використовується достовірний канал для початкової ідентифікації і автентифікації користувача (підпункт 6.1.9.1.2.4) | 1-НК-2.1 | Достовірний канал повинен використовуватися для початкової ідентифікації і автентифікації |
| ІА–7 | Зв’язок з достовірним каналом ініціюється тільки користувачем. КЗЗ реалізує функції для запобігання перериванню або перехопленню каналу не довіреним процесом (підпункт 6.1.9.1.3) | 1-НК-2.2 | Зв'язок з використанням даного каналу повинен ініціюватися виключно користувачем |