Requisiti NIS2 per la sicurezza delle identità: cosa devono dimostrare i team AD ed Entra

Requisiti NIS2 per la sicurezza delle identità: partire da ciò che il testo dice davvero

Se stai cercando di capire i requisiti NIS2 per la sicurezza delle identità, il primo errore da evitare è trattare la NIS2 come se fosse una guida di configurazione Microsoft. Non lo è. La Direttiva (UE) 2022/2555 stabilisce obblighi di gestione del rischio e aspettative di governance a livello dell’Unione. Non dice ai team di distribuire Microsoft Entra Privileged Identity Management, di applicare un template specifico di Conditional Access o di impostare una determinata lunghezza della password in Active Directory.

Questa distinzione conta, perché i team identity devono comunque dimostrare qualcosa di concreto. Anche se la NIS2 non nomina prodotti Microsoft, i team AD ed Entra devono essere in grado di dimostrare che l’accesso privilegiato è controllato, che l’autenticazione è abbastanza forte rispetto al rischio, che il controllo degli accessi è effettivamente applicato in produzione e che il monitoraggio permette di dimostrare violazioni di policy o deriva dei privilegi.

Questo articolo separa volutamente quattro livelli:

Questo inquadramento è ciò che separa una revisione difendibile da un articolo di compliance che sovrainterpreta il testo.

Cosa richiede davvero la NIS2 per la sicurezza delle identità?

Al livello più alto, l’articolo 21(1) della NIS2 richiede agli Stati membri di assicurare che le entità essenziali e importanti adottino misure tecniche, operative e organizzative appropriate e proporzionate per gestire i rischi che incidono sulla sicurezza delle reti e dei sistemi informativi. Si tratta di un obbligo basato sul rischio, non di una checklist di prodotto.

L’identità compare in modo più diretto nell’articolo 21(2). Per questo tema contano soprattutto due punti:

• L’articolo 21(2)(i) include politiche e procedure per valutare l’efficacia delle misure di gestione del rischio di cybersicurezza.
• L’articolo 21(2)(j) include l’uso di soluzioni di autenticazione multifattore o autenticazione continua, comunicazioni sicure e sistemi sicuri di comunicazione di emergenza all’interno dell’entità, ove appropriato.

La NIS2 aggiunge contesto importante anche nel considerando 89, che elenca pratiche di base di cyber hygiene come principi zero trust, aggiornamenti software, segmentazione di rete, identity and access management e consapevolezza degli utenti. Quel considerando non è una baseline Microsoft nascosta. È un segnale forte che governance delle identità, autenticazione e disciplina degli accessi fanno parte del lavoro di base che i regolatori si aspettano.

La lettura prudente per i team identity è quindi questa: la NIS2 non prescrive un unico modello di vendor, ma si aspetta chiaramente controlli di identità difendibili, basati sul rischio, riesaminati e in grado di ridurre l’impatto degli incidenti.

Dove si colloca identity and access management nella NIS2

Per i team AD ed Entra, la domanda pratica non è “quale funzionalità Microsoft richiede la NIS2?”. La domanda pratica è “quali obiettivi di sicurezza delle identità faticheremmo a dimostrare in caso di verifica?”.

Una lettura tecnica utile assomiglia piuttosto a questa:

È anche per questo che Conformita AD e Azure: NIS2, ISO 27001, CIS resta utile. Quell’articolo fa un mapping più ampio tra diversi framework. Quello che stai leggendo ora restringe la questione a un problema più difficile: cosa un team identity può realmente dimostrare in una review orientata alla NIS2.

Perché il perimetro conta: NIS2, regole settoriali e recepimento nazionale

È sul perimetro che molti articoli di compliance sbagliano.

Primo: la NIS2 è una direttiva, non uno standard di prodotto direttamente autoesecutivo. Gli Stati membri la recepiscono nel diritto nazionale e le aspettative di supervisione dipendono in parte da tale recepimento. Un team che opera in Francia, Germania, Italia o in un altro Stato membro condivide la stessa baseline UE, ma non necessariamente lo stesso confezionamento regolatorio, gli stessi documenti di riferimento o lo stesso workflow di implementazione.

