Cloud on My personal blog

Zero Trust nel cloud

Tue, 08 Sep 2026 09:00:00 +0200

Perché conta

Il cloud è il contesto dove lo Zero Trust non è una scelta architetturale ma la condizione nativa: non c’è un perimetro fisico da difendere, non c’è un “dentro”. Ci sono identità, API e configurazioni. Una risorsa cloud si raggiunge e si controlla tramite chiamate API autenticate da credenziali; chi ha la credenziale giusta fa l’azione, da ovunque. Questo rende i principi della serie — identità forte, minimo privilegio, verifica continua — letteralmente il modello di sicurezza del cloud, non un’aggiunta.

Il perimetro è l’IAM

Nel cloud, il piano di controllo è l’IAM del provider. Ogni azione — leggere un bucket, avviare una macchina, cancellare un database — è una chiamata API autorizzata da una policy IAM. Il “firewall” più importante non è di rete: è chi può fare cosa.

  flowchart LR
    P[Principal:<br/>utente o workload] -->|chiamata API| API[API del cloud]
    API --> IAM{Policy IAM}
    IAM -->|consenti/nega| RES[Risorsa cloud]
    SIG[Identità + ruolo + condizioni] --> IAM
    style IAM fill:#fde2e4,stroke:#e63946

È lo schema PDP/PEP: l’IAM del provider è insieme il motore di decisione e l’enforcement, per ogni API. Governare bene l’IAM è fare Zero Trust nel cloud.

Identità dei workload, non chiavi statiche

L’errore cloud più comune e pericoloso è la chiave statica: credenziali a lunga vita incollate nel codice o in una variabile d’ambiente, che finiscono in un repository pubblico e vengono abusate. Lo Zero Trust nel cloud le elimina a favore di identità di workload native:

1
2
3

# anti-pattern vs Zero Trust
chiave statica:   ACCESS_KEY + SECRET nel codice  → ruba una volta, usa per sempre
ruolo/identità:   il workload assume un ruolo      → credenziali temporanee, auto-rinnovate

Una macchina o un container assume un ruolo e riceve credenziali temporanee che si rinnovano da sole — la versione cloud-native dell’identità di workload vista con SPIFFE/SPIRE. Nessun segreto da proteggere, rotazione automatica, furto a vita breve.

Minimo privilegio, sul serio

Le policy IAM tendono a gonfiarsi: *:* “per far funzionare le cose”, permessi aggiunti e mai tolti — il privilege creep in salsa cloud. Lo Zero Trust esige policy minime, basate sull’uso reale (gli strumenti del provider mostrano i permessi effettivamente usati vs concessi), e condizioni sulle policy: solo da certe reti, solo con MFA, solo su certe risorse.

CSPM: la postura delle risorse

Come i dispositivi hanno una postura, le risorse cloud hanno una configurazione che può essere sicura o no: un bucket pubblico, un database senza cifratura, un gruppo di sicurezza aperto al mondo. Il CSPM (Cloud Security Posture Management) analizza di continuo le configurazioni contro le best practice e segnala le derive. È la verifica continua applicata alla postura dell’infrastruttura, non degli endpoint.

Multi-cloud: identità federata

Con più provider, la frammentazione delle identità è il rischio. Lo Zero Trust spinge verso l’identità federata: un IdP centrale da cui i workload e gli utenti ottengono accesso ai vari cloud via federazione (OIDC), invece di silos di credenziali per provider. Un punto solo dove applicare policy e revocare.

Lab

Con l’ambiente free-tier di un provider cloud (o LocalStack per AWS in locale):

Create un ruolo con permessi minimi per un compito specifico (es. leggere un solo bucket).
Fate assumere il ruolo a un workload e verificate che riceva credenziali temporanee, non una chiave statica.
Provate un’azione fuori dai permessi del ruolo: deve essere negata.
Eseguite uno strumento CSPM open source (es. Prowler, ScoutSuite) e leggete i rilievi sulle configurazioni.

