Condividi tramite

Framework e criteri di accesso condizionale

  • Articolo

Questo articolo fornisce un framework per l'implementazione di un'architettura di accesso condizionale basata su persona, come quella descritta in Architettura Dell'accesso condizionale Zero Trust. In questo articolo sono disponibili informazioni dettagliate su come formare e assegnare un nome ai criteri di accesso condizionale. C'è anche un punto di partenza per la creazione di criteri.

Se non si usa un framework come quello fornito qui, inclusi uno standard di denominazione, i criteri tendono a essere creati nel tempo da persone diverse in modo ad hoc. Ciò può comportare la sovrapposizione dei criteri. Se la persona che ha creato un criterio non è più disponibile, può essere difficile per gli altri conoscere lo scopo del criterio.

Se si segue un framework strutturato, è più semplice comprendere i criteri. Semplifica anche la copertura di tutti gli scenari ed evitare criteri in conflitto difficili da risolvere.

Convenzioni di denominazione

Una convenzione di denominazione definita correttamente consente all'utente e ai colleghi di comprendere lo scopo di un criterio, semplificando la gestione e la risoluzione dei problemi dei criteri. La convenzione di denominazione deve essere adatta al framework usato per definire i criteri.

I criteri di denominazione consigliati si basano su utenti, tipi di criteri e app. Avrà l'aspetto seguente:

<CANumber-Persona-PolicyType-App-Platform-GrantControl-OptionalDescription><><><><><><>

I componenti di questo nome sono descritti qui:

Componente di denominazione Descrizione/Esempio
CA Number Usato per identificare rapidamente l'ambito e l'ordine dei tipi di criteri. Esempio: CA001-CA099.
Utente Global, Amministrazione s, Internals, Externals, GuestUsers, Guest Amministrazione s, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts.
Tipo di criteri BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance.
App AllApps, O365 (per tutti i servizi di Office 365), EXO (per Exchange Online).
Piattaforma AnyPlatform, Unknown, Windows Telefono, macOS, iOS, Android.
Concedi controllo Block, ADHJ, Compliant, Unmanaged (dove non gestito è specificato nella condizione dello stato del dispositivo).
Descrizione Descrizione facoltativa dello scopo del criterio.

Schema di numerazione

Per semplificare l'amministrazione, è consigliabile usare questo schema di numerazione:

Gruppo persona Allocazione dei numeri
CA-Persona-Global CA001-CA099
CA-Persona-Amministrazione s CA100-CA199
CA-Persona-Internals CA200-CA299
CA-Persona-Externals CA300-CA399
CA-Persona-GuestUsers CA400-CA499
CA-Persona-Guest Amministrazione s CA500-CA599
CA-Persona-M365ServiceAccounts CA600-CA699
CA-Persona-AzureServiceAccounts CA700-CA799
CA-Persona-CorpServiceAccounts CA800-CA899
CA-Persona-WorkloadIdentities CA900-CA999
CA-Persona-Developers CA1000-CA1099

Tipo di criteri

Questi sono i tipi di criteri consigliati:

Tipo di criterio Descrizione/Esempi
BaseProtection Per ogni persona è disponibile una protezione di base coperta da questo tipo di criteri. Per gli utenti nei dispositivi gestiti, questo è in genere un utente noto e un dispositivo noto. Per gli utenti guest esterni, potrebbe essere nota l'autenticazione a più fattori e utente.

La protezione di base è il criterio predefinito per tutte le app per gli utenti nell'utente specifico. Se un'app specifica deve avere criteri diversi, escludere l'app dai criteri di protezione di base e aggiungere un criterio esplicito destinato solo a tale app.

Esempio: si supponga che la protezione di base per Internals richieda un utente noto e un dispositivo noto per tutte le app cloud, ma si vuole consentire Outlook sul web da qualsiasi dispositivo. È possibile escludere Exchange Online dai criteri di protezione di base e aggiungere un criterio separato per Exchange Online, in cui è necessaria l'autenticazione a più fattori o il dispositivo noto.
IdentityProtection Oltre alla protezione di base per ogni utente, è possibile avere criteri di accesso condizionale correlati all'identità.