Secondo: non tutti i dettagli tecnici che vengono spesso associati alla NIS2 provengono dal testo della direttiva. Il regolamento di esecuzione (UE) 2024/2690 stabilisce requisiti tecnici e metodologici per alcune categorie di entità coperte dall’articolo 21(5), tra cui DNS service provider, cloud computing service provider, data centre service provider, managed service provider, managed security service provider e trust service provider. Quel regolamento è rilevante, ma non è una scorciatoia generica da applicare senza modifiche a ogni organizzazione soggetta alla NIS2.

Terzo: alcune entità ricadono anche in testi settoriali o nazionali più specifici. Per questo una revisione seria dell’identità in chiave NIS2 deve chiarire tre domande prima ancora di iniziare:

1. L’entità rientra nel perimetro della NIS2 e in quale categoria?
2. È coperta anche da testi dell’Unione o nazionali più specifici?
3. Quali aspettative tecniche derivano dalla direttiva stessa, quali dagli atti di esecuzione e quali da guide nazionali?

Senza questa disciplina si finisce per leggere o scrivere frasi come “la NIS2 richiede PIM” oppure “la NIS2 richiede password di 12 caratteri”. Queste affermazioni non sono tecnicamente difendibili a partire dal solo testo europeo.

Controlli AD ed Entra che spesso supportano gli obiettivi identity della NIS2

La NIS2 non nomina né Active Directory né Microsoft Entra. Ma se il tuo ambiente si basa su questi sistemi, sono ovvi punti in cui verranno cercate evidenze.

Accesso privilegiato

Una revisione matura dell’identità deve poter mostrare quali utenti e gruppi dispongono di accesso amministrativo effettivo on-premises e in Entra, come tale accesso è stato concesso e se è ancora giustificato.

Questo di solito significa riesaminare:

• appartenenze dirette e annidate in gruppi AD privilegiati
• principal con diritti equivalenti a DCSync
• diritti delegati su oggetti AD sensibili, soprattutto quando GenericAll, WriteDACL o WriteOwner aprono percorsi di escalation
• assegnazioni di ruoli Entra permanenti rispetto a quelle eligibili
• account che mantengono privilegi nonostante inattività o deriva di ownership

È esattamente per questo che Deriva accessi privilegiati Active Directory: come i diritti admin ritornano dopo gli audit e Accesso Privilegiato Azure: Troppi Admin Globali sono riferimenti interni pertinenti. Non dimostrano da soli la conformità NIS2. Mostrano le condizioni identity che un team farebbe fatica a difendere sotto scrutinio.

Robustezza dell’autenticazione

La NIS2 riconosce chiaramente un ruolo al MFA o all’autenticazione continua, ma la formula “ove appropriato” resta importante. Un programma identity difendibile deve quindi poter spiegare:

• quali account privilegiati sono sempre protetti da MFA
• quali workflow amministrativi e quali applicazioni ad alto rischio sono soggetti a controlli di accesso rafforzati
• se restano aperti percorsi di autenticazione legacy
• se il tenant si basa ancora su uno schema password più eccezioni

La documentazione Microsoft è utile qui perché spiega cosa sia davvero Conditional Access: un motore di policy che combina segnali e applica decisioni di accesso. Questo la rende evidenza di un percorso di controllo, non prova del fatto che la NIS2 abbia imposto Conditional Access come prodotto.

Allo stesso modo, Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta aiuta a inquadrare correttamente il limite tecnico: MFA è importante, ma una cattiva governance dei ruoli, guest access troppo aperto o il consenso malevolo alle app possono comunque lasciare un’esposizione identity rilevante.

Controllo degli accessi, guest e permessi applicativi

