Zero Trust для офісного VPN: замініть плоскі мережі доступом за ролями

Що ви замінюєте: плоский офісний VPN

Типова модель «офісного VPN» виглядає так:

• Користувач автентифікується на VPN-концентраторі (часто з MFA, іноді без).
• Клієнт отримує внутрішню IP-адресу (або маршрути до внутрішніх підмереж).
• Правила фаєрволу дозволяють широкий схід-західний доступ, бо «вони в VPN».
• Контроль доступу здебільшого неявний: якщо ви можете побудувати маршрут, ви можете спробувати увійти.

Це не «Zero Trust з VPN». Це «замок і рови з телепортом». Воно зазнає поразки передбачуваними способами:

• Боковий рух стає дешевим. Зловмисники люблять сусідство, бо воно перетворює «одні облікові дані» на доступ до «багатьох систем».
• Авторизація фрагментована. Команди додатків реалізують авторизацію по-різному; мережеві команди замінюють це досяжністю.
• Сегментація мережі гниє. Люди створюють винятки, потім винятки копіюють, і ви практично повертаєтесь до плоскості.
• Операційна складність ховається в маршрутизації. Дебати split tunnel vs full tunnel стають релігійними війнами, а не інженерними рішеннями.

Zero Trust — це не магічний порошок. Це інший контракт: жоден користувач або пристрій за замовчуванням не отримує «доступ до внутрішньої мережі». Вони отримують доступ до конкретних додатків, через конкретні порти, за конкретних умов, з аудитом, який переживе поганий день.

Практичне правило: якщо ваша політика виражається як «користувачі VPN можуть доступати 10.0.0.0/8», у вас нема політики. У вас є зневага.

Факти та історичний контекст, які справді важливі

Zero Trust часто рекламують так, ніби його вигадав минулого кварталу. Це не так. Ось конкретні пункти, що допоможуть вам мислити про це:

1. VPN стали масовими наприкінці 1990-х з стандартизацією IPsec (IKE, ESP). Мета була конфіденційність через ворожі мережі, а не детальна авторизація.
2. SSL VPN (ранні 2000‑ті) популяризували «безклієнтський» веб-доступ і пізніше клієнти повного тунелю. Вони полегшили розгортання, але не покращили опірність боковому руху.
3. Припущення про мережевий периметр ослабли коли SaaS і хмара перемістили «внутрішні» додатки в публічний інтернет за логінами, а не за підмережами.
4. Мікросегментація стала модною коли віртуалізація й SDN дозволили фільтрування схід‑захід без перекладання кабелів. Більшість організацій зрозуміли, що писати правила — це найважча частина.
5. Модель BeyondCorp від Google (середина 2010‑х) просунула ідею, що корпоративна мережа не є кордоном безпеки; ідентичність і стан пристрою — так.
6. Крадення облікових даних випередило шкідливе ПЗ у багатьох інцидентах, бо дешевше фішингувати одного користувача, ніж експлуатувати десять хостів.
7. «Плоска мережа» часто — випадковість, а не дизайн: злиття, тимчасові VLAN і «приберемо пізніше» стають постійністю.
8. MFA необхідне, але недостатнє: воно зупиняє частину атак, але у плоскому VPN радіус ураження все ще величезний.
9. Продукти Zero Trust сходяться до кількох примітивів: провайдер ідентичності, рушій політик, конектор/проксі та сильна телеметрія.

Урок історії закінчено. Висновок: VPN вирішували конфіденційність і з’єднання. Zero Trust вирішує авторизацію та стримування, виходячи з припущення, що мережа вже ворожа.

Цільовий результат: доступ за ролями, а не надія на ролі

«Доступ за ролями» в контексті Zero Trust для офісу означає:

• Користувачі автентифікуються через провайдера ідентичності (IdP).
• Їх відображають у ролі/групи (Інженерія, Фінанси, IT, Постачальник‑ACME).
• Політики надають доступ до конкретних додатків/сервісів на підставі ролі + стану пристрою + контексту.
• З’єднання є обмеженим на рівні додатка (service‑scoped), а не на рівні підмережі.
• Кожна подія доступу логгується з ідентичністю, пристроєм і причиною рішення.

Помилка думати, що «RBAC» означає «додати групи і закрити питання». Справжній RBAC потребує:

• Гігієни ролей: стабільні ролі, мінімальний сплеск, чітка відповідальність.
• Інвентаризації ресурсів: ви не можете захистити те, що не вмієте назвати.
• Меж авторизації: додатки все ще повинні аутентифікувати; мережна політика — другий рівень, а не єдина замкова щілина.
• Час на відкликання: якщо відключення доступу при звільненні триває години, воно відбудеться саме в ті години, коли не треба.