Esempi: bloccare l'autenticazione legacy, richiedere l'autenticazione a più fattori aggiuntiva per un utente o un rischio di accesso elevato, richiedere un dispositivo noto per la registrazione dell'autenticazione a più fattori.
DataProtection Questo tipo di criterio indica criteri differenziali che proteggono i dati come livello aggiuntivo oltre la protezione di base.

Esempi:
  • Protezione di app criteri per iOS e Android che è possibile usare per crittografare i dati in un telefono e che offrono una migliore protezione dei dati. I criteri di Protezione di app includono anche la protezione delle app.
  • Criteri di sessione in cui Azure Information Protection consente di proteggere i dati durante il download se i dati sono sensibili.
AppProtection Questo tipo di criterio è un'altra aggiunta alla protezione di base.

Esempi:
  • Si supponga di voler consentire l'accesso Web a Exchange Online da qualsiasi dispositivo. È possibile escludere Exchange dai criteri di base e creare un nuovo criterio esplicito per l'accesso a Exchange, dove, ad esempio, si consente solo l'accesso in sola lettura a Exchange Online.
  • Si supponga di richiedere l'autenticazione a più fattori per la registrazione di Microsoft Endpoint Manager. È possibile escludere la registrazione di Intune Endpoint Manager dai criteri di base e aggiungere criteri di protezione delle app che richiedono l'autenticazione a più fattori per la registrazione di Endpoint Manager.
AttackSurfaceReduction Lo scopo di questo tipo di criteri è attenuare vari attacchi.

Esempi:
  • Se un tentativo di accesso proviene da una piattaforma sconosciuta, potrebbe trattarsi di un tentativo di ignorare i criteri di accesso condizionale in cui è necessaria una piattaforma specifica. È possibile bloccare le richieste da piattaforme sconosciute per attenuare questo rischio.
  • Bloccare l'accesso ai servizi di Office 365 per Azure Amministrazione istrators o bloccare l'accesso a un'app per tutti gli utenti se l'app è nota come non valida.
Conformità È possibile usare un criterio di conformità per richiedere a un utente di visualizzare le condizioni per l'utilizzo per gli utenti guest che accedono ai servizi clienti.

App

La tabella seguente descrive il componente App di un nome di criterio:

Nome dell'app Descrizione/Esempi
AllApps AllApps indica che tutte le app cloud sono destinate ai criteri di accesso condizionale. Tutti gli endpoint sono trattati, inclusi quelli che supportano l'accesso condizionale e quelli che non lo supportano. In alcuni scenari, la destinazione di tutte le app non funziona correttamente. È consigliabile impostare come destinazione tutte le app nei criteri di base in modo che tutti gli endpoint siano coperti da tale criterio. Anche le nuove app visualizzate in Microsoft Entra ID saranno conformi automaticamente ai criteri.
<AppName> <AppName> è un segnaposto per il nome di un'app a cui si rivolge il criterio. Evitare di rendere il nome troppo lungo.

Nomi di esempio:
  • EXO per Exchange Online
  • SPO per SharePoint Online

Tipo di piattaforma

La tabella seguente descrive il componente Platform di un nome di criterio:

Tipo di piattaforma Descrizione
AnyPlatform Il criterio è destinato a qualsiasi piattaforma. In genere, è possibile configurare questa opzione selezionando Qualsiasi dispositivo. Nei criteri di accesso condizionale vengono usati sia la parola platform che il dispositivo word.
iOS Il criterio è destinato alle piattaforme Apple iOS.
Android Il criterio è destinato alle piattaforme Google Android.
Finestre Questo criterio è destinato alla piattaforma Windows.
Linux Questo criterio è destinato alle piattaforme Linux.
Windows Telefono Il criterio è destinato alle piattaforme Windows Telefono.
macOS Il criterio è destinato alle piattaforme macOS
iOSAndroid Il criterio è destinato sia alle piattaforme iOS che Android.
Sconosciuto Il criterio è destinato a qualsiasi piattaforma non elencata in precedenza. Questa operazione viene in genere configurata includendo qualsiasi dispositivo ed escludendo tutte le singole piattaforme.

