Evidenze di hardening di Active Directory per gli audit 2026

L’allerta è arrivata alle 02:17. Un account ad alto privilegio, inattivo da sei mesi, aveva appena modificato un oggetto Criteri di gruppo critico. Quasi nello stesso momento, il SOC ha rilevato più errori di pre-autenticazione Kerberos provenienti da una sottorete di workstation. Cinque minuti dopo, Active Directory Certificate Services ha emesso un certificato per un account che non avrebbe mai dovuto poterlo richiedere.

Maria, CISO di una fintech di medie dimensioni, ha capito subito il significato dell’evento. L’organizzazione non aveva semplicemente rilevato attività sospette. Aveva rilevato un possibile attacco al piano di controllo delle identità.

L’indagine ha evidenziato un percorso noto. Un attore della minaccia aveva compromesso un server applicativo legacy, trovato credenziali in chiaro di un vecchio account di servizio e scoperto che quell’account disponeva ancora di privilegi eccessivi. La modifica alla GPO è stata bloccata prima della propagazione, ma la discussione in consiglio di amministrazione la mattina successiva è stata diretta.

“Com’è potuto accadere?” ha chiesto l’amministratore delegato. “Possiamo dimostrare alle autorità di vigilanza e ai clienti che le nostre chiavi del regno sono effettivamente sotto controllo?”

Questa domanda definisce l’hardening di Active Directory nel 2026. Per molte organizzazioni, Active Directory on-premises o ibrida supporta ancora accesso ai file, sistemi ERP, VPN, piattaforme di backup, server Windows, amministrazione privilegiata, applicazioni legacy, autenticazione Kerberos e sincronizzazione con Entra ID. Se AD cade, l’organizzazione non perde solo l’autenticazione. Perde il controllo.

Autorità di vigilanza e auditor lo comprendono ormai chiaramente. Ai sensi di NIS2, gli organi di amministrazione devono approvare le misure di gestione dei rischi di cibersicurezza e possono essere ritenuti responsabili delle violazioni. Ai sensi di DORA, le entità finanziarie devono gestire il rischio ICT mediante capacità documentate di governance, protezione, rilevazione, risposta e ripristino. Ai sensi del GDPR, le organizzazioni devono proteggere i dati personali mediante misure tecniche e organizzative adeguate e devono poter dimostrare la responsabilizzazione. Ai sensi di ISO/IEC 27001:2022, i rischi relativi ad Active Directory devono essere inclusi nell’ambito, valutati, trattati, monitorati e supportati da evidenze.

La risposta non è un’altra checklist non governata. La risposta è un modello di evidenze sostenibile che colleghi controller di dominio, Kerberos, Group Policy, AD CS, accessi privilegiati, logging e ripristino al SGSI, al registro dei rischi, alla Dichiarazione di applicabilità, al quadro delle politiche e alla traccia di audit.

Perché Active Directory è ancora un rischio a livello di consiglio di amministrazione

La maggior parte delle compromissioni di Active Directory non è esotica. Di norma combina privilegi eccessivi, account obsoleti, scarsa igiene degli account di servizio, Group Policy eccessivamente permissive, deleghe non sicure, configurazione Kerberos debole, modelli di certificato rischiosi, controller di dominio non aggiornati, monitoraggio incompleto e backup mai ripristinati.

L’impatto sulla conformità è diretto. Se un attaccante ottiene diritti di amministratore di dominio, può accedere a dati personali, distribuire GPO malevole, disabilitare strumenti di sicurezza, modificare log, manomettere backup, emettere certificati per mantenere la persistenza, muoversi lateralmente verso percorsi di identità cloud e interrompere servizi critici.

ISO/IEC 27001:2022 rende questo tema una questione di governance prima ancora che una questione tecnica. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di definire contesto, parti interessate, requisiti, ambito di applicazione e processi del SGSI. Per un ambiente di identità ibrido, l’ambito dovrebbe includere esplicitamente controller di dominio, AD CS, workstation amministrative privilegiate, sistemi di backup, server di sincronizzazione delle identità, fornitori di servizi gestiti e dipendenze dalle identità cloud.

Le clausole da 5.1 a 5.3 rendono la leadership responsabile di politiche, risorse, ruoli e reporting. La bonifica dei Domain Admins non è solo un’attività infrastrutturale. È una decisione di trattamento del rischio sostenuta dalla direzione.

Le clausole da 6.1.1 a 6.1.3 richiedono un processo ripetibile di valutazione del rischio e trattamento del rischio, inclusa la Dichiarazione di applicabilità. È qui che l’hardening di Active Directory diventa verificabile in audit.

[ZB] Zenith Blueprint: roadmap in 30 passi per l’auditor Zenith Blueprint rappresenta questo aspetto nella fase di Gestione del rischio, Step 13, Pianificazione del trattamento del rischio e Dichiarazione di applicabilità:

La SoA è di fatto un documento ponte: collega la valutazione e il trattamento del rischio ai controlli effettivamente presenti. Completandola, si verifica anche di non aver omesso alcun controllo.

Per Active Directory, quel ponte è critico. Un rischio come “compromissione degli account privilegiati AD con conseguente distribuzione di ransomware e accesso non autorizzato a dati personali” può essere mappato su accessi privilegiati, autenticazione sicura, gestione della configurazione, logging, monitoraggio, backup, risposta agli incidenti e controlli crittografici. La SoA può quindi spiegare perché ciascun controllo è applicabile, quali obblighi normativi supporta e quali evidenze ne dimostrano il funzionamento.

Lo stack di evidenze Active Directory atteso dagli auditor

Un ambiente AD sottoposto ad hardening non è pronto per audit solo perché esistono impostazioni configurate. Gli screenshot da soli sono deboli. Le politiche da sole sono incomplete. Un’esportazione GPO senza cronologia di approvazione è rischiosa. Evidenze solide mostrano governance, attuazione, monitoraggio e miglioramento.

Il divario di maturità non è di solito l’assenza di tutti i controlli. È l’assenza di titolarità, cadenza di riesame, gestione delle eccezioni e mappatura. Un auditor non chiederà soltanto se esiste un gruppo privilegiato, ma chi ne è il proprietario, chi ha approvato l’appartenenza, quando è stato riesaminato l’ultima volta, quali log sono raccolti e come scadono le eccezioni.

Accessi privilegiati: il primo controllo AD da evidenziare

La via più rapida alla compromissione di Active Directory è il privilegio eccessivo. Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, amministratori locali, amministratori OU delegati e amministratori delle autorità di certificazione richiedono tutti una governance esplicita.

[P11] Politica di gestione degli account utente e dei privilegi Politica di gestione degli account utente e dei privilegi definisce l’aspettativa aziendale:

I repository degli account, ad esempio Active Directory (AD) e le piattaforme di Gestione delle identità e degli accessi, devono essere protetti da controlli adeguati per prevenire accessi non autorizzati o manomissioni.

Dalla sezione “Requisiti di governance”, clausola di politica 5.6.

[P11S] Politica di gestione degli account utente e dei privilegi - PMI Politica di gestione degli account utente e dei privilegi - PMI fornisce una regola operativa di approvazione:

I privilegi elevati o amministrativi richiedono un’ulteriore approvazione del Direttore generale o del Referente IT e devono essere documentati, limitati nel tempo e soggetti a riesame periodico.

Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.2.2.

In [ZC] Zenith Controls: guida cross-compliance Zenith Controls, il controllo ISO/IEC 27002:2022 8.2, Diritti di accesso privilegiato, è mappato come controllo preventivo a supporto di riservatezza, integrità e disponibilità. La guida collega 8.2 a Gestione delle identità, Diritti di accesso, restrizione dell’accesso alle informazioni, autenticazione sicura, lavoro da remoto, logging e monitoraggio. Mappa inoltre il controllo a GDPR Article 5(1)(f), 25 e 32, alle aspettative di gestione del rischio di NIS2 Article 21 e alla governance del rischio ICT prevista da DORA per le entità finanziarie.

Zenith Blueprint, fase Controls in Action, Step 19, spiega l’aspettativa operativa:

A.8.2 – Diritti di accesso privilegiato: “L’assegnazione e l’uso dei diritti di accesso privilegiato dovrebbero essere limitati e gestiti.”

Controllare i diritti super user degli account amministrativi affinché siano concessi solo a chi ne ha effettiva necessità e gestirli con attenzione. Ad esempio, utilizzare un account amministrativo separato, senza usare diritti admin per il lavoro quotidiano, approvare e tracciare regolarmente chi riceve privilegi di domain admin o root. Inoltre, applicare controlli più forti su tali account, come MFA e registrazione delle relative azioni.

