Альтернативи VPN на основі нульової довіри для оборони: ZTNA, програмно-визначені периметри та проксі з урахуванням ідентичності

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

Чому застарілі VPN не справляються із сучасними оборонними архітектурами

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

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

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

Архітектура Zero Trust Network Access (ZTNA): принципи та компоненти

Zero Trust Network Access (ZTNA) — це архітектурний патерн, що безпосередньо замінює VPN для підключення користувач-застосунок. Засадничий принцип полягає в тому, що жодне підключення не є довіреним лише завдяки мережевому розташуванню. Кожен сеанс — чи то він походить від робочої станції в центрі обробки даних, чи від планшета на передовій операційній базі — має пред’явити перевірену ідентичність, атестацію стану пристрою та достатнє контекстне обґрунтування, перш ніж рушій політик авторизує доступ до конкретного застосунку. Тунель VPN замінюється посесійним підключенням, обмеженим застосунком, що опосередковується шлюзом ZTNA, який запроваджує рішення політики.

Архітектура ZTNA має чотири основні компоненти. Постачальник ідентичності (IdP) видає криптографічне твердження про ідентичність, яке користувач несе у сеанс. В оборонних розгортаннях це зазвичай система на основі PKI з використанням смарт-карт, апаратних токенів або ключів FIDO2 — а не лише парольних облікових даних. Рушій політик оцінює заяву про ідентичність, сигнали стану пристрою та атрибути запиту доступу за набором правил політики, щоб винести рішення «дозволити» чи «заборонити». Шлюз ZTNA запроваджує це рішення на мережевому рівні, проксіюючи лише авторизовані сеанси застосунків і відкидаючи весь інший трафік. Агент стану пристрою, що працює на вузлі, збирає та атестує сигнали здоров’я, потрібні рушію політик. Ці чотири компоненти взаємодіють у послідовності, що породжує обмежений у часі токен доступу, обмежений застосунком, для кожного авторизованого сеансу, а не постійний мережевий тунель.

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

Програмно-визначені периметри: авторизація одним пакетом і дизайн контролера

Програмно-визначені периметри (SDP) розширюють принцип ZTNA на рівень виявлення мережі: інфраструктура не просто контролюється за доступом, а робиться повністю невидимою для неавтентифікованих сторін. Шлюз SDP не відповідає на пакети TCP SYN, не з’являється у відповідях DNS, видимих недовіреним мережам, і відкидає весь трафік, якому не передував дійсний «стук» одно-пакетної авторизації (SPA). З погляду мережевого сканера чи автоматизованого фреймворку експлуатації інфраструктура просто не існує. Ця властивість «невидимої мережі» — визначальна характеристика, що відрізняє SDP від звичайної сегментації, запровадженої брандмауером, де інфраструктура видима, навіть якщо доступ заборонено.

Авторизація одним пакетом працює через точно визначене рукостискання. Клієнт SDP збирає токен ідентичності користувача, ідентифікатор запитуваного сервісу, мітку часу та nonce, підписує об’єднане навантаження приватним ключем з апаратного модуля безпеки пристрою або TPM і передає підписаний стук як єдину UDP-дейтаграму контролеру SDP. Контролер перевіряє криптографічний підпис стуку за зареєстрованим відкритим ключем користувача, перевіряє мітку часу для захисту від повторного відтворення (зазвичай вікно дійсності п’ять секунд), оцінює політику доступу для запитуваного сервісу і, якщо політика дозволяє, дає вказівку шлюзу SDP відкрити посесійне правило брандмауера для конкретного IP клієнта та порту призначення. Лише тоді клієнт намагається встановити TCP-підключення. Спостерігач, що моніторить мережу, бачить дейтаграму стуку — яка зашифрована й не несе відкритого ідентифікатора сервісу — але не може ані відтворити її, ані визначити, який сервіс було запитано, ані підключитися без дійсних облікових даних ідентичності.

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

Проксі з урахуванням ідентичності: запровадження політики доступу на рівні застосунку

Проксі з урахуванням ідентичності (IAP) доповнюють ZTNA та SDP, переносячи точку запровадження доступу з мережевого рівня на рівень застосунку. Там, де шлюз ZTNA контролює, чи може сеанс дістатися мережевої кінцевої точки застосунку, IAP завершує сеанс, інспектує протокол рівня застосунку, оцінює ідентичність і політику та перевидає підключення до бекенду лише якщо авторизація за кожним запитом успішна. IAP розуміє дієслова HTTP, шляхи URL, імена сервісів gRPC та підсистеми SSH — він може запроваджувати політику доступу на гранулярності окремих кінцевих точок API чи класів команд, а не лише на рівні застосунку в цілому.

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

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

Оцінка стану пристрою: перевірка здоров’я вузла перед наданням доступу

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

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

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

Розгортання ZTNA в ізольованих та засекречених середовищах: обмеження й адаптації

Реалізації ZTNA, спроєктовані для підключених до інтернету корпоративних середовищ, припускають, що постачальник ідентичності, рушій політик та канали загрозливих даних, на які покладається оцінка стану, досяжні через публічний інтернет або хмарний бекбон. Ізольовані (air-gapped) та засекречені мережі накладають інший набір обмежень: відсутність інтернет-зв’язку, суворі вимоги до діода даних чи рішення міждоменного обміну (CDS) на будь-якій зовнішній межі та процеси акредитації, що регулюють, які програмні компоненти можуть працювати в межах класифікаційного периметра. Ці обмеження вимагають архітектурних адаптацій, що зберігають модель доступу нульової довіри, водночас усуваючи кожну залежність від зовнішньої зв’язності.

Основна адаптація — розміщення всіх компонентів площини керування ZTNA у межах класифікаційного периметра. Постачальник ідентичності, центр сертифікації, що видає сертифікати реєстрації пристроїв, рушій політик, кластер контролерів SDP та розгортання IAP — усі вони експлуатуються як локальні робочі навантаження всередині анклаву. Оскільки немає зовнішньої зв’язності PKI, відкликання сертифікатів має оброблятися внутрішньо розміщеним OCSP-респондером або регулярно розповсюджуваним списком відкликання сертифікатів (CRL), що оновлюється через процес керування змінами анклаву. Канали загрозливих даних, що інформують політику стану — такі як нещодавно опубліковані CVE проти компонентів ОС — приймаються через контрольований процес передачі з визначеною періодичністю оновлення, а не в реальному часі.

Друге обмеження — процес реєстрації пристроїв. У корпоративних розгортаннях ZTNA пристрої реєструються користувачем, який відвідує розміщений на IdP портал реєстрації через інтернет. В ізольованих середовищах реєстрація має відбуватися через внутрішньосмуговий процес: пристрій під’єднується до виділеного мережевого сегмента реєстрації, встановлюється агент PKI і видається сертифікат реєстрації, після чого пристрій повторно під’єднується до операційної мережі. Цей процес має бути задокументований і запроваджений в акредитаційному пакеті, а сегмент мережі реєстрації має бути ізольований від операційного трафіку, щоб запобігти використанню видачі сертифікатів як вектора атаки. Патерни захисту оборонних робочих навантажень Kubernetes, що розміщують компоненти площини керування ZTNA, застосовують той самий принцип ізоляції та мінімального піддавання інтерфейсів керування кластера.

Шлях міграції: перехід із застарілого VPN на ZTNA без переривання обслуговування

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

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

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