Pianificare una distribuzione dell'accesso condizionale

Pianificare la distribuzione dell'accesso condizionale è fondamentale affinché la strategia di accesso per le applicazioni e le risorse dell'organizzazione sia quella desiderata. I criteri di accesso condizionale offrono una grande flessibilità di configurazione. Tuttavia, questa flessibilità significa anche pianificare attentamente per evitare risultati indesiderati.

L'accesso condizionale Microsoft Entra combina segnali come utente, dispositivo e posizione per automatizzare le decisioni e applicare i criteri di accesso aziendale per le risorse. Questi criteri di accesso condizionale consentono di bilanciare la sicurezza e la produttività, applicare i controlli di sicurezza quando è necessario e non disturbare l'utente quando non lo è.

L'accesso condizionale è la base del motore di politiche di sicurezza Zero Trust di Microsoft.

Microsoft fornisce impostazioni predefinite per la sicurezza che garantiscono un livello di sicurezza di base abilitato nei tenant che non dispongono dell'ID Microsoft Entra P1 o P2. Con l'accesso condizionale è possibile creare criteri che forniscono la stessa protezione delle impostazioni predefinite per la sicurezza, ma con granularità. Le impostazioni predefinite per l'accesso condizionale e la sicurezza non devono essere combinate perché la creazione di criteri di accesso condizionale impedisce di abilitare le impostazioni predefinite per la sicurezza.

Prerequisiti

• Un tenant di Microsoft Entra funzionante con una licenza P1, P2 o di prova di Microsoft Entra ID abilitata. Se necessario, crearne uno gratuitamente.
  • Microsoft Entra ID P2 è necessario per includere il Microsoft Entra ID Protection nei criteri di accesso condizionale.
• Gli amministratori che interagiscono con l'accesso condizionale devono avere una delle assegnazioni di ruolo seguenti a seconda delle attività eseguite. Per seguire il principio Zero Trust dei privilegi minimi, prendere in considerazione l'uso di Privileged Identity Management (PIM) per attivare just-in-time le assegnazioni di ruoli privilegiati.
  • Leggere criteri e configurazioni di accesso condizionale
    • Security Reader
  • Creare o modificare criteri di accesso condizionale
    • Amministratore accesso condizionale
• Un utente di test (non un amministratore) che consente di verificare che i criteri funzionino come previsto prima della distribuzione agli utenti reali. Se è necessario creare un utente, vedere Avvio rapido: Aggiungere nuovi utenti all'ID Microsoft Entra.
• Un gruppo di cui l'utente di test è membro. Se è necessario creare un gruppo, vedere Creare un gruppo e aggiungere membri in Microsoft Entra ID.

Comunicazione delle modifiche

La comunicazione è fondamentale per il successo di una nuova funzionalità. Comunicare in modo proattivo con gli utenti spiegando come cambierà l'esperienza, quando viene modificata e come ottenere supporto in caso di problemi.

Componenti dei criteri di accesso condizionale

I criteri di accesso condizionale rispondono alle domande su chi può accedere alle risorse, sulle risorse a cui è possibile accedere e in quali condizioni. I criteri possono essere progettati in modo da concedere l'accesso, limitare l'accesso con controlli di sessione o bloccare l'accesso. Per creare un criterio di accesso condizionale, definisci le istruzioni if-then, come:

Esclusioni di utenti

I criteri di accesso condizionale sono strumenti potenti, ma è consigliabile escludere dai criteri i seguenti account:

• Accesso di emergenza o account break-glass per impedire il blocco a causa di errori di configurazione dei criteri. Nello scenario improbabile che tutti gli amministratori siano bloccati, l'account amministrativo di accesso di emergenza può essere usato per accedere ed eseguire le operazioni necessarie per ripristinare l'accesso.
  • Altre informazioni sono disponibili nell'articolo Gestire gli account di accesso di emergenza in Microsoft Entra ID.
• Account di servizio e entità del servizio, ad esempio l'account di sincronizzazione Microsoft Entra Connect. Gli account del servizio sono account non interattivi che non sono collegati a un utente specifico. Vengono in genere usati dai servizi back-end che consentono l'accesso programmatico alle applicazioni, ma vengono usati anche per accedere ai sistemi per scopi amministrativi. Le chiamate effettuate dalle entità servizio non verranno bloccate dai criteri di accesso condizionale con ambito utenti. Usare l'accesso condizionale per le identità identità dei carichi di lavoro al fine di definire criteri destinati alle entità servizio.
  • Se l'organizzazione ha questi account in uso negli script o nel codice, è consigliabile sostituirli con le identità gestite.

Porre le domande giuste

