Un audit ISO/IEC 27001 sul controllo degli accessi chiede soprattutto una cosa: tracce prodotte mentre il lavoro accadeva, non ricostruzioni preparate la settimana prima. Autorizzazioni con un responsabile, revoche eseguite e registrate, revisioni periodiche dei privilegi con esiti documentati: se queste evidenze nascono in continuità, l'audit diventa una verifica di ciò che esiste già. Questa checklist ti aiuta a capire cosa raccogliere, come tenerlo in ordine e cosa resta comunque compito tuo.
Cosa si aspetta un auditor sul controllo degli accessi
Lo standard di riferimento è ISO/IEC 27001:2022 (edizione 3, con l'emendamento Amd 1:2024), la norma che definisce i requisiti di un Sistema di Gestione della Sicurezza delle Informazioni (SGSI). Due premesse che evitano equivoci. La certificazione riguarda l'organizzazione e il suo sistema di gestione, non un prodotto software: nessuno strumento, da solo, «rende conformi». E i controlli dell'Allegato A non sono una lista obbligata tutta intera: si scelgono e si motivano nella Dichiarazione di Applicabilità (SoA, Statement of Applicability) in base ai rischi dell'azienda.
Sul tema accessi, l'auditor verifica in genere che esista un processo riconoscibile: chi concede un'autorizzazione, su quale base, con quale durata; chi revoca l'accesso quando una persona cambia ruolo o lascia l'azienda; chi riesamina periodicamente i privilegi ancora attivi. I controlli citati per numero nelle fonti consultate riguardano per esempio credenziali e informazioni di autenticazione (A.5.17, A.8.5). La dicitura esatta e l'elenco completo dei controlli pertinenti vanno confermati sul testo della norma, che è un documento a pagamento: qui non lo riproduciamo.
Ciò che l'auditor conta di trovare, al di là dei numeri dei controlli, è coerenza tra tre elementi: la policy che hai dichiarato, le decisioni che hai preso e le tracce che lo dimostrano. Una regola ben scritta senza registrazioni vale poco; un archivio di registrazioni senza un responsabile che le esamina vale altrettanto poco.
Checklist delle evidenze da avere pronte
La tabella seguente riassume le evidenze più richieste sul controllo degli accessi, la domanda a cui rispondono e dove nascono. È una base operativa da adattare alla tua organizzazione e alla tua SoA, non una copia dei requisiti della norma.
| Evidenza | Domanda dell'auditor | Dove nasce |
|---|---|---|
| Autorizzazioni agli accessi | Chi ha richiesto questo accesso, chi lo ha approvato, per quale motivo e con quale durata? | Flusso di richiesta e approvazione: ogni concessione registrata con richiedente, approvatore, motivazione e scadenza. |
| Revoche | Quando una persona esce o cambia ruolo, come e quando vengono chiusi i suoi accessi? | Procedura di uscita e cambio ruolo: elenco degli accessi chiusi, data, esecutore e verifica finale. |
| Revisioni periodiche dei privilegi | Quando avete riesaminato l'ultima volta i privilegi attivi, e con quale esito? | Revisione periodica dei privilegi: data, perimetro, anomalie trovate, decisioni prese su ciascuna. |
| Abilitazioni temporanee ed eccezioni | Questo accesso urgente a un fornitore: era autorizzato, è scaduto, è stato revocato? | Registro delle eccezioni: finestra di validità, sistema interessato, approvatore, conferma della revoca. |
| Variazioni rilevanti su privilegi e regole | Chi ha cambiato questo privilegio o questa regola di rete, e con quale autorizzazione? | Traccia delle modifiche con proposta, decisione ed esito, come per le modifiche al firewall con traccia di approvazione. |
| Responsabilità e riesame | Chi presidia questo processo e come ne valuta l'efficacia? | Verbali di riesame della direzione, azioni di miglioramento, responsabilità assegnate nel SGSI. |
Due criteri trasversali valgono per ogni riga. Ogni evidenza deve avere data e responsabile: un file senza contesto non dimostra nulla. E le lacune vanno trattate onestamente: se manca l'approvazione di una modifica, registrare la lacuna e la sua gestione è meglio che ricostruire a posteriori una giustificazione.
Raccolta continua: il principio e gli strumenti
La logica della raccolta continua è la stessa che l'architettura zero trust applica agli accessi: come ogni accesso va autorizzato alla sessione e non ereditato «perché sei dentro la rete» — principio descritto dalla pubblicazione NIST SP 800-207 — così ogni decisione su un accesso va registrata quando avviene, non ricostruita dopo. La traccia è parte del controllo, non un suo sottoprodotto.
In pratica significa spostare la fatica dal mese dell'audit alla quotidianità: ogni autorizzazione, revoca o revisione produce subito la sua evidenza, in un unico posto consultabile. È il contributo che in OverZeus portano due agenti:
- Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti degli interventi. Se una modifica compare senza il riferimento autorizzativo nelle fonti collegate, segnala la lacuna senza inventare una ricostruzione: esattamente l'onestà che un auditor si aspetta.
- Athena controlla identità, gruppi e privilegi: spiega le autorizzazioni rilevate e mette in evidenza le variazioni da verificare, per esempio un account aggiunto a un gruppo amministrativo senza una richiesta approvata nelle fonti collegate.
Le operazioni attivabili dipendono dalle integrazioni e dalle policy concordate sul tuo ambiente: fonti lette, sistemi collegati e permessi vanno definiti per il progetto.
Esempio illustrativo: l'audit di sorveglianza senza raccolta straordinaria
Esempio illustrativo. Lo scenario seguente è inventato e non racconta un cliente reale.
Una società di servizi con una quarantina di dipendenti si avvicina all'audit di sorveglianza del suo SGSI. L'anno precedente la preparazione era costata due settimane: ricostruzione a memoria delle autorizzazioni concesse, caccia ai ticket di revoca, fogli di calcolo compilati a posteriori. Quest'anno il responsabile del sistema di gestione ha organizzato il lavoro in continuità. Le richieste di accesso passano da un flusso con approvazione registrata; le uscite del personale seguono una checklist che chiude identità, gruppi e app, come descritto nella revoca degli accessi all'uscita di un dipendente; ogni trimestre una revisione dei privilegi produce un esito firmato.
All'audit, la domanda «chi ha approvato l'accesso amministrativo di questo account?» trova risposta nel registro: richiesta, approvatore, motivazione, scadenza. Quando l'auditor chiede di una modifica senza riferimento, il responsabile mostra la lacuna registrata e la verifica che ne è seguita, invece di una spiegazione improvvisata. Il giudizio resta dell'auditor; ciò che cambia è che le evidenze esistono già.
Cosa resta compito del responsabile del SGSI
Il confine va detto chiaramente. Gli strumenti raccolgono tracce, segnalano variazioni e lacune, preparano proposte; in OverZeus ogni intervento attivo richiede l'approvazione prevista, e il silenzio non autorizza. Ma il SGSI resta tuo: scegliere i controlli e motivarli nella SoA, assegnare le responsabilità, condurre le revisioni, gestire il rapporto con l'organismo di certificazione e decidere le azioni di miglioramento sono attività di una persona. Per il quadro completo dei supporti documentali puoi consultare la pagina OverZeus per ISO 27001 e NIS2: il contributo alle evidenze non equivale a certificazione automatica.
Dal registro quotidiano all'audit
Preparare le evidenze sul controllo degli accessi senza corse dell'ultimo minuto significa decidere una volta cosa registrare — autorizzazioni, revoche, revisioni, eccezioni — e farlo mentre il lavoro accade. La checklist di questo articolo è il punto di partenza; la SoA della tua organizzazione decide il perimetro esatto.
Vuoi vedere come proposta, approvazione e registro lavorano insieme su un caso reale? Porta un caso di modifica ai privilegi o al firewall da discutere in demo.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.