Identity on My personal blog

Verifica continua e accesso adattivo al rischio

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

Perché conta

Il quinto dei cinque principi è quello che distingue lo Zero Trust maturo da un semplice “login forte”: l’accesso non è un evento, è uno stato. Un modello che verifica tutto perfettamente al login ma poi lascia la sessione aperta per otto ore ha solo spostato il perimetro al momento dell’autenticazione. Se a metà giornata il dispositivo viene compromesso o il comportamento diventa anomalo, nulla reagisce. La verifica continua rivaluta l’accesso nel tempo; l’accesso adattivo lo commisura al rischio del momento.

Da cancello a condizione

  flowchart LR
    L[Login] --> S{Sessione}
    S -->|segnali ok| A[Accesso mantenuto]
    S -->|rischio sale| STEP[Step-up: richiedi MFA]
    S -->|rischio alto| LIM[Restringi / sola lettura]
    S -->|anomalia grave| REV[Revoca sessione]
    style REV fill:#fde2e4,stroke:#e63946

La decisione del PDP non viene presa una volta e dimenticata: viene rinnovata a intervalli e a eventi. Token a vita breve (identità) sono il meccanismo di base — ogni rinnovo è una nuova occasione di rivalutare — ma la verifica continua va oltre, reagendo ai segnali mentre la sessione è viva.

Il punteggio di rischio

L’accesso adattivo combina i segnali in una valutazione del rischio della richiesta:

Segnale	Abbassa il rischio	Alza il rischio
Dispositivo	gestito, conforme (postura)	sconosciuto, non conforme
Posizione / rete	abituale	paese insolito, IP anonimizzante
Comportamento	coerente con lo storico	orario anomalo, volume inusuale
Risorsa	bassa sensibilità	dati critici

Il rischio risultante decide la risposta: consentire in silenzio, chiedere un fattore in più (step-up), restringere i privilegi, o revocare.

La chiave: attrito proporzionale al rischio

Qui si scioglie il malinteso che lo Zero Trust sia “sempre più fastidioso”. L’accesso adattivo è pensato per essere invisibile quando il rischio è basso: identità, dispositivo e contesto soliti → nessuna richiesta aggiuntiva. La frizione compare solo quando qualcosa è anomalo — ed è esattamente lì che la vogliamo.

# risposta in funzione del rischio
rischio basso:   accesso trasparente (nessun prompt)
rischio medio:   step-up (MFA resistente al phishing)
rischio alto:    accesso ridotto o negato, sessione rivalutata

Rispetto alla VPN classica — che chiede login e token a ogni connessione a prescindere — un modello adattivo ben fatto riduce l’attrito medio, concentrandolo dove serve.

Continuous access evaluation

Il meccanismo moderno che rende reattiva la sessione è la valutazione continua degli accessi: invece di aspettare la scadenza del token (anche solo un’ora), l’IdP e i servizi si scambiano eventi — “questo utente è stato disabilitato”, “il dispositivo ha perso la conformità”, “rischio elevato rilevato” — e la sessione viene rivalutata o chiusa subito. Chiude la finestra tra “il rischio è cambiato” e “il prossimo rinnovo del token”.

Il prerequisito: i segnali

L’accesso adattivo è buono quanto i segnali che lo alimentano. Senza telemetria su identità, dispositivi e comportamento, il “rischio” è una parola vuota. Per questo il capitolo successivo è dedicato alla telemetria: è il sistema nervoso senza cui la verifica continua non vede nulla.

Lab

Con un IdP che supporti policy di accesso condizionale/adattivo (Keycloak con flussi condizionali, o regole in un reverse proxy + OPA):

Definite una policy che consenta l’accesso trasparente da un contesto “normale” (device conforme, rete nota).
Introducete un segnale di rischio (login da IP/paese diverso) e configurate uno step-up MFA.
Simulate un peggioramento della postura a sessione avviata e verificate che l’accesso si restringa senza nuovo login.
Revocate l’utente e osservate la sessione cadere il prima possibile, non alla scadenza del token.