Di seguito sono riportate alcune domande comuni sulle assegnazioni e sui controlli di accesso. Documentare le risposte alle domande relative a ogni criterio prima della creazione.

Utenti o identità dei carichi di lavoro

• Quali utenti, gruppi, ruoli della directory o identità del carico di lavoro sono inclusi o esclusi dai criteri?
• Quali account o gruppi di accesso di emergenza devono essere esclusi dai criteri?

Applicazioni o azioni cloud

Questo criterio verrà applicato a qualsiasi applicazione, azione utente o contesto di autenticazione? Se sì:

• A quali applicazioni o servizi verranno applicati i criteri?
• Quali azioni utente sono soggette a questo criterio?
• A quali contesti di autenticazione verranno applicati questi criteri?

Filtrare per applicazioni

L'uso del filtro per le applicazioni per includere o escludere applicazioni anziché specificarle singolarmente consente alle organizzazioni di:

• Scalare e individuare un numero qualsiasi di applicazioni con facilità.
• Gestire facilmente le applicazioni con requisiti di criteri simili.
• Ridurre il numero di singoli criteri.
• Ridurre gli errori durante la modifica dei criteri: non è necessario aggiungere/rimuovere manualmente le applicazioni dai criteri. È sufficiente gestire gli attributi.
• Superare i vincoli di dimensione dei criteri.

Condizioni

• Quali piattaforme di dispositivo verranno incluse o escluse dal criterio?
• Quali sono i percorsi di rete noti dell'organizzazione?
  • Quali percorsi vengono inclusi o esclusi dal criterio?
• Quali tipi di app client sono inclusi o esclusi dai criteri?
• È necessario specificare gli attributi del dispositivo di destinazione?
• Se si utilizza Microsoft Entra ID Protection, vuoi incorporare il rischio di accesso o rischio utente?

Bloccare o concedere controlli

Si desidera concedere l'accesso alle risorse richiedendo uno o più degli elementi seguenti?

• Autenticazione a più fattori
• Dispositivo contrassegnato come conforme
• Uso di un dispositivo aggiunto a Microsoft Entra ibrido
• Uso di un'app client approvata
• Criteri di protezione delle app applicati
• Modifica della password
• Condizioni per l'utilizzo accettate

Blocca l'accesso è un potente controllo da applicare con le conoscenze appropriate. I criteri con istruzioni di blocco possono avere effetti collaterali imprevisti. I test e la convalida appropriati sono fondamentali prima di abilitare il controllo su larga scala. Gli amministratori devono utilizzare strumenti come la modalità di solo report di Accesso Condizionale e lo strumento What If in Accesso Condizionale quando si apportano modifiche.

Controlli di sessione

Si desidera applicare uno dei controlli di accesso seguenti nelle applicazioni cloud?

• Usa restrizioni imposte dalle app
• Usare il controllo app per l'accesso condizionale
• Applicare la frequenza di accesso
• Usare la sessione del browser persistente
• Personalizzare la valutazione continua dell'accesso

Combinazione di criteri

Quando si creano e si assegnano criteri, è necessario tenere conto del funzionamento dei token di accesso. I token di accesso concedono o negano l'accesso in base al fatto che gli utenti che effettuano una richiesta siano stati autorizzati e autenticati. Se il richiedente può dimostrare di essere chi dichiara di essere, può accedere alle risorse o alle funzionalità protette.

I token di accesso vengono emessi per impostazione predefinita se una condizione dei criteri di accesso condizionale non attiva un controllo di accesso.

Questo criterio non impedisce all'app di avere la propria capacità di bloccare l'accesso.

Si consideri ad esempio un esempio di criteri semplificato in cui:

Utenti: FINANCE GROUP
Accesso: PAYROLL APP
Controllo di accesso: autenticazione a più fattori

• L'utente A si trova nel GRUPPO FINANCE, deve eseguire l'autenticazione a più fattori per accedere all'APP PAYROLL.
• L'utente B non è nel GRUPPO FINANCE, viene emesso un token di accesso ed è autorizzato ad accedere all'APP PAYROLL senza eseguire l'autenticazione a più fattori.

Per garantire che gli utenti esterni al gruppo finance non possano accedere all'app payroll è possibile creare criteri separati per bloccare tutti gli altri utenti, ad esempio i criteri semplificati seguenti:

Utenti: includere tutti gli utenti/escludere GRUPPO FINANCE
Accesso: PAYROLL APP
Controllo di accesso: Blocca l'accesso

Ora, quando l'utente B tenta di accedere all'APP del libro paga, viene bloccato.

Consigli

Tenendo conto delle informazioni apprese nell'uso dell'accesso condizionale e nel sostegno di altri clienti, ecco alcuni consigli basati sulle nostre informazioni.

Applicare criteri di accesso condizionale a ogni app

Assicurarsi che ogni app abbia almeno un criterio di accesso condizionale applicato. Dal punto di vista della sicurezza è preferibile creare un criterio che includa tutte le risorse (in precedenza "Tutte le app cloud"). Questa procedura garantisce che non sia necessario aggiornare i criteri di accesso condizionale ogni volta che si esegue l'onboarding di una nuova applicazione.

Ridurre al minimo il numero di criteri di accesso condizionale

La creazione di un criterio per ciascuna applicazione non è un'operazione efficiente e rende complicata l'amministrazione. L'accesso condizionale ha un limite di 195 criteri per tenant. Questo limite di criteri 195 include i criteri di accesso condizionale in qualsiasi stato, inclusa la modalità solo report, attivata o disattivata.

È consigliabile analizzare le app e raggrupparle in applicazioni con gli stessi requisiti di risorse per gli stessi utenti. Se, ad esempio, tutte le applicazioni di Microsoft 365 o tutte le applicazioni per la gestione delle risorse umane hanno gli stessi requisiti per gli stessi utenti, creare un singolo criterio e includere tutte le applicazioni a cui si applica.

I criteri di accesso condizionale sono contenuti in un file JSON e tale file è associato a un limite di dimensioni che non si prevede che un singolo criterio superi. Se si usa un lungo elenco di GUID nei criteri, è possibile raggiungere questo limite. Se si raggiungono questi limiti, è consigliabile usare alternative come:

• Usare gruppi o ruoli per includere o escludere utenti anziché elencare singolarmente ogni utente.
• Usare il filtro per le applicazioni per includere o escludere applicazioni anziché specificarle singolarmente.

Configurare la modalità solo report

Per impostazione predefinita, ogni criterio creato dal modello viene creato in modalità solo report. È consigliabile testare e monitorare l'utilizzo delle organizzazioni per garantire il risultato previsto prima di attivare ogni criterio.

Abilitare le politiche in modalità solo per report. Dopo aver salvato un criterio in modalità solo report, è possibile osservarne l'effetto sugli accessi in tempo reale nei log di accesso. Nei log di accesso, selezionare un evento e passare alla scheda Solo report per visualizzare il risultato di ogni criterio di sola segnalazione.

È possibile visualizzare gli effetti aggregati dei criteri di accesso condizionale nella cartella di lavoro Insights e Report. Per accedere alla cartella di lavoro, è necessaria una sottoscrizione di Monitoraggio di Azure ed è necessario trasmettere i log di accesso a un'area di lavoro Log Analytics.

Pianificare l'interruzione

Per ridurre il rischio di blocco durante interruzioni impreviste, pianificare strategie di resilienza per l'organizzazione.

Abilitare le azioni protette

L'abilitazione delle azioni protette pone un altro livello di sicurezza sui tentativi di creare, modificare o eliminare criteri di accesso condizionale. Le organizzazioni possono richiedere una nuova autenticazione a più fattori o un altro controllo di concessione prima di modificare i criteri.

Impostare gli standard di denominazione per i criteri

Uno standard di denominazione consente di trovare i criteri e comprenderne lo scopo senza aprirli nel portale di amministrazione di Azure. Si consiglia di denominare il criterio per visualizzare:

• Un numero di sequenza
• Le applicazioni cloud a cui si applica
• Risposta
• A chi si applica
• Quando si applica

Esempio: un criterio per richiedere l'autenticazione a più fattori per gli utenti di marketing che accedono all'app Dynamics CRP da reti esterne potrebbe essere:

Un nome descrittivo consente di ottenere una panoramica dell'implementazione dell'accesso condizionale. Il numero di sequenza è utile se è necessario fare riferimento a un criterio in una conversazione. Se ad esempio si parla al telefono con un altro amministratore, è possibile chiedergli di aprire il criterio CA01 per risolvere un problema.

Standard di denominazione per i controlli di accesso di emergenza

Oltre ai criteri attivi, implementare criteri disabilitati che fungono da controlli di accesso resilienti secondari in scenari di interruzione o emergenza. Lo standard di denominazione per i criteri di emergenza deve includere:

• ENABLE IN EMERGENCY all'inizio in modo che il nome si distingua dagli altri criteri.
• Il nome dell'interruzione a cui deve essere applicato.
• Un numero di sequenza di ordinamento per consentire all'amministratore di sapere in che ordine devono essere abilitati i criteri.

Esempio: il nome seguente indica che questo criterio è il primo di quattro criteri da abilitare in caso di interruzione dell'autenticazione a più fattori:

