NIST Special Publication 800-207
Архітектура нульової довіри (Zero Trust Architecture)

1.1 Історія розвитку ініціатив Zero Trust у федеральних агентствах США

Концепція нульової довіри існувала в кібербезпеці задовго до того, як з’явився сам термін «zero trust». Агентство оборонних інформаційних систем (DISA) та Міністерство оборони США (DoD) опублікували результати своєї роботи над більш безпечною корпоративною стратегією під назвою «чорне ядро» (Black Core) [BCORE]. Стратегія Black Core передбачала перехід від моделі безпеки на основі периметра до моделі, зосередженої на безпеці окремих транзакцій.

Діяльність Jericho Forum у 2004 році популяризувала ідею «депериметризації» (de-perimeterization) — обмеження неявної довіри на основі фізичного місця розташування в мережі та усунення недоліків, пов’язаних із покладанням на єдині статичні бар’єри захисту великого мережевого сегмента [JERICHO]. Концепції депериметризації розвивалися й удосконалювалися у ширшу концепцію нульової довіри, термін для якої згодом запропонував Джон Кіндерваг (John Kindervag), перебуваючи на посаді аналітика у Forrester Research.

Після цього «Zero Trust» став загальновизнаним терміном для опису різноманітних рішень кібербезпеки, які відмовилися від передбачуваної довіри за мережевою ознакою і замість цього зосередилися на оцінці довіри для кожної окремої транзакції. Як приватний сектор економіки, так і вищі навчальні заклади також пройшли цю еволюцію від захисту периметра до безпекової стратегії, побудованої на засадах нульової довіри.

Федеральні агентства США закликалися до переходу на принципи нульової довіри понад десятиліття, поступово нарощуючи технологічні можливості та нормативну базу. Це відбувалося через Закон про модернізацію федеральної інформаційної безпеки (FISMA), за яким послідувала Рамкова програма управління ризиками (RMF); Федеральна програма управління ідентифікацією, обліковими даними та доступом (FICAM); ініціатива Довірених інтернет-з’єднань (TIC); та програма Безперервної діагностики та пом’якшення загроз (CDM).

Усі ці програми мали на меті обмежити доступ до даних і ресурсів лише авторизованими сторонами. Коли ці програми започатковувалися, вони стримувалися технічними можливостями тогочасних інформаційних систем. Політики безпеки були здебільшого статичними і застосовувалися у великих «вузлових точках перехоплення» (choke points), які підприємство могло контролювати для отримання максимального ефекту за мінімальних зусиль.

У міру дозрівання технологій з’явилася можливість постійно аналізувати й оцінювати запити на доступ у динамічний та деталізований спосіб на основі принципу «потреби в доступі» (need to access), мінімізуючи ризики компрометації облікових записів, моніторингу мережі зловмисниками та інших критичних загроз.

1.2 Структура цього документа

Подальший зміст цього стандарту організовано наступним чином:

• Розділ 2 визначає ZT і ZTA та перелічує базові припущення при проектуванні ZTA для підприємства. Цей розділ також містить повний перелік семи фундаментальних постулатів проектування нульової довіри.
• Розділ 3 документує логічні компоненти (будівельні блоки) нульової довіри. Унікальні практичні реалізації можуть компонувати елементи ZTA по-різному, проте виконуватимуть однакову логічну функціональність.
• Розділ 4 наводить можливі прецеденти використання (Use Cases), де ZTA робить корпоративні середовища безпечнішими та менш схильними до успішної експлуатації. Сюди входять підприємства з віддаленими співробітниками, хмарними сервісами та гостьовими мережами.
• Розділ 5 обговорює загрози для підприємства, що використовує ZTA. Багато з цих загроз є спільними для будь-яких архітектур мереж, проте в ZTA вони можуть вимагати принципово інших методів нейтралізації.
• Розділ 6 розглядає, як постулати ZTA узгоджуються з існуючими нормативними настановами для федеральних агентств та доповнюють їх.
• Розділ 7 представляє відправну точку для переходу підприємства (зокрема федерального відомства) до ZTA. Сюди входить опис загальних кроків, необхідних для планування та розгортання застосунків та корпоративної інфраструктури, керованих постулатами ZT.
• Додаток A містить офіційний глосарій акронімів та скорочень.
• Додаток B аналізує виявлені прогалини в сучасному стані розвитку та технологіях ZTA.

Оперативні визначення стандарту NIST SP 800-207:

Нульова довіра (Zero Trust, ZT) надає сукупність концепцій та ідей, розроблених для мінімізації невизначеності під час забезпечення точних рішень щодо надання доступу до інформаційних систем і сервісів за принципом найменших привілеїв для кожного окремого запиту в умовах, коли мережа апріорі розглядається як скомпрометована.

Архітектура нульової довіри (Zero Trust Architecture, ZTA) — це план кібербезпеки підприємства, який використовує концепції нульової довіри та охоплює взаємозв’язки між компонентами, проектування робочих процесів і політики доступу. Таким чином, підприємство з нульовою довірою — це мережева інфраструктура (фізична та віртуальна) і робочі політики, які діють на підприємстві як продукт плану ZTA.

2.1 Сім фундаментальних постулатів Zero Trust (Tenets of Zero Trust)

Архітектура нульової довіри проектується та розгортається відповідно до семи фундаментальних постулатів (Tenets), які визначають ідеальні цільові властивості системи:

Вищезазначені постулати розроблені як технологічно нейтральні (technology agnostic). Наприклад, термін «ідентифікація користувача (ID)» може включати декілька факторів: комбінацію логіна й пароля, цифрові сертифікати X.509, одноразові коди або біометричні маркери.

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

2.2 Погляд Zero Trust на сучасну мережу (A Zero Trust View of a Network)

Існує кілька базових припущень щодо мережевого підключення для будь-якої організації, яка використовує ZTA під час планування та розгортання мережі. Деякі з цих припущень застосовуються до власної мережевої інфраструктури підприємства, а деякі — до власних ресурсів підприємства, що функціонують на базі сторонньої мережевої інфраструктури (наприклад, у публічних мережах Wi-Fi або у провайдерів публічних хмар).

Ці припущення спрямовують формування ZTA. Мережа в організації, що впроваджує ZTA, повинна проектуватися з урахуванням сформульованих вище постулатів та наступних шести припущень:

1. Уся приватна мережа підприємства не вважається зоною неявної довіри.
   Активи повинні завжди діяти так, ніби в мережі підприємства постійно присутній зловмисник, і будь-яка комунікація повинна здійснюватися в найбільш захищений доступний спосіб (див. Постулат 2). Це тягне за собою такі обов’язкові дії, як автентифікація абсолютно всіх з’єднань і тотальне шифрування всього трафіку.
2. Пристрої в мережі можуть не належати підприємству та не конфігуруватися ним.
   Відвідувачі, сторонні аудитори та/або підрядні організації можуть використовувати активи, що не належать підприємству, але потребують мережевого доступу для виконання своїх робочих функцій. Сюди також входять політики використання власних пристроїв (BYOD), які дозволяють штатним суб’єктам підприємства використовувати персональні комп’ютери та смартфони для доступу до окремих корпоративних ресурсів.
3. Жоден ресурс не є довіреним від природи.
   Кожен актив повинен проходити оцінку свого стану безпеки через PEP перед тим, як його запит на доступ до ресурсу підприємства буде схвалено (аналогічно до Постулату 6 як для активів, так і для суб’єктів). Ця оцінка повинна залишатися безперервною впродовж усього часу тривалості сесії. Пристрої, що належать підприємству, можуть мати спеціальні криптографічні артефакти (наприклад, корпоративні сертифікати пристрою), які забезпечують автентифікацію та надають вищий рівень впевненості порівняно з аналогічним запитом від сторонніх гаджетів. Одних лише облікових даних суб’єкта (логіна та пароля) абсолютно недостатньо для автентифікації пристрою перед ресурсом підприємства.
4. Не всі ресурси підприємства розміщені на інфраструктурі, що належить підприємству.
   Ресурси включають віддалених суб’єктів підприємства, а також розподілені хмарні сервіси (IaaS, PaaS, SaaS). Активи, якими володіє або керує підприємство, часто змушені використовувати локальну сторонню мережу (тобто мережу, що не належить підприємству) для отримання базової зв’язності та службових мережевих сервісів (наприклад, публічного дозволу імен DNS або маршрутизації пакетів).
5. Віддалені суб’єкти та активи підприємства не можуть повністю довіряти своєму локальному мережевому з’єднанню.
   Дистанційні суб’єкти повинні виходити з того, що їхня локальна мережа (домашній Wi-Fi, мережа готелю, кав’ярні) є ворожою. Активи повинні припускати, що весь їхній трафік прослуховується, записується і потенційно модифікується. Усі запити на з’єднання повинні проходити автентифікацію та авторизацію, а вся взаємодія має вестися у максимально захищений спосіб із забезпеченням конфіденційності, цілісності та автентичності джерела.
6. Активи та робочі навантаження, що переміщуються між інфраструктурою підприємства та сторонньою інфраструктурою, повинні підтримувати узгоджену політику та стан безпеки.
   Активи та робочі навантаження повинні зберігати незмінний профіль безпеки при переході з інфраструктури підприємства на сторонню інфраструктуру і навпаки. Це стосується ноутбуків і телефонів, які переходять з офісної корпоративної мережі на домашню (дистанційні користувачі). Це також стосується віртуальних робочих навантажень, які мігрують із локальних ЦОД підприємства до публічних хмарних середовищ (наприклад, мікросервісні контейнери).

3. Логічні компоненти архітектури нульової довіри (Logical Components of ZTA)

