Architettura zero trust

Breve riepilogo

Zero Trust (ZT) è un modello di sicurezza in cui il perimetro di rete non è più considerato un'area di fiducia. Ogni richiesta (user→app, service→service, device→network) viene espressamente autenticata, autorizzata e crittografata in base ai segnali contestuali (identità, stato del dispositivo, posizione, rischio, comportamento). Obiettivo: ridurre al minimo i blast radius, ridurre il rischio di lateral movement e semplificare la compilazione.

Principi di base Zero Trust

1. Non c'è alcuna fiducia: la fiducia non viene ereditata dalla rete/VPN/ASN.
2. L'accesso è minimo: «Fornire solo ciò che serve».
3. Verifica continua: sessioni e token vengono sovrastimati regolarmente per rischio e contesto.
4. Presupposto di compromissione: segmentazione, osservabilità, containment rapido e rotazione delle chiavi.
5. Crittografia ovunque: TLS 1. 2+/1. 3 e mTLS all'interno dei DNS protetti, i segreti in KMS/HSM.

Paesaggio di destinazione e domini di controllo

Identità: persone (IdP: SSO, MFA, passkeys/FIDO2), macchine (SPIFFE/SVID, x509/mTLS).
Dispositivi: conformità alle regole (MDM/EDR, disco crittografato, patch, jailbreak/root - non consentito).
Rete: microsegmentazione L3/L7, gateway ZTNA/SDP, servizio-mesh (Avvoy/Istio/Linkerd).
Applicazioni/API: mTLS, OIDC/JWT, firme di query (HMAC), rate limits, DLP/Masking.
Dati: classificazione (Public/Confidential/Restringted), tornitura/crittografia a livello di campo.
Osservabilità: logi di autenticazione/autorizzazione centralizzati, analisi comportamentale, SLO/SLA.

Architettura arbitrale (nel taglio dei piani)

Control Plane: IdP/CIAM, PDP/PEP (OPA/Avvoy), directory di regole, PKI/CA, certificazione dei dispositivi.
Data Plane: accesso proxy (ZTNA), sidecar proxy (Avvoy) per il mTLS e il criterio L7, gateway di assistenza/API GW.
Gestione Plane: catalogo dei servizi, CMDB, CI/CD, gestione dei segreti (Vault/KMS), controllo centralizzato.

1. Identificazione (SSO + phishing-resistant MFA) 2) La valutazione del dispositivo (MDM posture) 3) del proxy ZTNA stabilisce l'applicazione 4) PDP (policy) per decidere in base agli attributi (ABAC/RBAC) 5) la rivalutazione continua del rischio (tempo, geo, anomalie).

Identità e autorizzazioni

IdP/SSO: OIDC/SAML, MFA predefinito, preferibilmente FIDO2 (passkeys).
RBAC/ABAC: ruoli + attributi del contesto (stato del dispositivo, reparto, profilo a rischio).
Accesso Just-In-Time (JIT) - Privilegi temporanei con richiamo automatico; break-glass - rigorosamente regolamentato.
mTLS per macchine SPIFFE/SVID o PKI interno con certificati di breve durata rotazione automatica.

Dispositivi e contesto

Controllo corrispondenza (posture) - Versione OS/EDR, unità encripted attivata, firewall; no-compliant → l'accesso al minimo o al blocco.
Certificazione: device identity + signed attribations (MDM/Endpoint).
Vincoli di rete: unità di tunnel di terze parti, DNS aziendale forzato, protezione contro le DNS/WebRTC.

Rete e microsegmentazione

Rifiuta VLAN piatte, invece, segmenti/VRF e criteri L7.
Servizio Mesh: sidecar proxy forniscono mTLS, autorizzazioni di criteri (OPA/EnvoyFilter), telemetria.
ZTNA/SDP: accesso a un'applicazione specifica, non a una rete; kliyent↔broker↔app, politica nel PDP.
Remote Access - Sostituisce il VPN «grasso» con il proxy app; tunnel fallback limitati a percorsi/porte.

Regole e motore delle soluzioni

PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
Modello di criterio: regole dichiarative (Rego/Cedar), attributi statici e contestuali, valutazione del rischio.

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
}

Traccia soluzioni: logica «input »/« result »/« explain» per il controllo.

Crittografia e fiducia predefinite

TLS 1. 2+/1. 3 ovunque, cifranti rigorosi, HSTS, OCSP stapling.
mTLS all'interno: servis↔servis solo con certificati reciproci; chiavi di breve durata (ore/giorni).
I segreti sono KMS/HSM, dynamic secret (Vault), TTL brevi, least-private per le applicazioni.

Osservabilità, SLO e risposta

• Autenticazione e autorizzazione riuscita (%), p95 tempo di decisione PDP, p95 TLS-handshake.
• Percentuale di richieste bloccate dal criterio (anomalie/false).
• Disponibilità dei broker ZTNA e del controller Mesh.
• Quota di dispositivi compliant e trend.

• «Disponibilità ZTNA» 99. 95 %/mes; p95 authZ decision ≤ 50 мс».
• «Percentuale di richieste di 99». 9%».
• «Non più». 1% di falsi errori di accesso/giorno".