• EM01 - ENABLE IN EMERGENCY: interruzione MFA [1/4] - Exchange SharePoint: Richiede join ibrido Microsoft Entra per gli utenti VIP.

Bloccare paesi/aree geografiche da cui non ci si aspetta mai un accesso

Microsoft Entra ID consente di creare posizioni denominate. Creare l'elenco di Paesi/aree geografiche consentite, quindi creare un criterio di blocco di rete con questi "Paesi/aree geografiche consentiti" come esclusione. Questa opzione crea meno sovraccarico per i clienti che si trovano in località geografiche più piccole. Assicurarsi di esentare gli account di accesso di emergenza da questo criterio.

Implementare i criteri di accesso condizionale

Quando si è pronti, distribuire i criteri di accesso condizionale in fasi.

Creare i criteri di accesso condizionale

Per un inizio iniziale, vedere Modelli di criteri di accesso condizionale e Criteri di sicurezza comuni per le organizzazioni di Microsoft 365 . Questi modelli sono un modo pratico per distribuire le raccomandazioni Microsoft. Assicurarsi di escludere gli account di accesso di emergenza.

Valutare l'impatto di un criterio

È consigliabile usare gli strumenti seguenti per valutare l'effetto dei criteri sia prima che dopo aver apportato modifiche. Un'esecuzione simulata dà una buona idea dell'effetto di un criterio di accesso condizionale, non sostituisce un'esecuzione di test effettiva in un ambiente di sviluppo configurato correttamente.

• Modalità solo report e cartella di lavoro per approfondimenti e creazione di report sull'accesso condizionale.
• Lo strumento What If

Testare i criteri

Assicurarsi di testare i criteri di esclusione di una politica. È possibile, ad esempio, escludere un utente o gruppo da un criterio che richiede l'autenticazione MFA. Verificare se agli utenti esclusi viene richiesta l'autenticazione MFA, perché la combinazione di altri criteri potrebbe richiedere l'autenticazione MFA per questi stessi utenti.

Eseguire tutti i test nel piano di test con gli utenti di test. Il piano di test è importante per disporre di un confronto tra i risultati previsti e i risultati effettivi. Nella tabella seguente vengono descritti alcuni test case di esempio. Modificare gli scenari e i risultati previsti in base al modo in cui sono configurati i criteri di accesso condizionale.

Distribuire nell'ambiente di produzione

Dopo aver verificato l'impatto usando la modalità solo report, un amministratore può spostare il toggle della politica di abilitazione da solo report a attivato.

Eseguire il rollback dei criteri

Nel caso in cui sia necessario eseguire il rollback dei criteri appena implementati, usare una o più delle opzioni seguenti:

• Disabilitare il criterio. La disabilitazione di un criterio garantisce che non venga applicato quando un utente tenta di accedere. È sempre possibile tornare indietro e abilitare il criterio quando si vorrà utilizzarlo.

• Escludere un utente o un gruppo da un criterio. Se un utente non è in grado di accedere all'applicazione, è possibile scegliere di escluderlo dal criterio.

  Attenzione

  Le esclusioni devono essere usate con moderazione, solo in situazioni in cui l'utente è attendibile. Gli utenti devono essere nuovamente aggiunti al criterio o al gruppo appena possibile.

• Se un criterio è disabilitato e non è più necessario, eliminarlo.

Risolvere i problemi relativi ai criteri di accesso condizionale

Se un utente presenta un problema con un criterio di accesso condizionale, raccogliere le informazioni seguenti per facilitare la risoluzione dei problemi.

• Nome entità utente
• Nome visualizzato dell'utente
• Nome del sistema operativo
• Timestamp (è sufficiente un'approssimazione)
• Applicazione di destinazione
• Tipo di applicazione client (browser rispetto a client)
• ID di correlazione (univoco per l'accesso)

Se l'utente ha ricevuto un messaggio con un collegamento Altri dettagli, è possibile raccogliere la maggior parte di queste informazioni dal collegamento.

Dopo aver raccolto le informazioni, vedere le seguenti risorse:

• Problemi di accesso con l'accesso condizionale : comprendere i risultati imprevisti dell'accesso correlato all'accesso condizionale tramite messaggi di errore e il log di accesso di Microsoft Entra.
• Uso dello strumento What-If : comprendere il motivo per cui un criterio è stato o non è stato applicato a un utente in una circostanza specifica o se un criterio verrebbe applicato in uno stato noto.

Contenuto correlato

• Altre informazioni sull'autenticazione a più fattori
• Altre informazioni su Microsoft Entra ID Protection
• Gestire i criteri di accesso condizionale con l'API Microsoft Graph