▪ 3.1 Варіації підходів до ZTA (Variations of ZTA Approaches)

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

▪ 3.2 Практичні моделі розгортання абстрактної архітектури (Deployed Variations)

Всі компоненти ZTA є логічними абстракціями. У практичному розгортанні вони реалізуються в чотирьох основних архітектурних конфігураціях:

3.2.1 Модель «Агент пристрою / Шлюз ресурсів» (Device Agent/Gateway Model)

У цій моделі точка забезпечення політики (PEP) розділена на дві частини: клієнтський агент, встановлений на пристрої суб’єкта, та ресурсний шлюз, розташований безпосередньо перед цільовим корпоративним ресурсом. Агент перевіряє цілісність системи, шифрує трафік і передає запити до шлюзу після погодження з Рушієм політик (PE).

Рис. 3 (Figure 3): Модель «Агент пристрою / Шлюз ресурсів» (Device Agent/Gateway Model). Клієнтський агент забезпечує збір стану пристрою, а шлюз перед ресурсом гарантує доступ лише після схвалення від Policy Administrator (PA).

3.2.2 Модель розгортання на основі шлюзу безпеки анклаву (Enclave-Based Deployment)

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

Рис. 4 (Figure 4): Модель шлюзу анклаву (Enclave Gateway Model). Шлюз PEP захищає групу взаємопов’язаних корпоративних ресурсів або спадкових систем у захищеному анклаві.

3.2.3 Модель розгортання на основі ресурсного порталу (Resource Portal-Based Deployment)

У цій моделі на клієнтський пристрій не встановлюється жоден агент. Користувач взаємодіє із захищеним веб-порталом (Resource Portal), який одночасно виступає точкою забезпечення політики (PEP) для одного або кількох застосунків. Це основний сценарій для пристроїв BYOD або співпраці із зовнішніми контрагентами.

Рис. 5 (Figure 5): Модель ресурсного порталу (Resource Portal Model). Доступ регулюється порталом без необхідності встановлення локального програмного агента на пристрій користувача.

3.2.4 Модель ізоляції в пісочниці застосунків (Application Sandboxing Deployment)

На пристрої суб’єкта робочі застосунки запускаються в суворо ізольованій «пісочниці» (контейнері або віртуальному середовищі). Пісочниця блокує спроби шкідливого ПЗ перехопити дані або заразити інші застосунки та керує захищеними каналами зв’язку із серверами організації.

Рис. 6 (Figure 6): Модель пісочниць застосунків (Application Sandboxes). Кожен корпоративний застосунок запускається в ізольованому безпековому середовищі на кінцевій станції.

▪ 3.3 Алгоритм оцінки довіри (The Trust Algorithm)

Рушій політик (Policy Engine, PE) є інтелектуальним «мозком» ZTA. Процес прийняття рішення щодо надання доступу або відхилення запиту базується на математичному та логічному Алгоритмі довіри (Trust Algorithm, TA).

Рис. 7 (Figure 7): Вхідні дані алгоритму довіри (Trust Algorithm Input). Багатовекторний аналіз запиту: параметри суб’єкта, стан пристрою, вимоги ресурсу, розвіддані про загрози та поведінковий контекст.

Ключові групи вхідних даних для алгоритму довіри:

• Запит на доступ (Access Request): безпосередній запит від суб’єкта (тип запитуваного ресурсу, порт, протокол, IP-адреса джерела).
• База даних суб’єктів (Subject Database): ідентифікатор, посада, ролі, належність до груп, історія навчання, історія автентифікацій.
• База даних активів та поточний стан (Asset Database & Status): виробник пристрою, ОС, статус шифрування дисків BitLocker, оновлення безпеки, активність антивірусу/EDR, наявність сертифіката пристрою.
• Вимоги до ресурсу (Resource Requirements): ступінь конфіденційності даних (Public, Confidential, Secret), критичність сервісу для безперервності бізнесу.
• Розвіддані про загрози (Threat Intelligence): фіди про активні атаки, шкідливі IP/домени, скомпрометовані сертифікати, глобальні вразливості нульового дня (0-day).

3.3.1 Варіації алгоритмів довіри (Trust Algorithm Variations)

Стандарт NIST SP 800-207 виділяє два основних технічних виміри класифікації алгоритмів довіри:

Ідеальний алгоритм є контекстним і адаптивним, проте налаштування вагових коефіцієнтів та порогових значень вимагає постійного калібрування адміністраторами для мінімізації помилкових блокувань легітимних співробітників (false denials) або помилкових схвалень скомпрометованих сеансів (false approvals).

▪ 3.4 Компоненти мережі та середовища: експлуатаційні передумови ZTA

У середовищі Zero Trust має забезпечуватися суворе логічне (а за потреби — і фізичне) розділення між Площиною керування (Control Plane) та Площиною даних (Data Plane). Трафік керування (сесії перевірки політик між PEP, PA та PE) захищається виділеними зашифрованими каналами й не змішується з трафіком прикладних даних.