Per AD, un auditor dovrebbe poter selezionare un utente privilegiato e ricostruire l’intero ciclo: richiesta, approvazione, giustificazione aziendale, assegnazione tecnica, monitoraggio, riesame, rimozione e gestione delle eccezioni.

Un pacchetto pratico di evidenze sugli accessi privilegiati dovrebbe includere:

1. Esportazione dei gruppi AD privilegiati, inclusi i gruppi annidati.
2. Proprietario aziendale nominativo per ciascun gruppo privilegiato.
3. Evidenza del riesame trimestrale degli accessi.
4. Account amministrativi separati per le attività privilegiate.
5. Assenza di uso quotidiano di posta elettronica o navigazione da account privilegiati.
6. MFA o autenticazione resistente al phishing per i percorsi di accesso privilegiato, ove applicabile.
7. Modello con workstation privilegiata o jump host amministrativo sicuro.
8. Logging delle modifiche all’appartenenza ai gruppi e delle operazioni privilegiate.
9. Inventario degli account break glass con controlli compensativi.
10. Accettazione del rischio per le eccezioni, con data di scadenza.

Così Maria ha chiuso la risultanza immediata sull’account di servizio. L’account è stato documentato come elemento ad alto rischio, la Politica di gestione degli account utente e dei privilegi - PMI è stata usata per contestare il privilegio permanente, il proprietario dell’applicazione ha identificato l’accesso minimo necessario, l’appartenenza a Domain Admins è stata rimossa e la modifica è stata documentata tramite il processo di gestione delle modifiche. La voce SoA per il controllo ISO/IEC 27002:2022 8.2 è stata aggiornata per mostrare la riduzione del rischio e la mappatura a GDPR Article 32 e NIS2 Article 21.

Kerberos e informazioni di autenticazione

Kerberos abilita l’autenticazione scalabile negli ambienti Windows, ma una configurazione debole o una scarsa igiene degli account di servizio può favorire Kerberoasting, abuso dei ticket, attacchi di replay e persistenza di lungo periodo. Le evidenze dovrebbero coprire le informazioni di autenticazione lungo l’intero ciclo di vita: password, chiavi, ticket, secret degli account di servizio, certificati, processi di reset e fattori MFA.

In Zenith Controls, il controllo ISO/IEC 27002:2022 5.17, Informazioni di autenticazione, è mappato come controllo preventivo a supporto di riservatezza, integrità e disponibilità. È collegato a Gestione delle identità, autenticazione sicura, ruoli e responsabilità, uso accettabile e conformità a politiche e norme. La mappatura trasversale lo collega alla protezione proporzionata al rischio contro l’accesso non autorizzato prevista dal GDPR, a NIS2 Article 21(2)(j) su MFA o autenticazione continua ove appropriato, e ai requisiti DORA per meccanismi di autenticazione robusti nell’ambito della gestione del rischio ICT.

GDPR Article 5(1)(f) richiede che i dati personali siano protetti contro trattamenti non autorizzati o illeciti e contro perdita, distruzione o danno accidentali. Article 5(2) aggiunge la responsabilizzazione. Se le credenziali AD concedono accesso a registrazioni HR, file dei clienti o caselle di posta, i controlli Kerberos e di autenticazione diventano evidenze GDPR.

NIS2 Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, tra cui analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, manutenzione sicura, valutazione dell’efficacia, igiene informatica, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e MFA o autenticazione continua ove appropriato.

Per le entità finanziarie soggette a DORA, le dipendenze di autenticazione devono essere considerate all’interno del quadro di gestione del rischio ICT. Se AD autentica il personale verso sistemi di pagamento, trading, assicurativi, clienti o di rischio, le evidenze Kerberos supportano la resilienza operativa.

Governance di Group Policy e gestione della configurazione

Group Policy è uno dei meccanismi di sicurezza più potenti in Active Directory. Può applicare firewall, restrizioni sugli amministratori locali, policy di audit, impostazioni di protezione degli endpoint, regole di esecuzione degli script e baseline sicure su migliaia di sistemi. Può anche indebolire quegli stessi controlli se usata in modo improprio.

In Zenith Controls, il controllo ISO/IEC 27002:2022 8.9, Gestione della configurazione, è mappato come controllo preventivo per la configurazione sicura. È collegato a Gestione delle vulnerabilità, Gestione delle modifiche, inventario degli asset, dispositivi endpoint, accessi privilegiati, autenticazione sicura, logging e monitoraggio. La guida collega la gestione della configurazione a GDPR Article 5(1)(f), 25 e 32, alle aspettative NIS2 Article 21 in materia di configurazione sicura e gestione del rischio, e all’affidabilità, sicurezza e resilienza dei sistemi ICT previste da DORA.