Domanda: se tutto nel cloud passa dall'IAM del provider, non sto semplicemente delegando la mia sicurezza al provider e sperando che faccia bene?

Qui aiuta il modello di responsabilità condivisa, che divide nettamente i compiti. Il provider è responsabile della sicurezza del cloud — l'infrastruttura fisica, l'hypervisor, la disponibilità del servizio IAM — e su quello sì, ci si fida (e lo si sceglie con cura, come un IdP). Ma la sicurezza nel cloud — quali policy IAM scrivete, se usate chiavi statiche o ruoli temporanei, se un bucket è pubblico, se attivate l'MFA — è interamente vostra, e il provider non la farà al posto vostro. La stragrande maggioranza delle brecce cloud non nasce da un fallimento del provider ma da una cattiva configurazione del cliente: una policy troppo larga, una chiave trapelata, un servizio esposto. Delegare all'IAM del provider non significa delegare le decisioni, significa avere un motore su cui applicarle — e quelle decisioni, cioè il minimo privilegio e la postura, restano il vostro lavoro. Il CSPM esiste proprio per verificare che lo stiate facendo bene.

Conclusione

Nel cloud lo Zero Trust è il modello nativo: niente perimetro, solo identità, API e configurazioni. Significa governare l’IAM come piano di controllo, sostituire le chiavi statiche con identità di workload temporanee, imporre il minimo privilegio con condizioni, e sorvegliare la postura delle risorse con il CSPM. La responsabilità della configurazione resta vostra. Resta un’ultima frontiera da coprire: i dati stessi, oggetto dello Zero Trust del prossimo capitolo.

Service mesh e Zero Trust

Tue, 11 Aug 2026 09:00:00 +0200

Perché conta

I capitoli 11 e 12 hanno dato ai servizi un’identità e un modo per autenticarsi con mTLS. Ma chiedere a ogni servizio di implementare mTLS, rotazione dei certificati, policy e telemetria nel proprio codice è irrealistico: ogni team lo farebbe in modo diverso, e metà lo farebbe male. Il service mesh risolve spostando tutta questa logica fuori dall’applicazione, in un sidecar: lo Zero Trust tra servizi diventa infrastruttura, trasparente al codice.

L’idea: il sidecar

In un service mesh, accanto a ogni servizio gira un proxy sidecar (es. Envoy) che intercetta tutto il traffico in entrata e in uscita. Il servizio crede di parlare in chiaro con localhost; è il sidecar a stabilire mTLS, applicare le policy e raccogliere le metriche.

  flowchart LR
    subgraph PodA[Pod A]
        A[Servizio A] <-->|localhost| PA[Sidecar]
    end
    subgraph PodB[Pod B]
        PB[Sidecar] <-->|localhost| B[Servizio B]
    end
    PA <==>|mTLS automatico| PB
    CP[Control plane<br/>PDP: policy + identità] -.configura.-> PA
    CP -.configura.-> PB
    style CP fill:#fde2e4,stroke:#e63946

Il control plane del mesh è il PDP: distribuisce identità e policy. I sidecar sono i PEP: applicano a ogni connessione. È lo schema Zero Trust, realizzato senza toccare il codice dei servizi.

Cosa dà al modello Zero Trust

mTLS automatico e universale: il mesh emette, distribuisce e ruota i certificati (spesso basati su SPIFFE) e cifra tutto il traffico est-ovest senza che gli sviluppatori facciano nulla. Il “costo dei certificati” del capitolo mTLS sparisce nell’infrastruttura.
Autorizzazione per identità: policy come “il servizio ordini può chiamare pagamenti solo sulla rotta /charge” si scrivono nel control plane e valgono per tutte le istanze.
Osservabilità uniforme: ogni sidecar produce metriche, log e tracce coerenti, alimentando la telemetria necessaria alla verifica continua.

# Istio AuthorizationPolicy: pagamenti accetta solo da 'ordini', solo POST /charge
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata: { name: pagamenti-allow-ordini }
spec:
  selector: { matchLabels: { app: pagamenti } }
  rules:
    - from: [{ source: { principals: ["spiffe://azienda/ns/ordini/sa/ordini"] } }]
      to:   [{ operation: { methods: ["POST"], paths: ["/charge"] } }]

