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à, applicando i controlli di sicurezza quando necessario e rimanendo al di fuori del modo dell'utente quando non lo è.

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

Diagramma che mostra una panoramica generale dell'accesso condizionale.

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

Comunicazione della modifica

La comunicazione è fondamentale per il successo di qualsiasi nuova funzionalità. È consigliabile comunicare in modo proattivo con gli utenti come cambia l'esperienza, quando cambia 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 possono 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, definire le istruzioni if-then come:

Se viene soddisfatta un'assegnazione Applicare i controlli di accesso
Se si è un utente di Finance che accede all'applicazione Payroll Richiedere l'autenticazione a più fattori e un dispositivo conforme
Se non si è membri di Finance che accede all'applicazione Payroll Blocca accesso
Se il rischio utente è elevato Richiedere un'autenticazione a più fattori e una modifica della password sicura

Esclusioni di utenti

I criteri di accesso condizionale sono strumenti avanzati, è consigliabile escludere gli account seguenti dai criteri:

  • Gli account di accesso di emergenza o critici per impedire il blocco degli account a livello di tenant. Nello scenario improbabile che tutti gli amministratori siano bloccati dal tenant, l'account amministrativo di accesso di emergenza può essere usato per accedere al tenant per eseguire le operazioni necessarie per ripristinare l'accesso.
  • Account del servizio e entità 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 a livello di codice alle applicazioni, ma vengono usati anche per accedere ai sistemi per scopi amministrativi. Gli account del servizio di questo tipo dovrebbero essere esclusi poiché l'autenticazione a più fattori non può essere eseguita a livello di codice. 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 dispone di questi account in uso negli script o nel codice, è consigliabile sostituirli con identità gestite. Come soluzione alternativa temporanea, è possibile escludere questi account specifici dai criteri di base.

Porre le domande giuste

Ecco alcune domande comuni su Assegnazioni e Controllo di accesso. Documentare le risposte alle domande relative a ogni criterio prima della creazione.

Utenti o identità del carico 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 le applicazioni

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

  • Scalabilità e destinazione di 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 dispositivi sono incluse o escluse dai criteri?
  • Quali sono i percorsi di rete noti dell'organizzazione?
    • Quali posizioni sono incluse o escluse dai criteri?
  • Quali tipi di app client sono inclusi o esclusi dai criteri?
  • È necessario specificare gli attributi del dispositivo di destinazione?
  • Se si usa Microsoft Entra ID Protection, si vuole incorporare il rischio di accesso o utente?
Rischio di accesso e utente

Per le organizzazioni con licenze Microsoft Entra ID P2, possono includere rischi per l'utente e l'accesso nei criteri di accesso condizionale. Queste aggiunte consentono di ridurre l'attrito delle misure di sicurezza richiedendo l'autenticazione a più fattori o la modifica della password sicura solo quando un utente o un accesso è considerato rischioso.

Per altre informazioni sul rischio e sul relativo uso nei criteri, vedere l'articolo Che cos'è il rischio.

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 ibrido a Microsoft Entra
  • Uso di un'app client approvata
  • Protezione di app criteri applicati
  • Modifica della password
  • Condizioni per l'utilizzo accettate

Il blocco dell'accesso è un controllo potente che va applicato con le dovute conoscenze. 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. Amministrazione istrator devono usare strumenti come Modalità di report solo per l'accesso condizionale e lo strumento What If nell'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 finanziario non possano accedere all'app con retribuzione, è possibile creare criteri separati per bloccare tutti gli altri utenti, ad esempio i criteri semplificati seguenti:

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

Ora, quando l'utente B tenta di accedere all'APP con pagamento in base al consumo, viene bloccato.

Consigli

Tenendo conto delle informazioni apprese nell'uso dell'accesso condizionale e del supporto 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 app cloud e quindi escludere le applicazioni a cui non si vuole applicare i criteri. Questa procedura garantisce che non sia necessario aggiornare i criteri di accesso condizionale ogni volta che si esegue l'onboarding di una nuova applicazione.

Suggerimento

Prestare molta attenzione nell'uso del blocco e di tutte le applicazioni in un singolo criterio. Questo potrebbe bloccare gli amministratori e le esclusioni non possono essere configurate per endpoint importanti, ad esempio Microsoft Graph.

Ridurre al minimo il numero di criteri di accesso condizionale

La creazione di criteri per ogni app non è efficiente e comporta un'amministrazione difficile. 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. Ad esempio, se tutte le app di Microsoft 365 o tutte le app HR hanno gli stessi requisiti per gli stessi utenti, creare un singolo criterio e includere tutte le app 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 si accresca oltre. Se si usa un lungo elenco di GUID nei criteri, è possibile raggiungere questo limite. Se si verificano questi limiti, è consigliabile usare alternative come:

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 i criteri in modalità solo report. Dopo aver salvato un criterio in modalità solo report, è possibile visualizzare 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 solo report.

È possibile visualizzare l'aggregazione sugli effetti dei criteri di accesso condizionale nella cartella di lavoro Informazioni dettagliate 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.

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 app cloud a cui si applica
  • Risposta
  • A chi si applica
  • Quando si applica

Diagramma che mostra gli standard di denominazione di esempio per i criteri.

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:

Diagramma che mostra uno standard di denominazione di esempio.

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, è opportuno implementare anche criteri disabilitati che agiscano come controlli di accesso resilienti secondari in scenari di emergenza o di interruzione dei servizi. 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: MFA Disruption [1/4] - Exchange SharePoint: Require Microsoft Entra hybrid join For VIP users (Richiedi aggiunta ibrida a 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 e 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.

Distribuire 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 offre 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 Informazioni dettagliate sull'accesso condizionale e Creazione di report.
  • Lo strumento What If

Testare i criteri

Assicurarsi di testare i criteri di esclusione di un criterio. Ad esempio, è possibile escludere un utente o un gruppo da un criterio che richiede l'autenticazione a più fattori. 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. La tabella seguente illustra 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.

Criteri Scenario Risultato previsto
Accessi a rischio L'utente accede all'app usando un browser non approvato Calcola un punteggio di rischio in base alla probabilità che l'accesso non sia stato eseguito dall'utente. Richiede all'utente di correggere automaticamente l'autenticazione a più fattori
Gestione dispositivi Un utente autorizzato cerca di accedere da un dispositivo autorizzato Accesso concesso
Gestione dispositivi Un utente autorizzato cerca di accedere da un dispositivo non autorizzato Accesso bloccato
Modifica password per gli utenti a rischio Un utente autorizzato tenta di accedere con credenziali compromesse (accesso a rischio elevato) All'utente viene richiesto di cambiare la password o l'accesso viene bloccato in base al criterio

Distribuire nell'ambiente di produzione

Dopo aver verificato l'impatto usando la modalità solo report, un amministratore può spostare l'interruttore Abilita criterio 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 applicata 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 il prima 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 correlazione (questo ID è 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.

Screenshot di un messaggio di errore di esempio e altri dettagli.

Dopo aver raccolto le informazioni, vedere le risorse seguenti:

  • 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.