3.4.1 Десять обов’язкових мережевих вимог для підтримки ZTA (NIST SP 800-207):

4.1 Підприємство з відокремленими філіями (Enterprise with Satellite Facilities)

Найбільш поширений класичний сценарій: організація має центральну штаб-квартиру з головним центром обробки даних (ЦОД) та декілька географічно віддалених локацій (філій, регіональних представництв, польових офісів), які можуть мати або не мати власної обчислювальної інфраструктури. Крім того, значна частина співробітників працює дистанційно з дому або в мобільному режимі (remote employees).

Традиційно в таких мережах увесь трафік філій перенаправлявся назад до штаб-квартири (backhauling) через дорогі орендовані канали зв’язку MPLS або постійні тунелі VPN «точка-точка», де проходив через централізований стек міжмережевих екранів для виходу в Інтернет чи до хмарних сервісів. Це створювало величезні мережеві затримки (latency), перевантажувало канали штаб-квартири та робило роботу віддалених офісів з сучасними хмарними застосунками (SaaS) вкрай некомфортною.

Підхід ZTA (Рисунок 8): Замість централізованого перенаправлення трафіку, філії та мобільні співробітники використовують прямий вихід до Інтернету (Direct Internet Access, DIA). Кінцеві пристрої співробітників підключаються безпосередньо до потрібних корпоративних ресурсів або хмарних служб через локальні або хмарні шлюзи PEP. Точка ухвалення рішень (PDP) централізовано контролює стан пристрою та профіль суб’єкта через Площину керування. Якщо співробітнику потрібен доступ до ресурсу в іншому польовому офісі чи хмарі, шлях зв’язку створюється безпосередньо між агентом пристрою та відповідним шлюзом PEP ресурсу, уникаючи транзиту через центральний офіс.

4.2 Мультихмарне підприємство та міжхмарна взаємодія (Multi-cloud/Cloud-to-Cloud Enterprise)

Дедалі частіше підприємства експлуатують інфраструктуру, розміщену одночасно у кількох різних постачальників хмарних послуг (наприклад, AWS, Microsoft Azure, Google Cloud), або комбінують приватну хмару з десятками зовнішніх SaaS-сервісів. У багатьох складних бізнес-процесах мікросервіс або застосунок, розміщений в одній хмарі, повинен безпечно викликати API або отримувати дані з бази даних, розташованої в іншій хмарі або локальному ЦОД.

Підхід ZTA (Рисунок 9): Шлюзи PEP розгортаються безпосередньо на точках входу до кожного хмарного сегмента або перед конкретними сервісами. Коли сервіс у Хмарі А звертається до ресурсу в Хмарі Б, це звернення розглядається як потенційно ворожий зовнішній мережевий виклик. Сервіси взаємно автентифікуються (mTLS) та передають криптографічні сеансові токени (наприклад, SPIFFE/OAuth), перевірені рушієм політик (PE). PDP забезпечує узгоджене виконання єдиної корпоративної політики безпеки незалежно від специфічних інструментів захисту конкретного хмарного провайдера.

4.3 Підприємство з підрядниками та гостьовим доступом (Contracted Services and Nonemployee Access)

Організація часто залучає зовнішніх підрядників, аудиторів, розробників програмного забезпечення або сторонніх сервісних спеціалістів, яким потрібен тимчасовий або обмежений доступ до внутрішніх ресурсів для виконання контрактних зобов’язань. Ці суб’єкти зазвичай використовують комп’ютери та мобільні телефони, які належать стороннім компаніям (підрядникам) і не знаходяться під керуванням систем MDM чи EDR підприємства-замовника.

Підхід ZTA (Рисунок 10): Замість видачі підрядникам загального доступу до корпоративного VPN (який би відкрив їм видимість усього внутрішнього периметра мережі), підприємство розгортає безагентні рішення (модель Ресурсного порталу за Розділом 3.2.3 або ізольовані віртуальні робочі столи VDI). Шлюз PEP надає доступ виключно до одного конкретного веб-додатку чи документообігу, необхідного підряднику. Будь-яка інша частина корпоративної мережі залишається для стороннього користувача повністю невидимою та недосяжною.

4.4 Співпраця через межі підприємств (Collaboration Across Enterprise Boundaries)

Спільні проекти між різними державними агентствами (Inter-agency projects), спільні науково-дослідні ініціативи університетів або партнерські програми приватно-державного співробітництва вимагають обміну даними та ресурсами без злиття внутрішніх мереж і без створення спільних довірчих відносин на рівні лісів Active Directory.

Підхід ZTA (Рисунок 11): Застосовується федеративна модель довіри. Підприємство А визнає автентифікацію суб’єкта, здійснену постачальником ідентичності (IdP) Підприємства Б за відкритими протоколами SAML або OIDC. Проте Рушій політик Підприємства А самостійно й незалежно вирішує, чи відповідає запит внутрішнім правилам безпеки організації-власника ресурсу, і керує відкриттям сесії через власний шлюз PEP.

4.5 Публічні сервіси та сервіси для клієнтів (Public- or Customer-Facing Services)

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

Підхід ZTA: Доступ структурується за різними рівнями довіри. Загальнодоступні інформаційні сервіси відкриваються через зовнішні мережі доставки контенту (CDN) та шлюзи захисту від DDoS та ботнетів (WAF). Для доступу до персональних кабінетів використовується сильна автентифікація FIDO2/Passkeys. Внутрішні бази даних і бекенд-сервери захищені внутрішніми PEP, виключаючи прямий зв’язок між клієнтом із відкритого Інтернету та конфіденційними сховищами даних.

5.1 Підрив процесу ухвалення рішень ZTA (Subversion of ZTA Decision Process)

У ZTA рушій політик (Policy Engine, PE) та адміністратор політик (Policy Administrator, PA) є ключовими компонентами всього підприємства. Жодна взаємодія між ресурсами підприємства не відбувається, доки вона не буде схвалена і, за необхідності, налаштована PE та PA. Це означає, що ці компоненти повинні бути бездоганно налаштовані та суворо підтримуватися.

Будь-який системний адміністратор підприємства з правами конфігураційного доступу до правил PE може здійснити несанкціоновані зміни або припуститися критичних помилок, здатних паралізувати операційну діяльність організації. Так само скомпрометований PA може дозволити доступ до ресурсів, які за нормальних умов ніколи б не отримали схвалення (наприклад, надати дозвіл зламаному персональному пристрою BYOD).

Зниження асоційованих ризиків вимагає належного конфігурування та безперервного моніторингу компонентів PE і PA; будь-які зміни в конфігурації повинні фіксуватися в журналах аудиту та підлягати обов’язковому перехресному контролю з боку кількох адміністраторів (multi-party approval).

5.2 Відмова в обслуговуванні або порушення зв’язку мережі (Denial-of-Service or Network Disruption)

У ZTA адміністратор політик (PA) є критично важливою ланкою для доступу до ресурсів. Корпоративні ресурси не можуть зв’язуватися між собою без явного дозволу PA та відповідних дій з налаштування маршрутів. Якщо зловмисник порушить роботу або заблокує доступ до точок забезпечення політик (PEP) чи комплексу PE/PA (через атаку типу DoS або перехоплення мережевих маршрутів BGP), це матиме руйнівний вплив на всі бізнес-процеси підприємства.

Підприємства можуть пом’якшити цю загрозу, розміщуючи компоненти забезпечення дотримання політик у надійно захищених хмарних середовищах або географічно дублюючи та реплікуючи їх у кількох локаціях відповідно до настанов NIST щодо кіберстійкості [NIST SP 800-160v2]. Це знижує ризик, проте не усуває його повністю.

Ботнети (такі як Mirai) здатні генерувати масовані розподілені атаки DoS проти ключових постачальників послуг Інтернету, порушуючи доступ мільйонів користувачів. Також можливо, що зловмисник перехопить і заблокує трафік до PEP або PA лише від частини облікових записів або конкретного віддаленого офісу чи окремого працівника. У таких випадках страждає лише частина користувачів підприємства, що аналогічно проблемам традиційних VPN віддаленого доступу.

Крім того, хмарний провайдер може випадково вимкнути хмарний PE або PA через технічний збій. Хмарні сервіси (як IaaS, так і SaaS) неодноразово зазнавали масових аварій у минулому. Операційна помилка провайдера може заблокувати функціонування всього підприємства, якщо рушій політик чи адміністратор стануть недосяжними з мережі. Існує також ризик, що ресурси підприємства стануть недосяжними для PA — у цьому разі, навіть якщо суб’єкт отримав схвалення, PA не зможе надіслати команду шлюзу на відкриття шляху зв’язку.

5.3 Викрадені облікові дані та внутрішні загрози (Stolen Credentials/Insider Threat)

Належним чином розгорнута ZTA значно звужує поле атаки та запобігає багатьом видам несанкціонованого доступу. Використання багатофакторної автентифікації (MFA) для доступу знижує ймовірність того, що атака за допомогою скомпрометованих облікових записів буде успішною. Проте зловмисник або скомпрометований інсайдер, озброєний дійсними обліковими даними, все ще може отримати авторизований доступ до ресурсів, для яких даний акаунт має дозвіл.

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

5.4 Видимість у мережі (Visibility on the Network)

Як зазначено у Постулаті 2, увесь трафік мережі шифрується. Це забезпечує конфіденційність та цілісність, проте одночасно ускладнює пасивний моніторинг безпеки. Мережеві аналізатори та системи виявлення вторгнень (NIDS), які традиційно аналізували дзеркальний порт комутатора (SPAN port), більше не можуть бачити незашифровані пакети для виявлення сигнатур атак.

