Come implementare un'architettura Zero Trust con accesso a privilegio minimo partendo dalla gestione delle identità

Un'architettura Zero Trust con accesso a privilegio minimo si implementa partendo dall'identità in tre mosse: portare ogni login su un unico punto di decisione (una piattaforma IAM integrata via SDK o REST API, con SSO e MFA), ridurre ogni identità — umana e non umana — ai soli permessi necessari per tenant e progetto, e rendere la revoca immediata e misurabile. Con LoginMaster la segmentazione avviene già nel livello di identità: ogni tenant e progetto ha chiavi crittografiche proprie, ogni token porta una doppia firma (Tenant e Cloud), e nemmeno il fornitore è una parte fidata, perché i dati personali restano sul tenant del cliente.

Questa è la guida operativa. Se cerchi la definizione del modello e dei suoi principi parti da cos'è lo Zero Trust; se vuoi vedere i controlli di prodotto, sono su Zero Trust con LoginMaster.

Perché partire dall'identità e non dalla rete

Le iniziative Zero Trust che partono dalla rete (microsegmentazione, ZTNA, sostituzione della VPN) si bloccano spesso alla stessa domanda: "chi è, esattamente, l'entità che sta chiedendo l'accesso, e cosa dovrebbe poter fare?". Se la risposta vive in dieci applicazioni con dieci basi utenti diverse, nessun componente di rete può prendere una decisione corretta. Il punto di partenza pratico è quindi il piano di controllo dell'identità: un solo posto in cui l'identità è verificata, il contesto è noto e la policy è dichiarata.

• Le credenziali compromesse restano uno dei vettori di accesso iniziale più frequenti: un controllo sull'identità le neutralizza a prescindere dalla rete da cui arrivano.
• Il lavoro remoto, i SaaS e i partner esterni hanno già spostato le richieste fuori dal perimetro: l'identità è l'unico attributo che viaggia con ogni richiesta.
• Il privilegio minimo è per definizione una proprietà delle identità e dei ruoli, non degli indirizzi IP.
• NIS2 (art. 21) e ISO/IEC 27001:2022 (controlli 5.15-5.18 e 8.5) chiedono evidenze su controllo degli accessi, gestione delle identità e autenticazione sicura: partire dall'identità produce anche le prove di audit.

I riferimenti: NIST SP 800-207 e CISA ZTMM 2.0

NIST SP 800-207: i sette principi tradotti in requisiti di identità

La Special Publication 800-207 del NIST (agosto 2020) definisce l'architettura di riferimento: un Policy Decision Point (Policy Engine + Policy Administrator) che decide, e un Policy Enforcement Point che applica la decisione davanti alla risorsa. Nell'approccio "identity-driven" descritto dal documento, il PDP è in larga parte la piattaforma IAM. I sette principi, letti dal punto di vista dell'identità:

CISA Zero Trust Maturity Model 2.0: dove sei oggi sul pilastro Identity

Il modello di maturità della CISA (versione 2.0, aprile 2023) organizza lo Zero Trust in cinque pilastri — Identity, Devices, Networks, Applications and Workloads, Data — con tre capacità trasversali (Visibility and Analytics, Automation and Orchestration, Governance) e quattro stadi: Traditional, Initial, Advanced, Optimal. Usalo come autovalutazione prima di pianificare, non come checklist di conformità.

Fase 1 (giorni 0-30) — Visibilità e un solo punto di decisione

Inventario: le identità che nessuno ha censito

L'inventario non è un foglio con i nomi dei dipendenti. Per ogni applicazione servono quattro informazioni: chi accede, con quale tipo di credenziale, con quali privilegi effettivi, e chi è il responsabile che può dire se quei privilegi sono ancora giustificati.

Login centralizzato via SDK e REST API

Il primo risultato concreto è che nessuna applicazione verifica più una password per conto proprio: l'autenticazione, il secondo fattore e la policy sono delegati alla piattaforma IAM, che restituisce all'applicazione un token firmato. In LoginMaster ogni applicazione è un progetto con configurazione di sicurezza indipendente sulla stessa base utenti del tenant, e l'integrazione avviene con gli SDK ufficiali TypeScript e .NET o via REST API. Per i dipendenti il SSO con Microsoft Entra ID o Google Workspace, tramite OAuth 2.0 / OpenID Connect, fa sì che la directory aziendale resti la fonte di verità: la procedura è nella guida al SSO con Entra ID e Google Workspace.

MFA obbligatoria per gli amministratori dal primo giorno