[P05S] Politica di gestione delle modifiche - PMI Politica di gestione delle modifiche - PMI stabilisce:

Se una modifica riguarda dati sensibili, diritti di accesso al sistema o integrazioni esterne, è richiesto un riesame dell’impatto sulla sicurezza. Il referente designato per la sicurezza o la conformità deve valutare se la modifica introduce rischi aggiuntivi e raccomandare misure di sicurezza aggiuntive.

Dalla sezione “Trattamento del rischio ed eccezioni”, clausola di politica 7.5.1.

[P05] Politica di gestione delle modifiche Politica di gestione delle modifiche richiede:

Tutte le richieste di modifica, i riesami, le approvazioni e le evidenze di supporto devono essere registrati nel sistema centralizzato di gestione delle modifiche.

Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.1.1.

Un pacchetto di evidenze GPO dovrebbe rispondere a quattro domande:

1. Chi è il proprietario di ciascuna GPO rilevante per la sicurezza?
2. Quale baseline applica?
3. Chi ha approvato le modifiche?
4. Come viene rilevata la deriva non autorizzata?

Zenith Blueprint, fase Controls in Action, Step 19, fornisce l’approccio alle baseline:

Iniziare definendo checklist di configurazione per tutti i principali tipi di sistema: server Windows, host Linux, dispositivi di rete, banche dati e servizi cloud. Queste baseline dovrebbero riflettere sia le migliori pratiche del settore, come i CIS Benchmarks, sia la postura di rischio interna.

Per AD, questo significa che le GPO dovrebbero applicare baseline documentate, non preferenze non documentate. Le evidenze dovrebbero includere esportazioni mensili delle GPO, mappatura ai requisiti di baseline, ticket di modifica per le variazioni, riesami delle autorizzazioni delegate, registrazioni di backup GPO e allerte per le modifiche alle GPO ad alto impatto.

AD CS e PKI: il percorso di attacco dimenticato

Active Directory Certificate Services spesso sfugge ai riesami di conformità perché opera silenziosamente in background. Gli attaccanti lo apprezzano per lo stesso motivo. Modelli di certificato configurati in modo errato, autorizzazioni di enrollment eccessive, controlli di emissione deboli o impostazioni Extended Key Usage pericolose possono abilitare escalation dei privilegi, impersonificazione e persistenza.

AD CS rientra nei controlli crittografici, nella Gestione delle identità, negli accessi privilegiati e nella Gestione delle modifiche. Non basta affermare “abbiamo una PKI”. L’organizzazione deve sapere quali CA esistono, quali certificati possono essere emessi, chi può richiederli, quali modelli abilitano l’autenticazione client, chi amministra la CA e se l’emissione è monitorata.

[P18S] Politica sui controlli crittografici - PMI Politica sui controlli crittografici - PMI stabilisce:

Il Fornitore di supporto IT deve mantenere un inventario aggiornato degli strumenti crittografici e dei certificati in uso

Dalla sezione “Requisiti di governance”, clausola di politica 5.1.2.

[P18] Politica sui controlli crittografici Politica sui controlli crittografici include esplicitamente:

Infrastruttura a chiave pubblica (PKI)

Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.4.

NIS2 Article 21 include politiche e procedure per crittografia e cifratura. GDPR Article 32 richiede la sicurezza del trattamento, incluse riservatezza, integrità, disponibilità e resilienza. DORA richiede che gli asset ICT a supporto dei processi finanziari siano protetti e recuperabili. AD CS può supportare tutti questi requisiti, oppure comprometterli tutti.

Logging, backup e ripristino dei controller di dominio

I controller di dominio non sono server ordinari. Sono sistemi di autenticazione, repliche di directory, punti di distribuzione delle policy e asset critici per il ripristino. Se il ransomware compromette AD, il ripristino dipende da backup puliti dei controller di dominio, ripristino dello stato del sistema, log conservati, GPO note come integre, backup AD CS, chiavi private protette e procedure di ripristino documentate.

[P22S] Politica di logging e monitoraggio - PMI Politica di logging e monitoraggio - PMI definisce le aspettative sui log di autenticazione:

Log di autenticazione: tentativi di accesso riusciti e non riusciti, durata della sessione, uso di MFA

