Le identità sono il nuovo perimetro dalla recinzione della rete al Zero Trust

Management Summary

L’era dei perimetri di rete è finita. Gli attacchi partono da email, browser, accessi remoti, identità e servizi che non vedono mai la vostra LAN. Chi continua a romanticizzare i packet filter perde in velocità e visibilità. La strada da seguire non è spettacolare: Zero Trust come principio operativo („verificare invece di fidarsi“), MFA forte, Least Privilege applicato con coerenza, autorizzazioni di breve durata ( JIT-Access ) e telemetria che collega le anomalie all’identità. Risultato: rilevamento più rapido, meno movimenti laterali, minori costi di fermo.

Perché il perimetro classico fallisce

Realtà ibrida: SaaS, lavoro remoto, accessi dei partner – l’“interno” di fatto non esiste più.
Furto di sessione invece di tentativi sulle password: le moderne catene di phishing puntano a token e cookie, non solo alle password.
Le identità macchina esplodono: service ID, token CI/CD, IoT – spesso con diritti permanenti, raramente monitorati.
Velocità del cambiamento: nuove app e integrazioni nascono più velocemente di quanto le regole firewall possano adattarsi.

Conclusione: il controllo deve spostarsi sull’identità – umana e macchina.

Zero Trust in cinque pilastri

Identità – Chi vuole cosa? Persone, servizi, dispositivi. MFA forte, processi di recupero robusti, policy di sessione rigide (re-challenge, binding al dispositivo).
Dispositivo – Da cosa avviene l’accesso? Stato di compliance, livello di patch, segnali di rischio. Dispositivi non conformi: modalità limitata.
Rete – Solo livello di trasporto e micro-segmentazione; nessuna zona di fiducia implicita.
Workload/Applicazione – Controllo davanti a ogni flusso sensibile (AuthN/Z, rate limit, igiene dei segreti).
Dati – Classificazione, permessi minimi, autorizzazioni dipendenti dal contesto, logging.

Principi: verifica esplicita, Least Privilege, assumere la compromissione, telemetry-first.

Piano di 90 giorni: dall’intenzione al controllo reale

Giorni 0–15 – Visione della situazione e decisioni difficili
Mappatura dei ruoli: admin, finance, sviluppatori, account di terze parti. Cosa è critico per il business?
Inventario dell’autenticazione: dove manca una MFA resistente al phishing? Quali flussi legacy sono ancora attivi (per esempio IMAP/POP, Basic/NTLM)?
Bozza di policy: le decisioni di accesso si baseranno su identità più stato del dispositivo più contesto.

Giorni 16–45 – Rafforzamento e disattivazioni
MFA per tutti i ruoli critici; disattivare i protocolli legacy; re-challenge della sessione in caso di rischio.
Pilotare il JIT-Access: diritti admin temporanei con ticket o approvazione a quattro occhi; durata massima in minuti o ore.
Rotazione dei segreti: passare gli account di servizio a token di breve durata; eliminare le password hard-coded.

Giorni 46–75 – Automatizzare e ottenere visibilità
Trasformare le decisioni di accesso in policy (policy engine): identità × dispositivo × posizione × sensibilità.
Rilevamento anomalie basato sull’identità: viaggi insoliti, login impossibili, deviazioni dal profilo di ruolo con contenimento automatico (chiusura sessione, step-up authentication).
Testare il processo break-glass: account di emergenza, uso tracciato, rotazione immediata.

Giorni 76–90 – Consolidare e misurare
Pulizia dei ruoli (RBAC/ABAC): chiudere account orfani, ridurre gruppi con troppi privilegi.
Percorso sviluppatori: vietare segreti nel codice, imporre firme, token CI/CD di breve durata.
Steering trimestrale: fissare obiettivi (per esempio 100 % MFA per ruoli critici, 90 % JIT-Access per azioni admin).

KPI che guidano davvero le decisioni

Copertura MFA (resistente al phishing): quota di ruoli critici con fattori forti.
Quota JIT: percentuale di azioni privilegiate approvate su base temporale.
Tasso di privilegi in eccesso: account con diritti oltre il profilo di ruolo.
Mean Time to Revoke: tempo tra offboarding o cambio ruolo e rimozione dei diritti.
Anomalie di sessione: rilevate, contenute automaticamente, confermate manualmente – in base alla criticità.
Identità macchina: quota di token di breve durata, intervalli di rotazione, ritrovamenti di segreti al mese.

Anti-pattern

„Abbiamo la MFA“ – ma con push spamming e fallback legacy consentiti. Risultato: falsa sicurezza.
„Una volta admin, per sempre admin“ – i diritti permanenti favoriscono il movimento laterale. Least Privilege non è un poster, è rimozione di diritti.
„Account di servizio dimenticati“ – password statiche, mai ruotate, onnipotenti. È una backdoor silenziosa.
„La rete è abbastanza sicura“ – finché una scheda del browser con un cookie rubato diventa prova di admin.
„Backup = tranquillità“ – senza rafforzare le identità, gli attaccanti tornano dopo il ripristino.

Checklist pratica (attuabile subito)

MFA resistente al phishing (passkey/FIDO2) per ruoli admin, finance, HR e sviluppatori.
Least Privilege: revisione dei ruoli, rimozione dei diritti non necessari, approvazioni tra pari.
JIT-Access: limiti di tempo, collegamento a ticket, logging completo, revoca automatica.
Account macchina: mTLS, token di breve durata, secrets scanning nel CI, rotazione entro 30 giorni o meno.
Sicurezza delle sessioni: binding del token a dispositivo o browser, re-challenge in caso di rischio, logout forzato dopo anomalie.
Offboarding in ore, non giorni; cascata automatica dei diritti fino ai sottosistemi.

Conclusione: prima l’identità – tutto il resto dopo

Chi prende sul serio la sicurezza IT costruisce il controllo attorno alle identità e ai loro contesti. Zero Trust non è un progetto ma uno standard operativo: MFA forte, Least Privilege rigoroso, JIT-Access applicato, telemetria solida. È meno appariscente di nuovi strumenti – ma riduce sensibilmente rischio, MTTR e costi. Chi inizia oggi e applica con coerenza i passi dei 90 giorni ottiene in pochi trimestri più impatto di qualsiasi ulteriore acquisto „best-of-breed“.