Governance dell’Accesso condizionale di Microsoft Entra nel 2026

Sono le 09:12 di un martedì quando Maria, CISO di una fintech europea in forte crescita, apre un rapporto di preparazione a DORA che avrebbe dovuto essere ordinario. Il cruscotto dell’Accesso condizionale di Microsoft Entra sembra solido. L’MFA è applicata agli amministratori. L’autenticazione legacy è bloccata. Gli accessi ad alto rischio sono sottoposti a verifica o negati. Le applicazioni finanziarie sensibili richiedono dispositivi conformi. L’accesso via browser da endpoint non gestiti è limitato.

Poi legge la risultanza dell’auditor.

“Le vostre regole di Accesso condizionale sono tecnicamente corrette, ma esistono nel vuoto. Mostrateci la politica approvata dal consiglio di amministrazione che impone queste impostazioni. Mostrateci la registrazione della modifica per la regola aggiornata il mese scorso. Mostrateci come la policy sugli accessi ad alto rischio fosse attiva durante il presunto attacco di credential stuffing. Mostrateci come queste evidenze supportano ISO 27001, DORA, NIS2 e GDPR.”

Il team IAM può esportare la configurazione. Il SOC può mostrare i log di accesso. Il responsabile compliance può indicare una cartella delle politiche. Ma nessuno è in grado di produrre una narrazione governata delle evidenze che colleghi rischio, politica, approvazione, configurazione, eccezioni, monitoraggio, risposta agli incidenti, obblighi privacy e riesame della direzione.

Questo è il problema della governance dell’Accesso condizionale nel 2026.

L’Accesso condizionale di Microsoft Entra non è più soltanto un’impostazione di identità. È un sistema di controllo a livello di consiglio di amministrazione che decide chi può accedere ai servizi cloud, a quali condizioni, da quali dispositivi, con quale robustezza di autenticazione e con quali restrizioni di sessione. Per le organizzazioni regolamentate, tali decisioni devono essere spiegabili, difendibili e mappate agli obblighi previsti da ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST e COBIT 2019.

L’Accesso condizionale è ormai un sistema di controllo verificabile

L’Accesso condizionale si colloca all’intersezione tra identità, postura di sicurezza del dispositivo, sensibilità dell’applicazione, posizione, rischio di accesso, rischio utente, comportamento di sessione e logging. Una singola policy può richiedere MFA, imporre un dispositivo conforme, bloccare l’accesso da una posizione rischiosa, limitare i download da browser non gestiti oppure forzare una nuova autenticazione quando il rischio cambia.

Questo lo rende uno dei punti di enforcement Zero Trust più efficaci negli ambienti cloud Microsoft. Lo rende anche altamente verificabile in sede di audit.

Ai sensi di ISO/IEC 27001:2022, un controllo non è maturo solo perché esiste in un portale. L’organizzazione deve comprendere il proprio contesto, valutare i rischi per la sicurezza delle informazioni, selezionare i trattamenti del rischio, documentare la Dichiarazione di Applicabilità, operare i controlli, monitorarne l’efficacia e migliorare nel tempo. Le clausole rilevanti includono la clausola 6.1.2 per la valutazione del rischio, la clausola 6.1.3 per il trattamento del rischio, la clausola 7.5 per le informazioni documentate, la clausola 8.1 per la pianificazione e il controllo operativi, la clausola 9.1 per il monitoraggio e la clausola 9.3 per il riesame della direzione.

L’Allegato A, allineato a ISO/IEC 27002:2022, fornisce il linguaggio pratico dei controlli che gli auditor riconoscono. L’Accesso condizionale supporta comunemente:

• 5.15 Controllo degli accessi
• 5.16 Gestione delle identità
• 5.17 Informazioni di autenticazione
• 5.18 Diritti di accesso
• 8.1 Dispositivi endpoint degli utenti
• 8.2 Diritti di accesso privilegiato
• 8.3 Limitazione dell’accesso alle informazioni
• 8.5 Autenticazione sicura
• 8.15 Logging
• 8.16 Attività di monitoraggio