Dalla sezione “Requisiti di governance”, clausola di politica 5.4.2.

[P22] Politica di logging e monitoraggio Politica di logging e monitoraggio richiede:

Tutti i sistemi coperti devono generare log che acquisiscano:

Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.1.1.

In un ambiente dipendente da AD, i sistemi coperti dovrebbero includere controller di dominio, server AD CS, sistemi di accesso privilegiato, workstation amministrative, server di sincronizzazione delle identità e console di backup.

Zenith Blueprint, fase Controls in Action, Step 19, è esplicito:

Assicurarsi che tutti i sistemi critici, inclusi server, domain controller e firewall, inoltrino i log al SIEM o all’aggregatore di log. Verificare che la Conservazione dei log sia allineata alla Politica di registrazione, ad esempio 90 giorni in linea e 1 anno in archivio. Selezionare un incidente o evento recente e dimostrare come è stato tracciato usando i log.

Evidenzia inoltre la sincronizzazione dell’orologio, mappata al controllo ISO/IEC 27002:2022 8.17, Sincronizzazione dell’orologio. Senza un orario affidabile, la correlazione dei log durante un incidente diventa fragile.

[P15S] Politica di backup e ripristino - PMI Politica di backup e ripristino - PMI definisce un requisito minimo di evidenza:

I test di ripristino sono eseguiti almeno trimestralmente e i risultati sono documentati per verificare la recuperabilità

Dalla sezione “Requisiti di governance”, clausola di politica 5.3.3.

I controlli ISO/IEC 27002:2022 rilevanti includono 8.13 Backup delle informazioni, 8.15 Logging, 8.16 Attività di monitoraggio, 8.17 Sincronizzazione dell’orologio, 5.24 Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni, 5.29 Sicurezza delle informazioni durante le interruzioni e 5.30 Prontezza ICT per la continuità operativa.

Un pacchetto pratico di evidenze per il ripristino dovrebbe includere:

1. Inventario dei controller di dominio e titolarità dei ruoli FSMO.
2. Ambito, frequenza ed evidenze di immutabilità dei backup.
3. Convalida del backup dello stato del sistema.
4. Risultati trimestrali dei test di ripristino.
5. Procedura di backup e ripristino delle GPO.
6. Evidenze di backup AD CS e protezione delle chiavi private.
7. Procedura di autenticazione break glass.
8. Configurazione della sincronizzazione dell’orologio.
9. Playbook per incidenti di compromissione AD.
10. Lezioni apprese da esercitazioni tabletop o tecniche di ripristino.

Anche NIS2 Article 23 è rilevante. Gli incidenti significativi possono richiedere un preallarme entro 24 ore dalla conoscenza, una notifica dell’incidente entro 72 ore e una relazione finale entro un mese dalla notifica dell’incidente. Se un’indisponibilità di AD interrompe servizi essenziali o importanti, le evidenze di ripristino e le cronologie degli incidenti diventano evidenze regolatorie.

Mappa cross-compliance per l’hardening di Active Directory

L’hardening di Active Directory è un esempio chiaro di un unico insieme di controlli che supporta molti obblighi.

Per NIS2, questo non è più teorico. Le misure nazionali si applicano a molte entità essenziali o importanti di medie e grandi dimensioni nei settori di Annex I e Annex II, nonché ad alcune entità indipendentemente dalle dimensioni, inclusi prestatori di servizi fiduciari, registri TLD, fornitori di servizi DNS e determinati servizi critici.

Per DORA, anche la tempistica è concreta. DORA si applica dal 17 gennaio 2025 e copre direttamente molte entità finanziarie. Se un MSP esternalizzato gestisce AD, diventano rilevanti i requisiti DORA sul rischio ICT di terze parti, inclusi registri dei contratti, due diligence, diritto di audit, assistenza sugli incidenti, aspettative di sicurezza e strategie di uscita ai sensi degli Article 28 e 30.

Per GDPR, il ponte è la responsabilizzazione. Se AD controlla l’accesso ai dati personali, i riesami degli accessi privilegiati, le evidenze di autenticazione, il logging, le baseline di configurazione, i controlli sui certificati e i test di ripristino aiutano a dimostrare misure tecniche e organizzative adeguate.

Costruire un pacchetto di evidenze di hardening AD in uno sprint

Uno sprint pratico di due settimane può trasformare un hardening AD frammentato in un pacchetto di evidenze pronto per audit.

