Sistemi IAM e privilegi minimi nella governance cyber

Ogni incidente di sicurezza significativo degli ultimi anni ha in comune un elemento ricorrente: credenziali compromesse o privilegi eccessivi.

Il ransomware che cifra l’intera infrastruttura di un’organizzazione raramente sfrutta una vulnerabilità zero-day sofisticata: quasi sempre si propaga attraverso account con privilegi amministrativi mal governati. Il data breach che espone milioni di record spesso origina non da un attacco esterno brillante, ma da un account interno con accesso a più dati di quanti ne servissero realmente. L’insider threat che compromette sistemi critici è reso possibile da permessi mai revocati dopo un cambio di ruolo avvenuto mesi prima.

In tutti questi scenari, un programma maturo di Identity and Access Management (IAM) sarebbe stato il controllo in grado di limitare significativamente il danno, se non di prevenirlo del tutto.

Questo perché l’IAM non è una tecnologia, ma una disciplina di governance che definisce chi ha accesso a cosa, perché, per quanto tempo e con quale livello di verifica.

Quando è implementata correttamente, trasforma la gestione delle identità da una funzione IT amministrativa in un controllo di sicurezza strategico che riduce la superficie di attacco, limita il movimento laterale e produce la tracciabilità necessaria per la compliance normativa.

Il ruolo dei sistemi IAM nella strategia di cyber governance

L’Identity and Access Management è l’insieme di politiche, processi e tecnologie che governano la gestione delle identità digitali e dei loro diritti di accesso alle risorse dell’organizzazione.

In un’infrastruttura moderna, distribuita su cloud, on-premise e ambienti ibridi, con utenti che accedono da dispositivi diversi in location diverse, l’IAM è il sistema che risponde continuamente a tre domande fondamentali: chi sei (autenticazione), cosa ti è permesso fare (autorizzazione), e cosa hai fatto (audit e tracciabilità).

Queste tre funzioni, integrate in un sistema coerente, costituiscono il nucleo della governance della sicurezza.

La relazione tra IAM e Zero Trust è strutturale: il modello Zero Trust («non fidarsi mai, verificare sempre») presuppone che nessuna identità sia intrinsecamente fidata per il solo fatto di trovarsi all’interno della rete aziendale.

Ogni richiesta di accesso deve essere valutata in funzione dell’identità verificata del richiedente, del dispositivo utilizzato, del contesto della richiesta (ora, localizzazione, comportamento recente) e della sensibilità della risorsa richiesta.

Questa valutazione continua e contestuale è impossibile senza un sistema IAM maturo che centralizzi la gestione delle identità, implementi l’autenticazione adattiva e mantenga log completi di ogni accesso.

Definizione del principio del minimo privilegio e vantaggi per il business

Il principio del minimo privilegio (Principle of Least Privilege, PoLP) stabilisce che ogni utente, processo o sistema dovrebbe avere accesso esclusivamente alle risorse strettamente necessarie per svolgere le proprie funzioni, e solo per il tempo in cui tale accesso è necessario.

Formulato per la prima volta da Jerome Saltzer e Michael Schroeder nel 1975 nel contesto della progettazione dei sistemi operativi, il PoLP è oggi uno dei principi fondanti della sicurezza informatica moderna, citato esplicitamente nelle linee guida NIST, nei framework CIS Controls e nei requisiti normativi di NIS2 e DORA.

I vantaggi del PoLP per il business vanno ben oltre la riduzione del rischio tecnico.

Dal punto di vista della conformità normativa, il minimo privilegio è un requisito esplicito o implicito di praticamente tutti i framework di sicurezza rilevanti: dimostrare la sua implementazione semplifica significativamente i processi di audit e certificazione.

Dal punto di vista operativo, la riduzione dei permessi non necessari riduce anche la complessità della gestione: meno eccezioni, meno conflitti di autorizzazione, meno overhead di riconciliazione tra sistemi diversi.

Dal punto di vista della resilienza, limita il raggio di azione di ogni incidente: un account compromesso con accesso minimo causa danni minimi; un account compromesso con accesso amministrativo globale può compromettere l’intera infrastruttura.

Come l’isolamento degli accessi riduce l’impatto di un potenziale attacco

L’isolamento degli accessi, cioè la separazione netta tra utenti con funzioni diverse, tra ambienti con livelli di criticità diversi, tra sistemi con diversi profili di rischio, è il meccanismo operativo attraverso cui il principio del minimo privilegio si traduce in resilienza concreta.

Un’organizzazione che ha implementato correttamente l’isolamento degli accessi è un’organizzazione in cui la compromissione di un account non implica automaticamente la compromissione di altri account o sistemi: ogni identità è una bolla isolata con connessioni esplicite e limitate verso altre identità e risorse.

Il valore dell’isolamento emerge con particolare chiarezza nell’analisi degli incidenti reali. L’attacco alla Colonial Pipeline del 2021, che ha causato l’interruzione del più grande oleodotto degli Stati Uniti, è partito da una VPN con credenziali compromesse che aveva accesso a sistemi OT non adeguatamente separati dalla rete IT.

Se l’accesso VPN fosse stato limitato ai soli sistemi necessari, il danno sarebbe rimasto confinato. Il caso SolarWinds ha mostrato come account di servizio con privilegi eccessivi abbiano consentito il movimento laterale verso sistemi che non avrebbero mai dovuto essere raggiungibili da quel tipo di account.

In entrambi i casi, l’isolamento degli accessi non avrebbe prevenuto l’accesso iniziale, ma avrebbe drasticamente limitato il raggio d’azione dell’attaccante.

Componenti chiave di un’architettura IAM orientata alla sicurezza

Un’architettura IAM matura si compone di strati funzionali interconnessi che coprono l’intero ciclo di vita dell’identità: dalla creazione alla gestione quotidiana, dalla verifica dell’autenticità alla tracciabilità degli accessi.

I componenti fondamentali di questa architettura sono:

• l’Identity Provider (IdP) centralizzato;
• il sistema di autenticazione multi-fattore;
• il motore di autorizzazione basato sui ruoli (RBAC) o sugli attributi (ABAC);
• il sistema di Privileged Access Management (PAM) per gli account privilegiati;
• la piattaforma di Identity Governance and Administration (IGA) per il ciclo di vita e le revisioni periodiche.

In ambienti cloud e multicloud, l’architettura IAM deve gestire un’ulteriore complessità: ogni provider cloud ha il proprio sistema IAM nativo (AWS IAM, Azure Entra ID, Google Cloud IAM) con modelli di permessi e logiche differenti.

La soluzione architetturale è la federazione delle identità attraverso un Identity Provider centralizzato (tipicamente Microsoft Entra ID, Okta, Ping Identity o un sistema equivalente) che gestisce le identità in un’unica fonte di verità e le federa con tutti i provider cloud e le applicazioni SaaS attraverso protocolli standard (SAML 2.0, OIDC, SCIM).

Questo approccio garantisce che la gestione del ciclo di vita delle identità – provisioning, modifica, deprovisioning – avvenga in un unico punto, riducendo il rischio di inconsistenze tra sistemi diversi.

Autenticazione a più fattori e sistemi di verifica basati sul contesto

L’autenticazione a più fattori (MFA) è oggi il controllo di sicurezza con il miglior rapporto tra efficacia e costo nell’intero panorama della cyber security.

Il dato estrapolato dal Microsoft Security Intelligence Report è inequivocabile: l’MFA blocca oltre il 99,9% degli attacchi di account takeover automatizzati.

Eppure, la sua adozione rimane incompleta in molte organizzazioni, spesso limitata agli accessi da internet ma non agli accessi interni o implementata per gli utenti privilegiati ma non per l’intera base utenti.

Questa implementazione parziale lascia aperte le vulnerabilità più sfruttate: le credenziali di account non protetti da MFA sono il vettore di accesso iniziale nella maggioranza degli incidenti documentati.

L’autenticazione adattiva o risk-based porta il concetto di MFA a un livello superiore: invece di richiedere sempre lo stesso secondo fattore indipendentemente dal contesto, valuta il rischio della richiesta di accesso in tempo reale e calibra il livello di verifica richiesto di conseguenza.