Il perimetro identity nella NIS2 è più ampio del semplice login dei dipendenti. Il controllo degli accessi riguarda anche utenti esterni, accesso applicativo e autorità delegate.

Un team tecnico deve poter dimostrare:

• come viene limitato il guest access
• chi è autorizzato a invitare guest
• se la collaborazione cross-tenant è governata in modo stretto o lasciata troppo aperta
• come vengono controllati permessi applicativi e consenso
• se le enterprise app sovraprivilegiate vengono riesaminate periodicamente

Non si tratta di questioni astratte. Microsoft documenta che gli application permissions possono concedere accesso app-only e che il consenso utente o admin governa il modo in cui le applicazioni ottengono accesso a risorse protette. Microsoft documenta anche come limitare le impostazioni di user consent per ridurre consensi malevoli o eccessivi. È per questo che App Azure con Privilegi Eccessivi nel Tenant e OAuth Consent Phishing: come le app malevole aggirano il furto di password fanno parte di una lettura seria del tema, anche se la NIS2 non usa mai questi nomi di prodotto.

Quali evidenze un team security deve saper produrre

Un programma debole di identity compliance spesso ha una buona policy, ma nessun pacchetto di evidenze robusto. In una review orientata alla NIS2, i team AD ed Entra devono poter produrre evidenze attuali, riesaminabili e direttamente collegate ai controlli che affermano di applicare.

Un pacchetto di evidenze pratico include normalmente:

Qui entrano in gioco Come auditare la sicurezza di Microsoft Entra ID (Azure AD): guida pratica, Auditare la sicurezza di Active Directory: checklist pratica e Monitoraggio Sicurezza AD: Event ID e SIEM, che aiutano a tradurre il linguaggio del framework in passaggi operativi di verifica.

Gap comuni tra policy scritta e controlli identity effettivamente applicati

I fallimenti identity più seri in una lettura NIS2 di solito non derivano dall’assenza di policy scritta. Derivano dal gap tra ciò che la policy dichiara e ciò che il tenant o il directory applicano davvero.

Esempi comuni:

• esiste una policy di least privilege, ma ci sono troppi admin permanenti in Entra o troppi gruppi privilegiati permanenti in AD
• esiste una policy MFA, ma lascia ancora fuori copertura flussi amministrativi sensibili o percorsi di autenticazione legacy
• esiste una policy sugli accessi di terze parti, ma le impostazioni di invito guest o di accesso cross-tenant restano troppo aperte
• esiste un processo trimestrale di access review, ma nessuno sa mostrare evidenza attuale del fatto che guest, gruppi o review dei ruoli siano stati completati davvero
• esiste una policy di governance applicativa, ma nessuno riesce a produrre lo stato corrente di permessi dei service principal, grant app-only o impostazioni di consenso
• esiste una policy di audit e monitoraggio che nomina i controlli, ma nessuno riesce a dimostrare lo stato corrente dell’audit AD o la copertura attuale degli Entra audit logs

Per questo un articolo NIS2 orientato all’identità non deve finire in slogan di governance. Un team tecnico deve poter mostrare stato applicato, non soltanto intenzione scritta.

Contesto Francia e ANSSI

Poiché questo articolo resta UE-first, la Francia entra come contesto e non come nucleo normativo.

La pagina ufficiale di ANSSI sulla NIS2 afferma che l’agenzia continuerà a comunicare durante tutto il recepimento nazionale, che le future entità essenziali e importanti sono incoraggiate a iniziare fin da ora un approccio di sicurezza coerente con la NIS2 e che dal 17 marzo 2026 ANSSI mette a disposizione il Référentiel Cyber France (ReCyF) come documento di lavoro. ANSSI precisa anche che ReCyF, di default, non è obbligatorio in questa fase e corrisponde al framework di cybersicurezza citato all’articolo 14 del disegno di legge Résilience.

La lettura prudente è semplice:

