Arhitectura Zero Trust

Scurt rezumat

Zero Trust (ZT) este un model de securitate în care perimetrul rețelei nu mai este considerat o zonă de încredere. Fiecare cerere (user→app, service→service, device→network) este autentificată, autorizată și criptată în mod explicit, ținând cont de semnalele contextuale (identitate, starea dispozitivului, locație, risc, comportament). Scopul este de a minimiza raza exploziei, de a reduce riscul de mișcare laterală și de a simplifica conformitatea.

Fundamentele Zero Trust

1. Nu există încredere explicită - încrederea nu este moștenită din rețeaua/VPN/ASN.
2. Accesul este minimul necesar: politica „pentru a furniza doar ceea ce este necesar acum”.
3. Verificare continuă: sesiunile și jetoanele sunt reevaluate în mod regulat pentru risc și context.
4. Presupunerea compromisului: segmentare, observabilitate, izolare rapidă și rotații cheie.
5. Criptare peste tot: TLS 1. 2+/1. 3 și mTLS în interiorul planurilor de date, protejate DNS, secrete în KMS/HSM.

Domenii ţintă peisaj şi control

Identitate: om (IdP: SSO, MFA, chei de acces/FIDO2), utilaje (SPIFFE/SVID, x509/mTLS).
Dispozitive: respectarea politicilor (MDM/EDR, disc criptat, patch-uri, jailbreak/root - interzis).
Rețea: microsegmentare L3/L7, gateway-uri ZTNA/SDP, plasă de serviciu (Envoy/Istio/Linkerd).
Aplicații/API-uri: mTLS, OIDC/JWT, semnături de cerere (HMAC), limite de rată, DLP/mascare.
Date: clasificare (Public/Confidential/Restricted), tokenizare/criptare la nivel de teren.
Observabilitate: jurnale de autentificare/autorizare centralizate, analiză comportamentală, SLO/SLA.

Arhitectura de referință (defalcată pe planuri)

Planul de control: IdP/CIAM, PDP/PEP (OPA/Envoy), cataloage de politici, PKI/CA, calificare dispozitiv.
Data Plane: acces proxy (ZTNA), proxy sidecar (Envoy) pentru politica mTLS și L7, gateway-uri de service GW/API-uri.
Management Plane: catalog de servicii, CMDB, CI/CD, management secret (Vault/KMS), audit centralizat.

1. Identificarea (SSO + rezistent la phishing MFA) → 2) Evaluarea dispozitivului (MDM postură) → 3) proxy ZTNA stabilește mTLS la aplicare → 4) PDP (politici) ia decizia pe baza atributelor (ABAC/RBAC) → 5) reevaluarea continuă a riscului (timp, geo, anomalii)

Identitate și autorizare

IdP/SSO: OIDC/SAML, MFA implicit, de preferință FIDO2 (chei de acces).
RBAC/ABAC: roluri + atribute contextuale (starea dispozitivului, departamentul, profilul de risc).
Acces Just-In-Time (JIT): privilegii temporare cu revocare automată; spargerea sticlei - strict reglementată.
mTLS pentru mașini: SPIFFE/SVID sau PKI intern cu certificate de scurtă durată; eliberare rotativă automată.

Dispozitive și context

postură: OS/EDR versiune, incluse disk-criptare, firewall; neconforme → acces minim sau bloc.
Atestat: identitate dispozitiv + atestate semnat (MDM/Endpoint).
Restricții de rețea: bloc de tuneluri terțe părți, DNS corporative forțate, protecție împotriva scurgerilor DNS/WebRTC.

Networking și microsegmentare

Eliminarea VLAN-urilor „plate”: în schimb, a segmentelor/VRF și a politicii privind L7.
Service Mesh: proxy-urile laterale furnizează mTLS, autorizarea politicii (OPA/EnvoyFilter), telemetrie.
ZTNA/SDP: accesul la o anumită aplicație, nu la rețea; kliyent↔broker↔app, politica în PDP.
Acces la distanță: înlocuirea VPN-ului „gros” cu un proxy al aplicației; tunelurile de rezervă sunt limitate la rute/porturi.

Politici și motor de soluție

PDP/PEP: Punct de decizie privind politica (OPA/Styra, Cedar и пр.) + Punct de aplicare a politicii (trimis/Istio/Gateway).
Model de politică: reguli declarative (Rego/Cedar), atribute statice și contextuale, evaluarea riscurilor.

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
}

Trace solutions: log 'input '/' result '/' explice' pentru audit.

Criptare implicită și încredere

TLS 1. 2+/1. 3 pretutindeni, suite de cifruri stricte, HSTS, capse OCSP.
mTLS în interior: servis↔servis numai prin certificate reciproce; chei pe termen scurt (ore/zile).
Secrete: KMS/HSM, secrete dinamice (Vault), TTL scurt, cel mai puțin privilegiu pentru aplicații.

Observabilitate, SLO și răspuns

• Succes de autentificare și autorizare (%), timp de decizie p95 PDP, p95 TLS-strângere de mână.
• Procentul cererilor blocate de politică (anomalii/false).
• Disponibilitatea brokerilor ZTNA și a controlerului Mesh.
• Proporția de dispozitive și tendințe conforme.

• "ZTNA ≥ 99 disponibilitate. 95 %/lună; decizia p95 authZ ≤ 50 мс"
• "Procentul cererilor cu mTLS ≥ 99. 9%».
• "Nu mai mult de 0. 1% false eșecuri de acces/zi"

Alarmare: explozii de negare, degradarea strângerilor de mână p95, lanțuri nevalide, scăderea proporției de dispozitive conforme, anomalii geografice/ASN.

Trecerea de la perimetru la Zero Trust: o foaie de parcurs

1. Inventar: aplicații, fluxuri de date, consumatori, sensibilitate (PII/card/plăți).
2. Identitate și MFA: SSO și MFA rezistent la phishing pentru toți.
3. Contextul dispozitivului: MDM/EDR, politici de conformitate de bază, bloc neconform.
4. Microsegmentarea căilor prioritare: plăți, back office, admin; Introduceți mTLS.
5. ZTNA pentru accesul utilizatorilor: publicarea aplicațiilor printr-un proxy, eliminați „VPN-ul larg”.
6. Politici ABAC: PDP centralizat, reguli declarative, audit.
7. Extensie plasă de serviciu: S2S mTLS, politica L7, telemetrie.
8. Automatizare și SLO: alertă, teste de politică (CI politic), zile de joc "ce se întâmplă dacă IdP nu este disponibil? ».

Specificitate pentru iGaming/fintech

Segmentarea rigidă a domeniului: plăți/PII/antifraudă/conținut - perimetre și politici separate; acces numai peste ZTNA.
Interacțiunea cu PSP/bănci: permiteți lista după ASN/intervale, mTLS până la punctele finale PSP, monitorizarea timpului până la portofel și eșecurile authZ.
Furnizori de conținut și parteneri: accesări temporare JIT API, jetoane TTL scurte, audituri de integrare.
Conformitate: PCI DSS/GDPR - minimizarea datelor, DLP/pseudonimizare, logarea acceselor la tabele sensibile.

Securitatea lanțului de aprovizionare și CI/CD

Semnături artefact (SLSA/Proveniență): semnături container (cosign), Politica de admitere în K8s.
SBOM și vulnerabilități: generarea SBOM (CycloneDX), politica-poarta în conducte.
Secretele în CI: Federația OIDC la Cloud KMS; interzicerea cheilor statice.
Rotații: frecvente, automate; revocarea forţată a incidentelor.

Bug-uri comune și anti-modele

„ZTNA = nou VPN”: publicarea unei rețele în loc de aplicații nu este Zero Trust.
Nici o verificare dispozitiv: MFA este, dar dispozitive infectate/înrădăcinate obține acces.
Un singur super utilizator: lipsa de JIT și roluri separate.
Politici în codul serviciului: auditul central/actualizarea nu este posibilă.
mTLS parțială: o parte a serviciilor fără mTLS → o buclă „scurgere”.
Zero UX: cereri MFA redundante, fără SSO; rezultat - rezistență la comenzi.

Mini-ghid pentru alegerea tehnologiilor

Acces utilizator: ZTNA/SDP broker + IdP (OIDC, FIDO2 MFA).
Securitate în serviciu: service-mesh (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID sau Vault PKI cu TTL scurt.
Politicieni: OPA/Rego sau Cedar; stocați în Git, verificați în CI (teste de politică).
Busteni si telemetrie: OpenTelemetry → analiza centralizata, detectie anomalii.

Configurații de probă (fragmente)

Trimisul (mutual-TLS între servicii)

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: true

OPA/Rego: accesul la rapoarte numai de la „finanțe”, de la dispozitive conforme, în timpul orelor de lucru

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 de verificare a implementării Zero Trust

1. Activați SSO și FIDO2 MFA pentru toți utilizatorii și administratorii.
2. Introduceți postura dispozitivului (MDM/EDR) cu blocare neconformă.
3. Transferați accesul utilizatorilor la ZTNA (per-app), lăsați VPN numai pentru canale de S2S înguste.
4. În interior - mTLS în mod implicit + certificate de scurtă durată.
5. Centralizați politicile (PDP/OPA), stocați în Git, testați în CI.
6. Segment domenii sensibile (plăţi/PII/back office) şi restricţiona est-vest.
7. Configurați telemetrie, SLO și alertă pe auth/authZ, mTLS share, semnale de postură.
8. Efectuați „zile de joc” (eșec IdP, scurgere de chei, cădere broker) și fixați SOPs/rollback.

ÎNTREBĂRI FRECVENTE

Este Zero Trust înlocuirea VPN în întregime?
Pentru accesul utilizatorilor - da, în favoarea ZTNA. Pentru trunchiurile S2S, VPN/IPsec poate rămâne, dar cu mTLS peste și politici stricte.

Ar putea ZT face UX mai rău?
Dacă fără gânduri. Cu SSO + FIDO2, adaptive MFA, și acces per-app, UX îmbunătățește de obicei.

Este necesar să introduceți o plasă de serviciu?
Nu întotdeauna. Dar pentru un mediu microservice mare, plasa simplifică radical mTLS/policy/telemetry.

Total

Zero Trust nu este un produs, ci o disciplină arhitecturală: identitatea ca un nou perimetru, contextul dispozitivului, accesul la aplicație (ZTNA), microsegmentarea și mTLS peste tot, politicile centralizate și fiabilitatea măsurabilă. Urmând foaia de parcurs și lista de verificare, veți reduce suprafața atacului, veți accelera auditul și veți obține o securitate durabilă fără „încredere implicită”.