Alarting: picchi deny, degrado p95 strette di mano, catene nevalidi, calo della quota di dispositivi compliant, anomalie geografiche/ASN.

Passaggio dal perimetro a Zero Trust: road map

1. Inventario: applicazioni, flussi di dati, consumatori, sensibilità (PII/carte/pagamenti).
2. Identità e MFA: SSO e phishing-resistant MFA per tutti.
3. Contesto dispositivi: MDM/EDR, criteri di base di conformità, blocco no-compliant.
4. Microsegmentazione dei percorsi prioritari: pagamenti, back office, adattamento; Immettere un mTLS.
5. ZTNA per l'accesso utente: pubblicazione delle applicazioni tramite proxy, rimozione «VPN ampio».
6. Criteri ABAC: PDP centralizzato, regole dichiarative, controllo.
7. Estensione a servizio-mesh: S2S mTLS, politica L7, telemetria.
8. Automazione e SLO: alerting, test di policy (CI), game days "e se non fosse disponibile? ».

Particolare per iGaming/Fintech

Segmentazione rigida dei domini: pagamenti/PII/antifrode/contenuti - perimetri e politiche separati; disponibile solo con ZTNA.
Interazione con PSP/banche: allow-list su ASN/intervalli, accesso a PSP-endpoint, monitoraggio Time-to-Wallet e guasti di .
Fornitori di contenuti e partner: disponibilità temporanea JIT API, token TTL brevi, controllo delle integrazioni.
Compagine: PCI DSS/GDPR - Minimizzazione dei dati, DLP/alias, registrazione delle disponibilità a tabelle sensibili.

Sicurezza delle catene di fornitura e CI/CD

Etichette manufatti (SLSA/Provenance) - Firma contenitori (cosign), criterio Admision in K8s.
SBOM e vulnerabilità: generazione di SBOM (CycloneDX), policy-gate in pipline.
I segreti in CI: la Federazione OIDC ai cloud KMS; Divieto delle chiavi statiche.
Rotazioni frequenti, automatiche; revoke forzato per gli incidenti.

Errori tipici e anti-pattern

«ZTNA = nuovo VPN» - La pubblicazione della rete al posto delle applicazioni non è Zero Trust.
Nessun controllo dei dispositivi: l'MFA è disponibile, ma i dispositivi infetti/rotati sono accessibili.
Un unico super utente è l'assenza di JIT e ruoli separati.
Regole nel codice dei servizi: impossibile verificare/aggiornare centralmente.
Parte parziale, parte dei servizi senza are il tracciato «buco».
Zero UX: richieste MFA ridondanti, assenza di SSO; il risultato è resistenza ai comandi.

Mini-hyde per la scelta della tecnologia

Accesso utenti: ZTNA/SDP broker + IdP (OIDC, FIDO2 MFA).
Sicurezza interna: servizio-mesh (Istio/Linkerd) + OPA/Avvoy authZ.
PKI: SPIFFE/SVID o Vault PKI con TTL brevi.
Regole: OPA/Rego o Cedar; memorizzare in Git, controllare in CI (policy-test).
e telemetria, analisi centralizzate, rilevamento delle anomalie.

Esempi di configurazione (sezioni)

Avvoy (mutual-TLS tra i servizi)

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 - Accesso ai report solo da «finance», da dispositivi compliant, durante le ore lavorative

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
}

Assegno foglio di implementazione Zero Trust

1. Abilita SSO e FIDO2 MFA per tutti gli utenti e ammiragli.
2. Inserisci device posture (MDM/EDR) con blocco no-compliant.
3. Tradurre l'accesso utente su ZTNA (per-app), lasciare VPN solo per i canali S2S stretti.
4. All'interno ci sono le mTLS predefinite + certificati di vita corta.
5. Centralizza criteri (PDP/OPA), memorizza in Git, prova in CI.
6. Segmentare i domini sensibili (pagamenti/PII/back office) e limitare l'east-west.
7. Regolare la telemetria, la SLO e l'alerting per la auth/authZ, la parte mTLS, i segnali posture.
8. Effettua «game days» (guasto, perdita delle chiavi, caduta del broker) e fissa i rimborsi SOP.

FAQ

Zero Trust sostituisce completamente VPN?
Per l'accesso utente, sì, a favore di ZTNA. Per le autostrade S2S, VPN/IPsec può rimanere, ma con regole rigide sopra e sopra.

ZT può peggiorare UX?
Se non è ragionevole. Con SSO + FIDO2, MFA adattivo e per-app, l'accesso UX è generalmente migliorato.

È necessario implementare il servizio-mesh?
Non sempre. Ma per un grande ambiente di microservizi, mesh semplifica radicalmente mTLS/policy/telemetria.

Totale

Zero Trust non è un prodotto, ma una disciplina architettonica: identità come un nuovo perimetro, contesto dei dispositivi, accesso alle applicazioni (ZTNA), microsegmentazione e mTLS dappertutto, politiche centralizzate e affidabilità misurabile. Seguendo la road map e il foglio di lavoro, si riduce la superficie di attacco, si accelera il controllo e si ottiene una protezione sostenibile senza «credibilità predefinita».