Для вирішення цієї проблеми підприємство ZTA повинно зосередитися на аналізі метаданих потоків зв’язку (IP-адреси, порти, час, розміри пакетів, протокольні послідовності), а також переносити інспекцію на кінцеві точки (через EDR) або проводити санкціоновану термінацію TLS безпосередньо на шлюзах PEP, де розшифрований потік аналізується перед передачею до прикладного сервісу.

5.5 Зберігання системної та мережевої інформації (Storage of System and Network Information)

Для динамічного функціонування ZTA агрегує та накопичує великі обсяги інформації про внутрішній устрій підприємства: карти активів, списки систем CDM, журнали трафіку, бази даних ролей та профілі ризику.

Ці сховища системної інформації самі по собі стають мішенями найвищої привабливості для супротивника. Отримавши доступ до цих сховищ або баз журналів SIEM, зловмисник отримує детальну розвідувальну карту слабких місць інфраструктури, конфігурацій серверів та діючих правил доступу, що дозволяє спланувати атаку в обхід діючих алгоритмів довіри. Тому сервери баз даних ZTA, сховища SIEM і репозиторії політик повинні мати найвищий рівень захисту та ізоляції.

5.6 Залежність від пропрієтарних форматів даних або рішень (Reliance on Proprietary Data Formats)

ZTA покладається на динамічну взаємодію між багатьма різнорідними компонентами: каталогами користувачів, системами CDM, датчиками EDR, потоками кіберрозвідки та шлюзами PEP. На сьогодні більшість рішень використовують пропрієтарні API та специфічні формати обміну даними, що створює серйозний ризик залежності від одного постачальника (vendor lock-in).

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

5.7 Використання нелюдських сутностей (NPE) в адмініструванні ZTA

Штучний інтелект, автоматизовані конфігураційні скрипти, CI/CD-пайплайни та програмні агенти (Non-Person Entities, NPE) все частіше виконують адміністративні завдання в мережах ZTA. Ці агенти самостійно надсилають команди до PA, переконфігуровують віртуальні мережі та керують обліковими записами.

Оскільки NPE не мають фізичного оператора, вони не можуть підтверджувати свої повноваження за допомогою традиційної інтерактивної біометричної чи апаратної MFA. Якщо зловмисник скомпрометує автоматизованого агента або перехопить його довготривалі статичні облікові ключі (API-токени), він зможе маніпулювати всією інфраструктурою ZTA. Захист NPE вимагає впровадження короткоживучих сертифікатів (short-lived tokens), безперервної перевірки поведінки процесів та жорсткого обмеження діапазону дозволених операцій.

6.1 ZTA та Рамкова програма управління ризиками NIST (NIST Risk Management Framework)

Розгортання ZTA передбачає розробку політик доступу навколо прийнятного рівня ризику для визначеної місії або бізнес-процесу (див. Розділ 7.3.3). Теоретично можливо взагалі заблокувати будь-який мережевий доступ до ресурсу і дозволити роботу лише через фізично підключений локальний термінал, проте в переважній більшості випадків це є непропорційно обмежувальним заходом, який повністю паралізує виконання робочих завдань. Для того, щоб федеральне агентство могло виконувати свою місію, завжди існує певний прийнятний рівень ризику. Ризики, пов’язані з виконанням даної місії, повинні бути чітко ідентифіковані, оцінені та або прийняті керівництвом, або мінімізовані. Для допомоги у цьому процесі було розроблено Рамкову програму управління ризиками NIST (Risk Management Framework, RMF) [NIST SP 800-37 Rev. 2].

Планування та впровадження ZTA може змінити межі авторизації систем (authorization boundaries), визначені підприємством. Це зумовлено додаванням нових компонентів (рушія політик PE, адміністратора політик PA та точок забезпечення PEP) та суттєвим зменшенням залежності від мережевих периметрових засобів оборони. Водночас загальний 7-етапний життєвий цикл управління ризиками, описаний у RMF, залишається незмінним у середовищі ZTA.

6.2 Zero Trust та Структура конфіденційності NIST (NIST Privacy Framework)

Захист конфіденційності користувачів та приватної інформації (зокрема персональних ідентифікаційних даних — Personally Identifiable Information, PII) є першочерговим пріоритетом для організацій. Захист конфіденційності та даних закріплений у нормативних програмах, таких як FISMA та Закон про мобільність і підзвітність медичного страхування (HIPAA). У відповідь на це NIST розробив спеціальну Структуру конфіденційності для організацій [NIST Privacy Framework]. Цей документ надає інструментарій для опису ризиків приватності та стратегій їх зменшення, а також процес ідентифікації, вимірювання та пом’якшення ризиків для конфіденційної інформації, що зберігається й обробляється організацією. Сюди входить персональна інформація співробітників, яка використовується підприємством для підтримки операцій ZTA, а також будь-які біометричні атрибути, задіяні під час оцінки запитів на доступ.

Однією з ключових вимог ZT є те, що підприємство повинно інспектувати та вести журнали всього трафіку (або принаймні реєструвати та інспектувати метадані, коли йдеться про трафік, який не може бути розшифрований системами моніторингу) у своєму середовищі. Частина цього трафіку неминуче міститиме приватну інформацію користувачів або нестиме ризики для приватності. Організаціям необхідно виявити будь-які потенційні ризики, пов’язані з перехопленням, скануванням та веденням журналів мережевого трафіку [NISTIR 8062]. Це може включати такі заходи, як інформування співробітників, отримання їхньої інформованої згоди (через сторінку авторизації, банери входу тощо) та регулярне навчання користувачів підприємства. Структура конфіденційності NIST допомагає створити формальний процес для управління цими ризиками.

6.3 ZTA та Федеральна архітектура ідентифікації, облікових даних та доступу (FICAM)

Федеральна програма FICAM [FICAM] спрямована на забезпечення спільних практик безпеки для управління цифровою ідентичністю та доступом у всіх відомствах уряду США. Меморандум Адміністративно-бюджетного управління OMB M-19-17 закріплює, що цифрова ідентичність повинна розглядатися як новий основний периметр безпеки.

Концепція ZTA повністю відповідає FICAM, вимагаючи використання стійких, сумісних і перевірених облікових даних (смарт-карток PIV/CAC або сучасних апаратних ключів FIDO2) для автентифікації всіх суб’єктів підприємства. Більше того, ZTA розширює вимоги FICAM, переносячи акцент з разової перевірки особи під час входу в мережу на динамічну посесійну оцінку прав і атрибутів суб’єкта перед кожним зверненням до конкретних ресурсів даних.

6.4 ZTA та програма Довірених інтернет-з’єднань версії 3.0 (Trusted Internet Connections, TIC 3.0)

Програма Довірених інтернет-з’єднань (TIC) була започаткована для оптимізації та стандартизації безпеки зовнішніх мережевих підключень федеральних відомств США. Попередня версія (TIC 2.0) вимагала жорсткого фізичного зведення всього інтернет-трафіку через обмежену кількість важких централізованих шлюзів (choke points), що призводило до затримок зв’язку, перевантаження каналів та неефективності при роботі з хмарними сервісами.

Модернізована настанова TIC 3.0 [TIC 3.0] визнає необхідність децентралізації і прямо узгоджується з постулатами Zero Trust. Замість обов’язкового повернення трафіку до центрального офісу (backhauling), TIC 3.0 визначає гнучкі «захисні можливості» (Security Capabilities), які можуть бути реалізовані у вигляді програмних накладень (overlays), розподілених шлюзів PEP або безпосередньо у хмарі. Це дозволяє підтримувати такі сценарії ZTA, як пряме підключення віддалених філій до Інтернету (Branch Office Use Case) та безпечна робота дистанційних користувачів (Remote User Use Case) без порушення федеральних вимог безпеки.

6.5 ZTA та Національна система кіберзахисту EINSTEIN (NCPS)

Національна система кіберзахисту (NCPS, широко відома як програма EINSTEIN), керована Агентством з кібербезпеки та захисту інфраструктури (CISA), здійснює моніторинг зовнішнього інтернет-трафіку федеральних агентств для виявлення кібератак національного рівня, сигнатурного аналізу шкідливого трафіку та блокування відомих загроз.

В умовах впровадження ZTA, де трафік шифрується наскрізними каналами від пристрою користувача до хмарного додатку, традиційні сенсори EINSTEIN на фізичному периметрі втрачають можливість безпосереднього аналізу вмісту пакетів. Адаптація полягає в перенесенні сенсорних механізмів NCPS на рівень хмарних шлюзів PEP та систем аналізу метаданих журналів безпеки (SIEM), що забезпечує збереження високого рівня національної ситуаційної обізнаності без порушення криптографічних вимог нульової довіри.

6.6 ZTA та Програма безперервної діагностики та пом’якшення загроз DHS (CDM)

Програма Continuous Diagnostics and Mitigation (CDM) Міністерства внутрішньої безпеки США (DHS) забезпечує федеральні відомства комерційними інструментами для виявлення вразливостей на кінцевих пристроях, інвентаризації обладнання та програмного забезпечення в режимі реального часу.

У контексті архітектури Zero Trust система CDM є одним із головних постачальників інформації про стан активів для Рушія політик (Policy Engine). Інформація системи CDM щодо наявності встановлених оновлень ОС, конфігураційних відхилень або виявленого шкідливого коду передається до PE у вигляді числових атрибутів і метрик впевненості. Якщо стан пристрою погіршується, PE негайно блокує або обмежує доступ до ресурсів до моменту усунення дефекту засобами CDM.

6.7 ZTA, стратегія Cloud Smart та Федеральна стратегія даних США

