Conformita AD e Azure: NIS2, ISO 27001, CIS

Che cos'è la AD and Azure Compliance?

La AD and Azure Compliance diventa utile solo quando i requisiti dei framework vengono tradotti in evidenze di produzione. In infrastrutture basate su Active Directory e Microsoft Entra ID, questo significa dimostrare come vengono effettivamente applicati la password policy, l'accesso privilegiato, l'MFA, l'audit logging, la governance del ciclo di vita e i controlli sull'accesso di terze parti.

La parte difficile è la traduzione. Il testo dei framework è intenzionalmente di alto livello, mentre le evidenze tecniche di cui un auditor o un responsabile della sicurezza hanno realmente bisogno sono specifiche: quale password policy è attiva, quali account amministrativi mantengono ancora privilegi permanenti, quali protezioni di accesso sono applicate, quali log vengono conservati e quali percorsi di accesso ospite o cross-tenant restano aperti.

Questo articolo mappa i requisiti di compliance più comuni sui controlli di identità tecnici che possono essere verificati in AD e Azure senza trasformare l'esercizio in un audit basato solo su fogli di calcolo.

Come funziona

Le revisioni di compliance incentrate sull'identità esaminano solitamente cinque aree:

• Policy di autenticazione, come lunghezza e complessità della password, MFA ed esposizione a protocolli legacy
• Controllo dell'accesso privilegiato, come ambito dei ruoli amministrativi, accesso just-in-time e governance dei break-glass
• Audit e monitoraggio, come la Advanced Audit Policy sui Domain Controller, i log di audit di Entra e la cadenza di revisione
• Ciclo di vita degli accessi, come provisioning, pulizia degli account inattivi e deprovisioning
• Accesso esterno e applicativo, come governance degli ospiti, consenso alle app e trust cross-tenant

Ogni area può essere tradotta in un insieme di controlli tecnici e di evidenze a supporto.

Mappatura dei framework di compliance per AD e Azure

Direttiva NIS2

L'Articolo 21(1) della NIS2 richiede agli Stati membri di garantire che i soggetti essenziali e importanti adottino "misure tecniche, operative e organizzative adeguate e proporzionate" per gestire i rischi di cybersecurity. Per l'identità, questo si traduce solitamente nei seguenti controlli:

CIS Controls v8.1

I CIS Controls trasformano l'hardening dell'identità in azioni difensive prioritizzate. La numerazione segue i CIS Controls v8.1, la versione attuale, invariata rispetto alla v8:

ISO 27001:2022

I controlli dell'Annex A di ISO 27001 più spesso mappati alla sicurezza della directory includono:

Aspettative di hardening della directory in stile ANSSI

Per le organizzazioni che si allineano a linee guida in stile ANSSI, i temi pratici sull'identità sono coerenti — consulta la Guida ANSSI Active Directory per l'insieme completo delle raccomandazioni:

• ridurre l'autenticazione legacy e la crittografia legacy laddove la compatibilità applicativa lo consenta
• isolare o irrobustire gli account privilegiati invece di lasciare che le identità di uso quotidiano mantengano privilegi permanenti
• documentare le eccezioni per i sistemi legacy invece di mantenerle silenziosamente a tempo indeterminato
• verificare che il monitoraggio, l'accesso privilegiato e i controlli sulle password siano applicati in produzione e non solo dichiarati nella policy

La valutazione del divario di compliance

Passo 1 - Definire la baseline dello stato attuale

# Baseline della password policy
Get-ADDefaultDomainPasswordPolicy |
  Select-Object MinPasswordLength, ComplexityEnabled, MaxPasswordAge

# Baseline del Conditional Access di Entra
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object {$_.State -eq "enabled"} |
  Select-Object DisplayName, State

# Baseline della audit policy su un domain controller
auditpol /get /category:"Account Logon","DS Access","Account Management" |
  Select-String "Success|Failure"

Passo 2 - Mappare i divari sui controlli nominati

$policy = Get-ADDefaultDomainPasswordPolicy

# La scadenza della password non viene deliberatamente valutata come un controllo. Microsoft ha
# rimosso le policy di scadenza della password dalle sue baseline di sicurezza di Windows nel 2019
# e definisce la scadenza periodica "una mitigazione antica e obsoleta di valore molto basso".
# Registra MaxPasswordAge come evidenza, e valutalo solo dove un framework o una policy interna
# richiedono ancora la rotazione.
$policy.MaxPasswordAge