Un accesso da un dispositivo noto, dall’indirizzo IP aziendale, durante l’orario lavorativo standard, con un pattern comportamentale coerente con la storia dell’utente: rischio basso, accesso con solo secondo fattore.

Un accesso da un paese mai visitato prima, alle 3 di notte, da un dispositivo non registrato: rischio alto, richiesta di verifica aggiuntiva o blocco con notifica al team di sicurezza.

Ciclo di vita delle identità aziendali dal provisioning al deprovisioning

Il ciclo di vita di un’identità aziendale è il processo che governa la creazione, la gestione e la dismissione di un account dall’ingresso di un utente nell’organizzazione alla sua uscita.

Ogni fase di questo ciclo presenta rischi specifici se non è governata da processi formali:

• il provisioning senza approvazione porta ad account con permessi eccessivi;
• la gestione senza revisioni periodiche porta all’accumulo di privilegi non necessari;
• il deprovisioning tardivo o incompleto lascia account attivi dopo la cessazione del rapporto di lavoro.

Gli account orfani, cioè gli account di utenti che hanno lasciato l’organizzazione ma il cui accesso non è stato revocato, sono una delle vulnerabilità più frequenti e più sottovalutate nella gestione delle identità.

Le statistiche di settore indicano che in organizzazioni senza processi automatizzati di deprovisioning, una percentuale significativa degli account attivi appartiene a persone che non hanno più un rapporto con l’organizzazione: ex dipendenti, consulenti a progetto terminato, fornitori il cui contratto è scaduto.

Questi account sono potenziali vettori di accesso non autorizzato, sia da parte degli ex-utenti stessi, sia da parte di attaccanti che ne hanno compromesso le credenziali e sono invisibili ai sistemi di monitoraggio comportamentale perché non mostrano anomalie rispetto al pattern storico dell’utente.

Strategie operative per implementare il controllo dei privilegi minimi

L’implementazione operativa del principio del minimo privilegio in un’organizzazione esistente, in cui i permessi si sono accumulati nel tempo senza una governance sistematica, è uno dei progetti IAM più complessi e politicamente delicati.

La complessità tecnica è reale: mappare i permessi effettivi di centinaia o migliaia di utenti su decine di sistemi diversi richiede strumenti dedicati e un processo metodico.

La complessità politica è altrettanto reale: ridurre i privilegi di utenti che li hanno sempre avuti genera resistenza, percezione di perdita di autonomia e potenziali impatti operativi se i permessi vengono rimossi senza un’analisi accurata delle effettive necessità.

La strategia più efficace è quella incrementale: iniziare dall’inventario e dall’analisi (sapere cosa c’è prima di cambiarlo), procedere con la rimozione dei permessi evidentemente superflui (account con zero utilizzo, permessi su sistemi non pertinenti al ruolo) e affrontare i casi più complessi, dove l’utente usa effettivamente permessi che non dovrebbe avere con un processo di rivalutazione che coinvolge il manager e il data owner.

Un approccio che tenta di correggere tutto contemporaneamente genera inevitabilmente impatti operativi e resistenza organizzativa che possono bloccare il progetto prima che produca risultati significativi.

Mappatura dei ruoli aziendali e assegnazione dei permessi granulari

Il Role-Based Access Control (RBAC) è il modello di autorizzazione più diffuso nelle organizzazioni di medie e grandi dimensioni: i permessi vengono assegnati a ruoli, e gli utenti vengono assegnati a ruoli.

Questo approccio semplifica la gestione quando un utente cambia ruolo, si cambia l’assegnazione del ruolo e i permessi si aggiornano automaticamente, ma richiede che i ruoli siano definiti con granularità sufficiente a rispettare il principio del minimo privilegio.

Un sistema con pochi ruoli molto ampi è facile da gestire ma garantisce privilegi eccessivi; un sistema con molti ruoli granulari rispetta il PoLP ma aumenta la complessità della gestione.

L’Attribute-Based Access Control (ABAC) rappresenta l’evoluzione del RBAC: le decisioni di autorizzazione non sono basate solo sul ruolo dell’utente, ma su un insieme di attributi contestuali (il dipartimento, il livello gerarchico, la localizzazione, l’ora del giorno, la classificazione del dato richiesto, lo stato di sicurezza del dispositivo).