Concedere tipi di controllo

Nella tabella seguente viene descritto il componente Grant Control di un nome di criterio:

Tipo di concessione Descrizione/Esempi
Blocca Il criterio blocca l'accesso
MFA Il criterio richiede l'autenticazione a più fattori.
Conforme Il criterio richiede un dispositivo conforme, come determinato da Endpoint Manager, quindi il dispositivo deve essere gestito da Endpoint Manager.
CompliantorAADHJ Il criterio richiede un dispositivo conforme o un dispositivo aggiunto a Microsoft Entra ibrido. Un computer aziendale standard aggiunto a un dominio è anche aggiunto a Microsoft Entra ID ibrido. I telefoni cellulari e i computer Windows 10 co-gestiti o aggiunti a Microsoft Entra possono essere conformi.
ConformeandAADHJ Il criterio richiede un dispositivo conforme e aggiunto ibrido a Microsoft Entra.
MFAorCompliant Il criterio richiede un dispositivo conforme o l'autenticazione a più fattori, se non è conforme.
MFAandCompliant Il criterio richiede un dispositivo conforme e l'autenticazione a più fattori.
MFAorAADHJ Il criterio richiede un computer ibrido Microsoft Entra o l'autenticazione a più fattori se non è un computer aggiunto ibrido a Microsoft Entra.
MFAandAADHJ Il criterio richiede un computer aggiunto ibrido a Microsoft Entra e l'autenticazione a più fattori.
RequireApprovedClient Il criterio richiede l'app client approvata.
AppProtection Il criterio richiede la protezione delle app
Non gestita Il criterio è destinato ai dispositivi non noti da Microsoft Entra ID. Ad esempio, è possibile usare questo tipo di concessione per consentire l'accesso a Exchange Online da qualsiasi dispositivo.

Posizioni specifiche

È consigliabile definire questi percorsi standard da usare nei criteri di accesso condizionale:

  • Indirizzi IP attendibili/reti interne. Queste subnet IP rappresentano posizioni e reti con restrizioni di accesso fisico o altri controlli sul posto, ad esempio la gestione del sistema informatico, l'autenticazione a livello di rete o il rilevamento delle intrusioni. Queste posizioni sono più sicure, quindi l'applicazione dell'accesso condizionale può essere rilassata. Valutare se Azure o altre località dei data center devono essere incluse in questa posizione o avere località denominate specifiche.
  • Indirizzi IP attendibili citrix. Se Si dispone di Citrix in locale, potrebbe essere utile configurare indirizzi IPv4 in uscita separati per le farm Citrix, se è necessario essere in grado di connettersi ai servizi cloud dalle sessioni Citrix. In tal caso, è possibile escludere tali posizioni dai criteri di accesso condizionale, se necessario.
  • Località di Zscaler, se applicabile. I computer hanno un agente ZPA installato e inoltra tutto il traffico verso Internet verso o attraverso il cloud Zscaler. Vale quindi la pena definire gli INDIRIZZI IP di origine Zscaler nell'accesso condizionale e richiedere a tutte le richieste provenienti da dispositivi non mobili di passare attraverso Zscaler.
  • Paesi/aree geografiche con cui consentire l'azienda. Può essere utile dividere paesi/aree geografiche in due gruppi di località: uno che rappresenta le aree del mondo in cui i dipendenti lavorano in genere e uno che rappresenta altre posizioni. In questo modo è possibile applicare controlli aggiuntivi alle richieste provenienti dall'esterno delle aree in cui l'organizzazione opera normalmente.
  • Le posizioni in cui l'autenticazione a più fattori potrebbe essere difficile o impossibile. In alcuni scenari, la richiesta dell'autenticazione a più fattori potrebbe rendere difficile per i dipendenti svolgere il proprio lavoro. Ad esempio, il personale potrebbe non avere il tempo o l'opportunità di rispondere a frequenti problemi di autenticazione a più fattori. Oppure, in alcune posizioni, lo screening RF o l'interferenza elettrica possono rendere difficile l'uso dei dispositivi mobili. In genere, si usano altri controlli in queste posizioni o potrebbero essere attendibili.

I controlli di accesso in base alla posizione si basano sull'INDIRIZZO IP di origine di una richiesta per determinare la posizione dell'utente al momento della richiesta. Non è facile eseguire lo spoofing sulla rete Internet pubblica, ma la protezione offerta dai limiti di rete potrebbe essere considerata meno rilevante di una volta. Non è consigliabile basarsi esclusivamente sulla posizione come condizione per l'accesso. Tuttavia, per alcuni scenari può essere il controllo migliore che è possibile usare, ad esempio se si protegge l'accesso da un account del servizio locale usato in uno scenario non interattivo.

È stato creato un foglio di calcolo che contiene i criteri di accesso condizionale consigliati. È possibile scaricare il foglio di calcolo qui.

Usare i criteri suggeriti come punto di partenza.

I criteri cambieranno probabilmente nel tempo per soddisfare i casi d'uso importanti per l'azienda. Ecco alcuni esempi di scenari che potrebbero richiedere modifiche:

  • Implementare l'accesso in sola lettura a Exchange Online per i dipendenti usando qualsiasi dispositivo non gestito basato sull'autenticazione a più fattori, sulla protezione delle app e su un'app client approvata.
  • Implementare la protezione delle informazioni per assicurarsi che le informazioni riservate non vengano scaricate senza una protezione migliorata fornita da Azure Information Protection.
  • Fornire protezione dalla copia e incolla da parte degli utenti guest.

Più anteprime sono attualmente in fase di anteprima pubblica, quindi si prevede che gli aggiornamenti al set suggerito di criteri di avvio dell'accesso condizionale (CA) siano presto disponibili.

Linee guida per l'accesso condizionale

Ora che si dispone di un set iniziale di criteri di accesso condizionale, è necessario distribuirli in modo controllato e in più fasi. È consigliabile usare un modello di distribuzione.

Ecco un approccio:

Diagram that shows a Conditional Access deployment model.

L'idea è prima di tutto distribuire i criteri a un numero ridotto di utenti all'interno di un gruppo di utenti. È possibile usare un gruppo Microsoft Entra associato denominato Persona Ring 0 per questa distribuzione. Dopo aver verificato che tutto funzioni, si cambia l'assegnazione in un gruppo, Persona Ring 1, che ha più membri e così via.

Si abilitano quindi i criteri usando lo stesso approccio basato su anello fino a quando non vengono distribuiti tutti i criteri.

In genere si gestiscono manualmente i membri dell'anello 0 e dell'anello 1. Un anello 2 o 3 gruppo che contiene centinaia o persino migliaia di utenti può essere gestito tramite un gruppo dinamico basato su una percentuale degli utenti in un determinato utente.

L'uso di anelli come parte di un modello di distribuzione non è solo per la distribuzione iniziale. È anche possibile usarlo quando sono necessari nuovi criteri o modifiche ai criteri esistenti.

Dopo aver completato la distribuzione, è necessario progettare e implementare anche i controlli di monitoraggio illustrati nei principi di accesso condizionale.

Oltre ad automatizzare la distribuzione iniziale, è possibile automatizzare le modifiche ai criteri usando le pipeline CI/CD. È possibile usare Microsoft365DSC per questa automazione.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi