Доступ з нульовою довірою (ZTNA) для оборони: проксі та рушій політик

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

Чому застарілий VPN не працює для оборонної нульової довіри

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

Неявна довіра після автентифікації. Автентифікація VPN — це брама, а не безперервна оцінка. Щойно браму пройдено, довіру не переоцінюють, поки сесія не завершиться або не станеться таймаут. Якщо обліковий запис користувача скомпрометовано посеред сесії, якщо пристрій інфіковано зловмисним програмним забезпеченням під час сесії або якщо користувач лишає пристрій без нагляду з активним тунелем, VPN продовжує надавати доступ рівня анклаву, поки адміністратор вручну не завершить сесію або тунель не завершиться за таймаутом. В оборонному середовищі, де тривалість сесій часто сягає цілого робочого дня, це означає розширене вікно невиявленого ризику.

Радіус ураження плоскої мережі. VPN розміщує користувача в мережевому сегменті. Плоска східно-західна зв'язність у межах цього сегмента означає, що скомпрометована сесія VPN може досягти не лише застосунку, до якого користувач мав намір отримати доступ, а кожного сервісу, бази даних та інтерфейсу керування в підмережі. Зловмисник, що краде облікові дані VPN, отримує опорну точку з тим самим мережевим охопленням, що й законний користувач, — або ширшим, оскільки політика VPN рідко обмежує трафік усередині підмережі. Це проблема радіуса ураження: компрометація однієї облікової пари відкриває весь плоский мережевий сегмент.

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

Архітектура ZTNA: моделі проксі та агента кінцевої точки

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

ZTNA на основі зворотного проксі (безклієнтний)

