Configurazione zero trust per le organizzazioni di difesa multi-tenant
Questo articolo illustra le organizzazioni multi-tenant come applicare le configurazioni in Microsoft Entra ID e soddisfare i requisiti comuni di difesa zero trust. Seguire queste raccomandazioni per stabilire l'architettura di identità multi-tenant corretta e implementare zero trust nell'ambiente in uso.
Figura 1: Architettura di difesa multi-tenant di esempio con configurazioni senza attendibilità.
Determinare l'architettura delle identità
I tenant di Microsoft Entra sono la base dell'architettura di identità. Un tenant è un limite di identità in Microsoft Entra ID. Un'organizzazione con un tenant Microsoft Entra ha un'architettura a tenant singolo. Le organizzazioni che usano più tenant di Microsoft Entra hanno un'architettura multi-tenant.
Vantaggi di un singolo tenant. Un singolo tenant è più facile da gestire e ridurre i costi grazie all'efficienza operativa. Consente di configurare più facilmente un ambiente senza attendibilità. Un singolo tenant evita di frammentare l'esperienza utente con più credenziali di accesso. Consente anche di evitare soluzioni silo che è necessario integrare in un secondo momento. È consigliabile cercare di avere i dati, Microsoft 365 e i servizi cloud di Azure in un singolo tenant. Se si dispone già di più tenant di Microsoft Entra, è consigliabile consolidare l'ambiente per usare un singolo tenant. È possibile consolidare i tenant trasferendo le sottoscrizioni di Azure dai tenant secondari al tenant primario. Per altre informazioni, vedere Trasferire una sottoscrizione di Azure a un'altra directory di Microsoft Entra.
Casi d'uso multi-tenant. Esistono motivi per cui un'organizzazione di difesa usa un'architettura multi-tenant. Le organizzazioni di difesa di grandi dimensioni e complesse potrebbero richiedere più tenant di Microsoft Entra per la sicurezza, la conformità e la collaborazione (vedere la tabella 1).
Tabella 1. Motivi per cui avere o creare più tenant.
| Motivo | Esempio |
|---|---|
| La privacy o la sicurezza richiede una separazione più approfondita dei dati | Un ufficio di controllo generale deve avere l'indipendenza. |
| Delega e segmentazione dell'amministrazione | Un'organizzazione non ha la possibilità di gestire un'altra organizzazione. |
| Sovranità e/o proprietà dei dati | Un'organizzazione non ha l'autorità legale per gestire i dati di un'altra organizzazione. |
| Rete e organizzazione IT | Non è possibile né favorevole comprimere più architetture IT aziendali aziendali di grandi dimensioni in un'unica architettura aziendale. |
| SOC Monitoring and Incident Response | SOC necessita di un tenant separato per gestire i ruoli e le responsabilità. |
Se sono necessari più tenant di Microsoft Entra, è consigliabile usare Microsoft Entra per ID esterno (B2B) e Azure Lighthouse. Queste funzionalità consentono di supportare ambienti di difesa multi-tenant. Per altre informazioni, vedere Modelli tenancy per una soluzione multi-tenant.
Identificare i tipi di tenant
Le organizzazioni di difesa multi-tenant possono classificare le istanze di Microsoft Entra usate come primario o secondario. Ogni organizzazione deve identificare e designare un tenant come tenant primario. Tutti gli altri tenant sono secondari. La figura 1 mostra un'organizzazione di difesa con un tenant primario e n tenant secondari (due tenant secondari visualizzati).
Identificare il tenant primario. La maggior parte delle organizzazioni di difesa crea il tenant primario quando si iscrive a Microsoft 365. Il tenant primario contiene (1) tutte le identità utente e le licenze di Microsoft 365, (2) dispositivi e (3) applicazioni (vedere la figura 1). Le organizzazioni di difesa usano spesso Microsoft Entra Connect per sincronizzare le identità da Active Directory locale al tenant principale di Microsoft Entra.
Alcune organizzazioni di difesa usano Microsoft 365 in un tenant condiviso di proprietà e gestite da un'agenzia esterna. Questa agenzia funge da provider di servizi condivisi per Microsoft 365. L'organizzazione potrebbe non gestire o controllare il tenant condiviso, ma contiene le identità di Microsoft Entra concesse in licenza agli utenti che probabilmente usano per Office 365 e altre applicazioni. In questo scenario, il tenant del provider di servizi condivisi è il tenant primario.
Identificare tutti i tenant secondari (se multi-tenant). Tutti gli altri tenant gestiti dall'organizzazione sono tenant secondari. Se è stata eseguita la migrazione di applicazioni nel cloud, potrebbero essere presenti tenant secondari prima di restare in piedi in una zona di destinazione di Azure su scala aziendale. In genere si usano tenant secondari per gestire (4) carichi di lavoro di Azure con utenti esterni (guest B2B) o (5) account solo cloud (vedere la figura 1).
Usare l'albero delle decisioni. Il modo più semplice per trovare il tenant primario consiste nel considerare le licenze di identità disponibili in Microsoft Entra ID.
Il tenant con le licenze di Microsoft 365 è il tenant primario (vedere la figura 2). Il tenant primario potrebbe non essere il primo tenant creato dall'organizzazione, ma deve essere il tenant principale con tutti gli utenti e le licenze di Microsoft 365.
Se l'organizzazione non usa Microsoft 365, qualsiasi tenant di Microsoft Entra con licenze Enterprise Mobility and Security (EMS) è il tenant primario. Questo tenant è il percorso in cui è stato aggiunto e verificato il nome di dominio dell'organizzazione. Il tenant usa spesso l'identità ibrida o si integra con un sistema di risorse umane (HR) (vedere la figura 2).
Figura 2. Albero delle decisioni per determinare il tenant primario e il tenant secondario di Microsoft Entra.
Per stabilire l'ID Microsoft Entra come piattaforma zero trust, è necessario un tenant popolato con le identità utente e concesso in licenza per i criteri di accesso basati su utenti e dispositivi. Le licenze di Microsoft 365 raggruppano queste funzionalità senza attendibilità con Office 365.Microsoft 365 licensing bundles these zero trust capabilities with Office 365. Se non si usa Microsoft 365, prendere in considerazione Enterprise Mobility + Security E5 per stabilire un provider di identità basato sul cloud per un'attendibilità zero. Per altre informazioni, vedere Scelta dell'autorità di identità.
Configurare zero trust
Quando si gestiscono le identità in Microsoft Entra ID, è consigliabile prendere in considerazione i consigli seguenti per ogni tipo di tenant. Sono disponibili raccomandazioni generali per tutti i tipi di tenant da adottare per primi. Dopo aver implementato tali raccomandazioni generali, trovare le raccomandazioni per il tipo di tenant specifico (primario o secondario) e quindi applicare tali raccomandazioni.
Per altre informazioni sulla protezione dei tenant di Microsoft Entra con zero attendibilità, vedere Piano di modernizzazione rapida Zero Trust e Piano di modernizzazione rapida della sicurezza.
Tutti i tenant
È consigliabile implementare le raccomandazioni seguenti in tutti i tenant di Microsoft Entra.
Stabilire account e procedure di accesso di emergenza. Creare due o più account di accesso di emergenza per evitare di essere bloccati dal tenant di Microsoft Entra. È necessario assegnare il ruolo di amministratore globale a questi account. Gli account devono essere account solo cloud. Gli account solo cloud usano il dominio *.onmicrosoft.com . Per altre informazioni, vedere Gestire gli account amministratore di accesso di emergenza.
Importante
Microsoft consiglia di usare i ruoli con le autorizzazioni più poche. Ciò consente di migliorare la sicurezza per l'organizzazione. L'amministratore globale è un ruolo con privilegi elevati che deve essere limitato agli scenari di emergenza quando non è possibile usare un ruolo esistente.
Proteggere l'ID Entra di Microsoft da attacchi locali. Seguire le procedure consigliate descritte in Protezione dell'accesso con privilegi. Assegnare solo le autorizzazioni di Microsoft Entra agli account utente solo cloud con credenziali resistenti al phishing, ad esempio l'autenticazione passkey hardware o basata su certificati. Non usare le identità federate per scopi amministrativi. Per altre informazioni, vedere Proteggere Microsoft 365 da attacchi locali.
Usare Privileged Identity Management. Usare Microsoft Entra Privileged Identity Management (PIM) per gestire le assegnazioni di ruolo per i ruoli Microsoft Entra ID e Azure. È anche consigliabile usare PIM per gestire l'appartenenza ai gruppi di sicurezza con privilegi. Stabilire verifiche di accesso periodiche per amministratori idonei e utenti esterni (guest B2B).
Abilitare l'autenticazione basata sul cloud per tutti gli utenti. I metodi di autenticazione basati sul cloud sono più sicuri dell'autenticazione federata. Offrono un'esperienza migliore per l'accesso Single Sign-On in combinazione con i dispositivi aggiunti a Microsoft Entra. L'autenticazione federata espone l'ID Microsoft Entra a Active Directory locale compromessi.
L'autenticazione basata su certificati Microsoft Entra (CBA) rende superfluo la federazione dei domini Microsoft Entra. L'autenticazione di Microsoft Entra supporta i metodi di autenticazione senza password seguenti:
- Passkeys (chiavi di sicurezza FIDO2)
- Autenticazione basata sui certificati
- Autenticatore Microsoft
- Windows Hello for Business (Configurare Windows Hello for Business)
Stabilire criteri di accesso condizionale di base. La baseline di accesso condizionale varia in base all'organizzazione e ai requisiti. Stabilire un set di base di criteri di accesso condizionale per tutti i tenant di Microsoft Entra. Usare le condizioni di identità, dispositivo, applicazione e rischio all'interno del set di criteri. Escludere gli account di accesso di emergenza dai criteri di accesso condizionale.
Microsoft Entra ID Protection consente alle organizzazioni di rilevare, analizzare e correggere i rischi basati sull'identità. Per proteggere gli accessi a rischio e gli utenti, creare criteri di accesso condizionale con condizioni di rischio. Usare criteri separati per gli utenti rischiosi e gli accessi a rischio. Aumentare i controlli applicati con livello di rischio per ogni tipo di rischio. Per bilanciare la produttività degli utenti con la sicurezza, evitare di usare il controllo Blocca nei criteri basati sui rischi.
Nota
Gli utenti possono correggere automaticamente i rischi di accesso con MFA. Per consentire agli utenti di correggere automaticamente i rischi di accesso, configurare il controllo delle concessioni MFA o authentication Strength in un criterio di accesso condizionale basato sul rischio di accesso.
Gli utenti possono correggere autonomamente i rischi degli utenti modificando le password. Per consentire agli utenti di correggere automaticamente i rischi utente, configurare un criterio di accesso condizionale basato sul rischio utente con Richiedi controllo di concessione delle modifiche delle password .
Attenzione
Gli utenti senza password che accedono solo con metodi senza password, ad esempio l'autenticazione basata su certificati Entra, la passkey o Windows Hello for Business, potrebbero essere bloccati dal controllo Richiedi concessione della modifica della password se non riescono a reimpostare la password in Microsoft Entra ID.
Progettare criteri di accesso condizionale per l'organizzazione usando l'elenco di controllo dei criteri di accesso condizionale di esempio (vedere la tabella 2). Usare la modalità solo report per testare i criteri di accesso condizionale prima della distribuzione nell'ambiente di produzione.
Tabella 2: Esempio di elenco di controllo dei criteri di accesso condizionale.
| Nome del criterio | Utenti | Applicazioni | Condizioni | Concedere il controllo |
|---|---|---|---|---|
| MFA per tutti gli utenti | Tutti gli utenti | Tutte le app | None | - MFA resistente al phishing |
| Richiedere un dispositivo gestito | Tutti gli utenti | Tutte le app | None | - Richiedi dispositivo aggiunto o conforme a Microsoft Entra ibrido |
| Proteggere gli accessi a rischio medio | Tutti gli utenti | Tutte le app | Rischio di accesso medio | - MFA resistente al phishing - Richiedere un dispositivo conforme - Frequenza di accesso: 1 ora (modificare in base alla tolleranza ai rischi dell'organizzazione) |
| Proteggere gli accessi ad alto rischio | Tutti gli utenti | Tutte le app | Rischio elevato di accesso | - MFA resistente al phishing - Richiedere un dispositivo conforme - Frequenza di accesso: ogni volta |
| Proteggere gli utenti ad alto rischio | Tutti gli utenti | Tutte le app | Rischio utente elevato | - MFA resistente al phishing - Richiedere un dispositivo conforme - Frequenza di accesso: ogni volta |
| Proteggere l'amministrazione di Microsoft Entra | Ruoli di Microsoft Entra | Tutte le app | None | - MFA resistente al phishing - Richiedi workstation con accesso con privilegi (PAW) conforme usando i filtri dei dispositivi |
| Proteggere la gestione del cloud | Tutti gli utenti | Gestione di Azure Google Cloud Platform Amazon Web Services |
None | - MFA resistente al phishing - Richiedi workstation con accesso con privilegi (PAW) conforme usando i filtri dei dispositivi |
Il set di criteri di esempio nella tabella 2 è destinato alle organizzazioni senza password in cui tutti gli utenti usano solo MFA resistenti al phishing dai dispositivi gestiti. Gli utenti con privilegi usano workstation paw (Privileged Access Workstation) gestite da Intune. Anziché richiedere una modifica della password per gli utenti ad alto rischio, i criteri utente rischiosi applicano i controlli di livello di autenticazione e frequenza di accesso. Questi controlli offrono alcune protezioni, ma non correggere il livello di rischio dell'utente in Microsoft Entra ID Protection. Il team addetto alle operazioni di sicurezza deve analizzare e correggere gli utenti ad alto rischio.
Per altre informazioni sulla distribuzione dell'accesso condizionale, vedere Pianificare una distribuzione dell'accesso condizionale.
Usare le identità del tenant primario per accedere a tutte le applicazioni. Gli utenti devono essere in grado di accedere alle applicazioni usando la propria identità nel tenant primario. È necessario registrare le applicazioni nel tenant primario. Stabilire un criterio per registrare le applicazioni con il tenant primario, indipendentemente dalla posizione di hosting dell'infrastruttura dell'applicazione.
Per le applicazioni legacy che non supportano protocolli di autenticazione moderni, usare il servizio proxy dell'applicazione Microsoft Entra nel tenant primario. Il proxy dell'applicazione Microsoft Entra porta le funzionalità di Microsoft Entra zero trust alle applicazioni legacy esistenti senza modifiche al codice.
Quando un provider di servizi condivisi o un'agenzia esterna controlla il tenant primario, deve delegare le autorizzazioni di registrazione dell'applicazione. Se il provider di servizi non offre questa delega, è necessario registrare le applicazioni con il tenant secondario che l'organizzazione controlla. Tuttavia, gli utenti devono comunque accedere a queste applicazioni senza creare una nuova identità nel tenant secondario. Per questa configurazione, assegnare l'accesso utente usando identità esterne (guest B2B) per gli utenti nel tenant primario. Per altre informazioni, vedere Proteggere le applicazioni con attendibilità zero.
Usare Microsoft Entra ID per gestire altri ambienti cloud. Microsoft Entra ID non è solo una piattaforma di identità per Azure e Microsoft 365. Usare Microsoft Entra ID per ottenere l'accesso ad altri ambienti cloud. Questi ambienti includono prodotti saaS (Software-as-a-Service) diffusi e piattaforme cloud come Amazon Web Services (AWS) e Google Cloud Platform (GCP). Per altre informazioni, vedere la raccolta di applicazioni Microsoft Entra.
Usare un'architettura SCCA (Secure Cloud Computing Architecture). Ogni organizzazione di difesa deve distribuire un'architettura della zona di destinazione conforme a SCCA. La zona di destinazione deve trovarsi nelle sottoscrizioni di Azure collegate al tenant primario.
Segmentare la gestione delle risorse di Azure in un singolo tenant. È consigliabile usare i ruoli di Azure per l'isolamento delle risorse e della gestione per le sottoscrizioni all'interno di una zona di destinazione di Azure su scala aziendale. Valutare la possibilità di trasferire le sottoscrizioni dai tenant secondari al tenant primario.
Usare Gestione delle autorizzazioni di Microsoft Entra. Gestione delle autorizzazioni di Microsoft Entra è la soluzione CIEM (Cloud Infrastructure Entitlement Management) di Microsoft. È consigliabile usare Gestione delle autorizzazioni di Microsoft Entra per ottenere visibilità sulle autorizzazioni assegnate a tutte le identità. È anche consigliabile usarlo per tenere traccia delle autorizzazioni in modo che si trovino nell'ambiente multicloud dell'organizzazione.
Usare Microsoft Entra ID Governance. Usare Microsoft Entra ID Governance per automatizzare il ciclo di vita delle assegnazioni di accesso per utenti e guest. Eseguire verifiche di accesso per rimuovere l'accesso all'ambiente cloud per gli utenti che non ne hanno più bisogno.
Proteggere le identità del carico di lavoro. Usare ID dei carichi di lavoro di Microsoft Entra funzionalità per gestire e applicare criteri di attendibilità zero adattiva per le identità dell'applicazione (entità servizio) in Microsoft Entra ID.
Abilitare Defender per il cloud per l'azienda. Usare Defender per il cloud per l'ambiente multicloud. Assicurarsi di attivare le funzionalità di sicurezza avanzate per monitorare le risorse di Azure e correggere i rischi di configurazione. Defender per il cloud protezione si estende oltre Azure per proteggere gli ambienti ibridi e multicloud.
Distribuire Sentinel e connettere tutte le origini dati disponibili. Aggregare i segnali di sicurezza in un sistema SIEM come Microsoft Sentinel. Distribuire Sentinel e connettere tutte le origini dati dei segnali di sicurezza configurando i connettori dati.
Tenant primari
È consigliabile implementare le raccomandazioni seguenti solo nel tenant primario.
Gli utenti finali hanno una sola identità in Entra ID. Sincronizzare Active Directory locale Domain Services con il tenant principale di Microsoft Entra. La sincronizzazione popola l'ID Di Microsoft Entra con utenti, gruppi e dispositivi per l'organizzazione. Gli utenti guest B2B esterni potrebbero esistere nei tenant secondari, ma gli utenti devono ricordare solo un nome utente per tutte le applicazioni e i servizi. L'esperienza utente e i risultati zero trust sono ottimali quando si usano le identità nel tenant primario per l'accesso a Windows e l'accesso alle applicazioni.
Aggiungere e gestire i dispositivi con il tenant primario. Il tenant principale di Microsoft Entra contiene tutti gli utenti e i dispositivi all'interno dell'organizzazione. Microsoft Entra join (o Microsoft Entra hybrid join) dispositivi Windows al tenant primario e gestire con Microsoft Intune. Usare i criteri di Intune per distribuire Microsoft Defender per endpoint abilitare la funzionalità XDR (Extended Detection and Response).
Delegare le autorizzazioni di registrazione dell'applicazione. Le app aziendali, incluso il codice dell'applicazione in esecuzione in qualsiasi sottoscrizione di Azure, usano il tenant principale dell'ID Microsoft Entra per l'identità utente. Rendere gli sviluppatori idonei per il ruolo Microsoft Entra per sviluppatori di applicazioni o un ruolo di registrazione dell'app personalizzato usando Privileged Identity Management. Questa configurazione consente agli sviluppatori di compilare applicazioni nei tenant secondari di registrarle con il tenant primario per l'identità.
Collegare servizi PaaS (Platform-as-a-Service) che necessitano dell'identità dell'utente finale. Alcuni servizi PaaS, ad esempio File di Azure e Desktop virtuale Azure, dipendono dalla configurazione ibrida delle identità o dai diritti delle licenze. È necessario distribuire questi servizi nelle sottoscrizioni di Azure nel tenant primario.
Tenant secondari
È consigliabile implementare le raccomandazioni seguenti nel tenant secondario.
Acquistare le licenze necessarie per la gestione di Microsoft Entra. Sono necessarie licenze per attivare le funzionalità di sicurezza avanzate nei tenant secondari. Prendere in considerazione le licenze necessarie per utenti, carichi di lavoro e dispositivi.
Identità utente. È necessario avere licenze Microsoft Entra ID Premium P2 per gli amministratori tenant e gli account di accesso di emergenza. Se si usa un modello di gestione di identità esterna (guest B2B), è necessario assegnare almeno una licenza Microsoft Entra ID Premium P2 a un utente locale nel tenant. Questa configurazione consente di abilitare funzionalità Premium come l'accesso condizionale e Identity Protection. Per altre informazioni, vedere Considerazioni comuni per la gestione degli utenti multi-tenant.
Identità dei carichi di lavoro. È consigliabile usare le identità del carico di lavoro Premium per proteggere le identità del carico di lavoro con accesso alle risorse nel tenant primario, ad esempio l'API Microsoft Graph.
Gestione di dispositivi. Potrebbe essere necessario gestire i dispositivi con Microsoft Intune nel tenant secondario. In tal caso, è necessario acquistare licenze Enterprise Mobility and Security (EMS).
Configurare i criteri di accesso tra tenant (XTAP). Microsoft Entra per ID esterno (Microsoft Entra B2B Collaboration) le impostazioni di accesso tra tenant consentono a un tenant secondario di considerare attendibili determinate attestazioni dal tenant primario home. Aggiungere il tenant principale di Microsoft Entra come organizzazione e aggiornare le impostazioni di trust in ingresso per includere:
- Considerare attendibile l'autenticazione a più fattori (MFA) dai tenant di Microsoft Entra
- Considerare attendibili i dispositivi conformi
- Considerare attendibili i dispositivi aggiunti a Microsoft Entra ibrido
- Facoltativo: riscattare automaticamente gli inviti con il tenant
Gestire il tenant secondario con identità dal tenant primario. Ridurre il sovraccarico amministrativo e i costi usando utenti esterni (guest B2B) dal tenant primario per gestire il tenant secondario e le risorse di Azure. Assegnare ruoli Microsoft Entra seguendo il ruolo Con privilegi minimi di Microsoft Entra per attività tramite Microsoft Entra Privileged Identity Management. Usare l'accesso avviato dall'utente finale o la sincronizzazione tra tenant per ridurre il sovraccarico di gestione dell'onboarding di identità esterne nel tenant secondario.
Usare Azure Lighthouse per facilitare l'accesso di Sentinel dal tenant primario. Azure Lighthouse offre un altro modo per gestire Azure tra tenant. Azure Lighthouse usa modelli di Azure Resource Manager (ARM) per assegnare ruoli di Azure alle identità in un tenant esterno. Questo approccio non usa oggetti utente guest B2B. Quando un amministratore accede al portale per gestire Azure, visualizza tutte le risorse in tutti i tenant. Questa vista consolidata include sottoscrizioni con autorizzazioni assegnate da Azure Lighthouse. Poiché non è presente alcun oggetto guest B2B, l'amministratore non deve cambiare directory. Usare Azure Lighthouse per facilitare la gestione di Microsoft Sentinel tra i tenant.