• ReCyF non è la direttiva NIS2 stessa
• ReCyF non sostituisce la lettura dei testi giuridici applicabili
• le entità basate in Francia possono comunque usarlo come punto di riferimento pratico rispetto alla supervisione nazionale
• i team devono trattare lo stato del recepimento francese e le aspettative ANSSI come un livello nazionale che si sovrappone alla direttiva UE

In questo senso, Guida ANSSI Active Directory: come applicare in pratica le raccomandazioni di sicurezza è una lettura complementare utile, ma non un sostituto dell’analisi NIS2.

Remediation

Anche prima della validazione formale, i team dovrebbero avviare remediation concreta sui punti che non riuscirebbero a difendere in una review. In pratica significa ridurre privilegi permanenti non giustificati, chiudere i percorsi di autenticazione legacy ancora aperti, rafforzare la governance di guest e cross-tenant, riesaminare i service principal sovraprivilegiati e documentare con precisione lo stato corretto.

Validazione dopo la remediation

Un programma identity realmente difendibile in una review NIS2 deve poter dimostrare che i gap sono stati corretti, non soltanto identificati.

Dopo la remediation, i team dovrebbero poter mostrare:

1. inventari aggiornati dell’accesso privilegiato in AD ed Entra
2. evidenza attuale che i controlli di autenticazione forte si applichino dove l’organizzazione dichiara che debbano applicarsi
3. impostazioni aggiornate di guest, cross-tenant e governance applicativa dopo le modifiche
4. evidenza di audit attuale che dimostri che le modifiche identity restano visibili
5. un elenco di eccezioni aggiornato che distingua il rischio residuo dalla deriva o dalla negligenza

In pratica, le azioni che migliorano di più la difendibilità di una postura identity sono spesso le stesse: rimuovere privilegi permanenti non necessari, chiudere accessi legacy ancora aperti, riesaminare guest e accesso cross-tenant, inventariare service principal sovraprivilegiati e poi rieseguire export e log che servono da evidenza. L’obiettivo non è produrre un’altra slide. L’obiettivo è dimostrare che un controllo dichiarato esiste ancora dopo la correzione.

È proprio questo passaggio di validazione a separare un esercizio una tantum di framework da una review che regge anche al ciclo di audit successivo.

Come EtcSec aiuta a misurare gap identity rilevanti per la NIS2

Qui EtcSec va posizionata in modo stretto.

Il punto non è dire che EtcSec “prova la conformità NIS2”. Il punto è che aiuta a misurare gap tecnici di identità che spesso contano quando un team deve dimostrare che accesso, autenticazione, governance dei privilegi e monitoraggio sono realmente applicati.

Esempi:

• EXCESSIVE_PRIVILEGED_ACCOUNTS
• PRIVILEGED_ACCOUNT_STALE
• DANGEROUS_GROUP_NESTING
• DCSYNC_CAPABLE
• ACL_GENERICALL
• CA_NO_MFA_REQUIREMENT
• PA_PIM_NOT_ENABLED
• GUEST_INVITATION_UNRESTRICTED
• B2B_CROSS_TENANT_OPEN
• AZ_SECURITY_DEFAULTS_DISABLED

Questi findings non creano alcuna presunzione legale. Aiutano il team security a rispondere a una domanda più difficile: se affermiamo che i nostri controlli identity sono basati sul rischio e realmente applicati, quale evidenza tecnica attuale sostiene questa affermazione?

Fonti primarie

• Directive (EU) 2022/2555 (NIS2) — EUR-Lex
• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
• Sintesi giuridica EUR-Lex sulla cybersicurezza di reti e sistemi informativi
• ANSSI: La directive NIS 2
• Microsoft Learn: What is Conditional Access?
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management?
• Microsoft Learn: What are Microsoft Entra audit logs?
• Microsoft Learn: Overview of permissions and consent in the Microsoft identity platform
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Restrict guest access permissions in Microsoft Entra ID
• Microsoft Learn: What are access reviews?
• Microsoft Learn: Advanced security audit policy settings