Per le organizzazioni regolamentate nell’UE, l’onere di governance è ancora più chiaro. NIS2 Article 20 attribuisce agli organi di gestione la responsabilità di approvare e sorvegliare le misure di gestione dei rischi di cibersicurezza. NIS2 Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, incluse controllo degli accessi, gestione degli asset, igiene informatica, gestione degli incidenti, sicurezza della catena di fornitura, valutazione dell’efficacia e autenticazione a più fattori o autenticazione continua, ove opportuno. NIS2 Article 23 introduce una segnalazione scaglionata degli incidenti significativi, inclusi un preallarme entro 24 ore, una notifica dell’incidente entro 72 ore e un rapporto finale entro un mese.

DORA introduce aspettative analoghe per le entità finanziarie. Article 5 richiede un quadro interno di governance e controllo. Article 6 richiede un quadro per la gestione del rischio ICT. Article 9 riguarda protezione e prevenzione, incluse restrizioni di accesso e pratiche di gestione delle identità. Articles 10, 11, 17, 18 e 19 collegano rilevazione, risposta, ripristino, gestione degli incidenti ICT, classificazione e segnalazione. Poiché DORA si applica dal 17 gennaio 2025, le entità finanziarie devono considerare l’Accesso condizionale come parte delle evidenze di resilienza operativa, non solo come rafforzamento dell’identità.

GDPR aggiunge la prospettiva privacy. Se l’Accesso condizionale protegge sistemi che trattano dati personali, supporta i principi di accountability di Article 5, la responsabilità del titolare del trattamento di Article 24, la protezione dei dati fin dalla progettazione di Article 25 e la sicurezza del trattamento di Article 32. Se si sospetta un accesso non autorizzato, i log dell’Accesso condizionale possono diventare parte delle evidenze per la valutazione della violazione e per la notifica.

L’errore consiste nel trattare queste richieste come audit separati. L’approccio maturo è un unico modello di governance dell’Accesso condizionale, segmentabile per quadro di riferimento, autorità di regolamentazione, cliente o consiglio di amministrazione.

La configurazione non è governance

La maggior parte delle organizzazioni sa rispondere alla domanda: “Che cosa è configurato?”. Meno organizzazioni sanno rispondere alle domande più difficili:

• Perché questa policy di Accesso condizionale è configurata in questo modo?
• Quale scenario di rischio tratta?
• Quale clausola della politica la richiede?
• Chi ha approvato la modifica?
• Quali utenti, applicazioni e dispositivi sono esclusi?
• Come viene testata?
• Quali log provano che ha funzionato?
• Con quale frequenza viene riesaminata?
• Che cosa accade quando fallisce?

È qui che di solito emergono le risultanze dell’audit. Le policy esistono ma non sono collegate alle impostazioni di Microsoft Entra. La conformità dei dispositivi è in capo alle operation IT ma non è mappata al rischio di controllo degli accessi. Le policy sul rischio di accesso sono abilitate senza soglie documentate o regole di escalation. Le restrizioni di sessione sono configurate ma non vengono mai testate da dispositivi non gestiti. I log sono conservati ma non trasformati in evidenze di audit utilizzabili.

Clarysec considera questo un problema di tracciabilità. Ogni decisione di Accesso condizionale deve collegare politica, rischio, controllo, configurazione, evidenza e riesame.

La SME Cloud Usage Policy-sme Cloud Usage Policy-sme - SME stabilisce:

Autenticazione a più fattori (MFA) per account amministrativi e account utente

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

Quella clausola è il mandato. La regola di Accesso condizionale è l’applicazione. Il log di accesso è l’evidenza. La registrazione del riesame dimostra la supervisione.

La SME Network Security Policy-sme Network Security Policy-sme - SME aggiunge il requisito relativo alla postura di sicurezza degli endpoint:

I sistemi senza antivirus aggiornato, patch aggiornate o una postura di sicurezza del dispositivo accettabile devono essere bloccati o messi in quarantena

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

In termini Microsoft Entra, questo può diventare “richiedere un dispositivo conforme”, “bloccare piattaforme non supportate”, “limitare le sessioni browser non gestite” oppure “negare l’accesso ad applicazioni ad alto rischio da dispositivi sconosciuti”. Ma il controllo non è completo finché l’organizzazione non può dimostrare ambito, approvazione, test, eccezioni e monitoraggio.

Costruire la base di governance prima dell’insieme di regole

Un programma di Accesso condizionale solido inizia fuori dal portale Entra. Inizia dal SGSI, dal Registro dei rischi, dalla Politica di controllo degli accessi, dalla Politica di utilizzo del cloud, dalla SoA e dal modello delle evidenze.

Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec Zenith Blueprint fornisce una sequenza pratica. Nella fase Gestione del rischio, passaggio 13, Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità, indica alle organizzazioni di collegare i controlli ai rischi e ai driver normativi:

Riferimenti incrociati alle normative: se determinati controlli sono attuati specificamente per conformarsi a GDPR, NIS2 o DORA, è possibile annotarlo nel Registro dei rischi (come parte della giustificazione dell’impatto del rischio) oppure nelle note della SoA.

Per l’Accesso condizionale, questo cambia la narrazione delle evidenze. Invece di dire: “Abbiamo abilitato l’MFA”, l’organizzazione può dire:

• Scenario di rischio: credenziali utente compromesse consentono un accesso non autorizzato ai dati dei clienti in Microsoft 365 e in SaaS finanziari.
• Proprietario del rischio: responsabile della sicurezza IT.
• Trattamento: l’Accesso condizionale di Entra richiede MFA forte per i ruoli privilegiati, MFA per gli utenti, blocco del rischio di accesso, dispositivi conformi per le applicazioni sensibili e restrizioni di sessione per endpoint non gestiti.
• Mappatura ISO/IEC 27002:2022: 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 e 8.16.
• Mappatura normativa: NIS2 Articles 20, 21 e 23, DORA Articles 5, 6, 9, 10, 17 e 18, GDPR Articles 24, 25, 32 e 33.
• Evidenze: approvazione della politica, esportazione dell’Accesso condizionale, ticket di modifica, risultati dei test, log di accesso, report di conformità dei dispositivi, Registro delle eccezioni, ticket SOC e verbali del riesame della direzione.

Il Zenith Blueprint spiega inoltre, nella fase Controlli in azione, passaggio 19, perché la postura di sicurezza degli endpoint deve far parte della decisione di accesso:

L’accesso alle informazioni tramite endpoint deve essere contestuale. Ad esempio, il dispositivo soddisfa gli standard minimi di sicurezza prima di accedere alle risorse aziendali? Ha superato di recente una scansione malware? Si connette da una posizione o da una rete insolita? Integrandosi con i principi Zero Trust, la postura di sicurezza dell’endpoint può alimentare l’accesso condizionale, negando l’ingresso finché il dispositivo non dimostra di essere sicuro.

Questo è il principio centrale di governance. L’Accesso condizionale deve essere basato sul rischio, contestuale e capace di produrre evidenze.

Mappare le decisioni di Accesso condizionale agli obiettivi di controllo

Un programma maturo definisce decisioni di accesso standard e quindi mappa ciascuna di esse all’intento di governance e alle evidenze. Questo evita la proliferazione delle policy e semplifica le conversazioni con gli auditor.

La Enterprise Cloud Usage Policy Cloud Usage Policy supporta l’integrazione centrale dell’identità:

L’integrazione Single Sign-On (SSO) con l’IdP dell’organizzazione è richiesta per garantire la coerenza dell’autenticazione.

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

La Enterprise User Account and Privilege Management Policy User Account and Privilege Management Policy rende esplicito il monitoraggio:

L’uso dei sistemi Single Sign-On (SSO) deve essere integrato con provider di identità centrali (ad es. Active Directory (AD), Azure AD) e monitorato per attività di accesso anomale.

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

Insieme, queste clausole richiedono più del SSO. Richiedono un’architettura di identità centrale, autenticazione coerente, monitoraggio degli accessi anomali ed evidenze che le decisioni di accesso siano riesaminate.

Conformità dei dispositivi: il controllo che gli auditor possono testare

La conformità dei dispositivi è una delle aree più facili da sopravvalutare. Un cruscotto può mostrare il 92% di dispositivi conformi, ma un auditor chiederà se la regola si applica alle applicazioni rilevanti, se i dispositivi personali sono consentiti, se le piattaforme non supportate sono bloccate e se le eccezioni sono approvate.

La Enterprise Remote Work Policy Remote Work Policy definisce la baseline di approvazione:

I dispositivi BYOD devono essere esplicitamente approvati e:

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

Questa breve frase è rilevante. BYOD non è solo uno stato tecnico. È una decisione di governance. Nell’Accesso condizionale deve tradursi in regole di proprietà del dispositivo, baseline minime di conformità, requisiti di cifratura, controlli su patch e protezione malware, protezione delle app mobili, gestione dei contraenti e riesame delle eccezioni.

Zenith Controls: The Cross-Compliance Guide di Clarysec Zenith Controls mappa il controllo ISO/IEC 27002:2022 5.15 Controllo degli accessi come preventivo, a protezione di riservatezza, integrità e disponibilità nella capacità operativa di gestione delle identità e degli accessi. Collega inoltre il controllo degli accessi ai dispositivi endpoint degli utenti, perché laptop, telefoni mobili e desktop non gestiti possono indebolire l’applicazione centralizzata degli accessi.

Un pratico Pacchetto trimestrale di evidenze sui dispositivi per l’Accesso condizionale dovrebbe includere:

• Baseline approvata di conformità dei dispositivi.
• Policy di Accesso condizionale che richiedono dispositivi conformi.
• Applicazioni protette da tali policy.
• Esportazione di utenti, gruppi, applicazioni e piattaforme esclusi.
• Report sull’andamento dei dispositivi non conformi.
• Esempi di log di accesso bloccato per dispositivi non conformi.
• Registro delle eccezioni con proprietario, motivazione, data di scadenza e accettazione del rischio.
• Registrazione del riesame della direzione.

Questo pacchetto di evidenze supporta il controllo operativo ISO/IEC 27001:2022, l’igiene informatica NIS2, protezione e prevenzione DORA e l’accountability GDPR.

Rischio di accesso: la rilevazione deve diventare evidenza decisionale

L’Accesso condizionale basato sul rischio è il punto in cui la rilevazione dell’identità diventa governance degli accessi. Microsoft Entra può valutare segnali come proprietà di accesso non familiari, indirizzi IP anonimi, impossible travel e credenziali trapelate. Tuttavia, gli auditor non accetteranno “policy di rischio abilitata” come risposta finale. Chiederanno perché sono state selezionate determinate soglie, chi riesamina gli eventi rischiosi e quando un accesso ad alto rischio diventa un incidente.

La SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME definisce un requisito minimo di registrazione:

Log di autenticazione: tentativi di accesso riusciti e non riusciti, durata della sessione, utilizzo dell’MFA

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

La Enterprise Logging and Monitoring Policy Logging and Monitoring Policy amplia l’insieme di eventi atteso:

Tipi di eventi da acquisire (ad es. accessi, errori di accesso, modifiche di configurazione, comandi amministrativi, rilevazione del malware)

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

Per l’Accesso condizionale, le evidenze utili dovrebbero includere accessi riusciti, accessi non riusciti, risultato della policy di Accesso condizionale, metodo MFA, rischio di accesso, rischio utente, stato di conformità del dispositivo, applicazione acceduta, posizione, applicazione client, risultato del controllo di sessione, cronologia delle modifiche alle policy e azioni amministrative.

Zenith Controls mappa il controllo ISO/IEC 27002:2022 8.16 Attività di monitoraggio come controllo di rilevamento e correttivo, associato ai concetti Detect e Respond. Collega il monitoraggio al logging, alla valutazione degli eventi, alle informazioni sulle minacce, al monitoraggio dei fornitori e alla gestione degli incidenti. Mappa inoltre le attività di monitoraggio a GDPR Articles 32 e 33, monitoraggio e segnalazione degli incidenti NIS2, tracciamento degli incidenti ICT DORA, monitoraggio continuo NIST e monitoraggio della sicurezza COBIT.

Un accesso ad alto rischio bloccato dall’Accesso condizionale non è quindi solo un successo di sicurezza. È evidenza che i processi preventivi, di rilevamento e di risposta sono collegati.

Controlli di sessione: il collegamento tra accesso e protezione dei dati

Le decisioni prima dell’accesso non bastano. Una volta autenticato l’utente, i controlli di sessione determinano quanta esposizione residua rimane. Questo è particolarmente importante per dispositivi non gestiti, contraenti, lavoro da remoto, terminali condivisi, posizioni rischiose e applicazioni che trattano dati personali.

La SME Application Security Requirements Policy-sme Application Security Requirements Policy-sme - SME stabilisce:

Gestione delle sessioni: i dati di sessione devono scadere dopo 15 minuti di inattività e includere avvisi di timeout ove applicabile.

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

Nella governance di Microsoft Entra, questo può mappare a frequenza di accesso, restrizioni sulle sessioni browser persistenti, Conditional Access App Control, restrizioni applicate dall’applicazione, blocco dei download, riautenticazione dopo variazioni del rischio e limitazioni di sessione basate sulla sensibilità.

I controlli di sessione supportano i controlli ISO/IEC 27002:2022 8.3 Limitazione dell’accesso alle informazioni e 8.5 Autenticazione sicura. Supportano inoltre GDPR Article 32 riducendo la visualizzazione, il download o la persistenza non autorizzati dell’accesso ai dati personali. Per DORA, le restrizioni di sessione aiutano a limitare l’esposizione nei sistemi ICT e supportano rilevazione e risposta. Per NIS2, sono misure proporzionate di controllo degli accessi e igiene informatica.

Le evidenze devono spiegare perché il controllo di sessione esiste. Ad esempio, “bloccare il download da dispositivi non gestiti per applicazioni HR e finanziarie” deve mappare a perdita di dati personali, compromissione degli endpoint e perdita di riservatezza. Le evidenze devono includere configurazione, ambito applicativo, test di accesso da dispositivi gestiti e non gestiti, log che mostrano le restrizioni e registrazioni di approvazione.

Creare un Registro dei controlli di Accesso condizionale

Un Registro dei controlli di Accesso condizionale è il collegamento operativo tra Registro dei rischi, Dichiarazione di Applicabilità e configurazione Microsoft Entra. Non sostituisce questi documenti. Li rende utilizzabili.

Utilizzare un ciclo di riesame in cinque fasi:

1. Confermare l’ambito: identificare le applicazioni cloud che trattano dati regolamentati, finanziari, operativi o personali.
2. Mappare le policy ai rischi: collegare ogni policy di Accesso condizionale ad almeno uno scenario di rischio e a un Proprietario del rischio.
3. Validare le esclusioni: esportare utenti, ruoli, app, gruppi, posizioni e dispositivi esclusi. Ogni esclusione richiede proprietario, motivazione, approvazione e scadenza.
4. Testare l’applicazione: utilizzare account di test per verificare MFA, conformità dei dispositivi, blocco del rischio, blocco dell’autenticazione legacy e restrizioni di sessione.
5. Preparare il pacchetto di evidenze: archiviare esportazioni, screenshot, log e approvazioni con metadati.

La SME Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme - SME è fondamentale per l’integrità delle evidenze:

I metadati (ad es. chi li ha raccolti, quando e da quale sistema) devono essere documentati.

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

Gli screenshot privi di fonte, data, soggetto che li ha raccolti e contesto di sistema sono evidenze deboli. Le esportazioni dell’Accesso condizionale, i log di accesso e i report di riesame devono essere trattati come registrazioni di audit controllate.

Mappatura di conformità trasversale per le evidenze di Accesso condizionale

Il valore dell’Accesso condizionale è che un unico insieme di controlli può soddisfare più prospettive di audit, se correttamente governato.

Zenith Controls mappa inoltre 5.15 Controllo degli accessi a GDPR Article 32, NIS2 Article 21(2)(i), concetti DORA di governance degli accessi, famiglie di controllo degli accessi NIST SP 800-53 e COBIT 2019 DSS06.04. Mappa 8.5 Autenticazione sicura a GDPR Articles 5, 24, 25 e 32, gestione dei rischi di cibersicurezza NIS2, gestione del rischio ICT DORA, identificazione e autenticazione NIST e identità e accesso logico COBIT.

La lezione è semplice. I quadri di riferimento usano linguaggi diversi, ma si aspettano lo stesso schema di assurance: gli utenti corretti, da contesti accettabili, con autenticazione forte, tramite sessioni governate, con log che dimostrano che cosa è accaduto.

Come gli auditor esamineranno l’Accesso condizionale

Un auditor ISO/IEC 27001:2022 partirà dal SGSI. Chiederà se l’Accesso condizionale rientra nell’ambito, quali rischi tratta, come compare nella SoA, come sono approvate le policy, come sono controllate le modifiche e se le evidenze dimostrano l’efficacia operativa. Aspettarsi campionamenti su utenti privilegiati, applicazioni sensibili, esclusioni e modifiche recenti alle policy.

Un auditor DORA o NIS2 si concentrerà su resilienza operativa, accountability della direzione e rischio. Potrà chiedere in che modo i controlli degli accessi proteggono funzioni critiche o importanti, come il consiglio di amministrazione supervisiona il rischio di identità, come vengono sottoposti a triage gli accessi ad alto rischio e se i fallimenti di accesso alimentano le decisioni di classificazione o segnalazione degli incidenti.

Un auditor focalizzato su GDPR si occuperà dei dati personali. Potrà chiedere come i dati HR, finanziari o dei clienti siano protetti dai dispositivi non gestiti, come i controlli di sessione riducano la visualizzazione non autorizzata, come l’accesso sia limitato agli utenti autorizzati e come i log supportino la valutazione della violazione.

Un revisore COBIT 2019 cercherà pratiche di governance, titolarità, metriche, ripetibilità, monitoraggio delle prestazioni e miglioramento. Un valutatore orientato a NIST confronterà gli esiti di identità, autenticazione, autorizzazione, monitoraggio e risposta con le evidenze tecniche.

La Enterprise Access Control Policy Access Control Policy definisce il tono per l’accesso privilegiato:

Gli accessi amministrativi devono essere strettamente controllati tramite:

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

Le evidenze Microsoft Entra devono completare operativamente quella frase. Quali ruoli sono privilegiati? Quali richiedono MFA resistente al phishing o forte? Quali sono eleggibili tramite Privileged Identity Management? Quali account sono account di emergenza break-glass? Quali sono esclusi dalle policy? Chi li riesamina? Dove vengono inviate le allerte?

Metriche per il consiglio di amministrazione sulla governance dell’Accesso condizionale

Poiché NIS2 e DORA enfatizzano l’accountability della direzione, la reportistica sull’Accesso condizionale deve essere leggibile dal consiglio di amministrazione. Evitare di riportare solo i nomi delle policy. Riportare postura di rischio e prestazione del controllo.

Metriche utili includono:

• Percentuale di account privilegiati protetti da MFA forte.
• Numero di esclusioni dall’Accesso condizionale per livello di rischio.
• Numero di accessi ad alto rischio bloccati, sottoposti a verifica o consentiti.
• Percentuale di accessi ad applicazioni sensibili che richiedono dispositivi conformi.
• Numero di sessioni da dispositivi non gestiti verso applicazioni regolamentate.
• Tempo di triage degli eventi di accesso ad alto rischio.
• Numero di modifiche alle policy di Accesso condizionale nel trimestre.
• Numero di eccezioni scadute, rinnovate e in ritardo.
• Copertura della registrazione di autenticazione, sessione e modifiche alle policy.
• Casi di test falliti nella validazione trimestrale dell’Accesso condizionale.

Queste metriche trasformano la configurazione dell’identità in evidenze di supervisione. Aiutano inoltre gli organi di gestione a dimostrare approvazione, riesame, assegnazione di risorse e miglioramento continuo.

Risultanze comuni da eliminare prima dell’audit

Le risultanze sull’Accesso condizionale derivano di solito da debolezze di governance, non da fallimenti tecnologici. I problemi più comuni includono:

• Gli account break-glass sono esclusi ma non monitorati.
• Le policy sono denominate in modo incoerente e non hanno proprietari.
• Le applicazioni sensibili mancano dalle regole di conformità dei dispositivi.
• Utenti guest e collaboratori esterni aggirano i controlli standard.
• Account di servizio e identità dei carichi di lavoro non sono governati separatamente.
• Le rilevazioni del rischio di accesso non sono sottoposte a triage né collegate agli incidenti.
• I controlli di sessione non vengono mai testati da dispositivi non gestiti.
• Le modifiche alle policy sono effettuate direttamente in produzione senza registrazioni delle modifiche.
• Le esclusioni sono permanenti, non documentate o approvate verbalmente.
• I log sono conservati ma non riesaminati.
• Le evidenze non includono metadati, contesto della fonte o catena di custodia.

Uno stato obiettivo pronto per il 2026 prevede governance degli accessi approvata dalla direzione, progettazione dell’Accesso condizionale basata sul rischio, mappatura esplicita ISO/IEC 27001:2022 e ISO/IEC 27002:2022, supporto documentato a NIS2, DORA e GDPR, MFA forte per ruolo e rischio, conformità dei dispositivi per accessi sensibili, restrizioni di sessione per contesti non gestiti, autenticazione e modifiche alle policy monitorate, ciclo di vita delle eccezioni, test trimestrali e reportistica alla direzione.

Trasformare Microsoft Entra in evidenze pronte per l’audit

Le tue policy di Accesso condizionale prendono già decisioni di sicurezza ogni minuto. La domanda è se tali decisioni siano governate, basate sul rischio, monitorate e mappate agli obblighi rilevanti per auditor e autorità di regolamentazione.

Inizia con Zenith Blueprint Zenith Blueprint, in particolare il passaggio 13, per collegare le policy di Accesso condizionale a rischi, trattamenti, Dichiarazione di Applicabilità e note normative. Usa Zenith Controls Zenith Controls per mappare controllo degli accessi, autenticazione sicura, postura di sicurezza degli endpoint, logging e monitoraggio rispetto a ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST e COBIT 2019.

Quindi allinea i requisiti interni con le politiche Clarysec, incluse Cloud Usage Policy-sme, Network Security Policy-sme, Logging and Monitoring Policy-sme, Audit and Compliance Monitoring Policy-sme, Application Security Requirements Policy-sme, Cloud Usage Policy, User Account and Privilege Management Policy, Remote Work Policy, Access Control Policy e Logging and Monitoring Policy.

Clarysec ti aiuta a trasformare l’Accesso condizionale di Microsoft Entra da una raccolta di impostazioni in un sistema di controllo applicabile, misurabile e pronto per l’audit. Scarica i toolkit Clarysec pertinenti, richiedi un riesame della mappatura delle politiche o prenota una valutazione per verificare se le tue evidenze di Accesso condizionale possono reggere lo scrutinio ISO 27001, NIS2, DORA e GDPR.