Zero Trust архітектура
Коротке резюме
Zero Trust (ZT) - це модель безпеки, в якій мережевий периметр більше не вважається довіреною зоною. Кожен запит (user→app, service→service, device→network) проходить явну автентифікацію, авторизацію і шифрування з урахуванням контекстних сигналів (ідентичність, стан пристрою, місце розташування, ризик, поведінка). Мета - мінімізація blast radius, зниження ризику lateral movement і спрощення комплаєнсу.
Базові принципи Zero Trust
1. Явна довіра відсутня: довіра не успадковується від мережі/VPN/ASN.
2. Доступ мінімально необхідний: політика «надати тільки те, що потрібно зараз».
3. Безперервна верифікація: сесії і токени регулярно переоцінювати за ризиком і контекстом.
4. Припущення компрометації: сегментація, спостережуваність, швидкий containment і ротації ключів.
5. Шифрування скрізь: TLS 1. 2+/1. 3 і mTLS всередині дата-планes, захищений DNS, секрети в KMS/HSM.
Цільовий ландшафт і домени контролю
Ідентичність: люди (IdP: SSO, MFA, passkeys/FIDO2), машини (SPIFFE/SVID, x509/mTLS).
Пристрої: відповідність політикам (MDM/EDR, диск шифрований, патчі, jailbreak/root - заборонені).
Мережа: мікросегментація L3/L7, ZTNA/SDP-шлюзи, сервіс-меш (Envoy/Istio/Linkerd).
Додатки/API: mTLS, OIDC/JWT, підписи запитів (HMAC), rate limits, DLP/маскування.
Дані: класифікація (Public/Confidential/Restricted), токенізація/шифрування на рівні полів.
Спостережуваність: централізовані логи аутентифікації/авторизації, поведінкова аналітика, SLO/SLA.
Референс-архітектура (в розрізі площин)
Control Plane: IdP/CIAM, PDP/PEP (OPA/Envoy), каталоги політик, PKI/CA, атестація пристроїв.
Data Plane: проксі-доступу (ZTNA), sidecar-проксі (Envoy) для mTLS і політика L7, сервісні шлюзи/API GW.
Management Plane: каталог сервісів, CMDB, CI/CD, секрет-менеджмент (Vault/KMS), централізований аудит.
1. Ідентифікація (SSO + phishing-resistant MFA) → 2) Оцінка пристрою (MDM posture) → 3) ZTNA-проксі встановлює mTLS до програми → 4) PDP (політики) приймає рішення на основі атрибутів (ABAC/RBAC) → 5) безперервна переоцінка ризику (час, гео, аномалії).
Ідентичність та авторизація
IdP/SSO: OIDC/SAML, MFA за замовчуванням, переважно FIDO2 (passkeys).
RBAC/ABAC: ролі + атрибути контексту (статус пристрою, відділ, ризик-профіль).
Just-In-Time (JIT) доступ: тимчасові привілеї з автоматичним відкликанням; break-glass - строго регламентований.
mTLS для машин: SPIFFE/SVID або внутрішня PKI з короткоживучими сертифікатами; автоматичний ротаційний випуск.
Пристрої та контекст
Перевірка відповідності (posture): версія OS/EDR, включений диск-енкрипт, firewall; non-compliant → доступ до мінімуму або блок.
Атестація: device identity + signed attestations (MDM/Endpoint).
Мережеві обмеження: блок сторонніх тунелів, примусовий корпоративний DNS, захист від DNS/WebRTC витоків.
Мережа та мікросегментація
Відмова від «плоских» VLAN: замість цього - сегменти/VRF і політика на L7.
Service Mesh: sidecar-проксі забезпечують mTLS, авторизацію з політики (OPA/EnvoyFilter), телеметрію.
ZTNA/SDP: доступ до конкретного додатка, а не до мережі; kliyent↔broker↔app, політика в PDP.
Remote Access: заміна «товстого» VPN на апп-проксі; fallback-тунелі обмежені за маршрутами/портами.
Політики і рушій рішень
PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
Модель політики: декларативні правила (Rego/Cedar), статичні та контекстні атрибути, оцінка ризику.
rego package access. http
default allow = false
allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}Трасування рішень: логуйте «input »/« result »/« explain» для аудиту.
Шифрування та довіра за замовчуванням
TLS 1. 2+/1. 3 скрізь, строгі шифросюїти, HSTS, OCSP stapling.
mTLS всередині: servis↔servis тільки за взаємними сертифікатами; ключі короткоживучі (години/дні).
Секрети: KMS/HSM, dynamic secrets (Vault), короткі TTL, least-privilege для додатків.
Спостережуваність, SLO і реагування
Метрики (мінімальний набір):- Успіх автентифікації та авторизації (%), p95 часу прийняття рішення PDP, p95 TLS-handshake.
- Відсоток запитів, заблокованих політикою (аномалії/помилкові).
- Доступність ZTNA брокерів і Mesh-контролера.
- Частка compliant пристроїв і тренди.
- "Доступність ZTNA ≥ 99. 95 %/міс; p95 authZ decision ≤ 50 мс».
- "Частка запитів з mTLS ≥ 99. 9%».
- "Не більше 0. 1% помилкових відмов у доступі/добу".
Алартінг: сплески deny, деградація p95 рукостискання, невалідні ланцюжки, падіння частки compliant пристроїв, аномалії географії/ASN.
Перехід від периметра до Zero Trust: дорожня карта
1. Інвентаризація: додатки, потоки даних, споживачі, чутливість (PII/карткові/виплати).
2. Ідентичність і MFA: SSO і phishing-resistant MFA для всіх.
3. Контекст пристроїв: MDM/EDR, базові політики відповідності, блок non-compliant.
4. Мікросегментація пріоритетних шляхів: платежі, бек-офіс, адмінка; введення mTLS.
5. ZTNA для користувацького доступу: публікація додатків через проксі, прибираємо «широкий VPN».
6. Політики ABAC: централізований PDP, декларативні правила, аудит.
7. Розширення на сервіс-меш: S2S мTLS, політика L7, телеметрія.
8. Автоматизація та SLO: алертинг, тести політик (політичний CI), гейм-дні "що якщо IdP недоступний? ».
Специфіка для iGaming/фінтех
Жорстка сегментація доменів: платежі/PII/антифрод/контент - окремі периметри і політики; доступи тільки по ZTNA.
Взаємодія з PSP/банками: allow-list за ASN/діапазонами, mTLS до PSP-ендпоінтів, моніторинг Time-to-Wallet і відмов на authZ.
Постачальники контенту та партнери: тимчасові JIT-доступи до API, токени з короткими TTL, аудит інтеграцій.
Комплаєнс: PCI DSS/GDPR - мінімізація даних, DLP/псевдонімізація, журналювання доступів до чутливих таблиць.
Безпека ланцюжків поставки і CI/CD
Підписи артефактів (SLSA/Provenance): підписи контейнерів (cosign), політика Admission в K8s.
SBOM та вразливості: генерація SBOM (CycloneDX), policy-gate в пайплайні.
Секрети в CI: OIDC-федерація до хмарних KMS; заборона на статичні ключі.
Ротації: часті, автоматичні; примусовий revoke при інцидентах.
Типові помилки і анти-патерни
«ZTNA = новий VPN»: публікація мережі замість додатків - не Zero Trust.
Немає перевірки пристроїв: MFA є, але заражені/рутовані пристрої отримують доступ.
Єдиний супер-користувач: відсутність JIT і роздільних ролей.
Політики в коді сервісів: неможливість централізованого аудиту/оновлення.
mTLS частковий: частина сервісів без mTLS → «дірявий» контур.
Нульовий UX: надлишкові запити MFA, відсутність SSO; підсумок - опір командам.
Міні-гайд за вибором технологій
Доступ користувачів: ZTNA/SDP брокер + IdP (OIDC, FIDO2 MFA).
Внутрішньосервісна безпека: сервіс-меш (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID або Vault PKI з короткими TTL.
Політики: OPA/Rego або Cedar; зберігати в Git, перевіряти в CI (policy-tests).
Логи і телеметрія: OpenTelemetry → централізований аналіз, детект аномалій.
Приклади конфігурацій (фрагменти)
Envoy (м'ютуал-TLS між сервісами)
yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: trueOPA/Rego: доступ до звітів тільки з «finance», з compliant-пристроїв, в робочі години
rego package policy. reports
default allow = false
allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}Чек-лист впровадження Zero Trust
1. Включити SSO і FIDO2 MFA для всіх користувачів і адмінок.
2. Ввести device posture (MDM/EDR) з блокуванням non-compliant.
3. Перевести користувацький доступ на ZTNA (per-app), залишити VPN лише для вузьких S2S-каналів.
4. Всередині - mTLS за замовчуванням + короткоживучі сертифікати.
5. Централізувати політики (PDP/OPA), зберігати в Git, тестувати в CI.
6. Сегментувати чутливі домени (платежі/PII/бек-офіс) і обмежити east-west.
7. Налаштувати телеметрію, SLO і алертинг на auth/authZ, mTLS-частку, posture-сигнали.
8. Провести «game days» (відмова IdP, витік ключів, падіння брокера) і зафіксувати SOP/відкати.
FAQ
Zero Trust повністю замінює VPN?
Для користувацького доступу - так, на користь ZTNA. Для S2S-магістралей VPN/IPsec може залишитися, але з mTLS поверх і суворими політиками.
Чи може ZT погіршити UX?
Якщо бездумно. З SSO + FIDO2, адаптивною MFA і per-app доступом UX зазвичай поліпшується.
Чи обов'язково впроваджувати сервіс-меш?
Не завжди. Але для великого мікросервісного середовища mesh радикально спрощує mTLS/політику/телеметрію.
Підсумок
Zero Trust - це не продукт, а архітектурна дисципліна: ідентичність як новий периметр, контекст пристроїв, додатковий доступ (ZTNA), мікросегментація і mTLS всюди, централізовані політики і вимірна надійність. Дотримуючись дорожньої карти і чек-листа, ви зменшите поверхню атаки, прискорите аудит і отримаєте стійку безпеку без «довіри за замовчуванням».