Controllo dei privilegi: revisione manuale, IAM e assistenza AI

Per tenere sotto controllo i privilegi esistono tre approcci che non si escludono: la revisione manuale periodica, gli strumenti di gestione delle identità e degli accessi (IAM, Identity and Access Management) e l'assistenza di un agente AI che prepara evidenze e richieste di approvazione. La scelta dipende da quante identità gestisci, quanto spesso cambiano e quanto rischio puoi tollerare tra una verifica e l'altra. In tutti i casi, la decisione su chi può accedere a cosa resta di una persona.

Cosa richiede la revisione manuale delle autorizzazioni

La revisione manuale è il punto di partenza di quasi tutte le aziende: a scadenze concordate, qualcuno esporta l'elenco di utenti, gruppi e permessi e lo confronta con ciò che dovrebbe esserci. Funziona, ma chiede tre cose che spesso mancano: tempo del responsabile, una fotografia affidabile dello stato attuale e un registro delle decisioni prese.

I limiti tipici:

• Fotografia istantanea. La revisione vede lo stato del giorno in cui la fai. Un privilegio concesso il giorno dopo resta invisibile fino al giro successivo.
• Contesto disperso. Capire perché un account ha un certo permesso richiede di interrogare colleghi, ticket e memoria. Senza un registro, ogni revisione riparte da zero.
• Costo crescente. Con poche decine di utenti è faticosa ma fattibile; con centinaia di identità, gruppi annidati e applicazioni diverse diventa un'attività che si rimanda.

Questo non la rende inutile: la revisione manuale è anche il momento in cui si discutono i casi che nessuno strumento può giudicare, per esempio se un ruolo è cambiato davvero o se una deroga ha ancora senso.

Quali compiti svolgono gli strumenti IAM già presenti

Una directory ben tenuta — l'elenco centralizzato di utenti, gruppi e applicazioni, spesso con un provider di identità (IdP, Identity Provider) che gestisce autenticazione e assegnazione dei permessi — copre una parte sostanziosa del problema. In particolare:

• Creazione e chiusura guidate. L'account nasce da una richiesta e si chiude con l'uscita della persona, invece di sopravvivere per dimenticanza.
• Assegnazione per gruppi e ruoli. I permessi seguono il ruolo, non la concessione estemporanea; chi cambia mansione cambia gruppo.
• Registrazione degli eventi. Accessi e modifiche lasciano tracce nei registri della directory, consultabili in caso di verifica.

Quando basta una directory ben tenuta? Quando le identità sono poche e stabili, le applicazioni critiche si contano sulle dita e le variazioni sono rare e sempre motivate. Quando invece gli account crescono, i fornitori entrano ed escono, i privilegi amministrativi si moltiplicano e nessuno ricorda più chi ha approvato cosa, serve un controllo continuo locale: qualcuno — o qualcosa — che osserva le variazioni mentre avvengono, non solo a scadenza. La gestione centralizzata dice come dovrebbero essere le cose; il monitoraggio continuo mostra cosa sta cambiando davvero.

È la stessa logica della pubblicazione NIST SP 800-207 sull'architettura zero trust: nessuna fiducia implicita per posizione di rete o appartenenza al perimetro, e una decisione di autorizzazione per ogni accesso a una risorsa. Attenzione: quella pubblicazione non è una certificazione di prodotto, e nessuno strumento è «conforme zero trust» da solo. Anche le Cybersecurity Performance Goals del CISA — un riferimento volontario nato per le infrastrutture critiche statunitensi, utile come buona pratica — includono tra gli obiettivi il principio dei privilegi minimi.

I tre approcci a confronto

La tabella riassume cosa fa bene ciascun approccio lungo il ciclo di verifica dei privilegi: osservare lo stato, notare le variazioni, decidere e conservare le evidenze.

Il punto non è sostituire un approccio con un altro: la directory resta la fonte della verità, la revisione periodica resta il momento di giudizio umano, e il monitoraggio continuo colma lo spazio tra le due. Su come organizzare la revisione periodica abbiamo dedicato un articolo alla revisione periodica dei privilegi.

Dove l'AI può preparare evidenze e richieste di approvazione

Che ruolo può avere un agente AI senza cedergli decisioni? Quello di un assistente che osserva e prepara, mentre la persona decide. In OverZeus questo ruolo è diviso tra due agenti:

• Athena controlla identità, gruppi e privilegi nelle fonti collegate. Spiega le autorizzazioni rilevate in linguaggio comprensibile e mette in evidenza le variazioni da verificare: per esempio un utente aggiunto a un gruppo amministrativo senza che nelle fonti compaia una richiesta approvata.
• Themis fa rispettare privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI: se un'operazione arriva con un'autorizzazione scaduta o non valida, blocca l'avvio e presenta il motivo. I limiti non dipendono dall'interpretazione del modello.

Il confine è esplicito: l'agente propone, spiega e chiede; l'intervento attivo richiede l'approvazione prevista e il silenzio non autorizza. Anche le credenziali amministrative restano fuori dal modello. Le operazioni attivabili dipendono dalle integrazioni e dalle policy concordate sull'ambiente specifico: in fase di valutazione, chiedi quali fonti identità possono essere collegate nel tuo caso.

Esempio illustrativo: il gruppo che nessuno ha più chiesto

Esempio illustrativo. Lo scenario seguente mostra come i tre approcci lavorano insieme; non racconta un caso avvenuto presso un cliente.

Un'azienda di logistica con una settantina di dipendenti ha creato, un anno prima, il gruppo «trasferte-admin» per consentire a tre persone di configurare il nuovo gestionale delle trasferte. Il progetto è finito, il consulente è uscito, ma il gruppo è rimasto e nel tempo ci sono finite altre due persone «per comodità».

• Con la sola revisione manuale, il gruppo emerge alla revisione semestrale, se qualcuno nota la voce e ricorda a cosa serviva. La motivazione va ricostruita a voce.
• Con la directory ben tenuta, il gruppo è documentato e i registri mostrano quando chi è entrato; ma nessuno legge quei registri finché qualcuno non va a cercare.
• Con il monitoraggio continuo, Athena segnala la variazione quando la quarta persona entra nel gruppo e prepara il caso: composizione precedente, nuovo membro, privilegi che il gruppo concede e possibili impatti di una riduzione. Themis verifica che l'eventuale modifica rientri in un'autorizzazione valida. Il responsabile decide — ridurre, confermare con motivazione, dismettere il gruppo — e la decisione resta registrata con la sua motivazione.

Il risultato pratico: la revisione periodica non riparte da zero, perché le variazioni intermedie sono già segnalate, spiegate e decise con traccia.

Come valutare la tua situazione

Tre domande per capire da dove partire:

1. Quante identità e quante variazioni? Sotto una certa dimensione, una directory ordinata e una revisione ben fatta bastano. Oltre, il carico manuale diventa il rischio stesso.
2. Chi risponde se chiedono «chi ha approvato?» Se la risposta vive nella memoria di una persona, ti serve un registro prima di uno strumento. È un tema che ritorna anche nella gestione degli accessi richiesta dalla direttiva NIS2 per i soggetti nel suo campo di applicazione.
3. Cosa deve non fare il sistema? Chiedi per iscritto quali azioni richiedono approvazione, cosa succede se nessuno risponde e quali fonti vengono lette. In una prova concordata, la modalità di sola osservazione consente di vedere le proposte senza toccare la produzione.

Se stai confrontando strumenti dedicati, la griglia di valutazione del nostro articolo sullo strumento di controllo dei privilegi può aiutarti a ordinare i criteri.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus