Un buon strumento per il controllo di privilegi e account di servizio si riconosce da tre cose: ti mostra chi ha accesso a cosa, ti avvisa quando qualcosa cambia e ti lascia decidere con una traccia scritta. Prima dell'acquisto, chiedi una prova in sola osservazione sui tuoi sistemi: è l'unico modo per verificare che lo strumento legga davvero le tue directory e i tuoi gruppi, e non solo quelli della demo.
Perché privilegi e account di servizio sfuggono al controllo manuale
In molte aziende i privilegi si accumulano per stratificazione. Una persona cambia ruolo e mantiene i gruppi del ruolo precedente. Un tecnico riceve un'abilitazione «temporanea» che nessuno revoca. Un account di servizio, creato anni prima per un gestionale poi sostituito, resta attivo con diritti ampi e nessun proprietario. Nessuno di questi eventi è drammatico da solo: è la somma a creare il problema.
Il controllo manuale — una revisione trimestrale con un foglio di calcolo — fatica a stare dietro a questa dinamica per due ragioni. La prima è la frequenza: le variazioni avvengono ogni giorno, la revisione ogni novanta giorni. La seconda è il contesto: una lista di gruppi esportata dalla directory dice chi è dentro, ma non perché ci è entrato, chi lo ha autorizzato e quando.
La pubblicazione NIST SP 800-207, Zero Trust Architecture (agosto 2020) descrive un principio utile anche fuori dai grandi contesti: nessuna fiducia implicita per posizione di rete o appartenenza, e una decisione di autenticazione e autorizzazione per ogni soggetto — persone, dispositivi e account di servizio compresi — prima di ogni accesso a una risorsa. Un account di servizio non merita fiducia «perché gira sul nostro server»: va trattato come qualsiasi altro soggetto, con privilegi minimi e un proprietario identificabile. Attenzione: SP 800-207 è un'architettura di riferimento, non una certificazione di prodotto. Nessuno strumento è «conforme zero trust» per il solo fatto di citarla.
I criteri di valutazione, spiegati
Quando confronti gli strumenti, usa questa griglia. Per ogni criterio, chiedi una risposta e una prova osservabile in demo: la differenza tra un prodotto serio e uno di facciata sta nel riscontro, non nella brochure.
| Criterio | Cosa deve fare | Prova da chiedere |
|---|---|---|
| Visibilità su gruppi e account | Leggere le directory e i sistemi di identità che usi davvero, distinguendo persone, account di servizio e accessi dei fornitori. | Elenco scritto delle sorgenti supportate nel tuo progetto, con dati letti e permessi richiesti. In demo, la vista su un gruppo reale del tuo ambiente di prova. |
| Alert sulle variazioni | Segnalare le modifiche ai privilegi con contesto: cosa è cambiato, quando, con quale account, e se esiste una richiesta approvata che lo giustifica. | Una variazione simulata (per esempio un utente aggiunto a un gruppo amministrativo) mostrata dall'inizio alla fine: rilevamento, notifica, spiegazione. |
| Flussi di approvazione | Raccogliere una decisione esplicita prima di qualsiasi intervento sui privilegi, e non interpretare il silenzio come un consenso. | In demo, un intervento in attesa di approvazione, un rifiuto e il comportamento quando nessuno risponde. |
| Privilegi minimi sugli account di servizio | Aiutarti a classificare gli account di servizio: proprietario, scopo, diritti effettivamente usati, diritti in eccesso. | Un esempio di account con privilegi superiori all'uso osservato e la proposta di riduzione che lo strumento prepara. |
| Evidenze per l'audit | Conservare variazioni, decisioni ed esiti in modo ricostruibile fra sei mesi, senza dipendere dalla memoria di una persona. | Una timeline dimostrativa completa: segnalazione, contesto, decisione, esito. |
| Trattamento dei dati | Chiarire dove vengono elaborati e conservati i dati sulle tue identità: in sede, in cloud, con quali dipendenze. | Architettura di trattamento messa per iscritto, con le dipendenze esterne dichiarate. |
Due avvertenze su questa griglia. Primo: «si collega alla tua directory» deve diventare un elenco concreto — quale directory, quale versione, quali dati legge, con quali permessi. Le integrazioni disponibili dipendono dal progetto e vanno concordate sull'ambiente specifico. Secondo: uno strumento che propone interventi è diverso da uno che li esegue. Chiedi sempre quali azioni sono preautorizzate, quali richiedono approvazione caso per caso e chi può cambiare questi limiti.
Cosa chiedere al fornitore prima di una prova
Prima di firmare qualsiasi cosa, porta al fornitore le stesse domande e gli stessi scenari. Ecco quelli che fanno più differenza:
- Quali sistemi di identità leggi oggi, nel mio caso? Non «supportiamo le principali directory»: un elenco nominativo con permessi e limiti, da verificare sull'ambiente reale.
- Cosa succede quando nessuno risponde a una segnalazione? La risposta corretta è che l'intervento attivo non parte. Se il silenzio sblocca un'azione, il controllo umano è solo nominale.
- Come distingui una variazione legittima da una sospetta? Chiedi come lo strumento confronta le modifiche con richieste e ticket approvati, e cosa fa quando questa fonte manca.
- Possiamo fare una prova in sola osservazione? Un periodo in cui lo strumento osserva e prepara proposte senza modificare nulla, su casi concordati con criteri di successo scritti. È il modo più onesto di valutare valore e limiti prima di concedere permessi.
- Cosa resta scritto, e dove? Variazioni, proposte, approvazioni, rifiuti ed esiti devono essere consultabili e conservati secondo regole concordate.
Se vuoi approfondire il tema degli account di servizio e della revisione periodica dei privilegi, ci sono articoli dedicati in questo catalogo.
Esempio illustrativo: la prova sul gruppo amministratori
Esempio illustrativo. Lo scenario seguente è inventato a scopo dimostrativo: non descrive un cliente né un incidente reale.
Un'azienda di quaranta persone sta valutando due strumenti di controllo dei privilegi. Invece di confrontare le schede prodotto, concorda con entrambi i fornitori lo stesso esercizio: nell'ambiente di prova, un utente dell'ufficio tecnico viene aggiunto al gruppo degli amministratori del dominio, senza alcuna richiesta registrata.
Il primo strumento genera un allarme generico: «modifica ai privilegi». Utile, ma il responsabile deve comunque ricostruire a mano chi ha fatto la modifica, quali accessi sono cambiati e se esiste una giustificazione. Il secondo mostra la variazione con il contesto: i privilegi precedenti, quelli nuovi, l'account che ha eseguito la modifica e l'assenza di una richiesta approvata nelle fonti collegate. Poi presenta tre opzioni — mantenere la modifica registrando la decisione, ripristinare l'appartenenza precedente dopo approvazione, oppure approfondire come possibile incidente — con gli impatti di ciascuna, incluso il rischio di interrompere un'attività legittima con il ripristino.
La differenza non è estetica: nel secondo caso il responsabile può decidere in minuti, con gli elementi davanti, e la decisione resta tracciata. È questo che la griglia dei criteri serve a misurare.
Come OverZeus affronta il controllo dei privilegi
In OverZeus questo tema coinvolge tre agenti, con ruoli distinti:
- Athena controlla identità, gruppi e privilegi. Spiega le autorizzazioni rilevate e mette in evidenza le variazioni da verificare: per esempio un utente aggiunto a un gruppo amministrativo senza una richiesta approvata nelle fonti collegate, con privilegi precedenti, nuovi accessi e possibili impatti di una revoca.
- Themis applica privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI. Se un'operazione arriva con un'autorizzazione scaduta, la blocca e richiede una nuova decisione: i limiti non dipendono dall'interpretazione del modello.
- Oracle gestisce la modalità di sola osservazione: durante la prova, nel perimetro collegato, rileva ciò che accade e prepara proposte senza modificare la produzione, producendo un report che distingue osservazioni, interpretazioni e interventi proposti. È la risposta concreta alla domanda «possiamo vedere il valore prima di attivarlo?» — scopri di più su Oracle e la prova in sola osservazione.
Come per ogni soluzione, le operazioni attivabili dipendono dalle integrazioni e dalle policy concordate sul tuo ambiente, e le azioni sensibili richiedono un'autorizzazione esplicita. Chiedi in demo quali directory e sistemi di identità possono essere letti nel tuo caso specifico.
Dalla griglia alla decisione
Scegliere uno strumento per il controllo di privilegi non significa trovare «il migliore» in assoluto, ma quello che legge i tuoi sistemi, spiega le variazioni con contesto e lascia la decisione a una persona, con traccia scritta. Porta la griglia in demo, fai eseguire lo stesso scenario a ogni fornitore e metti per iscritto integrazioni, limiti e condizioni della prova. Se il tuo problema è anche organizzativo — per esempio le revoche degli accessi quando una persona lascia l'azienda — valuta se lo strumento copre quel flusso, non solo l'allarme.
Porta un caso di modifica ai privilegi o al firewall da discutere in demo: vediamo insieme cosa osserva OverZeus, cosa propone e cosa resta nelle tue mani.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.