Zero architektury zaufania
Krótkie podsumowanie
Zero Trust (ZT) to model bezpieczeństwa, w którym obwód sieci nie jest już uważany za strefę zaufaną. Każde żądanie (użytkownik → aplikacja, usługa → usługa, urządzenie → sieć) jest wyraźnie uwierzytelnione, autoryzowane i szyfrowane, z uwzględnieniem sygnałów kontekstowych (tożsamość, stan urządzenia, lokalizacja, ryzyko, zachowanie). Celem jest zminimalizowanie promienia wybuchu, zmniejszenie ryzyka ruchu bocznego i uproszczenie zgodności.
Zero podstawy zaufania
1. Brak wyraźnego zaufania - zaufanie nie jest dziedziczone po sieci/VPN/ASN.
2. Dostęp jest niezbędny minimum: polityka „zapewnienia tylko tego, co jest teraz potrzebne”.
3. Weryfikacja ciągła: sesje i żetony są regularnie poddawane ponownej ocenie pod kątem ryzyka i kontekstu.
4. Założenie kompromisu: segmentacja, obserwowalność, szybkie ograniczanie i kluczowe rotacje.
5. Szyfrowanie wszędzie: TLS 1. 2+/1. 3 i mTLS wewnątrz planów danych, chroniony DNS, tajemnice w KMS/HSM.
Krajobraz docelowy i dziedziny kontroli
Tożsamość: ludzie (IdP: SSO, MFA, passkeys/FIDO2), maszyny (SPIFFE/SVID, x509/mTLS).
Urządzenia: zgodność z zasadami (MDM/EDR, dysk zaszyfrowany, plastry, jailbreak/root - zabronione).
Sieć: mikrosegmentacja L3/L7, bramki ZTNA/SDP, siatka serwisowa (wysłannik/Istio/Linkerd).
Aplikacje/API: mTLS, OIDC/JWT, podpisy żądania (HMAC), limity szybkości, DLP/maskowanie.
Dane: klasyfikacja (publiczna/poufna/ograniczona), tokenizacja/szyfrowanie na poziomie pola.
Obserwowalność: scentralizowane dzienniki uwierzytelniania/autoryzacji, analityka behawioralna, SLO/SLA.
Architektura odniesienia (w podziale na samoloty)
Płaszczyzna sterowania: IdP/CIAM, PDP/PEP (OPA/Envoy), katalogi zasad, PKI/CA, kwalifikacje urządzeń.
Płaszczyzna danych: dostęp proxy (ZTNA), sidecar proxy (Envoy) dla polityki mTLS i L7, bramki usług GW/interfejsy API.
Management Plane: katalog usług, CMDB, CI/CD, secret management (Vault/KMS), scentralizowany audyt.
1. Identyfikacja (SSO + odporne na phishing MFA) → 2) Ocena urządzenia (MDM postawy) → 3) ZTNA proxy ustanawia mTLS do aplikacji → 4) PDP (polityki) podejmuje decyzję na podstawie atrybutów (ABAC/RBAC) → 5) ciągłe ryzyko ponowna ocena (czas, geo, anomalie).
Tożsamość i autoryzacja
IdP/SSO: OIDC/SAML, domyślny MFA, najlepiej FIDO2 (passkeys).
RBAC/ABAC: role + atrybuty kontekstowe (stan urządzenia, dział, profil ryzyka).
Dostęp Just-In-Time (JIT): tymczasowe uprawnienia z automatycznym odwołaniem; break-glass - ściśle regulowane.
mTLS dla maszyn: SPIFFE/SVID lub wewnętrzny PKI z certyfikatami krótkotrwałymi; automatyczne zwolnienie obrotowe.
Urządzenia i kontekst
postawa: wersja OS/EDR, włączone szyfrowanie dyskowe, firewall; niezgodny → minimalny dostęp lub blok.
Poświadczenie: identyfikacja urządzenia + podpisane zaświadczenia (MDM/Endpoint).
Ograniczenia sieciowe: blok tuneli zewnętrznych, wymuszony korporacyjny DNS, ochrona przed wyciekami DNS/WebRTC.
Tworzenie sieci i mikrosegmentacja
Odrzucanie „płaskich” sieci VLAN: zamiast tego segmenty/VRF i zasady dotyczące L7.
Service Mesh: sidecar proxies provide mTLS, policy authorization (OPA/EnvoyFilter), telemetry.
ZTNA/SDP: dostęp do określonej aplikacji, a nie do sieci; kliyent اbroker اapp, zasady w PDP.
Zdalny dostęp: zastąpienie „grubej” sieci VPN serwerem proxy aplikacji; tunele awaryjne są ograniczone do tras/portów.
Polityka i silnik rozwiązania
PDP/PEP: Policy Decision Point (OPA/Styra, Cedar ка.) + Punkt egzekwowania polityki (wysłannik/Istio/Gateway).
Model polityki: zasady deklaracyjne (Rego/Cedar), atrybuty statyczne i kontekstowe, ocena ryzyka.
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
}Rozwiązania śladowe: log 'input '/' result '/' explain' do audytu.
Domyślne szyfrowanie i zaufanie
TLS 1. 2+/1. 3 wszędzie, surowe apartamenty szyfrujące, HSTS, zszywanie OCSP.
mTLS w środku: servis i servis tylko za pomocą wzajemnych certyfikatów; klucze krótkoterminowe (godziny/dni).
Sekrety: KMS/HSM, tajemnice dynamiczne (Vault), krótki TTL, najmniejszy przywilej dla aplikacji.
Obserwowalność, SLO i odpowiedź
Mierniki (minimalny zestaw):- Uwierzytelnianie i autoryzacja sukces (%), p95 PDP czas decyzji, p95 TLS-uścisk dłoni.
- Odsetek żądań zablokowanych przez politykę (anomalie/fałszywe).
- Dostępność brokerów ZTNA i kontrolera Mesh.
- Odsetek zgodnych urządzeń i trendów.
- "Dostępność ZTNA ≥ 99. 95 %/miesiąc; Decyzja p95 authZ ≤ 50 м"
- "Odsetek wniosków o mTLS ≥ 99. 9%».
- "Nie więcej niż 0. 1% nieprawdziwych awarii dostępu/dzień"
Alarting: wybuchy zaprzeczenia, degradacja uścisków dłoni p95, nieprawidłowe łańcuchy, spadek udziału urządzeń zgodnych z wymogami, anomalie geografii/ASN.
Przejście z obwodu do Zero Trust: mapa drogowa
1. Inwentaryzacja: aplikacje, przepływy danych, konsumenci, czułość (PII/karta/wypłaty).
2. Identyfikacja i MSZ: SSO i MSZ odporne na phishingi dla wszystkich.
3. Kontekst urządzenia: MDM/EDR, podstawowe zasady zgodności, blok niezgodny.
4. Mikrosegmentacja ścieżek priorytetowych: płatności, zaplecze, administrator; Wprowadź mTLS.
5. ZTNA dla dostępu użytkownika: publikowanie aplikacji za pośrednictwem serwera proxy, usuwanie „szerokiej sieci VPN”.
6. Polityka ABAC: scentralizowany PDP, zasady deklaracyjne, audyt.
7. Rozszerzenie siatki serwisowej: S2S mTLS, polityka L7, telemetria.
8. Automatyzacja i SLO: alert, testy polityki (political CI), dni gry "co jeśli IdP nie jest dostępny? ».
Specyfika dla iGaming/fintech
Sztywna segmentacja domen: płatności/PII/zwalczanie nadużyć finansowych/treści - odrębne obwody i polityki; dostęp tylko przez ZTNA.
Interakcja z PSP/bankami: zezwala na listę według ASN/zakresów, mTLS do punktów końcowych PSP, monitorowania czasu do portfela i awarii authZ.
Dostawcy i partnerzy treści: tymczasowe dostęp JIT API, krótkie tokeny TTL, audyty integracyjne.
Zgodność: PCI DSS/RODO - minimalizacja danych, DLP/pseudonimizacja, rejestrowanie dostępu do tabel wrażliwych.
Bezpieczeństwo łańcucha dostaw i CI/CD
Podpisy artefaktowe (SLSA/Origin): podpisy kontenerowe (cosign), Polityka przyjmowania w K8s.
SBOM i luki: generacja SBOM (CycloneDX), brama polityki w rurociągu.
Sekrety w CI: Federacja OIDC do Cloud KMS; zakaz stosowania kluczy statycznych.
Obroty: częste, automatyczne; przymusowe odwołanie incydentów.
Powszechne błędy i anty-wzory
„ZTNA = nowa sieć VPN”: publikowanie sieci zamiast aplikacji nie jest Zero Trust.
Brak sprawdzenia urządzenia: MFA jest, ale zainfekowane/zakorzenione urządzenia uzyskują dostęp.
Pojedynczy super użytkownik: brak JIT i oddzielnych ról.
Zasady w kodzie serwisowym: audyt centralny/aktualizacja nie jest możliwa.
mTLS częściowy: część usług bez mTLS → „nieszczelna” pętla.
Zero UX: zbędne żądania MFA, brak SSO; wynik - odporność na polecenia.
Mini-przewodnik do wyboru technologii
Dostęp do użytkownika: ZTNA/SDP broker + IdP (OIDC, FIDO2 MFA).
Bezpieczeństwo eksploatacyjne: service-mesh (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID lub skarbiec PKI z krótkim TTL.
Politycy: OPA/Rego lub Cedar; przechowywać w Git, sprawdź w CI (policy-tests).
Dzienniki i telemetria: OpenTelemetry → scentralizowana analiza, wykrywanie anomalii.
Konfiguracje próbki (fragmenty)
Wysłannik (wzajemne TLS między usługami)
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: dostęp do raportów tylko z „finansowania”, z urządzeń zgodnych, w godzinach pracy
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
}Lista kontrolna realizacji zero zaufania
1. Włącz usługę SSO i FIDO2 MFA dla wszystkich użytkowników i administratorów.
2. Wprowadź postawę urządzenia (MDM/EDR) z blokadą niezgodną z wymogami.
3. Transfer dostępu użytkownika do ZTNA (per-app), pozostaw VPN tylko dla wąskich kanałów S2S.
4. Wewnątrz - domyślnie mTLS + certyfikaty krótkotrwałe.
5. Scentralizować zasady (PDP/OPA), przechowywać w Git, testować w CI.
6. Domeny wrażliwe segmentu (płatności/PII/zaplecze) i ograniczają wschodnio-zachodnie.
7. Skonfiguruj telemetrię, SLO i alert na auth/authZ, mTLS share, sygnały postawy.
8. Prowadzenie „dni gry” (awaria IdP, wyciek klucza, kropla maklera) i naprawić SOP/rolki.
NAJCZĘŚCIEJ ZADAWANE PYTANIA
Czy Zero Trust całkowicie zastępuje sieć VPN?
Dla dostępu użytkownika - tak, na korzyść ZTNA. W przypadku S2S pni, VPN/IPsec może pozostać, ale z mTLS ponad i surowe polityki.
Czy ZT może pogorszyć UX?
Jeśli bezmyślnie. Dzięki FIDO2 SSO +, adaptacyjny MFA i dostępowi do aplikacji, UX zazwyczaj się poprawia.
Czy konieczne jest wprowadzenie siatki serwisowej?
Nie zawsze. Ale dla dużego środowiska mikroservice, siatka radykalnie upraszcza mTLS/polityka/telemetria.
Razem
Zero Trust nie jest produktem, ale dyscypliną architektoniczną: tożsamość jako nowy obwód, kontekst urządzenia, dostęp do aplikacji (ZTNA), mikrosegmentacja i mTLS wszędzie, scentralizowane zasady i wymierna niezawodność. Podążając za mapą drogową i listą kontrolną, zmniejszysz powierzchnię ataku, przyspieszysz audyt i uzyskasz trwałe bezpieczeństwo bez „domyślnego zaufania”.