Le righe evidenziate sono una policy Zero Trust completa tra servizi: chi (identità SPIFFE di ordini), cosa (POST su /charge), tutto il resto negato.

Il prezzo: complessità

Il service mesh non è gratis. Aggiunge un proxy per ogni pod (risorse, latenza), un control plane da gestire, e una curva di apprendimento ripida. Per poche manciate di servizi può essere più peso che beneficio. Le alternative emergenti basate su eBPF (es. Cilium) spostano parte del lavoro nel kernel, riducendo l’overhead dei sidecar. La scelta dipende dalla scala: il mesh conviene quando i servizi sono tanti e la gestione manuale di mTLS e policy è già un problema.

Lab

In un cluster di test con Linkerd (più semplice) o Istio:

Installate il mesh e iniettate i sidecar in due servizi di test.
Verificate che il traffico tra loro sia automaticamente in mTLS (ispezionate i certificati o le metriche del mesh), senza aver toccato il codice.
Applicate una policy di autorizzazione che consenta solo una rotta da un solo servizio di origine.
Provate una chiamata non autorizzata e osservatela bloccata dal sidecar.

Domanda: il service mesh fa le stesse cose della microsegmentazione e dello ZTNA; non è ridondanza?

Si sovrappongono in parte, ma operano a livelli diversi e complementari. La microsegmentazione di rete (NetworkPolicy, livello 3/4) decide se due workload possono scambiarsi pacchetti: è un controllo grossolano e robusto, indipendente dall'applicazione. Il service mesh lavora al livello 7 e decide cosa può fare una connessione già permessa: quale metodo HTTP, quale percorso, con quale identità provata da mTLS — più cifratura e telemetria uniformi. Lo ZTNA, ancora diverso, governa l'accesso nord-sud degli utenti alle applicazioni. Difesa in profondità: la NetworkPolicy è il muro grezzo, il mesh è il controllo fine sul traffico ammesso, lo ZTNA è la porta per gli utenti. Usarli insieme non è ridondanza, è applicare lo stesso principio — verificare ogni accesso — a granularità e direzioni diverse. La ridondanza vera sarebbe affidarsi a uno solo e sperare che copra tutto.

Conclusione

Il service mesh sposta mTLS, autorizzazione per identità e telemetria dal codice dei servizi a un sidecar governato da un control plane: il PDP/PEP dello Zero Trust tra servizi, trasparente agli sviluppatori. Il prezzo è la complessità, giustificata dalla scala. Finora le policy le abbiamo descritte a parole; il prossimo capitolo le rende codice versionato e verificabile con OPA.

SASE e Zero Trust: la sicurezza che segue l'utente

Tue, 07 Jul 2026 09:00:00 +0200

Perché conta

Lo ZTNA risolve l’accesso alle applicazioni, ma un’azienda ha bisogno anche di navigare in sicurezza, filtrare il traffico, proteggere i dati verso il SaaS. Se utenti e risorse sono ovunque, far passare tutto il traffico da un data center centrale (per “ispezionarlo”) è assurdo e lento. Il SASE (Secure Access Service Edge) sposta rete e sicurezza nel cloud, al bordo vicino all’utente, e include lo ZTNA come tassello di accesso. È lo Zero Trust che segue l’utente invece di aspettarlo al perimetro. Per il quadro generale del SASE si veda anche l’articolo dedicato.

Il problema del “tromboning”

Con le risorse nel cloud e gli utenti a casa, il modello tradizionale fa un giro assurdo: l’utente remoto si collega in VPN al data center, da lì esce verso il SaaS, e la risposta rifà il percorso al contrario. Questo “tromboning” aggiunge latenza e carica un data center che non è più il centro di nulla.

  flowchart LR
    U[Utente remoto] -->|VPN| DC[Data center]
    DC -->|ispezione| SaaS[(SaaS / Cloud)]
    SaaS --> DC --> U
    style DC fill:#fde2e4,stroke:#e63946