Domanda: valutare il rischio in continuazione non rischia di bloccare utenti legittimi per falsi positivi — un viaggio, una VPN personale, una giornata diversa dal solito?

Il rischio di falsi positivi è reale, ed è il motivo per cui la risposta corretta è quasi mai "blocca" e quasi sempre "chiedi conferma". Un segnale anomalo — sei in un altro paese, usi una rete nuova — non deve negare l'accesso, deve innescare uno step-up: una verifica in più (una passkey) che l'utente legittimo supera in due secondi e l'attaccante no. Così l'anomalia benigna costa un tocco, non una giornata persa. Il blocco secco si riserva ai casi gravi e combinati (dispositivo non gestito e paese a rischio e accesso a dati critici), dove il falso positivo è raro e il costo del falso negativo altissimo. E i modelli imparano: il "nuovo" paese, dopo una conferma, entra nello storico e smette di essere anomalo. L'errore da evitare è trattare ogni deviazione come una minaccia binaria; l'accesso adattivo fatto bene gradua la risposta, e la gradazione è proprio ciò che tiene bassi sia i falsi positivi sia i falsi negativi.

Conclusione

Lo Zero Trust maturo tratta l’accesso come uno stato da rivalutare, non un cancello da aprire una volta: il rischio si ricalcola di continuo dai segnali, e la risposta — trasparente, step-up, ridotta, revocata — è proporzionale. Fatto bene, riduce l’attrito concentrandolo dove il rischio è reale. Tutto questo dipende dalla qualità dei segnali: il prossimo capitolo costruisce il sistema nervoso dello Zero Trust, la telemetria.

SPIFFE e SPIRE: dare un'identità a ogni workload

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

Perché conta

Nel capitolo precedente abbiamo stabilito che ogni workload ha bisogno di un’identità crittografica per l’mTLS. Ma sorge subito il problema più difficile dell’intera identità macchina-a-macchina: il bootstrap della fiducia. Come fa un servizio appena avviato a ottenere il suo primo certificato in modo sicuro, senza un segreto pre-condiviso che a sua volta andrebbe protetto? SPIFFE e SPIRE risolvono proprio questo: uno standardizza cos’è l’identità di un workload, l’altro la emette senza il problema dell’uovo e della gallina.

SPIFFE: lo standard dell’identità

SPIFFE (Secure Production Identity Framework For Everyone) definisce un formato universale per l’identità di un workload: lo SPIFFE ID, un URI che descrive chi è il servizio, indipendentemente da dove gira.

1
2

spiffe://azienda.it/ns/pagamenti/sa/servizio-ordini
         └─ trust domain ─┘ └──── percorso del workload ────┘

Questa identità viene incapsulata in un documento verificabile, lo SVID (SPIFFE Verifiable Identity Document), tipicamente un certificato X.509 (usabile direttamente in mTLS) o un JWT. Il vantaggio dello standard: servizi, mesh e strumenti diversi parlano la stessa lingua di identità.

SPIRE: emettere senza segreti pre-condivisi

SPIRE è l’implementazione che emette gli SVID. Il suo cuore è l’attestazione: invece di dare a ogni servizio un segreto iniziale (che andrebbe custodito, diventando il nuovo bersaglio), SPIRE verifica proprietà osservabili del workload e della piattaforma per decidere a chi dare quale identità.

  flowchart TD
    W[Workload] -->|"chiedo la mia identità"| A[SPIRE Agent<br/>sul nodo]
    A -->|attesta: quale processo,<br/>quale pod, quale nodo| S[SPIRE Server]
    N[Attestazione del nodo:<br/>cloud, k8s, TPM] --> S
    S -->|verifica contro i<br/>registration entries| S
    S -->|emette SVID<br/>certificato a vita breve| A
    A --> W
    style S fill:#fde2e4,stroke:#e63946

Node attestation: SPIRE prova su quale nodo gira l’agent (identità del nodo cloud, token Kubernetes, TPM).
Workload attestation: l’agent prova quale processo/pod sta chiedendo l’identità (selettori come lo UID del processo, le label del pod).