Федеральна стратегія Cloud Smart заохочує агентства переносити корпоративні додатки та дані до комерційних хмарних середовищ для підвищення ефективності, надійності та зниження витрат. Паралельно Федеральна стратегія даних (Federal Data Strategy) вимагає розглядати державні дані як стратегічний національний актив, що підлягає надійному захисту.

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

7. Міграція до архітектури нульової довіри (Migrating to a ZTA)

▪ 7.1 Чиста архітектура нульової довіри (Pure Zero Trust Architecture)

У сценарії створення нової інфраструктури «з чистого аркуша» (greenfield approach) організація має унікальну можливість від самого початку побудувати мережу за канонічними принципами Zero Trust. У такій системі не створюється жодної зони неявної довіри: всі робочі місця, хмарні сервери та бази даних від початку ізольовані точками PEP, автентифікація здійснюється через єдиного постачальника ідентичності (IdP), а доступ контролюється Рушієм політик (PE).

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

▪ 7.2 Гібридна архітектура ZTA та периметрової оборони (Hybrid ZTA)

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

Міграція робочого процесу до ZTA вимагає часткового реінжинірингу потоків даних і налаштування нових точок PEP, при цьому решта корпоративної мережі може продовжувати функціонувати в класичному режимі периметрового захисту.

▪ 7.3 Етапи переходу від периметрової моделі до ZTA

Успішна міграція вимагає детальної інвентаризації та глибокого розуміння активів, користувачів та бізнес-процесів організації. NIST SP 800-207 визначає циклічний процес розгортання:

Рис. 12 (Figure 12): Цикл розгортання ZTA (ZTA Deployment Cycle). Постійний цикл: Інвентаризація суб’єктів та активів → Визначення процесів → Формулювання політик → Вибір рішень → Початкове розгортання в режимі моніторингу → Розширення ZTA.

Офіційні нормативні джерела та бібліографія стандарту (References, Стор. 51–53)

Додаток A: Акроніми та скорочення (Appendix A – Acronyms)

Повний перелік офіційних скорочень, стандартизованих та використаних у публікації NIST SP 800-207:

Додаток B: Виявлені прогалини в сучасному стані розвитку ZTA (Identified Gaps in the Current State-of-the-Art in ZTA)

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

Нижче наведено зведення виявлених прогалин в екосистемі ZTA та напрямів, які потребують подальших досліджень.

Нормативні посилання та офіційна бібліографія (References)

• [ACT-IAC] American Council for Technology-Industry Advisory Council (2019) Zero Trust Cybersecurity Current Trends. Available at https://www.actiac.org/act-iac-white-paper-zero-trust-cybersecurity-current-trends
• [BCORE] Defense Information Systems Agency (2007) Department of Defense (DoD) Global Information Grid Architectural Vision.
• [FIPS 199] National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 199. https://doi.org/10.6028/NIST.FIPS.199
• [JERICHO] The Open Group (2007) Jericho Forum Commandments, Version 1.1. Available at https://www.opengroup.org/jericho/commandments_v1.1.pdf
• [NIST SP 800-37] Joint Task Force Transformation Initiative (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-37, Rev. 2. https://doi.org/10.6028/NIST.SP.800-37r2
• [NIST SP 800-53] Joint Task Force Transformation Initiative (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5. https://doi.org/10.6028/NIST.SP.800-53r5
• [NIST SP 800-63] Grassi PA, Garcia ME, Fenton JL (2017) Digital Identity Guidelines. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63-3. https://doi.org/10.6028/NIST.SP.800-63-3
• [NIST SP 800-63B] Grassi PA, Fenton JL, Newton EM, Perlner RA, Regenscheid AR, Burr WE, Richer JP, Lefkovitz NB, Danker JM, Choong YY, Greene KK, Theofanos MF (2017) Digital Identity Guidelines: Authentication and Lifecycle Management. NIST Special Publication (SP) 800-63B. https://doi.org/10.6028/NIST.SP.800-63b
• [NIST SP 800-160v1] Ross RS, McEvilley M, Oren JC (2016) Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems. NIST Special Publication (SP) 800-160, Vol. 1. https://doi.org/10.6028/NIST.SP.800-160v1
• [NIST SP 800-162] Hu VC, Ferraiolo D, Kuhn R, Schnitzer A, Sandlin K, Miller R, Scarfone K (2014) Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST Special Publication (SP) 800-162. https://doi.org/10.6028/NIST.SP.800-162
• [OMB M-19-17] Office of Management and Budget (2019) Enabling Mission Delivery through Improved Identity, Credential, and Access Management. (The White House, Washington, DC), OMB Memorandum M-19-17. Available at https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf
• [TIC 3.0] Cybersecurity and Infrastructure Security Agency (2020) Trusted Internet Connections 3.0 Core Guidance Documents. Available at https://www.cisa.gov/publication/tic-30-core-guidance-documents