Парафраз відомої SRE‑фігури (цитата): Werner Vogels наголошував, що все рано чи пізно ламається, тож системи повинні бути спроєктовані з урахуванням відмов. Застосуйте це тут: припускайте, що облікові дані витікають, ноутбуки захоплюють, а мережі неправильно маршрутизуються. Проєктуйте так, щоб радіус ураження був малим, а трейл аудиту — придатним.

Друге практичне правило: ваша політика має бути читабельною людиною о 2:00 ночі під час інциденту. Якщо єдина людина, яка її розуміє, у відпустці — у вас ризик, а не система.

Жарт №1: Плоский VPN — це як дати всім головний ключ, бо ви їм довіряєте не ходити в комору. Комора з цим не згодна.

Варіанти архітектури: оберіть свій бій

Існують три загальні шаблони. Усі можуть працювати; кожен дає різні наслідки при провалі.

1) ZTNA через identity-aware proxy (кращий для HTTP/S та сучасних додатків)

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

• Веб-додатків (внутрішні дашборди, Git, CI/CD UI)
• API
• Панелей адміністрування, що вже підтримують SSO

Це може бути незручним для:

• Сирих TCP‑сервісів (БД, SSH), якщо продукт не підтримує їх добре
• Легісі товстих клієнтів, які розраховують на сусідство в LAN

2) Пер‑ап тунелі (краще для TCP/SSH/доступу до БД з явною цілевою адресацією)

Замість «підключитися до VPN» користувач підключається до «prod-db-readonly» або «k8s-admin» через брокера. З’єднання встановлюється лише до конкретних дозволених напрямків. Це те, куди ви штовхаєте розробників і адміністраторів, коли вони наполягають, що «потрібен SSH». Добре. Вони отримують SSH лише до конкретних хостів, з короткоживучими обліковими даними та логуванням.

3) Мікросегментований VPN (перехідний шаблон, не кінцева мета)

Ви залишаєте VPN, але припиняєте маршрутизувати користувачів у спільну внутрішню підмережу. Ви видаєте IP‑пули для кожної ролі і застосовуєте суворі ACL. Це все ще довіряє мережі, але принаймні радіус ураження менший. Використовуйте це як крок, якщо ландшафт додатків дуже легатний.

Обґрунтована порада: за замовчуванням обирайте identity-aware proxy для вебу, пер‑ап тунелі для адміністративних протоколів, і тримайте загальний VPN лише для рідкісних випадків з датою виведення з експлуатації.

Модель політик: ідентичності, ролі та «хто може дістатися до чого»

Почніть з графа доступу, а не з карти підмереж

Мережеві інженери люблять діапазони IP, бо вони конкретні. Zero Trust змушує змоделювати щось ближче до графа доступу:

• Суб’єкти: користувачі, сервісні акаунти, пристрої
• Атрибути: роль, відділ, ризиковий бал, керований/некерований, версія ОС, рівень патчів
• Об’єкти: додатки, API, бази даних, адміністративні ендпоінти, SSH‑бастіони
• Дії: HTTP GET/POST, SSH, RDP, підключення до бази даних, kubectl
• Умови: MFA, стан пристрою, геолокація, час, мережа, посилання на тикет

Хороша політика читається як речення:

• «Інженери на керованих пристроях з шифруванням диска і свіжим рівнем патчів можуть доступатись до Git і CI через HTTPS.»
• «On‑call SRE можуть SSH до продакшн‑бастіона з MFA і JIT‑погодженням, сесії записуються.»
• «Фінанси можуть доступатись до payroll‑додатка лише з керованих пристроїв; блокувати некеровані та BYOD.»

Визначайте ролі по‑нудному

Ролі мають бути стабільними й грубозернистими. Завжди можна додати тонші дозволи пізніше. Ви не зможете легко видалити 400 мікро‑ролей, коли у кожної команди своя. Почніть з:

• Співробітник vs підрядник vs постачальник
• Ролі на рівні відділу (Інженерія, Продажі, Фінанси, HR)
• Привілейовані ролі (IT Admin, SRE On‑call, Security)
• Ролі середовища (Доступ до проду, доступ до стейджингу)

Потім накладіть обмеження:

• Власник ролі: у кожної ролі є людина‑власник, яка погоджує членство.
• Джерело істини членства: ідеально HRIS → IdP → система доступу, з відслідковуванням винятків.
• Обмежене в часі підвищення прав: ролі break‑glass, що мають термін дії.

Не плутайте автентифікацію з авторизацією

Сильна ідентичність потрібна. Але все ще потрібні рішення авторизації близько до ресурсу. На практиці:

• Для веб‑додатків: використовуйте SSO і застосовуйте ролі на рівні додатка; проксі — це ворота, а не єдина замкова щілина.
• Для SSH: використовуйте короткоживучі сертифікати і forced commands коли можливо.
• Для баз даних: уникайте спільних паролів; використовуйте IAM‑автентифікацію або індивідуальні облікові записи; обмежуйте мережевий шлях як другий рівень.

Жарт №2: «Просто поставте за VPN» — це еквівалент «просто перезавантажте». Іноді допомагає; ніколи не є стратегією.

Чеклісти / покроковий план: мігруйте, не підпаливши себе

Крок 0: інвентаризуйте, для чого насправді використовується VPN

• Перелік напрямків: підмережі, імена хостів, сервіси, порти.
• Перелік груп користувачів: хто підключається, коли і навіщо.
• Класифікація трафіку: веб‑додатки, SSH/RDP, бази даних, файлові шари, внутрішній DNS, служби AD.

Результат рішення: ви виявите, що 80% використання передбачуване і може бути переміщене на пер‑ап доступ. Решта 20% — де живе дивина.

Крок 1: оберіть точку примусового застосування

• Identity‑aware proxy для HTTP/S і додатків, що підтримують SSO.
• Пер‑ап тунелі для SSH/БД/Kubernetes та інших TCP‑протоколів.
• Тримайте легасі‑VPN лише для «не можна мігрувати зараз», але звужуйте маршрути.

Крок 2: визначте «керований пристрій» і застосуйте перевірку стану

• Оберіть сигнали MDM/EDR, яким довіряєте: шифрування, рівень патчів ОС, блокування екрана, відомий агент EDR.
• Вирішіть, як обробляти BYOD: окрема роль з обмеженим доступом або відсутність доступу до чутливих додатків.

Результат рішення: доступ — це не лише «хто ви», а й «чим ви користуєтесь». Зловмисникам це не подобається.

Крок 3: мігруйте найменш проблемні додатки першими

• Внутрішня вікі, дашборди, трекінг завдань, портали документації.
• Додатки, що вже за SSO.
• Додатки з чистими іменами хостів і TLS.

Крок 4: займіться адміністративними протоколами з явними робочими процесами

• Впровадьте бастіон або брокера доступу для SSH/RDP.
• Реалізуйте JIT‑підвищення для продакшну.
• Увімкніть запис сесій там, де можливо.

Крок 5: звужуйте VPN аж поки не стане соромно

• Замініть маршрути 10.0.0.0/8 на тільки конкретні легасі‑підмережі.
• Сегментуйте користувачів за ролями в різні IP‑пули і жорстко їх фаєрвольте.
• Встановіть дату: «цей маршрут VPN вмирає». Потім дійсно вбийте його.

Крок 6: вимірюйте і ітеруйте

• Відстежуйте: відхилені запити, час на онбординг нового додатка, звернення в підтримку, медіану затримки.
• Переглядайте політики щоквартально так само, як ви переглядаєте on‑call: обрізайте, спрощуйте, переосмислюйте власність.

Практичні завдання (з командами): перевірити, діагностувати, вирішити

Ось типи завдань, які ви виконуєте під час міграції та під час тикетів «чому я не можу дістатися X». Кожне містить, що означає вивід і яке рішення прийняти.

Завдання 1: визначте, які маршрути насправді встановлює клієнт VPN

cr0x@server:~$ ip route show
default via 192.168.1.1 dev wlp2s0 proto dhcp metric 600
10.0.0.0/8 via 10.8.0.1 dev tun0 proto static metric 50
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.23 metric 50

Що це означає: VPN маршрутизує цілий RFC1918‑суперпідмережа (10/8) через tun0. Це класичне сусідство плоскої мережі.

Рішення: замініть широкий маршрут на пер‑ап доступ або, принаймні, звузьте маршрути до легасі‑напрямків, які справді потрібні.

Завдання 2: підтвердити поведінку split tunnel vs full tunnel

cr0x@server:~$ curl -s https://ifconfig.me
203.0.113.47

Що це означає: Ваш egress IP — публічний ISP (split tunnel), а не корпоративний egress (full tunnel). Якщо ви очікуєте корпоративний egress для відповідності — це промах.

Рішення: для Zero Trust віддавайте перевагу доступу, обмеженому на рівні додатка, і уникайте примусу full tunnel, якщо немає чіткої вимоги (і є ресурси) для цього.

Завдання 3: перевірити шлях резолюції DNS (поширена міграційна пастка)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 1.1.1.1
DNS Domain: corp.example

Що це означає: Ви використовуєте внутрішній DNS із публічним фолбеком. Це може призводити до витоку запитів або до неконсистентної резолюції, якщо зони корп не обробляються правильно.

Рішення: у моделі Zero Trust вирішіть, які імена мають резолюватися внутрішньо, і забезпечте відповідний DNS‑шлях для доступу (split‑horizon, DoH‑політика або проксі‑базований хост‑роутинг).

Завдання 4: перевірити, чи конкретний внутрішній сервіс досяжний політикою (TCP)

cr0x@server:~$ nc -vz git.corp.example 443
Connection to git.corp.example 443 port [tcp/https] succeeded!

Що це означає: Мережевий шлях до 443 існує. Якщо додаток все ще не працює, проблема, ймовірно, в TLS/SSO/авторизації додатка, а не в маршрутизації.

Рішення: перемикайте налагодження на HTTP/TLS/рівень ідентичності, а не на правила фаєрволу.

Завдання 5: діагностувати, що проблема в DNS чи в з’єднанні

cr0x@server:~$ dig +short git.corp.example
10.20.30.40

Що це означає: Ім’я резолюється в приватну IP. Якщо ви використовуєте identity‑aware proxy, ви, можливо, не хочете, щоби користувачі взагалі резолювали приватні адреси.

Рішення: або (a) опублікуйте додаток через проксі з публічним ім’ям, що не витікає внутрішніх IP, або (b) забезпечте, щоб пер‑ап тунель покривав цю IP/порт і DNS був консистентним.

Завдання 6: підтвердити TLS і SNI‑поведінку до ендпоінта додатка

cr0x@server:~$ openssl s_client -connect git.corp.example:443 -servername git.corp.example -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=git.corp.example
Verification: OK

Що це означає: TLS здоровий, сертифікат відповідає, SNI працює. Якщо користувачі бачать попередження в браузері, ймовірно, причина — перехоплення/проксі або проблеми з довірчим сховищем пристрою.

Рішення: якщо ваше ZTNA‑рішення робить TLS‑термінацію, переконайтеся, що воно пред’являє довірчий ланцюг сертифікатів і не ламає очікування додатка.

Завдання 7: переглянути правила фаєрволу, що випадково тримали мережу плоскою

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "tun0" ip daddr 10.0.0.0/8 accept
    ct state established,related accept
  }
}

Що це означає: Є явний дозвіл з VPN‑інтерфейсу до 10/8. Це — ваш шосе бокового руху.

Рішення: замініть загальний дозвіл на правила, специфічні для додатків, або взагалі відмовтесь від форварду на користь проксі/тунелів.

Завдання 8: підтвердити членство в групі ідентичності для RBAC (IdP через інспекцію токена SSO)

cr0x@server:~$ jq -r '.email, .groups[]' /tmp/id_token_claims.json
alex@example.com
role:engineering
env:staging
priv:none

Що це означає: Клами користувача показують engineering + staging доступ, без привілейованого підвищення.

Рішення: якщо їм потрібен продовий доступ, ви не «просто додаєте». Ви реалізуєте тимчасову привілейовану групу з погодженнями та аудитом.

Завдання 9: перевірити сигнал стану пристрою (керований vs некерований) з кінцевої точки

cr0x@server:~$ sudo osqueryi "select * from disk_encryption;"
device_name = /dev/nvme0n1p3
encrypted = 1
type = luks

Що це означає: Шифрування диска увімкнено (добре). Це одна з небагатьох перевірок стану, що корелює з ризиком «втраченого ноутбука».

Рішення: якщо шифрування вимкнене — блокувати доступ до чутливих додатків і направляти користувача на реєстрацію. Не сперечайтесь з фізикою.

Завдання 10: валідувати, що пер‑ап тунель відкриває лише заплановані напрямки

cr0x@server:~$ ss -tnlp | grep 127.0.0.1:15432
LISTEN 0 4096 127.0.0.1:15432 0.0.0.0:* users:(("ztna-client",pid=2214,fd=9))

Що це означає: Локальний клієнт слухає лише на localhost. Добре: він не відкриває порт у вашу LAN або в інтернет.

Рішення: тримайте локальний bind на 127.0.0.1 для DB‑тунелів; зафіксуйте цей шаблон у SOP.

Завдання 11: підтвердити, що існує аудитна стежка для спроби доступу

cr0x@server:~$ sudo journalctl -u ztna-connector --since "10 min ago" | tail -n 8
Dec 28 12:11:02 connector-01 ztna-connector[1189]: allow user=alex@example.com app=git-web device=managed policy=eng-web-mfa
Dec 28 12:11:04 connector-01 ztna-connector[1189]: deny user=alex@example.com app=prod-bastion reason=missing_jit_approval

Що це означає: Є явні події allow/deny з причинами. Це золото під час інцидентів і переглядів доступу.

Рішення: якщо система не може пояснити deny, її обійдуть. Виправте спостережуваність до масштабного розгортання.

Завдання 12: визначити джерела затримки (DNS, час підключення, TLS, TTFB)

cr0x@server:~$ curl -o /dev/null -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://git.corp.example/
dns=0.012 connect=0.031 tls=0.112 ttfb=0.487 total=0.512

Що це означає: DNS/connect/TLS в межах норми; відповідь сервера (TTFB) домінує. Ймовірно, це навантаження на додаток/бекенд або буферизація проксі, а не «VPN повільний».

Рішення: ескалюйте до продуктивності додатка або потужності проксі; не витрачайте дні на підгонку MTU, якщо бекенд — вузьке місце.

Завдання 13: перевірити MTU і проблеми PMTUD (класична VPN‑біль)

cr0x@server:~$ ip link show dev tun0
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
    link/none

Що це означає: MTU = 1280 (типово в тунельних середовищах). Деякі легасі‑сервіси ламаються, якщо вони очікують 1500 і ICMP блокується.

Рішення: якщо ви бачите зависання на великих передачах, перевірте PMTUD і дозволіть потрібні типи ICMP, або робіть clamp MSS на краю тунеля.

Завдання 14: підтвердити, чи «заблокований» додаток фактично доступний напряму, а не через проксі

cr0x@server:~$ traceroute -n git.corp.example | head -n 6
traceroute to git.corp.example (10.20.30.40), 30 hops max, 60 byte packets
 1  192.168.1.1  1.103 ms  0.921 ms  0.877 ms
 2  203.0.113.1  9.902 ms  10.004 ms  9.811 ms
 3  * * *

Що це означає: Ви намагаєтесь маршрутизувати до приватної IP через публічний інтернет (це не спрацює). Так буває, коли DNS вказує на внутрішні IP, але користувачі вже не в VPN.

Рішення: виправте DNS і публікацію: приватні IP не повинні витікати до клієнтів, яким не дозволено мережний доступ.

Завдання 15: перевірити межі сегментації в офісній мережі (реалії схід‑захід)

cr0x@server:~$ sudo tcpdump -ni eth0 'tcp port 445' -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:20:11.102938 IP 10.50.12.34.51322 > 10.50.0.10.445: Flags [S], seq 122233, win 64240, options [mss 1460,sackOK,TS val 1 ecr 0,nop,wscale 7], length 0

Що це означає: Ви бачите спроби SMB всередині нібито сегментованого середовища. Це поверхня для бокового руху, перевдягнена в плащ.

Рішення: забезпечте, щоб робочі VLAN не могли досягати серверних VLAN, окрім через явні allow‑правила; по можливості видаліть легасі‑поширення файлових шарів.

Завдання 16: виявити, хто ще користується легасі‑VPN і навіщо

cr0x@server:~$ sudo awk '{print $1,$2,$3,$9}' /var/log/openvpn/status.log | tail -n 5
CLIENT_LIST alex@example.com 10.8.0.23 192.0.2.44
CLIENT_LIST sam@example.com 10.8.0.24 198.51.100.19
ROUTING_TABLE 10.30.0.0/16 10.8.0.23
ROUTING_TABLE 10.40.0.0/16 10.8.0.24
GLOBAL_STATS Max_bcast_mcast_queue_length 0

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

Рішення: використовуйте ці дані для пріоритезації цілей міграції і щоб аргументувати видалення маршрутів доказами, а не відчуттями.

Плейбук швидкої діагностики: знайдіть вузьке місце швидко

Коли хтось каже «Zero Trust зламав мій доступ», не починайте з зміни політик. Почніть з визначення, який шар відмовляє. Ось порядок, що економить час.

Перший: резолюція і правильність цілі

• Чи ім’я хоста резолюється? Куди — на публічну адресу проксі чи на приватну IP?
• Чи використовує користувач правильну URL (вхід через фронт‑дверу проксі) чи старе внутрішнє ім’я?
• Чи вони потрапляють на застарілу закладку, яка обминає ваші контролі?