Il workload non presenta nessun segreto: è la piattaforma stessa a testimoniare chi è. Si àncora la fiducia a proprietà verificabili, non a una chiave che qualcuno deve consegnare per primo.

Il problema del bootstrap, risolto

# il nodo delle tartarughe: come si autentica il primo segreto?
API key / cert statico →  serve un segreto per ottenere il segreto (ricorsione)
SPIFFE/SPIRE          →  attestazione di proprietà della piattaforma
                         (nessun segreto iniziale da proteggere)

Questo è il contributo concettuale: eliminare il “segreto zero”. La fiducia iniziale non poggia su una credenziale consegnata, ma su ciò che la piattaforma può attestare del workload — lo stesso principio dell’attestazione del dispositivo via TPM, applicato ai servizi.

Rotazione automatica

Gli SVID hanno vita breve e SPIRE li ruota di continuo, trasparente al workload. Questo rende pratico ciò che il capitolo mTLS richiedeva: certificati a vita breve senza gestione manuale. Un SVID rubato vale per minuti, non per sempre.

Lab

Con SPIRE in un cluster di test:

Avviate SPIRE Server e un SPIRE Agent su un nodo.
Create un registration entry che leghi uno SPIFFE ID a selettori di workload (es. una certa label di pod o UID).
Avviate un workload che combaci e verificate che riceva uno SVID (X.509) via l’API del Workload.
Usate due SVID per stabilire una connessione mTLS tra due servizi e osservate la rotazione automatica dei certificati.

Domanda: l'attestazione si basa su selettori come "questo pod ha questa label"; chi impedisce a un attaccante di avviare un pod con la label giusta e rubare l'identità?