$checks = @{
    "Lunghezza minima password >= 14"   = $policy.MinPasswordLength -ge 14
    "Complessità password abilitata" = $policy.ComplexityEnabled
    "Audit DS Changes abilitato"    = (auditpol /get /subcategory:"Directory Service Changes") -match "Success"
    "Audit Kerberos abilitato"      = (auditpol /get /subcategory:"Kerberos Authentication Service") -match "Success"
}

$checks.GetEnumerator() | ForEach-Object {
    [PSCustomObject]@{
        Control = $_.Key
        Status  = if ($_.Value) { "PASS" } else { "FAIL" }
    }
} | Format-Table -AutoSize

Passo 3 - Prioritizzare per esposizione, non per numero di caselle spuntate

1. Critico: assenza di MFA per identità privilegiate, nessun controllo sulle assegnazioni di ruoli ad alto rischio, delega non vincolata, principal in grado di eseguire DCSync
2. Alto: password policy debole, copertura di audit mancante, troppi amministratori permanenti, governance degli ospiti debole
3. Medio: account inattivi, LAPS mancante, processo di revisione dei ruoli incompleto, controlli granulari mancanti dove necessari
4. Basso: lacune nella documentazione, incoerenza nella denominazione, problemi di presentazione non rilevanti

Rilevamento

L'evidenza di compliance è debole se esiste solo al momento dell'audit. I controlli rilevanti dovrebbero essere verificabili in modo continuo.

Verifiche continue di compliance

# Deriva dei gruppi privilegiati negli ultimi 7 giorni, verificata su ogni domain controller.
# whenChanged NON viene replicato - ogni DC mantiene il proprio valore - quindi interrogare un
# singolo DC può far perdere silenziosamente una modifica scritta altrove.
$cutoff = (Get-Date).AddDays(-7)
foreach ($dc in (Get-ADDomainController -Filter *).HostName) {
    Get-ADGroup "Domain Admins" -Properties whenChanged -Server $dc |
      Where-Object {$_.whenChanged -gt $cutoff} |
      Select-Object @{Name="DC";Expression={$dc}}, Name, whenChanged
}

# Account abilitati inattivi da 90+ giorni.
# -Filter non è uno script block di PowerShell: accetta solo <attributo> <operatore> <valore>,
# quindi il cutoff deve essere calcolato prima. LastLogonDate non fa nemmeno parte del set di
# proprietà predefinito, quindi va richiesto esplicitamente o la colonna torna vuota.
$inactive = (Get-Date).AddDays(-90)
Get-ADUser -Filter 'Enabled -eq $true -and LastLogonDate -lt $inactive' -Properties LastLogonDate |
  Select-Object SamAccountName, LastLogonDate

Remediation

Sequenza prioritaria di remediation

1. Applicare l'MFA per gli account privilegiati e l'accesso cloud sensibile
2. Ridurre i privilegi permanenti rivedendo le assegnazioni dei ruoli e utilizzando l'elevazione just-in-time dove disponibile
3. Abilitare la copertura di audit sui Domain Controller e in Entra, in modo che i fallimenti dei controlli siano verificabili
4. Correggere l'igiene delle password, inclusa lunghezza, complessità, elenchi di password vietate e proliferazione delle eccezioni
5. Ripulire le identità inattive e orfane in AD e Azure
6. Rivedere l'accesso ospite e cross-tenant, in modo che l'accesso di terze parti sia governato
7. Documentare le eccezioni giustificate con proprietario, motivazione e data di revisione

Come EtcSec rileva questo problema

EtcSec mappa i rilievi tecnici sulle famiglie di controlli più spesso citate nel lavoro di compliance.

Ogni rilievo pertinente aiuta a rispondere a tre domande pratiche:

• quale controllo di identità è mancante o debole
• quali account, ruoli o oggetti sono interessati
• quale evidenza il team di sicurezza dovrebbe raccogliere per dimostrare che il divario è stato colmato

La categoria Compliance è utile quando si vuole trasformare i rilievi tecnici grezzi in un backlog di remediation azionabile, invece che in un generico foglio di calcolo per il framework.

Pacchetto di evidenze per AD and Azure Compliance

Una revisione di compliance solida di solito fallisce per due motivi: il controllo non è mai stato implementato in produzione, oppure il team non è in grado di dimostrarlo. Costruisci un pacchetto di evidenze che regga sia a una contestazione interna sia a un audit esterno:

• output attuale della password policy ed eventuali eccezioni granulari approvate
• export dei ruoli privilegiati e dell'appartenenza ai gruppi privilegiati, incluse le assegnazioni permanenti
• stato del Conditional Access o dei Security Defaults per il tenant in ambito
• output della audit policy dei Domain Controller per le sottocategorie su cui si basa il rilevamento
• impostazioni di accesso ospite, cross-tenant e applicativo per le popolazioni coperte dalla revisione
• proprietario, motivazione dell'eccezione e data di revisione per tutto ciò che ancora non raggiunge lo stato target

Questo pacchetto di evidenze è ciò che trasforma la AD and Azure Compliance da un esercizio di presentazione a una revisione dei controlli ripetibile.

Eseguire una revisione unica invece di tre

Le organizzazioni che affrontano contemporaneamente NIS2, ISO 27001 e CIS Controls raramente hanno bisogno di tre cicli di revisione separati. I tre framework convergono sulle stesse poche primitive di identità — MFA, governance dell'accesso privilegiato, igiene delle password e copertura di audit — quindi una singola revisione tecnica può produrre evidenze che soddisfano tutte e tre le mappature contemporaneamente.

Un approccio pratico di sequenziamento:

1. Costruire prima un'unica baseline dei controlli. Raccogli una volta sola la password policy, lo stato del Conditional Access, l'output della audit policy e l'appartenenza ai gruppi privilegiati. Ogni mappatura dei framework qui sopra attinge dagli stessi pochi punti dati.
2. Etichettare i rilievi rispetto a ogni framework che soddisfano, non solo a uno. Un singolo divario di MFA su un account Global Administrator è contemporaneamente un divario dell'Articolo 21(2)(j) della NIS2, un divario del CIS Control 6 e un divario di ISO 27001 A.8.5. Registrarlo una sola volta con più etichette evita di raccogliere tre volte la stessa evidenza.
3. Prioritizzare in base al valore per l'attaccante, poi completare la documentazione. Correggere prima i divari a maggiore esposizione — delega non vincolata, account in grado di eseguire DCSync, accesso Global Admin permanente senza MFA — chiude i rilievi in tutti e tre i framework prima ancora che venga spuntata una singola casella di compliance.
4. Mantenere la documentazione delle eccezioni in un unico posto. Un'applicazione legacy che non può supportare l'MFA è un'unica scheda di eccezione con un unico proprietario e un'unica data di revisione, non tre giustificazioni separate depositate rispetto a tre framework diversi.

Questo sequenziamento è particolarmente rilevante per i team che hanno ereditato il lavoro di compliance come effetto collaterale di una revisione di sicurezza, piuttosto che per team che partono da un documento di framework vuoto. L'evidenza tecnica sottostante — password policy, copertura di audit, stato dell'accesso privilegiato — non cambia a seconda di quale framework la richieda.

Divari comuni che riappaiono ogni trimestre

Anche i team maturi tendono a riaprire gli stessi divari di compliance sull'identità:

• eccezioni per applicazioni legacy che preservano silenziosamente un'autenticazione debole
• identità privilegiate inattive che non sono mai state rimosse dopo un progetto o un cambio di personale
• esclusioni del Conditional Access aggiunte durante un incidente e mai riviste
• percorsi di accesso ospite che restano più ampi di quanto consentito dalla policy scritta
• controlli di monitoraggio documentati una volta ma non più convalidati sui Domain Controller attuali o sull'ambito attuale del tenant

Se questi divari non vengono tracciati come debito operativo con un proprietario assegnato, la mappatura del framework apparirà sana mentre la superficie di attacco resta in gran parte invariata.

Letture correlate

Per l'aspetto tecnico delle stesse famiglie di controlli, consulta Accesso Privilegiato Azure: Troppi Admin Globali, Azure Identity Protection: Bloccare le Credenziali Divulgate, Auditare la sicurezza di Active Directory: cosa verificare per prima e come dimostrare la remediation e App Azure con Privilegi Eccessivi nel Tenant. Questi articoli aiutano a trasformare il linguaggio dei framework in passaggi concreti di hardening e validazione.