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 tre punti:

• L'articolo 21(2)(f) include politiche e procedure per valutare l'efficacia delle misure di gestione del rischio di cybersicurezza.
• L'articolo 21(2)(i) include la sicurezza delle risorse umane, le politiche di controllo degli accessi e la gestione degli asset. È l'unico punto dell'elenco che nomina direttamente il controllo degli accessi, ed è il riferimento che un team identity dovrebbe citare.
• L'articolo 21(2)(j) include l'uso di soluzioni di autenticazione multifattore o autenticazione continua, comunicazioni vocali, video e testuali 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, configurazione dei dispositivi, segmentazione di rete, identity and access management o consapevolezza degli utenti. Quel considerando non è una baseline Microsoft nascosta. È un segnale forte che governance delle identità, autenticazione e disciplina degli accessi fanno parte di ciò che i regolatori si aspettano che le entità trattino come lavoro di sicurezza fondamentale.

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, adottato il 17 ottobre 2024 ai sensi dell'articolo 21(5), primo comma, stabilisce requisiti tecnici e metodologici per un elenco chiuso di tipologie di entità coperte: DNS service provider, registri di nomi di dominio TLD, cloud computing service provider, data centre service provider, content delivery network provider, managed service provider, managed security service provider, fornitori di mercati online, di motori di ricerca online e di piattaforme di social networking, e trust service provider. Quel regolamento è rilevante, ma non è una scorciatoia generica da applicare senza modifiche a ogni organizzazione soggetta alla NIS2.

Per le entità che rientrano in tale perimetro, l'Allegato è molto più prescrittivo sull'identità rispetto alla direttiva stessa. Il suo punto 11 riguarda il controllo degli accessi ed è collegato dalla Commissione all'articolo 21(2), punti (i) e (j): il punto 11.2.3 richiede che i diritti di accesso siano riesaminati a intervalli pianificati con documentazione dei risultati, il punto 11.3 richiede politiche per gli account privilegiati e gli account di amministrazione di sistema che includano un'autenticazione forte come l'autenticazione multifattore, e il punto 11.7 richiede più fattori di autenticazione o meccanismi di autenticazione continua ove appropriato, con una robustezza di autenticazione commisurata alla classificazione dell'asset a cui si accede.

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". Nessuna delle due affermazioni è difendibile: la direttiva non nomina alcun prodotto, e persino il regolamento di esecuzione descrive l'autenticazione multifattore come un esempio di autenticazione forte, non come un mandato che designa un prodotto specifico.

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: «unisce i segnali per prendere decisioni e applicare le policy organizzative», e Microsoft ora lo descrive come il proprio motore di policy Zero Trust. La stessa pagina aggiunge un dettaglio rilevante per l'evidenza: Conditional Access viene applicato dopo il completamento del primo fattore di autenticazione. 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: cosa verificare per prima e come dimostrare la remediation 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.

Convalida dopo la Remediation

Un programma identity pronto per la NIS2 deve dimostrare che i gap sono stati corretti, non soltanto che sono stati identificati.

Dopo la remediation, i team dovrebbero poter mostrare:

1. inventari aggiornati dell'accesso privilegiato sia in AD sia in 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

È 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: Microsoft Entra Conditional Access, the Zero Trust policy engine
• Microsoft Learn: What is Privileged Identity Management?
• Microsoft Learn: Learn about the audit logs in Microsoft Entra ID
• 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