Другий: встановлення шляху (мережа + тунель/проксі)

• Чи можна встановити TCP до проксі/ендпоінта тунелю?
• Чи MTU/PMTUD викликає часткові зависання (особливо великі завантаження, клонування git, pull‑и контейнерів)?
• Чи є асиметрична маршрутизація між конектором і додатком?

Третій: ідентичність і рішення політики

• Чи має користувач правильні групові/рольові клейми?
• Чи проходить перевірку стан пристрою? (керований, зашифрований, відповідний)
• Чи політика відхиляє з причиною, видимою в логах?

Четвертий: аутентифікація на рівні додатка та продуктивність

• Чи SSO зациклиться? Неправильні домени cookie? Плутанина TLS‑термінації?
• Чи повільність бекенду помилково приписують «VPN‑затримці»?
• Чи ліміти або WAF блоки тригерять через публічний IP виходу проксі?

Правило‑шорткат: якщо ви не бачите причину deny в логах за п’ять хвилин, ваша система ще не придатна до експлуатації. Виправте телеметрію перед подальшим розгортанням.

Поширені помилки: симптоми → корінь → виправлення

1) «Користувачі не можуть дістатися внутрішніх додатків, якщо не користуються старим VPN»

Симптоми: Тайм‑аути в браузері; traceroute показує публічні хопи; DNS резолює приватні IP.

Корінь: Split‑horizon DNS все ще повертає внутрішні адреси зовнішнім клієнтам; додаток неправильно опублікований через проксі/тунель.

Виправлення: опублікуйте додаток за identity‑aware фронт‑дверима з іменем, що резолюється для віддалених клієнтів; припиніть витік внутрішніх IP у зовнішньому DNS.

2) «ZTNA повільніший за VPN» (сказано голосно, великими буквами)

Симптоми: Повільні клонування git; зависання великих завантажень; лаги в інтерактивних shell’ах.

Корінь: Невідповідність MTU, PMTUD заблокований або конектор/проксі недостатньо підготовлені. Іноді це просто повільний бекенд, який тепер видно.

Виправлення: виміряйте розбивку часу (DNS/connect/TLS/TTFB). Дозвольте потрібні ICMP для PMTUD або робіть clamp MSS. Масштабуйте конектори горизонтально і розміщуйте їх ближче до навантажень.

3) «Ми додали групи RBAC, але люди досі мають надто великий доступ»

Симптоми: Користувачі одного відділу можуть дістатися до несумісних сервісів; пентест показав, що боковий рух все ще можливий.

Корінь: Мережна політика досі видає широкий доступ по підмережах; доступ до додатків не обмежений на рівні додатка.

Виправлення: видаліть маршрути підмереж з пристроїв користувачів. Замініть їх на пер‑ап конектори/проксі і явні списки дозволених сервісів за ідентичністю сервісу.

4) «Підрядники мають доступ до продакшну, бо вони в тій же «Інженерній» групі»

Симптоми: Аудит вказує; ніяково нарада; раптовий інтерес до розділення обов’язків.

Корінь: Ролі моделювалися навколо оргструктури, а не меж ризику. Статус підрядника не закодований в атрибутах ідентичності.

Виправлення: створіть окремі ідентичності/ролі для підрядників і постачальників; вимагайте суворіших умов (керований VDI, JIT‑погодження) для чутливого доступу.

5) «SSO зациклюється» після проксування внутрішнього веб‑додатка

Симптоми: Петля редиректів; cookie не зберігаються; користувач бачить повторні запити на вхід.

Корінь: Неправильні callback URI, проблеми з доменом cookie, змішані HTTP/HTTPS припущення або подвійна TLS‑термінація, що плутає додаток.

Виправлення: стандартизуйте HTTPS енд‑то‑енд. Узгодьте базовий URL додатка з зовнішнім URL проксі. Перевірте redirect URI в IdP та налаштування cookie (Secure, SameSite).

6) «Доступ працює з ноутбуків, але не з телефонів»

Симптоми: Мобільні користувачі відхиляються; десктопи в порядку.

Корінь: Вимоги стану пристрою виключають некеровані пристрої; або на мобайлі відсутній потрібний клієнт/сертифікат.

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

7) «Ми включили full tunnel для «безпеки» і все зламалось»

Симптоми: SaaS‑логіни ламаються; відеодзвінки деградують; трафік робить hairpin; черга helpdesk росте зубастою.

Корінь: Корпоративний egress не був розрахований; винятки split tunnel — хаотичні; DNS та проксі‑політики конфліктують.

Виправлення: надавайте перевагу доступу, обмеженому на рівні додатка. Якщо потрібен full tunnel — інвестуйте в пропускну здатність, локальний egress і чіткі правила маршрутизації. Виміряйте до і після.

8) «Наші політики правильні, але логи — нікчемні»

Симптоми: Події deny без контексту; немає correlation ID; неможливо відповісти «хто до чого мав доступ».

Корінь: Логи не вважалися вимогою першого порядку; дані не централізовані; проблеми з синхронізацією часу.

Виправлення: стандартизувати поля логів (user, device, app, decision, reason). Централізувати в SIEM/сховище логів. Забезпечити NTP скрізь.

Три корпоративні міні‑історії з практики

Міні‑історія 1: інцидент через неправильне припущення

Середня компанія мігрувала на нову платформу доступу. План проекту казав: «Більше немає VPN. Усе за проксі.» Вони вимкнули перемикач для віддаленого доступу і похвалилися календарним запрошенням «ZTNA зроблено». Запрошення погано постаріло.

Неправильне припущення було тонким: вони вірили, що видалення VPN‑клієнта прибирає мережеве сусідство. Насправді, офісне Wi‑Fi все ще було плоским, а віддалим користувачам залишався профіль «легасі VPN» для «винятків». Список винятків тихо зростав, бо так завжди буває. Декілька сервісів досі покладалися на внутрішні DNS‑імена, а людей навчили «просто використовувати VPN», коли щось не завантажувалось.

Потім ноутбук підрядника піддався фішингу. Атакуючому не потрібні були складні експлойти; вони використали VPN‑доступ підрядника, опинилися в робочому VLAN і просканували. Файлові шари відповіли. Інтерфейс керування на старому гіпервізорі відповів. Платформа доступу не була обійдена; вона просто стала неактуальною для шляхів, які обрав атакуючий.

Під час реагування команда бачила дашборди з логами проксі, що показували «нічого підозрілого». Це було правдою, але марною. Підозріла активність була на старих VPN‑маршрутах та в плоскій офісній мережі. Проксі стерегло передні двері, поки задні двері були підперті «на кілька тижнів».

Виправлення не вимагало нового інструменту. Це було рішення про межі: видалити широкі VPN‑маршрути, впровадити рольову сегментацію в офісних мережах і публікувати додатки так, щоб не покладатися на витік внутрішніх DNS. Також підрядників перекваліфікували в окремий рівень ризику з іншими умовами. Урок: Zero Trust вмирає, коли ви тримаєте «тимчасовий» шлях довіри.

Міні‑історія 2: оптимізація, що відбилася боком

Команда корпоративного IT захотіла зменшити затримку. Вони перемістили конектори в центральний дата‑центр і змусили весь трафік віддалих користувачів йти через нього, бо «один egress легше моніторити». Безпека погодилась: моніторинг заспокоює, і всім подобаються графіки.

Скарги на продуктивність почалися протягом тижня. Не тому, що платформа доступу була повільною, а тому, що шлях трафіку став абсурдним: користувач → проксі → центральний конектор → хмарна робоче навантаження в іншому регіоні → назад. Додаткові кругові поїздки вбивали чатливі протоколи і додатки з багатьма дрібними HTTP‑запитами. Кількість тикетів зросла, і люди почали шепотіти заборонену фразу: «Чи можемо ми повернути VPN?»

Команда подвоїла CPU і пропускну здатність конекторів. Витрати зросли; досвіду користувача ледь покращився. Вузьке місце було не в пропускній здатності, а в латентності й дизайні шляху. Вони оптимізували для зручності моніторингу, а не для фізики.

Відновлення було нудним інжинірингом. Вони розгорнули конектори ближче до робочих навантажень (включно з хмарними VPC), використали регіональний egress там, де дозволяла відповідність, і централізували логи замість пакетів. Політики розділили за чутливістю додатків: payroll пішов більш суворим шляхом; внутрішня вікі — швидшим.

Урок оптимізації: «один вузол пропуску» привабливий операційно, поки він не стає реальним вузьким місцем.

Міні‑історія 3: нудна, але правильна практика, що врятувала день

Компанія з розвиненою культурою SRE впровадила пер‑ап доступ для адміністрації продакшну. Нічого драматичного: вимагали JIT‑підвищення для prod SSH, використовували короткоживучі сертифікати і записували сесії. Реалізація була непоказною. Вона працювала.

Місяць потому ноутбук старшого інженера викрали з машини. Інженер вчинив правильно і швидко повідомив. Security ротувала токени, відкликала сесії і зняла довіру пристрою. Все одно всі напружились, бо «вкрадений ноутбук» — фраза, що змушує керівництво вивчати нову лексику.