У моделі зворотного проксі на кінцевій точці не встановлюється жодне програмне забезпечення. Сервіс ZTNA публікує проксі-кінцеву точку — зазвичай URL у домені організації, — що стоїть перед кожним захищеним застосунком. Користувач переходить на URL проксі в браузері, автентифікується через брокер ідентичності (пред'являючи облікові дані CAC/PIV і проходячи MFA) та отримує короткоживучий токен сесії. Проксі валідує токен при кожному запиті та пересилає автентифіковані, авторизовані запити до бекенда застосунку. Пристрій користувача ніколи не розміщується в мережі застосунків; мережевий шлях до бекенда має лише проксі.

Головне обмеження безклієнтної моделі — покриття протоколів: вона природно працює для застосунків HTTPS і може опрацьовувати RDP і SSH через браузерні клієнти (шлюзи HTML5 RDP/SSH), але не підтримує довільні протоколи TCP/UDP або застосунки з товстим клієнтом, що спілкуються пропрієтарними протоколами. Видимість довіри до пристроїв також обмеженіша без агента: проксі може інспектувати клієнтські сертифікати TLS і рядки user-agent браузера, але не може перевірити стан EDR або атестацію TPM без допомоги локального агента.

ZTNA на основі агента кінцевої точки

Агентна модель встановлює легковагий демон на керованій кінцевій точці. Агент працює безперервно, перехоплює трафік, призначений для адрес захищених застосунків (через локальний віртуальний мережевий адаптер або пакетний фільтр рівня ОС), виконує перевірки довіри до пристрою локально та встановлює зашифрований тунель до сервісного краю ZTNA. Захищений трафік застосунків проходить через цей тунель, а не через відкритий інтернет або VPN. Бекенд застосунку отримує з'єднання від проксі ZTNA, а не безпосередньо від кінцевої точки — мережева адреса бекенда ніколи не відкривається кінцевій точці.

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

Хмарний та локальний ZTNA

Хмарний ZTNA запускає площину керування та проксі сесій у мультитенантному хмарному сервісі. Ця модель підходить нетаємним програмам, де застосунки розміщені в комерційних або державних хмарних середовищах. Для таємних програм — IL4, IL5 та повітряно ізольованої IL6 — площину керування ZTNA слід розгорнути в межах акредитованої межі. Локальний ZTNA розміщує рушій політик, брокер ідентичності та проксі сесій усередині таємного анклаву. Трафік застосунків ніколи не виходить за таємну межу. Зовнішні залежності площини керування — валідація сертифікатів, запити стану EDR, пошуки в провайдері ідентифікації — мають усі розв'язуватися в акредитованій мережі без доступу до інтернету.

Сигнали ідентичності: хто під'єднується

Рішення про доступ ZTNA обумовлені ідентичністю користувача, що під'єднується. Для оборонного персоналу перевірка ідентичності якориться до фізичного ідентифікатора, виданого кадровою системою організації, — смарт-картки CAC або PIV — і збагачується атрибутами ролей і груп із каталогу.

Перевірка сертифікатів CAC/PIV

Картка CAC (Common Access Card) і PIV (Personal Identity Verification) несуть сертифікат ідентичності X.509, виданий затвердженим PKI організації. Перевірка сертифіката в ZTNA передбачає: пред'явлення сертифіката брокеру ідентичності ZTNA через клієнтську автентифікацію TLS; валідацію ланцюга сертифіката проти затвердженого якоря довіри (кореневі та проміжні CA у сховищі довіри організації); перевірку сертифіката за списком відкликаних сертифікатів (CRL) або респондером OCSP, щоб підтвердити, що він не відкликаний; і витяг розрізнювального імені суб'єкта або UPN із сертифіката для ідентифікації принципала користувача.

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

Багатофакторна автентифікація для доступу ZTNA

Введення PIN-коду CAC задовольняє вимогу MFA «щось, що ви маєте, плюс щось, що ви знаєте» для більшості програм. Однак застосунки, визначені як чутливі, можуть вимагати додаткового фактора понад CAC — код TOTP, push-сповіщення до зареєстрованого застосунку-автентифікатора або апаратний ключ безпеки. Рушій політик ZTNA може примусово застосовувати вимоги рівня MFA для кожного застосунку: стандартний CAC-PIN для загальних застосунків, CAC-PIN плюс TOTP для чутливих командних застосунків і обмежений у часі робочий процес позасмугового підтвердження для привілейованого адміністративного доступу. Таке розшарування рівнів MFA на рівні застосунків недосяжне з плоскою політикою VPN.

Інтеграція з провайдером ідентифікації: LDAP і Active Directory

Автентифікація сертифікатом ідентифікує принципала користувача, але не несе поточного членства в ролях чи групах — ним керують у каталозі, і воно може змінюватися незалежно від видачі сертифіката. Рушій політик ZTNA опитує провайдера ідентифікації — LDAP або Active Directory — у момент кожного запиту доступу, щоб розв'язати поточні членства користувача в групах і призначення ролей. Розв'язані атрибути стають входами політики: користувач має бути членом групи Active Directory «analysts-secret», щоб отримати доступ до таємного аналітичного застосунку, незалежно від того, що каже його сертифікат. Якщо користувача вилучено з групи в Active Directory, його наступний запит доступу до аналітичного застосунку відхиляється рушієм політик ZTNA без потреби відкликання сертифіката чи зміни політики VPN. Такий контроль доступу на основі атрибутів, підкріплений запитами до каталогу в реальному часі, — фундаментальна спроможність управління ідентичністю, яке застосовують оборонні організації для ущільнення життєвого циклу контролю доступу.

Сигнали довіри до пристроїв: який пристрій під'єднується

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

Сертифікат пристрою

Перший сигнал довіри до пристрою — машинний сертифікат: сертифікат, виданий PKI пристроїв організації кінцевій точці під час реєстрації. Машинний сертифікат доводить, що пристрій зареєструвала авторизована система MDM або керування пристроями і що на той момент він був керованим активом. Агент ZTNA пред'являє сертифікат пристрою разом із сертифікатом користувача під час встановлення сесії. Рушій політик валідує ланцюг сертифіката пристрою проти якоря довіри PKI пристроїв, перевіряє статус відкликання та підтверджує, що ідентифікатор пристрою в сертифікаті відповідає ідентичності пристрою, зафіксованій в інвентарі MDM.

Стан EDR

Агент виявлення та реагування на кінцевих точках (EDR), що працює на пристрої, підтримує оцінку статусу загроз пристрою в реальному часі. Агент ZTNA опитує локального агента EDR або API платформи керування EDR щодо атестації стану: чи працює агент EDR, чи актуальна його база розвідувальних даних про загрози та чи є активні загрози в карантині чи усуненні? Пристрій із застарілою базою сигнатур EDR фактично сліпий до нещодавніх сімейств загроз — політика ZTNA має розглядати такий пристрій як неконформний і або відмовляти в доступі, або обмежувати його рівнем обмеженого доступу до оновлення EDR. Подія карантину активної загрози під час сесії спричиняє подію безперервної оцінки, яка може призвести до негайного призупинення сесії.

Перевірка відповідності патчам

Рівень патчів операційної системи та застосунків опитується з платформи MDM або з локального інвентарю встановлених патчів агента ZTNA. Рушій політик ZTNA порівнює стан патчів пристрою з визначеним мінімумом: наприклад, усі критичні CVE і CVE високої серйозності, опубліковані за останні 30 днів, мають бути встановлені, перш ніж дозволити доступ до таємних застосунків. Пристрої, що відстають у патчингу, переспрямовуються на повідомлення про усунення, а не на запитаний застосунок. Перевірка відповідності патчам також охоплює сторонні застосунки в керованому програмному інвентарі пристрою — непатчований веб-браузер або читач PDF на керованому пристрої є вектором експлуатації, навіть якщо ОС повністю патчована.

Атестація обладнання через TPM 2.0

Для оборонних керованих кінцевих точок, обладнаних модулем TPM 2.0, агент ZTNA може запросити цитату атестації TPM — криптографічно підписане вимірювання ланцюга завантаження пристрою, створене TPM і перевірюване проти еталонного маніфесту відомого справного стану. Атестація доводить, що пристрій завантажився з авторизованого образу мікропрограми й ОС і що ланцюг завантаження не підроблено з часу останньої атестації. Цей засіб контролю актуальний для виявлення зловмисного програмного забезпечення рівня завантаження — руткітів і буткітів, що персистують нижче ОС і не були б виявлені агентом EDR рівня ОС. Атестація TPM вимагає, щоб площина керування ZTNA утримувала еталонний маніфест для кожної моделі пристрою в керованому парку; маніфест наповнюється під час реєстрації пристрою та оновлюється, коли розгортаються авторизовані зміни мікропрограми.

Рушій безперервної оцінки політик

Рушій політик — ядро ухвалення рішень архітектури ZTNA. Він отримує запити доступу — від проксі сесій, коли користувач ініціює з'єднання, і від циклу безперервної оцінки протягом активної сесії — і повертає рішення про доступ: дозволити, відмовити або підсилити (вимагати додаткової автентифікації перед дозволом).

Політика-як-код з OPA і Rego

Оборонним розгортанням ZTNA вигідно висловлювати політику доступу як код, а не як правила, налаштовані через GUI. Open Policy Agent (OPA) з мовою політик Rego — домінуючий фреймворк для цього патерну. Політика Rego для ZTNA декларативно кодує всі умови доступу: потрібні групи користувачів, мінімальний рівень відповідності пристрою, дозволені години доступу, потрібний рівень MFA і поріг балу ризику. Політики версіонуються у вихідному репозиторії, рецензуються через той самий процес контролю змін, що й код застосунків, і розгортаються в рушій OPA через конвеєр CI/CD. Кожна зміна політики має автора, запис рецензії, мітку часу розгортання і може бути відкочена до попередньої версії одним відкатом конвеєра. Ця аудитованість — суттєва перевага над правилами міжмережевих екранів на рівні застосунків, що накопичуються без контролю версій.

Рішення про доступ з урахуванням контексту

Рішення політик ZTNA можуть включати контекстні сигнали понад ідентичність і довіру до пристроїв. Політика часу доступу обмежує доступ до чутливих застосунків визначеними вікнами робочих годин, зменшуючи вікно викриття для зловживання обліковими даними поза нормальними робочими годинами. Політику геолокації або мережевого джерела — звідки під'єднується користувач — може оцінювати рушій політик: таємний застосунок може дозволяти доступ лише з мережевих точок виходу під керуванням організації або зі специфічних затверджених локацій віддаленого доступу. Інтеграція балу ризику дозволяє рушію політик споживати числовий сигнал ризику, що його породжує платформа аналітики поведінки користувачів і сутностей (UEBA): якщо патерн доступу користувача за останні 24 години породив високий бал аномального ризику, рушій політик підвищує поріг доступу, вимагаючи підсиленої MFA перед дозволом доступу до чутливих застосунків.

Переоцінка ризику сесії

Традиційний контроль доступу ухвалює рішення на початку сесії й не повертається до нього. Безперервна оцінка ZTNA переоцінює рішення про доступ протягом сесії з налаштовуваним інтервалом опитування. Цикл оцінювання опитує провайдера ідентифікації про зміни статусу облікового запису (блокування облікового запису або відкликання групи після початку сесії), платформу EDR — про нові події загроз на пристрої, сервіс відповідності пристроїв — про зміни статусу патчів, а сервіс оцінювання ризику — про зміни балу аномальності. Коли зміна перетинає поріг політики, рушій відповідає пропорційно: помірне зростання ризику спричиняє виклик підсиленої MFA без завершення сесії; критична подія — блокування облікового запису, активна загроза EDR, відкликання сертифіката — спричиняє негайне завершення сесії. Модель безперервної оцінки означає, що зловмисник, який компрометує пристрій посеред сесії, стикається з вікном виявлення, обмеженим інтервалом опитування, а не повним життям сесії. Ті самі принципи, що керують програмами керування привілейованим доступом в обороні, — доступ just-in-time, запис сесій і переоцінка ризику в реальному часі — застосовуються безпосередньо до проєктування безперервної оцінки ZTNA для високопривілейованих сесій.

ZTNA для таємних мереж: розгортання IL4/IL5

Комерційні хмарні сервіси ZTNA працюють у мультитенантній спільній інфраструктурі, не авторизованій для таємних робочих навантажень. Оборонні програми, що працюють на рівнях впливу IL4 (контрольована нетаємна інформація) та IL5 (системи національної безпеки), потребують моделі розгортання ZTNA, яка тримає операції площини керування та трафік застосунків у межах акредитованої межі.

Локальний ZTNA для повітряно ізольованих таємних середовищ

Локальне розгортання ZTNA для таємної мережі відтворює функціональні компоненти хмарного сервісу ZTNA усередині таємного анклаву. Рушій політик, брокер ідентичності, проксі сесій і сервіс довіри до пристроїв розгортаються як локальні обчислювальні робочі навантаження — або на виділеному обладнанні, або в таємному кластері Kubernetes. Усі залежності площини керування розв'язуються в межах анклаву: провайдером ідентифікації є таємний екземпляр Active Directory, консоль керування EDR розгорнута локально, центр сертифікації та сервіс CRL працюють у повітряній ізоляції, і жоден виклик оцінювання політики не залишає меж таємної мережі.

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

Проєктування крос-доменного проксі ZTNA

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

Міграція зі застарілого VPN на ZTNA

Міграція з VPN на ZTNA в оборонній програмі — операційний перехід, який має зберегти безперервність доступу для критичних для місії застосунків, поступово ущільнюючи контроль доступу. Поетапна стратегія міграції, яка працює з VPN і ZTNA паралельно протягом перехідного періоду, — стандартний підхід.

Поетапна стратегія міграції

Міграція відбувається у три етапи. На першому етапі інфраструктуру ZTNA розгортають і валідують для інтеграції ідентичності та довіри до пристроїв, але жодних застосунків не підключають, і користувачі продовжують отримувати доступ до всіх застосунків через VPN. Пілотна група користувачів — типово команда ІТ і безпеки — тестує доступ ZTNA до застосунку низької критичності, щоб валідувати наскрізний потік, перш ніж залучати користувачів місії. На другому етапі застосунки підключають до ZTNA в порядку пріоритету. Протягом цього етапу VPN лишається доступним як запасний варіант для застосунків, ще не підключених. Користувачів навчають користуватися порталом доступу ZTNA і агентом, перш ніж їхні основні застосунки переїдуть на ZTNA. На третьому етапі, щойно всі застосунки в межах охоплення підключені та пілотна популяція валідувала доступ, VPN-доступ відкликають для мігрованої популяції користувачів. Шлюз VPN лишається доступним лише для застосунків, виключених з охоплення ZTNA (якщо такі є), протягом фінального етапу, а потім виводиться з експлуатації, коли решта застосунків завершить підключення.

Послідовність підключення застосунків

Застосунки підключають до ZTNA в послідовності, спроєктованій мінімізувати ризик і навчитися на ранніх підключеннях, перш ніж братися за складні випадки. Почніть із внутрішніх веб-порталів і інформаційних панелей — застосунків HTTPS із браузерними фронтендами, які природно працюють із ZTNA зі зворотним проксі та мають широкі популяції користувачів, здатних швидко дати відгук. Далі переходьте до застосунків продуктивності: веб-інтерфейси пошти, портали керування документами, внутрішні вікі. Потім беріться за категорії застосунків, що потребують агентної моделі: Windows-сервери через RDP, Linux-системи через SSH, застосунки C2 або застосунки місії з товстим клієнтом. Наостанок лишіть найскладніші інтеграції: застосунки з нестандартними механізмами автентифікації, системи реального часу високої критичності та будь-який застосунок, який зараз покладається на контроль доступу за IP через VPN, а не на автентифікацію на рівні застосунку.

Навчання користувачів патернам доступу ZTNA

Досвід користувача ZTNA суттєво відрізняється від VPN. Користувачі, звичні до VPN, під'єднуються раз на початку дня і прозоро користуються всіма застосунками решту дня. З ZTNA користувач отримує доступ до застосунків через портал ZTNA або через з'єднання, перехоплені агентом, і може стикатися з викликами підсиленої MFA протягом дня, якщо безперервна оцінка виявить зміну ризику. Навчання має охопити три поведінкові зміни. Перше, портал доступу: куди переходити, щоб знайти застосунки, і як автентифікуватися через CAC. Друге, агент: як агент ZTNA виглядає в системному треї, що означають його індикатори стану і як повідомляти про проблеми. Третє, підсилена автентифікація: як виглядає виклик MFA посеред сесії (щоб користувачі не сплутали легітимний запит підсилення з фішинговою спробою) і як його пройти. Програми, які інвестують у навчання користувачів перед підключенням першого користувача місії, бачать суттєво менші обсяги звернень до служби підтримки та швидше ухвалення, ніж програми, що розгортають ZTNA без навчальної програми.