Questo articolo descrive un'architettura di accesso condizionale conforme ai principi Zero Trust. L'architettura usa un approccio basato su persona per formare un framework di accesso condizionale strutturato.
Architettura Zero Trust per l'accesso condizionale
È innanzitutto necessario scegliere un'architettura. È consigliabile prendere in considerazione un'architettura di accesso condizionale Di destinazione o Zero Trust. La figura seguente illustra le impostazioni corrispondenti:
L'architettura dell'accesso condizionale Zero Trust è l'architettura che meglio aderisce ai principi di Zero Trust. Se si seleziona l'opzione Tutte le app cloud in un criterio di accesso condizionale, tutti gli endpoint sono protetti dai controlli di concessione forniti, ad esempio l'utente noto e il dispositivo conforme o noto. I criteri non si applicano solo agli endpoint e alle app che supportano l'accesso condizionale, ma si applicano a qualsiasi endpoint con cui l'utente interagisce.
Un esempio è un endpoint del flusso di accesso del dispositivo usato in vari nuovi strumenti di PowerShell e Microsoft Graph. Il flusso di accesso del dispositivo consente di consentire l'accesso da un dispositivo in cui non è possibile visualizzare una schermata di accesso, ad esempio un dispositivo IoT.
Un comando di accesso basato su dispositivo viene eseguito nel dispositivo specificato e viene visualizzato un codice all'utente. Questo codice viene usato in un altro dispositivo. L'utente passa a https://aka.ms/devicelogin e specifica il nome utente e la password. Dopo l'accesso dall'altro dispositivo, l'accesso ha esito positivo nel dispositivo IoT nel contesto utente.
Il limite di questo tipo di accesso è che non supporta l'accesso condizionale basato su dispositivo. Ciò significa che nessuno può usare gli strumenti e i comandi se si applicano criteri di base che richiedono un utente noto e un dispositivo noto per tutte le app cloud. Esistono altre applicazioni che presentano lo stesso problema con l'accesso condizionale basato su dispositivo.
L'altra architettura, quella di destinazione , è basata sul principio che si rivolge solo alle singole app da proteggere nei criteri di accesso condizionale. In questo caso, l'accesso al dispositivo per gli endpoint precedentemente coperti da tutte le app cloud, ad esempio le chiamate a gragrafi a Microsoft Entra ID, non è protetto dai criteri di accesso condizionale, quindi continuano a funzionare.
Quando si usa device-login come esempio per distinguere le due architetture, è possibile eseguire l'autenticazione con device-login. L'accesso al dispositivo può essere potenzialmente consentito per una o poche singole applicazioni, dato che ogni applicazione è destinata e può quindi essere esclusa in un criterio di accesso condizionale che richiede l'accesso basato su dispositivo.
La sfida con l'architettura di destinazione è che si potrebbe dimenticare di proteggere tutte le app cloud. Anche in questo caso, è possibile scegliere tutte le applicazioni selezionabili nei criteri di accesso condizionale. Si lascia l'accesso alle applicazioni che non possono essere selezionate senza protezione. Gli esempi includono l'accesso al portale di Office, al portale di Azure EA (Contratto Enterprise) e al portale delle informazioni di sicurezza, che sono tutti portali molto sensibili.
Un'altra considerazione è che il numero di app di Office 365 e Microsoft Entra aumenta nel tempo, man mano che Microsoft e i partner rilasciano nuove funzionalità e man mano che gli amministratori IT integrano varie applicazioni con Microsoft Entra ID. L'accesso a tutte queste applicazioni è protetto solo se si dispone di un meccanismo che rileva una nuova app che supporta l'accesso condizionale e che applica automaticamente un criterio. La creazione e la gestione di uno script di questo tipo potrebbero essere difficili.
Inoltre, il numero massimo supportato di app per qualsiasi criterio di accesso condizionale è di circa 250. È possibile aggiungere fino a 600 app prima di ricevere un errore relativo al superamento del payload, ma tale numero non è supportato.
Personas di accesso condizionale
Esistono molti modi per strutturare i criteri di accesso condizionale. Un approccio consiste nel definire i criteri in base alla riservatezza della risorsa a cui si accede. In pratica, questo approccio può essere difficile da implementare in un modo che continui a garantire la protezione dell'accesso alle risorse per vari utenti.
Ad esempio, è possibile definire criteri di accesso condizionale che richiedono un utente noto e un dispositivo noto per l'accesso a una risorsa sensibile a cui è necessario accedere sia da utenti guest che da dipendenti. Quando gli utenti guest tentano di accedere da un dispositivo gestito, la richiesta di accesso non funzionerà. È necessario modificare i criteri di accesso condizionale per soddisfare entrambi i requisiti, che in genere comportano un criterio che soddisfi i requisiti meno sicuri.
Un altro approccio consiste nel cercare di definire i criteri di accesso in base alla posizione in cui un utente si trova nell'organizzazione. Questo approccio potrebbe comportare la creazione di numerosi criteri di accesso condizionale e potrebbe non essere gestibile.
Un approccio migliore è quello di definire i criteri correlati alle esigenze di accesso comuni e raggruppare un set di esigenze di accesso in un utente tipo per un gruppo di utenti che hanno le stesse esigenze. Gli utenti tipo sono tipi di identità che condividono attributi aziendali comuni, responsabilità, esperienze, obiettivi e accesso.
Conoscere il modo in cui i vari utenti tipo accedono agli asset e alle risorse aziendali è fondamentale per sviluppare una strategia di Zero Trust completa.
Di seguito sono riportati alcuni utenti consigliati per l'accesso condizionale di Microsoft:
Microsoft consiglia anche di definire un utente tipo separato per le identità che non fanno parte di alcun altro gruppo di utenti tipo. Questo utente è definito utente tipo Global. L'utente tipo Global consente di applicare criteri per le identità che non appartengono a un gruppo di utenti tipo e criteri che devono essere applicati per tutti gli utenti tipo.
Le sezioni seguenti descrivono alcuni utenti consigliati.
Global
Global è un segnaposto/persona per i criteri di natura generale. Viene usato per definire i criteri che si applicano a tutti gli utenti tipo o che non si applicano a un utente tipo specifico. Usare questo utente tipo per i criteri che non sono coperti da altri utenti tipo. Questo utente tipo consente di proteggere tutti gli scenari pertinenti.
Si supponga, ad esempio, di voler usare un criterio per bloccare l'autenticazione legacy per tutti gli utenti. È possibile renderlo un criterio globale invece di usare un gruppo di criteri legacy che potrebbero essere diversi per vari utenti.
Un altro esempio: si vuole bloccare un determinato account o utente da applicazioni specifiche e l'utente o l'account non fa parte di nessuno degli utenti. Ad esempio, se si crea un'identità cloud nel tenant di Microsoft Entra, questa identità non fa parte di nessun altro utente perché non viene assegnato alcun ruolo di Microsoft Entra. È comunque possibile impedire all'identità di accedere ai servizi di Office 365.
Potrebbe essere necessario bloccare tutti gli accessi dalle identità che non sono coperte da alcun gruppo di utenti. In alternativa, è sufficiente applicare l'autenticazione a più fattori.
Amministrazione
In questo contesto, un amministratore è qualsiasi identità non guest, cloud o sincronizzata, con qualsiasi ID Microsoft Entra o altro ruolo di amministratore di Microsoft 365 (ad esempio, in app di Microsoft Defender per il cloud, Exchange, Defender per endpoint o Compliance Manager). Poiché gli utenti guest che hanno questi ruoli sono coperti da un utente tipo diverso, gli utenti guest sono esclusi da questo utente tipo.
Alcune aziende hanno account separati per i ruoli di amministratore sensibili su cui si basa questo utente. In modo ottimale, gli amministratori usano questi account sensibili da una workstation paw (Privileged Access Workstation). Tuttavia, spesso si nota che gli account amministratore vengono usati nelle workstation standard, in cui l'utente passa da un account all'altro su un dispositivo.
È possibile distinguere in base alla riservatezza dei ruoli di amministratore cloud e assegnare ruoli di Azure meno sensibili all'utente interno anziché usare account separati. È quindi possibile usare l'elevazione JIT (Just-In-Time). In questo caso, un utente è destinato a due set di criteri di accesso condizionale, uno per ogni persona. Se si usano workstation PAW, è anche possibile introdurre criteri che usano i filtri dei dispositivi nell'accesso condizionale per limitare l'accesso in modo che gli amministratori siano consentiti solo nelle workstation PAW.
Sviluppatori
L'utente sviluppatore contiene utenti che hanno esigenze specifiche. Si basano su account Active Directory sincronizzati con Microsoft Entra ID, ma hanno bisogno di un accesso speciale ai servizi come Azure DevOps, pipeline CI/CD, flusso del codice del dispositivo e GitHub. L'utente degli sviluppatori può includere utenti considerati interni e altri considerati esterni, ma una persona deve trovarsi solo in uno degli utenti.
Meccanismi interni
Internals contiene tutti gli utenti che dispongono di un account Active Directory sincronizzato con Microsoft Entra ID, dipendenti dell'azienda e che lavorano in un ruolo utente finale standard. Si consiglia di aggiungere gli utenti interni che sono sviluppatori all'utente tipo Developers.
Esterni
Questa persona contiene tutti i consulenti esterni che dispongono di un account Active Directory sincronizzato con Microsoft Entra ID. Si consiglia di aggiungere gli utenti esterni che sono sviluppatori all'utente tipo Developers.
Guests
Gli utenti guest contengono tutti gli utenti che dispongono di un account guest Microsoft Entra che è stato invitato al tenant del cliente.
Guest Amministrazione s
L'utente Guest Amministrazione s contiene tutti gli utenti che dispongono di un account guest Microsoft Entra a cui è assegnato uno dei ruoli di amministratore indicati in precedenza.
Microsoft365ServiceAccounts
Questo utente utente contiene account di servizio basati su cloud (Microsoft Entra ID) usati per accedere ai servizi di Microsoft 365 quando nessun'altra soluzione soddisfa le esigenze, ad esempio l'uso di un'identità del servizio gestito.
AzureServiceAccounts
Questo utente utente contiene account di servizio basati su cloud (Microsoft Entra ID) usati per accedere ai servizi di Azure (IaaS/PaaS) quando nessun'altra soluzione soddisfa la necessità, ad esempio l'uso di un'identità del servizio gestita.
CorpServiceAccounts
Questa persona contiene account del servizio basati sull'utente che hanno tutte queste caratteristiche:
- Sono stati creati in Active Directory locale.
- Vengono usati dall'ambiente locale o da una macchina virtuale basata su IaaS in un altro data center (cloud), ad esempio Azure.
- Vengono sincronizzati con un'istanza di Microsoft Entra che accede a qualsiasi servizio di Azure o Microsoft 365.
Questo scenario deve essere evitato.
Identificatori del carico di lavoro
Questa persona contiene identità del computer, ad esempio le entità servizio e le identità gestite di Microsoft Entra. L'accesso condizionale supporta ora la protezione dell'accesso alle risorse da questi account, con alcune limitazioni relative alle condizioni e ai controlli di concessione disponibili.
Schede modello di accesso
È consigliabile usare le schede modello di accesso per definire le caratteristiche per ogni persona. Ecco un esempio:
La scheda modello per ogni utente tipo fornisce l'input per creare i criteri di accesso condizionale specifici per ogni utente tipo.
Linee guida per l'accesso condizionale
Esaminare un framework di accesso condizionale che include un approccio strutturato per il raggruppamento dei criteri in base agli utenti creati.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Claus Jespersen | ID consulente principale&sec
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Percorso di apprendimento: Implementare e gestire identità e accesso
- Informazioni sull'accesso condizionale
- Criteri comuni di accesso condizionale