Implementare una strategia Zero Trust: ruoli, responsabilità e metriche

Chi oggi vuole implementare una strategia Zero Trust si accorge rapidamente: la vera barriera raramente è la mancanza di uno strumento, ma la mancanza di chiarezza. Zero Trust è un modello operativo per identità, dispositivi, reti, dati e applicazioni. Sposta le decisioni dal «l’interno è affidabile» a «ogni accesso è verificato in modo continuo». Questo incide profondamente sui processi: autorizzazioni, gestione delle modifiche, Incident Response, prove di audit e non ultimo sull’esperienza utente.

Affinché un’iniziativa Zero Trust non si riduca a una raccolta di singole misure di sicurezza, servono tre elementi che nella pratica spesso mancano: (1) un modello di ruoli e responsabilità che vincoli in modo chiaro IT, Security e le unità di business, (2) policy attuabili che possano essere integrate in esercizio e progetti, e (3) metriche che rendano trasparenti progresso e rischio senza creare un mostro di reporting.

Questo articolo fornisce esattamente questo: una struttura di governance pratica, una logica RACI per i componenti critici e un set di KPI che sia solido tanto per la direzione IT quanto per compliance e audit. I termini tecnici vengono brevemente inquadrati, affinché decisori e responsabili di esercizio parlino la stessa lingua.

Implementare una strategia Zero Trust: cosa significa Zero Trust nella pratica (e cosa non è)

Zero Trust viene spesso frainteso come «tutto è proibito, finché non è esplicitamente consentito». In pratica non si tratta di un grado massimo di RESTrizione, ma di fiducia controllata con una giustificazione verificabile. I principi fondamentali possono essere ridotti a tre linee guida operative:

• Verificare esplicitamente: l’accesso è vincolato all’identità, allo stato del dispositivo, al contesto (luogo, tempo, rischio) e alla risorsa. I meccanismi tipici sono MFA (autenticazione multi-fattore) e Conditional Access (regole di accesso basate sul contesto).
• Least Privilege: ciascuno riceve solo i privilegi necessari per svolgere il compito, e solo per il tempo necessario. Questo riguarda sia gli utenti operativi sia gli account amministrativi e i service account.
• Presupporre una compromissione: si pianifica come se un attaccante fosse già presente nella rete. Ne conseguono segmentazione, logging accurato e reazione rapida.

Cosa Zero Trust non è: un singolo prodotto, un puro progetto di rete o una singola misura IAM. Un’«architettura Zero Trust» è piuttosto un’immagine obiettivo che viene implementata gradualmente attraverso più domini: identità (IAM), account privilegiati (PAM), endpoint (Endpoint Management/EDR), accesso di rete (ZTA/Proxy/VPN-Ersatz), accesso ai dati (DLP/Classification) e osservabilità (Logging/SIEM).

Perché ruoli e responsabilità determinano successo o stallo

Zero Trust genera molte nuove „piccole decisioni“: un account di servizio può ancora accedere ai database di produzione senza MFA? Quali requisiti sui dispositivi valgono per i fornitori esterni? Quali eccezioni sono ammesse, per quanto tempo e chi le approva? Se queste decisioni non sono ancorate in un modello chiaro, emergono tre tipici scenari di errore:

• Eccezioni in ombra: i team eludono le policy perché i processi sono troppo lenti o non c’è nessuno responsabile. Risultato: il rischio reale aumenta, la capacità di audit diminuisce.
• Blocchi eccessivi: la security impone regole rigide senza riscontro operativo. Risultato: il lavoro produttivo ne risente, i progetti si rallentano, cresce la pressione per disattivare i controlli.
• Cecità di misurazione: si fa «molto», ma nessuno può dire se il rischio diminuisce o se aumenta solo il carico di lavoro.

La contromisura è la governance classica, ma adattata in modo concreto a Zero Trust: ruoli definiti, RACI per ciascun elemento di controllo e un set snello di KPI che provengono direttamente dai sistemi (Identity Provider, Endpoint Management, SIEM, Ticketing).

Modello di ruoli per l’implementazione di una strategia Zero Trust

A seconda della dimensione aziendale, i ruoli sono ricoperti da persone o da team. Importante: la responsabilità non è delegabile, i compiti sì. I ruoli seguenti hanno dimostrato la loro efficacia nella pratica:

Executive Sponsor (CIO/responsabile IT o direzione con riferimento all’IT)

Garantisce budget e priorità, decide i conflitti tra security e business e accetta consapevolmente i rischi (Risk Acceptance). Senza uno sponsor le eccezioni diventano lo stato normale.

CISO/Responsabile della sicurezza delle informazioni

Responsabile dell’obiettivo di sicurezza, della logica delle policy e del modello di rischio. Importante: non «gestire tutto in prima persona», ma rendere i requisiti verificabili e governarli tramite metriche.

Direzione del programma Zero Trust (Security/IT congiunte)

Orchestra la roadmap, le dipendenze e le ondate di rollout. Questo ruolo è centrale per la prioritizzazione: quali sistemi prima, quali controlli a quale profondità e quali quick win alleggeriscono immediatamente l’operatività (es. Admin-MFA, conformità dei dispositivi).

Responsabile IAM (Identity and Access Management)

L’IAM comprende identità, ruoli, gruppi, autenticazione e provisioning (Joiner/Mover/Leaver). Il responsabile IAM garantisce che i permessi siano tracciabili e che gli accessi non vengano concessi «via mail».

Responsabile PAM (Privileged Access Management)

Il PAM gestisce gli account privilegiati: accessi admin, account break-glass, credential vaulting, registrazione delle sessioni. Questo ruolo è decisivo, perché i privilegi sono la scorciatoia più frequente per gli attaccanti.

Responsabile Endpoint Management/Workplace

Responsabile dello stato dei dispositivi (livello di patch, crittografia, agente EDR, Secure Boot) e quindi della base per il Conditional Access. Senza una solida conformità dei dispositivi, Zero Trust si riduce rapidamente a «solo MFA».

Gestione rete e piattaforme

Implementa segmentazione, percorsi di accesso e controlli di piattaforma (ad es. ZTNA-Gateways, proxy, regole firewall, Cloud Security Controls). Importante: percorsi standard documentati invece di rotte speciali individuali per ogni applicazione.

Application Owner / Responsabili di sistema

Responsabile dal punto di vista funzionale e tecnico per applicazioni e dati. Decide sulla classificazione dei dati, sui pattern di integrazione, sugli account di servizio e sulle finestre di implementazione. Senza un Application Owner, regole di eccezione chiare sono difficili da applicare.

Interfaccia Compliance/Privacy/Audit

Traduce i requisiti normativi (es. NIS2 come direttiva UE per la cybersicurezza, ISO 27001 come standard di sistema di gestione) in requisiti di evidenza verificabili: quali log, quali autorizzazioni, quali versioni delle policy vengono presentate in sede di audit?

Matrice RACI: chi decide, chi attua, chi fornisce le evidenze?

Una matrice RACI (Responsible, Accountable, Consulted, Informed) evita che «tutti siano in qualche modo coinvolti». Di seguito un profilo praticabile per tipici componenti Zero Trust. Adattate le denominazioni dei ruoli alla vostra organizzazione, non la logica.

RACI (forma breve, esemplificativa)

Componente / Decisione                     R            A            C                          I
-----------------------------------------------------------------------------------------------------------
Zero-Trust-Policy-Set (regole di base)     CISO         Sponsor      IT-Betrieb, Compliance       Reparti specialistici
MFA-Standard (chi, quando, eccezioni)      IAM-Owner    CISO         Service Desk, Compliance     Tutti gli utenti
Conditional Access (dispositivo, posizione, rischio)IAM-Owner CISO    Endpoint-Owner, SOC          Direzione IT
PAM-Umfang (amministratori, terze parti, emergenze)  PAM-Owner     CISO         IT-Betrieb, Audit            Sponsor
Standard di conformità dei dispositivi     Endpoint-Owner   Direzione IT   CISO, Rappresentanza dei lavoratori/HR         Utenti
Segmentazione / percorsi di accesso        Operazioni di rete   Direzione IT   CISO, App Owner              SOC
Logging/SIEM-Use-Cases & retention      SOC/SIEM-Owner CISO         Protezione dei dati, Operazioni IT      Audit
Processo di eccezione (Risk Acceptance)    Responsabile programma  Sponsor      CISO, Compliance, App Owner  Audit
On-/Offboarding (Joiner/Mover/Leaver)      IAM-Owner     Direzione IT   HR, reparto specialistico              CISO
Accesso di terze parti (fornitori)         PAM-Owner     Direzione IT   Acquisti, Compliance, App Owner       CISO

Importante per l’auditabilità: per ogni componente deve essere chiaro, dove si generano le evidenze (es. ticket, repository delle policy, IdP-Logs, PAM-Reports) e chi può fornirle in modo riproducibile su richiesta.

Governance che funziona in esercizio: policy, eccezioni e change control

Zero Trust si basa sulle policy. Una policy non è solo un documento, ma una regola leggibile da macchina (es. regola di Conditional Access) unitamente alla governance di accompagnamento: versionamento, approvazione, rollout, monitoraggio, eccezioni.

Livelli di policy che dovreste separare con chiarezza

• Principi: poche, linee guida stabili (es. «accessi amministrativi solo tramite PAM»).
• Standard: concreti e verificabili (es. «MFA per tutti gli accessi remoti», «i dispositivi devono essere cifrati»).
• Applicazione tecnica: regole nei sistemi (IdP, endpoint, rete, cloud).
• Eccezioni: temporanee, basate sul rischio, con owner e misure compensative (es. segmentazione più stretta, monitoraggio aggiuntivo).

Modello: contenuto minimo per un processo di eccezione (a prova di audit)

Le eccezioni sono normali, ma devono essere controllate. Uno standard praticabile è un template di ticket o workflow con i seguenti campi obbligatori:

• Risorsa/applicazione, gruppi di utenti o account interessati
• Policy specifica dalla quale si devia
• Motivazione (tecnica/organizzativa), impatto sul business senza l’eccezione
• Valutazione del rischio (es. basso/medio/alto) e classificazione dei dati
• Misure compensative (registrazione dei log, segmentazione, diritti temporanei, monitoraggio)
• Data di inizio, data di fine (sunset), data di revisione

Change-Control: Perché Zero Trust non è un ‚imposta una volta sola‘

Nuove applicazioni, nuove integrazioni, M&A, migrazioni cloud, modelli di lavoro modificati: tutto questo cambia i percorsi di accesso. Per questo Zero Trust deve essere integrato nei processi di change esistenti. In pratica ciò significa:

• Ogni change con impatto su identità o rete deve ricevere un Security-Impact-Check (breve questionario).
• Le policy vengono versionate; i rollout avvengono in fasi (pilota, gruppi controllati, ampia distribuzione).
• È previsto un rollback: se una policy blocca troppo, deve essere chiaro come ripristinare rapidamente e in modo controllato, senza aprire falle di sicurezza.

Logica di attuazione: dare priorità in base al rischio, non alla conformazione del parco sistemi

Molti programmi falliscono perché sono organizzati per silos tecnologici („prima rete, poi IAM“). Meglio una sequenza basata sul rischio lungo percorsi di attacco tipici e colli di bottiglia organizzativi.

Fase 1: Stabilizzare identità e accessi privilegiati

Quando un attaccante compromette identità, la distinzione „interno/esterno“ diventa irrilevante. Perciò, prima di tutto:

• MFA per tutti gli utenti, in particolare per gli accessi amministrativi e remoti; gli account Break-Glass devono essere strettamente limitati e utilizzati in modo controllato.
• PAM per amministratori e sistemi critici (Vaulting, diritti amministrativi temporanei, tracciabilità delle sessioni).
• Inventariare e ruotare gli account di servizio; ove possibile passare a procedure più moderne (p. es. token di breve durata).

Fase 2: Conformità dei dispositivi come condizione di accesso

Conditional Access è efficace quanto la qualità degli attributi del dispositivo. Definite requisiti minimi (crittografia, stato delle patch, EDR, blocco schermo) e associate questi requisiti agli accessi a risorse critiche.

Fase 3: Unificare i percorsi di accesso (ZTNA/Proxy, Segmentazione)

Invece di ampi accessi di rete (VPN classica), si stabiliscono percorsi basati sull’accesso: gli utenti raggiungono solo le applicazioni di cui hanno bisogno. Qui per segmentazione non si intende necessariamente microsegmentazione a livello host, ma prima di tutto: separare zone critiche, limitare il traffico est-ovest, separare i percorsi amministrativi.

Fase 4: Raffinare la visibilità su dati e applicazioni

Al più tardi a questo livello gli Application Owner devono fornire: classificazione dei dati, transazioni critiche, interfacce, account tecnici. Zero Trust riguarda anche le API (Application Programming Interface, cioè interfacce definite tra sistemi): chi può richiamare quali dati e con quale frequenza, e come viene rilevato un uso improprio?

Metriche: Cosa misurare affinché Zero Trust sia governabile

Senza metriche Zero Trust diventa una questione di fede. Con le metriche sbagliate si genera azionismo. Buoni KPI hanno tre caratteristiche: sono (1) derivabili dai sistemi, (2) utilizzabili per decisioni, (3) robusti contro la manipolazione dei valori.

KPI-Set 1: Identità & Accesso (IAM)

• Copertura MFA: percentuale degli account utente attivi con MFA, distinta per utenti interni/esterni e per account privilegiati.
• Autenticazione rafforzata in caso di rischio: percentuale di login a rischio per i quali sono stati forzati fattori aggiuntivi (da segnali di rischio dell’IdP).
• Tempi Joiner/Mover/Leaver: tempo fino alla revoca dell’account dopo uscita o cambio ruolo; importante per audit e rischio insider.
• Account orfani: numero di account senza login da X giorni o senza assegnazione di owner.

KPI-Set 2: Privileged Access (PAM)

• Copertura PAM per accessi amministrativi critici: percentuale dei workflow amministrativi che passano tramite PAM (non solo „PAM è installato“).
• Just-in-Time/Just-Enough-Access: quota dei diritti amministrativi assegnati temporaneamente vs. privilegi assegnati in modo permanente.
• Uso del Break-Glass: frequenza e qualità della motivazione; ogni evento è un trigger per una revisione.
• Rotazione delle credenziali: percentuale delle credenziali privilegiate che sono state ruotate entro i termini definiti.

KPI-Set 3: Device Trust (Endpoint/Postazione)

• Compliance-Quote: percentuale dei dispositivi gestiti che soddisfano gli standard minimi (crittografia, patch, EDR).
• Shadow Devices: dispositivi rilevati ma non gestiti che tentano accessi.
• Time-to-Patch (kritisch): tempo dalla disponibilità all’installazione di aggiornamenti di sicurezza critici (raggruppato per criticità).

KPI-Set 4: Controlli di rete e applicativi

• Percorsi di accesso ridotti: numero/percentuale delle applicazioni raggiungibili senza ampio accesso di rete (ZTNA/Proxy invece di „Netz frei“).
• Violazioni di segmentazione: connessioni Est-Ovest non autorizzate rilevate (da telemetria di rete).
• Rischio dei Service-Accounts: numero di Service-Accounts con privilegi estesi o senza rotazione/proprietario.

KPI-Set 5: Detection, Response e Audit-Evidence

• Log-Completeness: percentuale dei sistemi critici i cui log di autenticazione, amministrazione e accesso arrivano centralizzati (SIEM/piattaforma di log).
• MTTD/MTTR (Trend): Mean Time To Detect/Respond come trend, non come verità assoluta; importante è la coerenza del metodo di misurazione.
• Policy-Drift: deviazioni tra lo standard definito e la configurazione reale (es. regole disattivate, eccezioni non riviste).
• Evidence-Lead-Time: tempo per fornire le evidenze richieste per un audit (ticket, report, estratti di log). Questo è un indicatore di management sottovalutato.

Ritmo di reporting: poco, ma vincolante

Un ritmo sensato è mensile a livello operativo (Security/operazioni IT) e trimestrale nello Steering (Sponsor, CISO, Compliance). È fondamentale che ogni cluster di KPI risponda a una domanda chiara, per esempio: «Quanto è probabile un Account Takeover?» o «Quante eccezioni sono giustificate tecnicamente e temporanee?»

Prospettiva audit e regolamentare: evidenze invece di dichiarazioni d’intenti

Che si tratti di ISO 27001, revisione interna o requisiti di NIS2: le verifiche raramente si concentrano su «avete Zero Trust?», ma sui controlli e sulla loro efficacia. Domande tipiche di audit sono: Come assicurate che solo persone autorizzate abbiano accesso a sistemi critici? Come vengono registrate le azioni privilegiate? Come vengono approvate e monitorate le eccezioni?

Un programma Zero-Trust resistente all’audit produce artefatti di evidenza „by design“:

• Versioni delle policy con protocollo di approvazione (chi, quando, perché)
• Report di sistema: copertura MFA, utilizzo PAM, compliance dei dispositivi
• Evidenze nei ticket: eccezioni con data di scadenza, revisioni, accettazione del rischio
• Protocolli: log amministrativi e di autenticazione, retention centrale e protezione degli accessi ai log (in modo che i log stessi non possano essere manipolati)

Nota pratica: gli auditor tendono ad accettare più facilmente le eccezioni se (1) l’eccezione è temporanea, (2) è documentata una misura compensativa e (3) l’organizzazione può dimostrare di ridurre attivamente le eccezioni (metrica: «eccezioni scadute»).

Costi, sforzo e conseguenze operative: dove Zero Trust assorbe risorse reali

Zero Trust comporta costi, ma molti non sono licenze bensì sforzi operativi e di progetto. Chi non li considera genera frustrazione e shadow-IT. I principali fattori di costo:

• Qualità dei dati di identità: modelli di autorizzazione, gestione dei ruoli, Ownership (chi è responsabile per un account?).
• Riadattamento delle applicazioni: applicazioni legacy senza autenticazione moderna o con account hardcoded richiedono adattamenti o gateway intermedi.
• Service Desk e comunicazione: MFA-reset, enrollment dei dispositivi, processi di eccezione. Buoni flussi self-service riducono significativamente questo carico in seguito.
• Monitoring e Incident Response: più segnali significano più triage. Senza prioritarizzazione dei casi d’uso il SOC (Security Operations Center) sarà sovraccarico.

Contemporaneamente emergono vantaggi operativi se implementato correttamente: meno diritti amministrativi a lungo termine, percorsi di accesso più chiari, deprovisioning più rapido, migliore tracciabilità in caso di incidenti. Questi vantaggi dovrebbero essere esplicitamente considerati come criterio decisionale, non attesi come „effetto collaterale“.

Lista di controllo: pronti in 30 giorni (senza grandi dibattiti architetturali)

I punti seguenti sono stati selezionati per indirizzare prevalentemente aspetti di governance e fondamentali e per avere un effetto rapido:

• Nomina di un Executive Sponsor, stabilire una serie di riunioni di steering per 6 mesi
• Ufficializzare la direzione del programma Zero Trust e gli owner per IAM, PAM, endpoint, rete/SIEM
• Definire le top-10 di sistemi critici e aree di dati (può collegarsi alle liste esistenti di requisiti di protezione o di rischio)
• Approvare un set minimale di policy: MFA, accesso admin tramite PAM, compliance dei dispositivi per accessi critici, processo di eccezione con termine prefissato (sunset)
• Stabilire una baseline iniziale di KPI: copertura MFA, account orfani, utilizzo Break-Glass, compliance dei dispositivi
• Definire il luogo per le evidenze di audit: dove risiedono le versioni delle policy, i report, i ticket di eccezione, le prove nei log?

Ostacoli frequenti e come evitarli

«Prima costruiamo l’architettura target perfetta»

Una visione target è importante, ma Zero Trust è un modello operativo iterativo. Iniziate con policy minime ben definite e misurate gli effetti. L’architettura matura con le conoscenze derivate dalle eccezioni, dagli incidenti e dai dati operativi.

«MFA ovunque» come strategia unica

MFA è necessaria, ma non sufficiente. Senza PAM, compliance dei dispositivi e logging, il rischio dovuto a furto di token, misconfigurazioni e account eccessivamente privilegiati rimane elevato.

Responsabilità poco chiare per service account e interfacce

I service account sono spesso „senza padrone“. Definite Ownership e rotazione, altrimenti rimane un punto di accesso permanente. Questo vale particolarmente per le integrazioni tra software di business, database e piattaforme di integrazione.

Troppe eccezioni senza sunset

Un’eccezione senza data di scadenza è una sovrascrittura nascosta delle policy. Misurate le eccezioni scadute e rendetele visibili in sede di steering.

Conclusione: Zero Trust è un problema di governance con leve tecniche

Una strategia Zero Trust fallisce raramente perché „la tecnologia non ce la fa“, ma perché le decisioni non sono ancorate correttamente: chi definisce le policy, chi si assume i rischi, chi fornisce le evidenze? Se definite ruoli (Owners), RACI e un set snello di metriche, Zero Trust diventa pianificabile: le eccezioni vengono controllate, l’operatività non viene travolta e i requisiti di audit possono essere soddisfatti con evidenze affidabili.

Cominciate con l’identità, gli accessi privilegiati e la conformità dei dispositivi, istituite un rigoroso processo di eccezione con Sunset e costruite il vostro set di KPI in modo che sostenga le decisioni. Allora „Zero Trust“ passerà da parola d’ordine a realtà operativa nella vostra IT.