Ось що не сталося: немає доказів доступу до продакшну з цього пристрою після крадіжки. Логи сесій показували останнє успішне підвищення, а події deny в системі доступу показували спроби повторного використання з некерованого стану пристрою. У зловмисника була машина, але не постура, не сертифікати і не JIT‑погодження.

Інцидент вирішили без загальної ротації продакшн‑облікових даних. Не довелося знімати з роботи половину інфраструктури. Провели таргетований огляд, підтвердили, що обмеження працюють, і продовжили роботу. Найціннішим активом команди була не технологія; це була практика: тимчасові привілеї і чисті журнали аудиту.

Нудна практика врятувала день. Ось у чому справа.

FAQ

1) Чи Zero Trust — це просто «MFA скрізь»?

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

2) Чи потрібно повністю відмовитись від VPN?

Ні. Але варто усунути плоску маршрутизацію VPN. Тримайте легасі‑VPN лише для чітко визначених винятків, з вузькими маршрутами і планом виведення з експлуатації.

3) У чому різниця між ZTNA і мікросегментацією?

ZTNA зосереджений на рішеннях доступу користувач→додаток з урахуванням ідентичності і стану. Мікросегментація фокусується на контролі схід‑захід між робочими навантаженнями. Зазвичай потрібні обидва: ZTNA зменшує радіус ураження користувача; мікросегментація зменшує те, до чого може дістатися скомпрометований сервер.

4) Як обробляти SSH‑доступ у моделі Zero Trust?

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

5) Чи не вибухне RBAC у сплеску ролей?

Вибухне, якщо дозволити кожній команді вільно винаходити ролі. Встановіть обмеження: стабільні ролі, власники, щоквартальні рев’ю та прагнення до грубозернистих ролей плюс авторизація на рівні додатка.

6) А сервісні акаунти та автоматизація — чи можуть вони «робити Zero Trust» також?

Так, або ви збудували охайний фронт‑двер і лишили роботизований бічний вхід. Використовуйте ідентичність навантаження, короткоживучі токени і явну політику сервіс→сервіс. Не тунелюйте цілі мережі для CI‑раннерів.

7) Як уникнути ламання легасі‑додатків, які розраховують на LAN‑доступ?

Почніть із ізоляції: пер‑ап тунелі, обмежені списки напрямків і суворий стан пристрою. Потім плануйте модернізацію: SSO, TLS і усунення залежностей від broadcast, старих протоколів і спільних файлових шарів.

8) Який найшвидший виграш з найбільшим зниженням ризику?

Припиніть маршрутизувати віддалих користувачів у широкі внутрішні підмережі. Перемістіть найбільш чутливі адміністративні шляхи (prod SSH/RDP, адміністрування БД) на пер‑ап доступ з JIT та логуванням.

9) Як довести аудиторам, що це працює?

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

10) Якщо впаде проксі доступу — чи втратимо ми усе?

Якщо спроєктовано погано — так. Будуйте з резервністю: кілька конекторів, health checks і чіткі процедури break‑glass з короткоживучими, аудитованими підвищеннями. Доступність — це вимога безпеки, бо відмови створюють обхідні шляхи.

Висновок: наступні кроки, що переживуть контакт з реальністю

Якщо ви запам’ятаєте одне — нехай це буде це: ваша мета не замінити VPN‑клієнт іншим клієнтом. Мета — замінити неявну мережеву довіру на явний, рольовий, ідентифікаційно‑орієнтований доступ.

Наступні кроки

1. Інвентаризація реальних VPN‑маршрутів, напрямків і популяцій користувачів. Використовуйте логи, а не припущення.
2. Публікуйте веб‑додатки через identity‑aware доступ першочергово. Це найшвидший спосіб зменшити залежність від підмереж.
3. Перемістіть адміністративний доступ (SSH/RDP/kubectl/адмін БД) на пер‑ап тунелі з короткоживучими обліковими даними і JIT.
4. Агресивно звужуйте маршрути VPN: видаляйте 10/8 та подібні. Якщо хтось «потрібен усім», він потребує архітектурного перегляду, а не маршруту.
5. Зробіть стан пристрою реальністю: визначте керовані пристрої, застосовуйте шифрування і вимоги до патчів, а BYOD трактуйте як окремий рівень.
6. Оперціоналізуйте: логування з причинами deny, плейбук швидкої діагностики, щоквартальні рев’ю ролей і чіткий break‑glass шлях, що не стає дефолтом.

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