Questo approccio consente politiche di accesso molto più precise («i medici del reparto oncologia possono accedere alle cartelle dei propri pazienti nelle ore di servizio dal dispositivo aziendale») ma richiede un’infrastruttura IAM più sofisticata e una gestione degli attributi accurata e aggiornata.

Per le organizzazioni in settori regolamentati con requisiti di accesso granulari – sanità, finanza, difesa – l’ABAC è spesso l’unico approccio in grado di soddisfare contemporaneamente i requisiti operativi e quelli di conformità.

Gestione degli accessi privilegiati per gli amministratori di sistema

Gli account privilegiati di amministratori di sistema, DBA, account di servizio con accesso root e account di gestione dei sistemi di sicurezza sono il bersaglio più appetibile per un attaccante che ha ottenuto un accesso iniziale.

Con un account privilegiato, il movimento laterale verso qualsiasi sistema dell’organizzazione diventa immediatamente possibile.

Il Privileged Access Management (PAM) è la categoria di strumenti e processi dedicata specificamente alla protezione di questi account ad alto rischio, e la sua implementazione è raccomandata come priorità assoluta in qualsiasi programma IAM.

Un aspetto spesso trascurato riguarda gli accessi privilegiati dei fornitori terzi: system integrator, MSP e consulenti IT che operano con credenziali privilegiate sui sistemi del cliente sono uno dei vettori di attacco supply chain più frequentemente documentati e uno dei meno governati dai programmi PAM tradizionali, che tendono a concentrarsi sugli account interni trascurando quelli esterni.

Le funzionalità core di una soluzione PAM includono:

il vault delle credenziali privilegiate (le password degli account amministrativi non sono mai visibili agli utenti, vengono generate automaticamente, ruotate periodicamente e iniettate nelle sessioni senza essere mostrate);

la registrazione completa delle sessioni privilegiate (ogni comando eseguito durante una sessione amministrativa viene registrato con timestamp, consentendo l’analisi forense post-incidente e la verifica delle attività);

il controllo granulare dei comandi (possibilità di limitare quali comandi specifici un utente privilegiato può eseguire, anche all’interno di una sessione amministrativa);

l’accesso just-in-time (gli account privilegiati vengono abilitati solo per la durata specifica del task, con scadenza automatica e revoca al termine).

Come prevenire il fenomeno del privilege creep nelle organizzazioni

Il privilege creep, cioè la progressiva e involontaria accumulazione di permessi non necessari da parte degli utenti nel corso del tempo, è uno dei problemi più pervasivi nella gestione delle identità aziendali.

Non è il risultato di decisioni deliberatamente sbagliate: è il prodotto naturale di organizzazioni che cambiano.

Un utente che assume temporaneamente le funzioni di un collega in malattia riceve i permessi necessari e poi non li vede revocati. Un manager che partecipa a un progetto speciale ottiene l’accesso ai sistemi del progetto e lo mantiene anche dopo la conclusione. Un dipendente che cambia dipartimento ottiene i permessi del nuovo ruolo senza che quelli del vecchio siano rimossi.

Con il tempo, ogni utente accumula un profilo di permessi che non corrisponde più al suo ruolo attuale: un profilo che, se le sue credenziali vengono compromesse, fornisce all’attaccante un accesso molto più ampio del necessario.

La prevenzione del privilege creep richiede due meccanismi complementari: la revisione periodica degli accessi (access certification o access review) e la gestione formale delle eccezioni temporanee.

La revisione periodica è il processo attraverso cui, a intervalli regolari, ogni manager certifica che i permessi dei propri collaboratori siano ancora appropriati per il ruolo corrente.

Le piattaforme IGA (Identity Governance and Administration) automatizzano questo processo: inviano campagne di revisione ai manager, raccolgono le risposte e implementano automaticamente le revoche approvate, riducendo l’overhead operativo e garantendo la copertura sistematica di tutti gli utenti.

Revisioni periodiche degli accessi e approvazioni temporanee delle funzioni

La frequenza delle revisioni degli accessi deve essere proporzionale alla criticità del sistema e al livello di privilegio dell’account:

• gli account privilegiati (amministratori, DBA, account di servizio) devono essere revisionati almeno trimestralmente;
• gli account standard degli utenti finali almeno semestralmente;
• gli accessi a sistemi critici classificati (sistemi di autenticazione, sistemi di backup, sistemi di sicurezza) almeno ogni 90 giorni con revisione da parte di un responsabile di secondo livello.

Le normative NIS2 e DORA prevedono implicitamente questi requisiti di revisione come parte degli obblighi di gestione del rischio e di controllo degli accessi.

Le approvazioni temporanee, ossia i meccanismi che consentono di concedere accessi eccezionali per un periodo limitato senza modificare permanentemente il profilo dell’utente, sono lo strumento che sostituisce la pratica informale di «dammi i permessi per questo task e poi li togliamo».

Implementati correttamente, prevedono: una richiesta documentata con motivazione e durata prevista, un’approvazione esplicita da parte del responsabile e del data owner, una scadenza automatica che revoca l’accesso senza necessità di intervento manuale, e una notifica al team di sicurezza per gli accessi temporanei a sistemi critici.

Il risultato è che le eccezioni alla regola del minimo privilegio diventano visibili, documentate e automaticamente reversibili invece di trasformarsi silenziosamente in permessi permanenti.

Certificazioni e conformità normativa attraverso la gestione delle identità

La gestione delle identità e degli accessi è un’area trasversale a praticamente tutti i framework di sicurezza e compliance rilevanti per le organizzazioni che operano in ambienti IT complessi.

La ISO 27001:2022, nella sua versione aggiornata, include controlli specifici sull’IAM nell’Annex A: A.5.15 (gestione degli accessi), A.5.16 (gestione delle identità), A.5.17 (informazioni di autenticazione), A.8.2 (diritti di accesso privilegiati), A.8.4 (accesso al codice sorgente).

I CIS Controls v8 includono tre controlli interamente dedicati alla gestione degli accessi (CIS Control 5: Account Management, CIS Control 6: Access Control Management, CIS Control 12: Network Infrastructure Management).

NIS2 richiede esplicitamente l’autenticazione a più fattori e sistemi di autenticazione continua come misure di sicurezza obbligatorie per i soggetti essenziali e importanti.

Soddisfare i requisiti di tracciabilità previsti dai principali standard di sicurezza

La tracciabilità degli accessi, cioè la capacità di ricostruire chi ha avuto accesso a quale risorsa, quando, da quale dispositivo e con quale risultato, è un requisito trasversale a tutti i framework di compliance e assume un’importanza critica nelle attività di risposta agli incidenti.

Senza log completi e integri degli accessi, è impossibile ricostruire la catena di eventi che ha portato a una compromissione, identificare tutti i sistemi raggiunti dall’attaccante, e dimostrare alle autorità di vigilanza la portata effettiva dell’incidente e le misure adottate.

I requisiti di tracciabilità impongono standard precisi su tre dimensioni:

1. la completezza dei log (quali eventi devono essere registrati: ogni autenticazione riuscita e fallita, ogni modifica ai permessi, ogni accesso a risorse classificate, ogni azione di account privilegiati);
2. la conservazione (per quanto tempo i log devono essere mantenuti: NIS2 richiede almeno 12 mesi, con 6 mesi di accesso immediato; GDPR e normative finanziarie possono richiedere periodi più lunghi);
3. l’integrità (i log devono essere protetti da modifiche non autorizzate: il logging centralizzato su sistemi separati dagli ambienti monitorati è il controllo fondamentale per garantire che i log non vengano alterati da un attaccante che ha compromesso i sistemi che li generano).

L’implementazione di un sistema di logging IAM conforme ai requisiti normativi richiede l’integrazione tra il sistema IAM, il SIEM aziendale e una piattaforma di log management con retention configurata sulle scadenze normative.

La correlazione degli eventi IAM con altri eventi di sicurezza nel SIEM (un’autenticazione riuscita seguita da un accesso anomalo a sistemi inusuali, una serie di autenticazioni fallite seguita da un successo da IP diverso) è il meccanismo che trasforma i log da archivio passivo a strumento di rilevamento attivo delle minacce.