Giorni 1-2: includere AD nell’ambito del SGSI. Utilizzare le clausole da 4.1 a 4.4 di ISO/IEC 27001:2022 per confermare se AD, Entra Connect, controller di dominio, AD CS, workstation amministrative privilegiate, sistemi di backup e fornitori di servizi gestiti rientrano nell’ambito. Registrare le parti interessate, incluse autorità di vigilanza, clienti, auditor, interessati, titolari dei processi aziendali e operation IT.

Giorni 3-4: aggiungere i rischi AD al registro dei rischi. Includere compromissione dei controller di dominio, accessi privilegiati eccessivi, abuso di Kerberos, manomissione delle GPO, configurazione errata di AD CS, compromissione della sincronizzazione delle identità, fallimento del backup e logging insufficiente. Assegnare proprietari, probabilità, impatto e decisioni di trattamento.

Giorni 5-6: aggiornare la SoA. Seguendo Zenith Blueprint Step 13, contrassegnare come applicabili controlli quali Diritti di accesso privilegiato, Informazioni di autenticazione, Gestione della configurazione, Logging, Monitoraggio, Backup delle informazioni, Gestione degli incidenti, controlli crittografici e Gestione delle modifiche. Aggiungere note che li colleghino a GDPR Article 32, NIS2 Article 21 e alla gestione del rischio ICT DORA, ove rilevante.

Giorni 7-9: raccogliere evidenze tecniche. Esportare gruppi privilegiati, impostazioni Kerberos, inventario GPO, baseline dei controller di dominio, modelli CA, log di emissione dei certificati, stato dei job di backup e stato di acquisizione nel SIEM. Aggiungere proprietario, data, revisore, risultanza e stato di remediation.

Giorni 10-11: condurre un workshop di riesame dei controlli. IT, sicurezza, conformità e titolari dei processi aziendali riesaminano le eccezioni. Perché questo account di servizio necessita di un SPN? Perché questo gruppo può modificare le GPO? Perché questo modello può emettere certificati di autenticazione client? Perché questo controller di dominio non inoltra i log?

Giorni 12-14: confezionare la narrativa di audit. Creare un pacchetto di evidenze di hardening AD con sintesi esecutiva, ambito, rischi, mappatura SoA, evidenze dei controlli, risultanze aperte, piano di remediation e calendario dei test.

Il risultato è una storia sostenibile: conosciamo il rischio, abbiamo selezionato i controlli, li abbiamo attuati, li monitoriamo, testiamo il ripristino e la direzione ha visibilità.

Risultanze comuni degli audit Active Directory e azioni di chiusura

Lo schema di chiusura è coerente: requisito di politica, attuazione tecnica, acquisizione delle evidenze, cadenza di riesame, gestione delle eccezioni e reporting alla direzione.

Trasformare l’hardening di Active Directory in evidenze pronte per audit

L’hardening di Active Directory nel 2026 non è una bonifica una tantum. È un sistema di controllo vivo che deve essere governato, supportato da evidenze e migliorato. Controller di dominio, Kerberos, Group Policy, AD CS, accessi privilegiati, logging e ripristino si collocano tutti all’intersezione tra operazioni di sicurezza e responsabilizzazione normativa.

Clarysec aiuta CISO, responsabili IT e team di conformità a costruire quel ponte. Usa Zenith Blueprint per mappare i rischi AD nel SGSI, nel registro dei rischi e nella Dichiarazione di applicabilità. Usa Zenith Controls per incrociare i controlli ISO/IEC 27002:2022 con GDPR, NIS2, DORA, NIST CSF 2.0 e aspettative di audit. Usa i modelli di politiche Clarysec, tra cui Politica di gestione degli account utente e dei privilegi, Politica di gestione delle modifiche, Politica sui controlli crittografici, Politica di logging e monitoraggio e Politica di backup e ripristino - PMI, per trasformare l’hardening tecnico in evidenze ripetibili.

Se il prossimo audit, la prossima richiesta dell’autorità di vigilanza o il prossimo questionario di assurance del cliente chiede come viene controllata Active Directory, non rispondere solo con screenshot. Costruisci il pacchetto di evidenze, collegalo al rischio e mostra che la direzione può fare affidamento sul piano di controllo delle identità.

Inizia con uno sprint: accessi privilegiati, governance delle GPO, riesame AD CS, logging dei controller di dominio e test di ripristino. Clarysec può aiutarti a strutturarlo, documentarlo con evidenze e sostenerlo in sede di audit.