È la domanda corretta, e la robustezza dell'attestazione sta nel combinare più selettori e nel radicarli il più in basso possibile. Una sola label di pod sarebbe debole, esatto: chiunque possa creare pod in quel namespace potrebbe imitarla. Per questo SPIRE compone l'attestazione del nodo (provata da qualcosa che l'attaccante non falsifica: l'identità dell'istanza cloud, un token del kubelet, un TPM) con quella del workload (selettori multipli: service account, namespace, immagine, UID del processo). L'identità viene emessa solo se tutti combaciano, e molti selettori dipendono da privilegi che l'attaccante non ha nel namespace giusto sul nodo giusto. La sicurezza non è mai migliore della piattaforma sottostante — se qualcuno controlla l'orchestratore, controlla le identità — ma questo riporta il problema al controllo d'accesso della piattaforma, dove deve stare, invece di nasconderlo dietro un segreto pre-condiviso altrettanto rubabile. L'attestazione sposta il bersaglio da "una stringa segreta" a "l'integrità della piattaforma", che è molto più difficile da falsificare e molto più facile da monitorare.

Conclusione

SPIFFE dà un formato universale all’identità dei workload (lo SPIFFE ID, incapsulato in uno SVID); SPIRE la emette tramite attestazione, eliminando il “segreto zero” e ruotando i certificati in automatico. È l’infrastruttura che rende praticabile l’mTLS su scala. Ma chiedere a ogni servizio di gestire SVID e mTLS nel proprio codice è troppo: serve uno strato che lo faccia per tutti. È il service mesh, il prossimo capitolo.

Least privilege e accesso Just-in-Time

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

Perché conta

Il terzo dei cinque principi è il minimo privilegio, e spesso è il più tradito. Nelle organizzazioni reali i permessi si accumulano: qualcuno riceve un accesso per un progetto, il progetto finisce, il permesso resta. Anni dopo, account con decine di privilegi dimenticati sono la norma. E quando uno di quegli account viene compromesso, l’attaccante eredita ogni permesso in un colpo solo. Lo Zero Trust risponde dando il minimo accesso per il minimo tempo.

Il privilege creep

  flowchart LR
    A[Nuovo ruolo] --> P1[+ accesso progetto X]
    P1 --> P2[+ accesso temporaneo Y]
    P2 --> P3[+ 'serve per un attimo' Z]
    P3 --> ACC["Account con 30 permessi,<br/>3 davvero usati"]
    style ACC fill:#fde2e4,stroke:#e63946

Il “privilege creep” è entropia: aggiungere un permesso è facile e richiesto, toglierlo non lo chiede mai nessuno. Il risultato è una superficie d’attacco che cresce in silenzio. La soluzione non è ricordarsi di revocare (non succede), è rendere i permessi temporanei per costruzione.

Due assi: enough e in-time

Just-enough-access (JEA): non “accesso admin”, ma esattamente il permesso per il compito — leggere quella tabella, riavviare quel servizio, nulla di più.
Just-in-Time (JIT): il permesso non è permanente, si richiede al momento del bisogno, è concesso per una finestra breve, e scade da solo.

Insieme: invece di “Alice è amministratrice del database”, si ha “Alice può richiedere 1 ora di accesso in scrittura al database, con motivazione, e l’accesso sparisce da solo”.

Il flusso Just-in-Time

  sequenceDiagram
    participant U as Utente
    participant B as Broker JIT (PDP)
    participant R as Risorsa
    U->>B: richiede accesso (compito, durata)
    B->>B: valuta policy + eventuale approvazione
    B->>R: concede permesso temporaneo (es. 60 min)
    Note over R: accesso attivo, registrato
    Note over B,R: alla scadenza il permesso viene revocato automaticamente

Il punto non è solo la scadenza: è che ogni elevazione è esplicita, motivata e registrata. Lo stato “a riposo” di ogni identità è il minimo; l’elevazione è l’eccezione tracciata, non la regola.

Gli account più pericolosi: gli admin

Dove il JIT conta di più è sugli account privilegiati. Un amministratore che resta admin 24/7 è un bersaglio permanente. Con il PAM (Privileged Access Management) in modalità JIT, nessuno è admin di default: lo si diventa per una sessione approvata e tracciata, con credenziali effimere. Un account admin compromesso che non ha privilegi attivi in quel momento vale molto meno.

# modello concettuale
stato normale:   permessi = { minimo per il ruolo }
elevazione JIT:  richiesta + (approvazione) → permesso temporaneo con TTL
scadenza:        permesso revocato automaticamente, torna al minimo

Il legame con il resto

Il minimo privilegio non vive da solo: ha senso solo se l’identità è forte (altrimenti non si sa a chi si concede), se il PDP valuta le richieste, e se tutto è registrato (altrimenti l’elevazione non è verificabile). Lo stesso principio vale per i workload: un servizio ottiene scope minimi e token a vita breve, non una chiave onnipotente.

Lab

Con un broker di accesso o uno script che gestisca permessi temporanei (es. su un DB o via sudo con timeout):

Partite da un utente senza privilegi su una risorsa.
Implementate una richiesta JIT che conceda un permesso con TTL (es. accesso in scrittura per 15 minuti).
Verificate l’accesso durante la finestra e la revoca automatica allo scadere.
Registrate ogni richiesta ed elevazione in un log e rileggetele: chi, cosa, quando, perché.

Domanda: chiedere l'accesso ogni volta e aspettare che scada non rallenta il lavoro degli amministratori fino a renderlo insopportabile?

È la tensione reale tra sicurezza e operatività, e si gestisce dosando l'attrito sul rischio. L'errore è pensare che ogni elevazione richieda un'approvazione umana lenta: la maggior parte può essere auto-approvata dalla policy (identità valida, dispositivo conforme, orario lavorativo), con concessione in pochi secondi e scadenza automatica — l'amministratore quasi non se ne accorge, ma lo stato a riposo resta il minimo. L'approvazione manuale si riserva alle azioni davvero sensibili (produzione, dati critici), dove qualche minuto di attesa è un prezzo accettabile per un'operazione rara. E il beneficio è concreto proprio per gli admin: non essere un bersaglio con privilegi perenni significa che una loro credenziale rubata, da sola, non apre nulla. Il JIT fatto male è burocrazia; fatto bene, è invisibile quando il rischio è basso e presente solo dove serve — la stessa logica dell'accesso adattivo.

Conclusione

I permessi permanenti sono debito che si accumula e che un account compromesso eredita per intero. Lo Zero Trust li rende temporanei per costruzione: minimo privilegio (just-enough) concesso al momento (just-in-time) e revocato da solo, con ogni elevazione motivata e registrata — soprattutto per gli amministratori. Finora abbiamo parlato di utenti; i prossimi capitoli applicano la stessa logica ai servizi, partendo dall’identità dei workload con mTLS.

Device trust e postura: l'altro metà dell'identità

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

Perché conta

La verifica esplicita usa tutti i segnali, e il dispositivo è tra i più importanti. Un utente perfettamente legittimo, con MFA resistente al phishing, che accede da un laptop infetto da malware è comunque un vettore: l’attaccante cavalca la sessione dell’utente autenticato. L’identità dell’utente da sola non basta; serve anche l’identità e lo stato del dispositivo. È l’altra metà del perimetro-identità.

Due domande sul dispositivo

Lo Zero Trust pone al dispositivo due domande distinte:

Identità: è un dispositivo che conosciamo e gestiamo? (non un portatile qualunque)
Postura: è in uno stato sano? (cifrato, aggiornato, con EDR attivo, senza jailbreak)

  flowchart LR
    DEV[Dispositivo] --> ID{Identità nota?}
    ID -->|sì| POS{Postura sana?}
    ID -->|no| DENY[Nega / solo guest]
    POS -->|sì| OK[Accesso pieno]
    POS -->|parziale| LIM[Accesso ridotto]
    POS -->|no| DENY
    style DENY fill:#fde2e4,stroke:#e63946

La postura non è binaria: un dispositivo quasi conforme può ottenere accesso ridotto invece di essere respinto — è la gradualità dell’accesso adattivo (cap. 15).

Identità hardware: il TPM

L’identità forte di un dispositivo si àncora all’hardware. Il TPM (Trusted Platform Module) è un chip che custodisce chiavi che non lasciano il dispositivo e può attestare lo stato di avvio (secure boot, misura dei componenti caricati). Un certificato legato al TPM diventa l’identità del dispositivo — l’equivalente, per la macchina, di una passkey per l’utente: non trasferibile, non clonabile.

Questa identità si usa per l’accesso alla rete via 802.1X / EAP-TLS e per i controlli ZTNA.

I segnali di postura

La postura si compone di segnali concreti, raccolti da un agente di gestione (MDM/EDR):

Segnale	Perché conta
Disco cifrato	un dispositivo rubato non rivela i dati
OS aggiornato / patch	niente vulnerabilità note aperte
EDR attivo e sano	rilevamento sul dispositivo
Firewall locale attivo	superficie ridotta
Nessun jailbreak/root	il modello di sicurezza dell’OS è intatto

Questi segnali alimentano il PDP: la decisione di accesso combina identità dell’utente e postura del dispositivo.

Il dispositivo non gestito

Non tutti gli accessi vengono da dispositivi aziendali: il BYOD e i collaboratori esterni esistono. Lo Zero Trust non li blocca in assoluto, li tratta per quello che sono — meno fidati — concedendo accesso ridotto: solo app web via ZTNA clientless, nessun download di dati, sessioni più brevi. La fiducia è commisurata a ciò che si può verificare.

# policy concettuale: accesso in funzione del dispositivo
se dispositivo gestito E cifrato E patchato:  accesso pieno
se dispositivo gestito ma non conforme:        accesso ridotto + remediation
se dispositivo non gestito (BYOD):             solo web, sola lettura, no download
altrimenti:                                     nega

Lab

Con un MDM/strumento di compliance open source (o uno script di attestazione) e 802.1X:

Emettete un certificato dispositivo legato al TPM (dove disponibile) e usatelo per l’accesso alla rete.
Raccogliete segnali di postura di base (cifratura disco, stato patch) con uno script.
Costruite una policy che dia accesso pieno solo se i segnali sono verdi, altrimenti ridotto.
Degradate un segnale (disattivate la cifratura su una VM di test) e osservate l’accesso restringersi.

Domanda: i segnali di postura arrivano da un agente sul dispositivo; se la macchina è compromessa, l'agente non può mentire e dichiararsi sano?

È la critica più seria al device trust, e la risposta sta nel radicare la fiducia nell'hardware, non nel software. Un agente software su una macchina pienamente compromessa può essere manomesso: per questo i segnali più forti non vengono dall'agente ma dall'attestazione hardware. Il TPM misura la catena di avvio e firma quelle misure con una chiave che il malware non può estrarre: un sistema con bootkit o secure boot disattivato produce un'attestazione che non combacia, e lo si rileva a prescindere da cosa dichiari l'agente. I segnali software (patch, EDR) restano utili come strato aggiuntivo, ma non sono la radice della fiducia. Il principio è lo stesso di FIDO2: la prova nasce in un elemento sicuro che il software compromesso non controlla. Dove l'hardware di attestazione non c'è (vecchi dispositivi, BYOD), lo si tratta onestamente come meno fidato e si concede meno — invece di fingere una garanzia che non si ha.

Conclusione

Lo Zero Trust verifica il dispositivo quanto l’utente: identità ancorata all’hardware (TPM) e postura (cifratura, patch, EDR) entrano nella decisione di accesso, che diventa graduale invece che binaria. Il dispositivo non gestito non è bandito, è limitato a ciò che si può verificare. Verificati utente e dispositivo, resta da stringere cosa possono fare: il minimo privilegio e l’accesso Just-in-Time, il prossimo capitolo.

MFA resistente al phishing: FIDO2 e WebAuthn

Tue, 09 Jun 2026 09:00:00 +0200

Perché conta

Se l’identità è il perimetro, l’autenticazione è la serratura. E non tutte le serrature sono uguali: aggiungere “un secondo fattore” non basta se quel fattore si può rubare con l’inganno. Gran parte delle brecce odierne non rompe la crittografia, ruba le credenziali — compresi i codici MFA — con il phishing. La MFA resistente al phishing (FIDO2/ WebAuthn) chiude proprio questa strada, ed è il tipo di autenticazione che lo Zero Trust richiede.

Perché OTP e push non bastano

I fattori più diffusi sono rubabili perché l’utente può essere ingannato a consegnarli:

OTP (codici a tempo): un sito di phishing che imita quello vero chiede il codice; l’utente lo digita; l’attaccante lo inoltra al sito vero in tempo reale. Il codice non sa a chi lo stai dando.
Push “approva/nega”: l’attaccante tenta il login e l’utente riceve la richiesta; con il MFA fatigue (richieste ripetute, di notte) prima o poi qualcuno approva per sfinimento.
SMS: in più soffre di SIM swapping.

Il difetto comune: il fattore non è legato al sito legittimo. L’utente è l’anello che può essere indirizzato verso il posto sbagliato.

L’idea di FIDO2: legare la credenziale al dominio

FIDO2/WebAuthn usa la crittografia a chiave pubblica e lega la credenziale all’origine (il dominio) per cui è stata creata. La chiave privata vive in un autenticatore (chiave di sicurezza, TPM, Secure Enclave del telefono) e non lascia mai il dispositivo; al sito va solo una firma.

  sequenceDiagram
    participant U as Utente + autenticatore
    participant B as Browser
    participant S as Sito (origine)
    S->>B: challenge + origine attesa
    B->>U: firma challenge (lega all'origine reale del browser)
    Note over U: chiave privata non esce mai
    U->>B: firma
    B->>S: firma verificata con chiave pubblica

Il punto decisivo: il browser include l’origine reale nella firma. Se l’utente è su un sito di phishing (banca-login.evil.com), la firma è per quel dominio, e il sito vero (banca.it) la rifiuta. La credenziale non è trasferibile a un dominio diverso. Il phishing smette di funzionare non perché l’utente è più attento, ma perché la tecnica è inefficace.

Passkey: FIDO2 usabile

Le passkey sono credenziali FIDO2 sincronizzabili (via il portachiavi del sistema operativo) o legate a un dispositivo. Rendono FIDO2 pratico per il grande pubblico: niente password, sblocco con biometria o PIN locale, e resistenza al phishing di serie. Per lo Zero Trust sono il fattore da preferire per gli utenti; per gli account ad alto privilegio, le chiavi di sicurezza hardware dedicate.

Registrazione e verifica, in breve

# registrazione (una volta)
navigator.credentials.create(...)   # genera coppia di chiavi legata a questa origine
# → la chiave pubblica viene salvata dal sito, la privata resta nell'autenticatore

# login (ogni volta)
navigator.credentials.get(...)      # firma la challenge SOLO per questa origine
# → il server verifica la firma con la chiave pubblica registrata

Le due righe evidenziate sono il cuore: la creazione lega la credenziale all’origine, e il login firma solo per quell’origine. Nessun segreto condiviso viaggia mai.

Non dimenticare il recupero

L’anello debole di ogni MFA forte è il recupero account: se “ho perso la chiave” riporta a un codice via email o a una domanda segreta, l’attaccante punta lì. Il recupero va trattato con lo stesso rigore: un secondo autenticatore registrato in anticipo, o un processo verificato, non una backdoor via SMS.

Lab

Con una libreria WebAuthn in laboratorio (o un IdP come Keycloak che supporta FIDO2) e una chiave di sicurezza o una passkey:

Registrate una credenziale FIDO2 su un’app di test servita da localhost.
Effettuate il login con la passkey/chiave: nessuna password.
Simulate il phishing: servite la stessa app da un host diverso e verificate che l’autenticatore non produca una firma valida per l’origine sbagliata.
Registrate un secondo autenticatore come recupero e provate a perdere il primo.

Domanda: se la passkey è sul telefono e perdo il telefono, non resto chiuso fuori da tutto?

È la preoccupazione giusta, e il motivo per cui le passkey moderne sono pensate attorno al recupero, non solo all'accesso. Due meccanismi la risolvono. Primo: le passkey sincronizzate vivono nel portachiavi del vostro ecosistema (Apple, Google, un password manager) e si ripristinano sul nuovo dispositivo dopo esservi autenticati a quell'account — la passkey non è prigioniera di un singolo pezzo di hardware. Secondo, e sempre consigliato in azienda: registrare almeno due autenticatori in anticipo (ad esempio il telefono più una chiave hardware tenuta al sicuro), così la perdita di uno non chiude fuori. Il rischio reale non è perdere l'accesso, è un recupero debole: se il "ho perso tutto" ripiega su un codice via email, avete riaperto proprio la porta che FIDO2 aveva chiuso. Il recupero va progettato forte quanto l'accesso.

Conclusione

La MFA conta solo se è resistente al phishing: OTP e push si fanno rubare perché non sanno a chi si consegnano, FIDO2/WebAuthn no perché lega la credenziale al dominio e non la fa mai uscire dal dispositivo. È il fattore che lo Zero Trust richiede per utenti e, a maggior ragione, per gli amministratori. Autenticata l’identità, serve il motore che decide cosa può fare: PDP e PEP, il prossimo capitolo.

L'identità è il nuovo perimetro

Tue, 02 Jun 2026 09:00:00 +0200

Perché conta

Nel capitolo precedente abbiamo tolto alla rete il potere di conferire fiducia (oltre il perimetro). Ma la fiducia deve pur fondarsi su qualcosa: nello Zero Trust quel qualcosa è l’identità. Non più “da quale IP arrivi”, ma “chi sei e cosa ti è concesso”. L’identità diventa il piano di controllo: il punto da cui parte ogni decisione di accesso. Se l’identità è debole, tutto il resto dell’architettura poggia sulla sabbia.

Identità: non solo utenti

Un errore comune è pensare all’identità solo come all’utente umano. Nello Zero Trust hanno un’identità verificabile anche:

Dispositivi: il laptop, il telefono (cap. 09).
Workload: servizi, container, funzioni — che si autenticano a vicenda con mTLS e identità come SPIFFE.
Servizi esterni: API di terze parti, partner.

Ogni attore che fa una richiesta ha un’identità, e ogni identità è verificata.

Il piano di controllo dell’identità

  flowchart TD
    subgraph CP["Piano di controllo: Identity Provider (IdP)"]
        DIR[(Directory<br/>utenti/gruppi)]
        AUTH[Autenticazione + MFA]
        TOK[Emissione token]
    end
    U[Utente / servizio] -->|si autentica| AUTH
    AUTH --> TOK
    TOK -->|token firmato| APP1[App A]
    TOK -->|token firmato| APP2[App B]
    DIR --> AUTH
    style CP fill:#fde2e4,stroke:#e63946

Un Identity Provider (IdP) centrale autentica l’identità una volta e rilascia token firmati (OpenID Connect / SAML) che le applicazioni verificano. Centralizzare l’autenticazione significa un solo posto dove applicare MFA, un solo posto dove revocare un accesso, un solo registro di chi è chi.

SSO e federazione

Il Single Sign-On (SSO) permette a un’identità di accedere a molte applicazioni con una sola autenticazione forte presso l’IdP. La federazione estende questo tra organizzazioni e domini: un partner si autentica presso il proprio IdP, e il nostro si fida di quell’asserzione tramite una relazione di trust stabilita.

Il vantaggio per lo Zero Trust è doppio: meno password in giro (meno da rubare) e un punto unico dove applicare le policy. Lo svantaggio da gestire: l’IdP diventa il bersaglio numero uno — se cade lui, cade tutto. Per questo il capitolo 04 dedica attenzione all’autenticazione resistente al phishing.

Un token non è un lasciapassare eterno

Un token OIDC/SAML dice “questa identità è stata verificata”. Ma nello Zero Trust non basta averlo: conta per quanto vale e cosa autorizza. Token a vita breve, scope minimi, e verifica a ogni accesso (non “ho il token, entro ovunque”). Il token prova l’identità; l’autorizzazione resta una decisione separata del PDP.

# claim essenziali di un token (concettuale)
sub: alice@azienda.it      # chi
aud: app-gestionale        # per quale servizio
exp: +10m                  # scadenza BREVE
scope: ordini:lettura      # privilegio MINIMO, non "tutto"

Identità forte come prerequisito

Se l’identità è il perimetro, va resa robusta prima di tutto il resto:

Una fonte autorevole unica delle identità (directory), senza account fantasma.
MFA ovunque, meglio se resistente al phishing (cap. 04).
Deprovisioning immediato: quando qualcuno se ne va, l’accesso sparisce subito.
Separazione tra autenticazione (chi sei) e autorizzazione (cosa puoi), per poter cambiare i privilegi senza toccare l’identità.

Lab

Con un IdP open source (Keycloak o Authentik) in laboratorio:

Configurate un IdP e due applicazioni di test che si fidano di esso via OpenID Connect.
Abilitate il SSO: autenticatevi una volta e accedete a entrambe le app senza re-login.
Impostate token a vita breve e osservate il rinnovo.
Revocate l’utente nell’IdP e verificate che l’accesso a entrambe le app cada.

Domanda: centralizzare tutto sull'IdP non crea un singolo punto di fallimento catastrofico?

Sì, e va affrontato apertamente: l'IdP diventa il sistema più critico dell'intera architettura, sul piano sia della disponibilità sia della sicurezza. Ma l'alternativa — identità e password sparse su decine di sistemi, ognuno con la propria logica — non è più sicura, è solo più difficile da difendere e da revocare. La concentrazione è un vantaggio se la si tratta come tale: alta disponibilità e ridondanza per non restare chiusi fuori, MFA resistente al phishing per gli account, protezione rigorosa degli amministratori dell'IdP, e monitoraggio di ogni autenticazione anomala. Si sposta il rischio da "molti bersagli mediocri" a "un bersaglio critico ben difeso": è un compromesso migliore, ma solo se quel bersaglio lo si difende davvero.

Conclusione

Tolta alla rete, la fiducia si fonda sull’identità: utenti, dispositivi e workload, ciascuno con un’identità verificata a ogni accesso tramite un IdP centrale. L’identità è il piano di controllo dello Zero Trust, e perciò va resa forte per prima. Il pezzo più fragile dell’identità è l’autenticazione: nel prossimo capitolo la rendiamo resistente al phishing.