Molte organizzazioni sanno di dover tracciare le attività degli amministratori di sistema, ma spesso non sanno da dove iniziare davvero. Il quadro normativo che si è andato consolidando in questi anni — dal Provvedimento del Garante Privacy del 27 novembre 2008 sugli amministratori di sistema, al GDPR (Regolamento UE 2016/679), fino alla Direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024 — converge su un punto preciso: chi accede in modalità privilegiata ai sistemi informativi deve essere identificabile, le sue azioni devono essere registrate, e le evidenze devono essere conservate per un tempo congruo e disponibili in caso di verifica.
Il 2026 è l’anno in cui questo passaggio diventa concreto. Il regime di notifica degli incidenti significativi al CSIRT Italia è pienamente operativo dal 15 gennaio. Le finestre di registrazione e categorizzazione ACN si concentrano tra aprile e giugno. La completa implementazione delle misure di sicurezza di base per i soggetti già iscritti scade a ottobre 2026, e da quella data l’Agenzia per la Cybersicurezza Nazionale può avviare l’attività ispettiva. Per i soggetti essenziali, le sanzioni amministrative arrivano fino a 10 milioni di euro o al 2% del fatturato mondiale annuo. Non è più un esercizio teorico, è una scadenza con numeri.
La buona notizia è che non serve un progetto di mesi: con un approccio pragmatico è possibile costruire una base solida di tracciabilità in poche ore. Questo articolo va dritto al punto: cosa serve attivare subito per essere difendibili in caso di audit. Non è una guida normativa — per quella ci sono i testi di legge e i consulenti — ma è una guida operativa, costruita attorno a Microsoft Sentinel come piattaforma di centralizzazione e detection.
Il minimo indispensabile
Quando si parla di amministratori, le verifiche ruotano quasi sempre attorno a tre domande fondamentali: chi ha accessi privilegiati, cosa ha fatto, come possiamo dimostrarlo. Se riusciamo a rispondere rapidamente a queste tre domande, siamo già su un livello di maturità superiore alla media. Il resto del lavoro consiste nel mantenere quelle risposte aggiornate, leggibili e ricostruibili a posteriori.
Step 1 — Partiamo dalle identità privilegiate
Non iniziamo dai server, non iniziamo dai firewall: li vedremo più avanti. Iniziamo dagli account amministrativi, perché è da lì che passa la maggior parte del rischio.
Le priorità assolute sono:
- tenant e cloud admin
- domain admin
- account root o equivalenti
- account di emergenza (break-glass)
Su Microsoft Sentinel colleghiamo subito i log di autenticazione, di modifica dei ruoli e di attività amministrativa. Tracciando le identità privilegiate copriamo già una quota dominante del rischio: la maggior parte degli incidenti critici passa da un’escalation di privilegi o dall’uso improprio di un account a privilegio elevato.
Step 2 — Centralizziamo i log
Log sparsi significa compliance fragile. L’obiettivo è uno solo: avere un punto unico dove cercare. Appena colleghiamo le prime fonti, verifichiamo tre cose: che i log arrivino correttamente, che gli orari siano coerenti tra le sorgenti, che la retention sia attiva.
Sulla retention, un suggerimento operativo: impostiamo almeno 6 mesi di conservazione come baseline. È spesso la prima cosa che viene controllata in audit ed è richiesta in modo esplicito dal Provvedimento AdS del 2008, che prescrive la conservazione degli access log degli amministratori di sistema per almeno sei mesi, in forma adeguata a garantirne integrità e immodificabilità.
Step 3 — Tracciamo le azioni che cambiano lo stato dei sistemi
Non serve raccogliere tutto, serve raccogliere ciò che conta. Concentriamoci sugli eventi ad alto impatto:
- aggiunta di nuovi amministratori
- escalation di privilegi
- disattivazione di controlli di sicurezza
- modifiche alle policy
- cancellazione dei log
Se un’azione può alterare la sicurezza o l’accesso ai dati, deve essere visibile. È qui che si gioca la differenza tra un SIEM che colleziona e un SIEM che racconta cosa è successo davvero.
Step 4 — Proteggiamo anche il SIEM
L’errore più comune è monitorare gli amministratori dei sistemi, ma dimenticare chi può manipolare i log dello stesso strumento di monitoraggio. Verifichiamo quindi che l’accesso a Sentinel sia limitato, che i ruoli siano separati, e che le attività degli amministratori della piattaforma stessa siano tracciate. Anche gli amministratori della sicurezza devono essere auditabili, esattamente come tutti gli altri.
Per un approfondimento sulla segregazione amministrativa e sull’Enterprise Access Model, rimandiamo alla documentazione ufficiale Microsoft su Privileged Access Accounts e sull’Enterprise Access Model.
Step 5 — Creiamo almeno tre detection il primo giorno
Non usciamo dalla configurazione iniziale senza aver attivato detection. Bastano tre use case semplici ma potenti:
- login amministrativo anomalo
- assegnazione di privilegi elevati
- uso di account di emergenza (break-glass)
Non serve essere sofisticati, serve essere operativi. Una detection grezza ma attiva vale più di una architettura raffinata che resta in backlog.
Errori da evitare
Sono diffusissimi, vale la pena tenerli a mente:
- raccogliere log senza guardarli mai
- collegare tutto contemporaneamente, senza priorità
- dimenticare di configurare la retention
- avere troppi amministratori, e quindi troppi soggetti da auditare
La compliance non nasce dalla quantità di dati raccolti, ma dalla loro utilizzabilità. Un terabyte di log che nessuno consulta non protegge da nulla, mentre poche query ben strutturate su un dataset pulito producono evidenze immediate.
Una regola semplice per decidere cosa loggare
Quando si è in dubbio, una sola domanda risolve quasi sempre il caso: questa azione potrebbe finire in un report post-incidente? Se la risposta è sì, va loggata. È un criterio empirico, ma allinea le scelte tecniche con la prospettiva di chi un giorno dovrà ricostruire una kill chain a posteriori.
Conclusioni
Implementare la tracciabilità degli amministratori di sistema non richiede architetture complesse. Richiede soprattutto chiarezza sulle priorità: identità privilegiate, log centralizzati, eventi critici, retention adeguata, alert di base. Microsoft Sentinel fornisce la piattaforma, ma il valore lo determina come la si configura — quali fonti si collegano, quali soglie si scelgono, quali use case si attivano per primi.
In un contesto in cui il D.Lgs. 138/2024 ha portato la cybersicurezza dalle stanze IT al consiglio di amministrazione, dove il management è formalmente responsabile dell’approvazione delle misure di gestione del rischio, e dove il regime sanzionatorio è ormai allineato a quello del GDPR, la tracciabilità degli accessi privilegiati non è più una buona pratica facoltativa: è la base concreta su cui poggia la dimostrabilità di tutto il resto. Senza access log integri e consultabili, qualsiasi modello di governance, qualsiasi policy approvata dal CdA, qualsiasi piano di incident response rischia di non resistere a una verifica seria.
L’approccio in cinque step descritto in questo articolo non sostituisce un percorso strutturato di adeguamento alla NIS2 e neppure una gap analysis condotta secondo gli ambiti definiti dall’ACN. Ma offre una base operativa difendibile in poche ore, su cui costruire il resto in modo incrementale. Nella seconda parte dell’articolo entreremo nel dettaglio della configurazione, con le query KQL, i connector specifici e le analytics rule pronte all’uso che permettono di passare dalla teoria a un tenant Sentinel effettivamente conforme e operativo.