Il SASE elimina il giro: l’utente si connette al punto di presenza cloud più vicino, dove avvengono ispezione e policy, e va direttamente alla risorsa.

I componenti del SASE

Il SASE unisce funzioni di rete e di sicurezza erogate come servizio cloud. Il lato sicurezza è spesso chiamato SSE (Security Service Edge):

Componente	Funzione
ZTNA	accesso Zero Trust alle applicazioni (cap. 07)
SWG (Secure Web Gateway)	filtra la navigazione, blocca malware e siti pericolosi
CASB (Cloud Access Security Broker)	controlla l’uso del SaaS, applica policy sui dati
FWaaS (Firewall as a Service)	firewall nel cloud
DLP	previene la fuga di dati sensibili (cap. 18)
SD-WAN	il lato rete: instrada il traffico in modo ottimale

Dove sta lo Zero Trust

Il SASE non è lo Zero Trust: è un modello di erogazione (sicurezza come servizio al bordo) in cui lo Zero Trust è il principio di accesso. Il collante è l’identità: ogni componente — dallo ZTNA al SWG — applica policy basate su chi è l’utente e in che stato è il dispositivo, non su dove si trova. Il SASE, in pratica, mette i PEP nel cloud, al bordo, invece che nel data center.

  flowchart LR
    U[Utente ovunque] --> POP["POP cloud SASE<br/>(PEP: ZTNA+SWG+CASB)"]
    ID[IdP] --> POP
    POP --> I((Internet / SaaS))
    POP --> APP[App private]
    style POP fill:#fde2e4,stroke:#e63946

Il compromesso: dipendere dal fornitore

Il SASE concentra una quantità enorme di traffico e di policy in un fornitore cloud. È potente — un solo posto dove applicare lo Zero Trust a tutto il traffico — ma crea una dipendenza critica: disponibilità, copertura geografica dei POP, e fiducia nel fornitore che vede (e potenzialmente decifra) il traffico. Va scelto con gli stessi criteri con cui si sceglie un IdP: è infrastruttura di cui ci si fida per tutto.

Lab

Il SASE commerciale non si riproduce in laboratorio, ma se ne possono assemblare i pezzi open source per capirne la logica:

Uno ZTNA (cap. 07) per l’accesso alle app private.
Un proxy di navigazione (Squid + filtri, o un SWG open source) come secure web gateway.
Un IdP comune che alimenta le policy di entrambi.
Verificate che un utente, autenticato una volta, abbia navigazione filtrata e accesso per-app, con policy coerenti basate sull’identità.

Domanda: SASE non è solo un pacchetto di prodotti vecchi (proxy, firewall, VPN) rietichettato come Zero Trust?

In parte la critica è giusta, ed è il motivo per cui conviene distinguere il modello dal marketing. È vero che i mattoni — gateway web, firewall, broker di accesso — esistono da anni. La novità reale del SASE è dove e come vengono erogati: non apparati nel data center che l'utente deve raggiungere, ma servizi distribuiti al bordo cloud, con un piano di policy unificato e centrato sull'identità. La differenza non è cosmetica: elimina il tromboning, e soprattutto fa applicare a tutte le funzioni la stessa decisione basata su identità e dispositivo, invece di dieci prodotti con dieci logiche scollegate. Detto questo, il rischio del rietichettamento è concreto: un fornitore che vende una VPN e un proxy sotto il cappello "SASE/Zero Trust" senza un piano di policy unificato e senza verifica per-risorsa sta usando la parola, non il modello. Il metro resta quello del capitolo 01.

Conclusione

Il SASE porta rete e sicurezza nel cloud, al bordo vicino all’utente, con lo ZTNA come componente di accesso e l’identità come collante. Non è lo Zero Trust, è il modo di erogarlo quando utenti e risorse sono ovunque. Finora abbiamo verificato utenti e applicazioni; il prossimo capitolo aggiunge un attore che la verifica esplicita non può ignorare: il dispositivo e la sua postura.