Non serve aspettare il modello dei ruoli per proteggere gli account a maggior impatto. Imposta la 2FA TOTP come obbligatoria sui progetti di amministrazione e sui ruoli privilegiati, con un periodo di grazia per l'enrolment: chi non si mette in regola entro la scadenza può essere disattivato. In LoginMaster, una volta che un utente ha attivato il secondo fattore, nessun amministratore può disattivarlo: è il controllo che chiude l'ingegneria sociale verso l'helpdesk. Il dettaglio operativo è nella guida a TOTP e accesso condizionale sulle app interne.

Fase 2 (giorni 30-90) — Privilegio minimo e segmentazione dell'identità

Il modello dei ruoli: negazione di default, per tenant e per progetto

Il privilegio minimo fallisce quasi sempre per lo stesso motivo: si parte dai permessi che le persone hanno oggi e si prova a toglierne. Il metodo che regge è l'opposto: ogni ruolo nasce con zero permessi e ne riceve solo quelli giustificati da un'attività documentata. Tre regole di disegno:

1. 1Ruoli legati al progetto, non globali: 'operatore' del progetto fatturazione non è 'operatore' del progetto produzione. In LoginMaster i ruoli vivono nel contesto di tenant e progetto, e un utente collegato a un solo progetto non vede gli altri.
2. 2Separazione dei compiti esplicita: chi approva un pagamento non lo esegue, chi gestisce gli utenti non amministra le chiavi. Elenca le coppie di ruoli incompatibili e verificale a ogni assegnazione.
3. 3Pochi ruoli, ben nominati: un modello con più ruoli che persone è un modello che nessuno ricertificherà mai.

Un dettaglio che fa la differenza in audit: in LoginMaster l'amministratore non è onnipotente. Nessun amministratore può leggere o impostare la password, l'email o il secondo fattore di un utente, e il recupero dell'accesso passa da un recovery code in mano all'utente più una richiesta approvata. È privilegio minimo applicato anche a chi gestisce la piattaforma. Il limite dichiarato: senza reset amministrativo, il recupero di un account è più lento. I dettagli sono su governance degli accessi.

Accesso condizionale: la tabella segnale → decisione

Zero Trust chiede che ogni accesso sia deciso da una policy. La domanda pratica è quali condizioni la policy usa. In LoginMaster il rischio è espresso da policy statiche e dichiarate su tenant, progetto e ruolo — 2FA TOTP disabilitata, opzionale o obbligatoria, più i parametri di sessione e di blocco — non da un punteggio di rischio calcolato in tempo reale: ogni decisione è spiegabile e verificabile in audit. Ecco cosa si configura oggi:

Per rendere le policy revisionabili conviene scriverle come matrice prima di configurarle. L'esempio che segue è pseudocodice illustrativo, non il formato di configurazione del prodotto:

tenant: acme
progetti:
  console-deploy:   { criticita: alta,  sessione: 15m, tentativi_max: 5 }
  fatturazione:     { criticita: alta,  sessione: 1h,  tentativi_max: 5 }
  wiki-interno:     { criticita: bassa, sessione: 8h,  tentativi_max: 10 }
regole_2fa:
  - se: criticita == alta            allora: obbligatoria
  - se: ruolo in [admin, approvatore] allora: obbligatoria
  - altrimenti:                       opzionale
registrazione:
  domini_autorizzati: [acme.it]
sso_abilitati: [entra-id]
periodo_grazia_enrolment: 14d

Segmentazione al livello di identità: chiavi per tenant e per progetto

La microsegmentazione di rete separa i flussi; la segmentazione crittografica dell'identità separa le fiducie. In LoginMaster ogni tenant e ogni progetto ha chiavi proprie e ogni token è firmato due volte (RS256), da Tenant e Cloud: un token emesso per il progetto A fallisce la validazione nel progetto B, e non per un controllo applicativo che qualcuno potrebbe dimenticare. È il principio "assume breach" applicato all'identità: la compromissione di un contesto non si propaga agli altri.

C'è un secondo livello, spesso trascurato: il fornitore dell'IAM. In molte piattaforme il vendor è implicitamente una parte fidata, perché custodisce gli hash delle credenziali e i dati personali. Nell'architettura Tenant-Cloud di LoginMaster i dati personali restano sul tenant del cliente e il Cloud opera solo su dati cifrati e pseudonimizzati; le password sono protette con Argon2 e split-salt fra Tenant e Cloud. Il fornitore, quindi, non può accedere alle identità che gestisce: è "never trust" esteso anche alla supply chain. Il meccanismo è spiegato in come funziona un IAM in cui il vendor non può leggere le password.

Identità non umane: servizi, dispositivi, agenti AI

Un programma Zero Trust che copre solo le persone lascia aperta la parte più numerosa delle identità. Le regole sono le stesse, con credenziali diverse:

• Un'identità per ogni servizio, dispositivo o agente, mai condivisa: in LoginMaster il dispositivo è un tipo di soggetto distinto dall'utente, con credenziali proprie.
• Chiavi API per il traffico server-to-server, revocabili singolarmente senza impattare le altre identità.
• Supporto nativo ad AWS IoT con protocollo MQTT per i dispositivi, gestiti dallo stesso pannello di utenti e applicazioni.
• Agenti AI con identità e permessi propri, mai con il token personale di uno sviluppatore: l'agente deve poter fare meno della persona per cui agisce, non di più.
• Credenziali protette con Argon2id e split-salt e validate da token a doppia firma, isolate per tenant.

Approfondimenti: identità degli agenti AI, identità dei dispositivi IoT e la guida identità non umane: IoT, API key e agenti AI.

Fase 3 (giorni 90-180) — Ciclo di vita, revoca e misura

Joiner-mover-leaver come operazioni API

Il privilegio minimo si degrada con il tempo: le persone cambiano ruolo e accumulano permessi (il cosiddetto "privilege creep"). L'unico rimedio che scala è legare il ciclo di vita a eventi automatici.

In LoginMaster il provisioning e la revoca si automatizzano oggi tramite REST API e SDK TypeScript e .NET. All'offboarding cancellare il soggetto non basta: la procedura deve revocare come passi distinti accessi ai progetti, chiavi API e sessioni attive, e verificare ciascuno. La revoca delle sessioni è applicata lato server tramite blacklist dei token, quindi una sessione revocata smette davvero di essere valida. Con la federazione Entra ID / Google Workspace, un utente disattivato nella directory non riesce più ad autenticarsi. Il provisioning via SCIM 2.0 e i webhook di lifecycle sono in roadmap: lo schema di integrazione con il sistema HR è nella guida provisioning e ciclo di vita via REST API e SDK e su provisioning degli utenti.

Ricertificazione periodica degli accessi

Una volta al trimestre per i ruoli privilegiati, una volta all'anno per gli altri, il responsabile di ogni applicazione conferma o revoca i privilegi delle persone e delle identità non umane del proprio progetto. La ricertificazione funziona solo se il modello dei ruoli è piccolo e se il responsabile vede i dati giusti: chi ha il ruolo, da quando, ultimo accesso. È l'evidenza che ISO/IEC 27001 (controllo 5.18) e NIS2 si aspettano di trovare.

Visibilità: eventi di identità e SIEM

Il settimo principio NIST chiede di raccogliere informazioni per migliorare la postura. Il connettore SIEM nativo di LoginMaster (Syslog CEF su TLS, verso Splunk, QRadar, Sentinel o Elastic) è in roadmap: finché non è disponibile, l'inoltro degli eventi di identità al SIEM va pianificato come lavoro di integrazione dedicato, e conviene concordarlo con il fornitore prima di impegnarsi su una data di audit. Quali eventi servono e come mapparli ai controlli è nella guida log di accesso per ISO 27001 e SIEM; lo stato aggiornato di ogni funzione è su chi siamo.

I KPI da misurare (prima, durante e dopo)

Senza misure, lo Zero Trust resta una dichiarazione d'intenti. Questi indicatori vanno misurati alla fine della fase 1 come baseline e poi ogni mese; gli obiettivi sotto sono indicazioni di direzione, da tarare sulla tua organizzazione, non risultati garantiti.

Gli errori che fanno fallire il progetto

• Partire comprando un prodotto di rete prima di sapere chi accede a cosa.
• Applicare la MFA a tutti con la stessa intensità: l'attrito spinge le persone a cercare scorciatoie. La MFA per policy concentra il costo dove c'è il rischio.
• Lasciare ai fornitori di SaaS e IAM un accesso implicito ai dati: un vendor che può leggere le credenziali è una parte fidata non dichiarata.
• Dimenticare le identità non umane, che sono spesso più numerose di quelle umane e non fanno mai logout.
• Considerare il progetto concluso: senza ricertificazione e KPI il privilegio minimo torna privilegio massimo in un anno.
• Dichiarare supportate funzioni che non lo sono: in selezione chiedi sempre cosa è disponibile oggi e cosa è in roadmap.

Come LoginMaster si colloca nell'architettura

LoginMaster è una piattaforma IAM e CIAM europea, progettata e sviluppata in Italia, con prezzo flat per tenant e progetti e utenti illimitati: estendere lo Zero Trust a clienti, partner e identità non umane non fa crescere il costo per utente. Per gli obblighi normativi collegati vedi conformità GDPR e NIS2, allineamento ISO 27001 e la guida NIS2 e gestione degli accessi; se gestisci sia dipendenti sia clienti finali, la distinzione è in IAM vs CIAM.