Identità ibrida con Active Directory e Microsoft Entra ID nelle zone di destinazione di Azure
Questo articolo fornisce indicazioni su come progettare e implementare l'ID Entra Microsoft e l'identità ibrida per le zone di destinazione di Azure.
Le organizzazioni che operano nel cloud richiedono un servizio directory per gestire le identità utente e l'accesso alle risorse. Microsoft Entra ID è un servizio di gestione delle identità e degli accessi basato su cloud che offre un solido set di funzionalità per gestire utenti e gruppi. È possibile usare Microsoft Entra ID come soluzione di gestione delle identità autonoma oppure integrarlo con un'infrastruttura di Servizi di dominio Microsoft Entra o un'infrastruttura di Servizi di dominio di Active Directory locale.
Microsoft Entra ID offre una gestione moderna delle identità e degli accessi sicura per i servizi di Azure e Microsoft 365. È possibile usare Microsoft Entra ID per varie organizzazioni e carichi di lavoro. Ad esempio, le organizzazioni con un'infrastruttura di Active Directory Domain Services locale e i carichi di lavoro basati sul cloud possono usare la sincronizzazione delle directory con Microsoft Entra ID. La sincronizzazione delle directory garantisce che gli ambienti locali e cloud condividono un set coerente di identità, gruppi e ruoli. Le applicazioni che richiedono meccanismi di autenticazione legacy potrebbero richiedere Servizi di dominio per i servizi di dominio gestiti nel cloud e estendere l'infrastruttura di Active Directory Domain Services locale in Azure.
La gestione delle identità basata sul cloud è un processo iterativo. È possibile iniziare con una soluzione nativa del cloud con un piccolo set di utenti e i ruoli corrispondenti per una distribuzione iniziale. Con la maturità della migrazione, potrebbe essere necessario integrare la soluzione di gestione delle identità usando la sincronizzazione della directory o aggiungere servizi di dominio ospitati nel cloud come parte delle distribuzioni cloud.
Modificare la soluzione di gestione delle identità nel tempo a seconda dei requisiti di autenticazione del carico di lavoro e di altre esigenze, ad esempio le modifiche alla strategia di identità dell'organizzazione e ai requisiti di sicurezza o all'integrazione con altri servizi directory. Quando si valutano le soluzioni Active Directory di Windows Server, è possibile comprendere le differenze tra Microsoft Entra ID, Domain Services e Servizi di dominio Active Directory in Windows Server.
Per altre informazioni, vedere Identity Decision Guide.For more information, see Identity decision guide.
Servizi di gestione delle identità e degli accessi nelle zone di destinazione di Azure
Il team della piattaforma è responsabile dell'amministrazione della gestione delle identità e degli accessi. I servizi di gestione delle identità e degli accessi sono fondamentali per la sicurezza dell'organizzazione. L'organizzazione può usare Microsoft Entra ID per controllare l'accesso amministrativo e proteggere le risorse della piattaforma. Questo approccio impedisce agli utenti esterni al team della piattaforma di apportare modifiche alla configurazione o alle entità di sicurezza contenute in Microsoft Entra ID.
Se si usa Servizi di dominio Active Directory o Servizi di dominio, è necessario proteggere i controller di dominio da accessi non autorizzati. I controller di dominio sono altamente vulnerabili agli attacchi e devono avere controlli di sicurezza rigorosi e separazione dai carichi di lavoro dell'applicazione.
Distribuire controller di dominio e componenti associati, ad esempio i server Microsoft Entra Connect, nella sottoscrizione Identity che si trova nel gruppo di gestione della piattaforma. I controller di dominio non vengono delegati ai team dell'applicazione. Questo isolamento consente ai proprietari di applicazioni di usare i servizi di gestione delle identità senza doverli gestire, riducendo così il rischio di compromissione ai servizi di gestione delle identità e degli accessi. Le risorse nella sottoscrizione di Identity Platform sono un punto critico di sicurezza per gli ambienti cloud e locali.
Effettuare il provisioning delle zone di destinazione in modo che i proprietari di applicazioni possano scegliere Microsoft Entra ID o Servizi di dominio Active Directory per soddisfare le esigenze del carico di lavoro. Potrebbe essere necessario configurare altri servizi, a seconda della soluzione di gestione delle identità. Ad esempio, potrebbe essere necessario abilitare e proteggere la connettività di rete alla rete virtuale Identity. Se si usa un processo di distribuzione automatica delle sottoscrizioni, includere queste informazioni di configurazione nella richiesta di sottoscrizione.
Domini di Azure e locali (identità ibrida)
Gli oggetti utente creati interamente in Microsoft Entra ID sono noti come account solo cloud. Gli account solo cloud supportano l'autenticazione moderna e l'accesso alle risorse di Azure e Microsoft 365 e supportano l'accesso per i dispositivi locali che usano Windows 10 o Windows 11.
L'organizzazione potrebbe avere già directory di Active Directory Domain Services di lunga durata integrate con altri sistemi, ad esempio la pianificazione line-of-business o aziendale (ERP) tramite ldap (Lightweight Directory Access Protocol). Questi domini possono avere molti computer e applicazioni aggiunti a un dominio che usano protocolli Kerberos o NTLMv2 precedenti per l'autenticazione. In questi ambienti è possibile sincronizzare gli oggetti utente con Microsoft Entra ID in modo che gli utenti possano accedere sia ai sistemi locali che alle risorse cloud con una singola identità. L'unificazione dei servizi directory locali e cloud è nota come identità ibrida. È possibile estendere i domini locali nelle zone di destinazione di Azure:
Per mantenere un singolo oggetto utente in ambienti cloud e locali, è possibile sincronizzare gli utenti di dominio Active Directory Domain Services con Microsoft Entra ID tramite Microsoft Entra Connect o Microsoft Entra Cloud Sync. Per determinare la configurazione consigliata per l'ambiente, vedere Topologie per Microsoft Entra Connect e Topologie per Microsoft Entra Cloud Sync.
Per aggiungere a un dominio macchine virtuali Windows e ad altri servizi, è possibile distribuire controller di dominio Active Directory Domain Services o Servizi di dominio in Azure. Usare questo approccio in modo che gli utenti di Active Directory Domain Services possano accedere a server Windows, condivisioni file di Azure e altre risorse che usano Active Directory come origine di autenticazione. È anche possibile usare altre tecnologie di Active Directory, ad esempio Criteri di gruppo, come origine di autenticazione. Per altre informazioni, vedere Scenari di distribuzione comuni per Microsoft Entra Domain Services.
Raccomandazioni per l'identità ibrida
Per determinare i requisiti della soluzione di gestione delle identità, documentare il provider di autenticazione usato da ogni applicazione. Usare la guida alle decisioni di identità per selezionare i servizi giusti per l'organizzazione. Per altre informazioni, vedere Confrontare Active Directory con Microsoft Entra ID.
È possibile usare Servizi di dominio per le applicazioni che si basano su servizi di dominio e usano protocolli meno recenti. I domini di Active Directory Domain Services esistenti supportano talvolta la compatibilità con le versioni precedenti e consentono protocolli legacy, che possono influire negativamente sulla sicurezza. Anziché estendere un dominio locale, è consigliabile usare Servizi di dominio per creare un nuovo dominio che non consenta protocolli legacy. Usare il nuovo dominio come servizio directory per le applicazioni ospitate nel cloud.
Fattore di resilienza come requisito di progettazione critico per la strategia di gestione delle identità ibrida in Azure. Microsoft Entra ID è un sistema basato sul cloud con ridondanza globale, ma Servizi di dominio e Servizi di dominio Active Directory non lo sono. Pianificare attentamente la resilienza quando si implementano Servizi di dominio e Servizi di dominio Active Directory. Quando si progetta uno dei due servizi, è consigliabile usare distribuzioni con più aree per garantire un'operazione di servizio continua in caso di evento imprevisto a livello di area.
Per estendere un'istanza di Active Directory Domain Services locale in Azure e ottimizzare la distribuzione, incorporare le aree di Azure nella progettazione del sito di Active Directory. Creare un sito in siti e servizi di Active Directory Domain Services per ogni area di Azure in cui si prevede di distribuire i carichi di lavoro. Creare quindi un nuovo oggetto subnet nei siti e nei servizi di Active Directory Domain Services per ogni intervallo di indirizzi IP che si intende distribuire nell'area. Associare il nuovo oggetto subnet al sito di Active Directory Domain Services creato. Questa configurazione garantisce che il servizio del localizzatore di controller di dominio indirizzi le richieste di autorizzazione e autenticazione ai controller di dominio Active Directory Domain Services più vicini all'interno della stessa area di Azure.
Valutare gli scenari che configurano guest, clienti o partner in modo che possano accedere alle risorse. Determinare se questi scenari coinvolgono Microsoft Entra B2B o Microsoft Entra per ID esterno per i clienti. Per altre informazioni, vedere Microsoft Entra per ID esterno.
Non usare il proxy dell'applicazione Microsoft Entra per l'accesso Intranet perché aggiunge la latenza all'esperienza utente. Per altre informazioni, vedere Microsoft Entra application proxy planning and Microsoft Entra application proxy security considerations .For more information, see Microsoft Entra application proxy planning and Microsoft Entra application proxy security considerations.
Prendere in considerazione vari metodi che è possibile usare per integrare Active Directory locale con Azure per soddisfare i requisiti dell'organizzazione.
Se è disponibile la federazione di Active Directory Federation Services (AD FS) con Microsoft Entra ID, è possibile usare la sincronizzazione dell'hash delle password come backup. AD FS non supporta l'accesso Single Sign-On (SSO) facile di Microsoft Entra.
Determinare lo strumento di sincronizzazione corretto per l'identità cloud.
Se si hanno requisiti per l'uso di AD FS, vedere Distribuire AD FS in Azure.
Se si usa Microsoft Entra Connect come strumento di sincronizzazione, è consigliabile distribuire un server di gestione temporanea in un'area diversa dal server Principale di Microsoft Entra Connect per il ripristino di emergenza. In alternativa, se non si usano più aree, implementare le zone di disponibilità per la disponibilità elevata.
Se si usa Microsoft Entra Cloud Sync come strumento di sincronizzazione, è consigliabile installare almeno tre agenti in server diversi in più aree per il ripristino di emergenza. In alternativa, è possibile installare gli agenti tra server in zone di disponibilità diverse per la disponibilità elevata.
Importante
È consigliabile eseguire la migrazione all'ID Microsoft Entra, a meno che non sia necessario specificamente AD FS. Per altre informazioni, vedere Risorse per rimuovere le autorizzazioni di AD FS e Eseguire la migrazione da AD FS a Microsoft Entra ID.
ID Microsoft Entra, Domain Services e Servizi di dominio Active Directory
Per implementare i servizi directory Microsoft, acquisire familiarità con gli amministratori con le opzioni seguenti:
È possibile distribuire controller di dominio di Active Directory Domain Services in Azure come macchine virtuali Windows che controllano completamente gli amministratori della piattaforma o delle identità. Questo approccio è una soluzione IaaS (Infrastructure as a Service). È possibile aggiungere i controller di dominio a un dominio di Active Directory esistente o ospitare un nuovo dominio con una relazione di trust facoltativa con domini locali esistenti. Per altre informazioni, vedere Architettura di base di Azure Macchine virtuali in una zona di destinazione di Azure.
Domain Services è un servizio gestito da Azure che è possibile usare per creare un nuovo dominio di Active Directory gestito ospitato in Azure. Il dominio può avere una relazione di trust con domini esistenti e può sincronizzare le identità dall'ID Microsoft Entra. Gli amministratori non hanno accesso diretto ai controller di dominio e non sono responsabili dell'applicazione di patch e di altre operazioni di manutenzione.
Quando si distribuiscono Servizi di dominio o si integrano ambienti locali in Azure, usare aree con zone di disponibilità per una maggiore disponibilità quando possibile. Prendere in considerazione anche la distribuzione in più aree di Azure per aumentare la resilienza.
Dopo aver configurato Servizi di dominio Active Directory o Domain Services, è possibile usare lo stesso metodo dei computer locali per aggiungere le macchine virtuali e le condivisioni file di Azure a un dominio. Per altre informazioni, vedere Confrontare i servizi basati su directory Microsoft.
Raccomandazioni su Microsoft Entra ID e Servizi di dominio Active Directory
Usare il proxy dell'applicazione Microsoft Entra per accedere alle applicazioni che usano l'autenticazione locale in modalità remota tramite Microsoft Entra ID. Questa funzionalità fornisce accesso remoto sicuro alle applicazioni Web locali. Il proxy dell'applicazione Microsoft Entra non richiede una VPN o le modifiche apportate all'infrastruttura di rete. Tuttavia, viene distribuita come singola istanza in Microsoft Entra ID, quindi i proprietari delle applicazioni e i team di piattaforma o identità devono collaborare per assicurarsi che l'applicazione sia configurata correttamente.
Valutare la compatibilità dei carichi di lavoro per Servizi di dominio Active Directory in Windows Server e Servizi di dominio. Per altre informazioni, vedere Casi d'uso e scenari comuni.
Distribuire le macchine virtuali del controller di dominio o i set di repliche di Servizi di dominio nella sottoscrizione di Identity Platform all'interno del gruppo di gestione della piattaforma.
Proteggere la rete virtuale che contiene i controller di dominio. Per impedire la connettività Internet diretta da e verso la rete virtuale e il controller di dominio, posizionare i server di Active Directory Domain Services in una subnet isolata con un gruppo di sicurezza di rete.To prevent direct Internet connectivity to and from the virtual network network and domain controller, place the AD DS servers in an isolated subnet with a network security group (NSG). Il gruppo di sicurezza di rete fornisce funzionalità del firewall. Le risorse che usano controller di dominio per l'autenticazione devono avere una route di rete alla subnet del controller di dominio. Abilitare una route di rete solo per le applicazioni che richiedono l'accesso ai servizi nella sottoscrizione identity. Per altre informazioni, vedere Distribuire Active Directory Domain Services in una rete virtuale di Azure.
Usare Azure Rete virtuale Manager per applicare regole standard applicabili alle reti virtuali. Ad esempio, è possibile usare Criteri di Azure o tag delle risorse di rete virtuale per aggiungere reti virtuali della zona di destinazione a un gruppo di rete se richiedono servizi di gestione delle identità di Active Directory. Il gruppo di rete può quindi essere usato che consente l'accesso alla subnet del controller di dominio solo dalle applicazioni che lo richiedono e bloccano l'accesso da altre applicazioni.
Proteggere le autorizzazioni di controllo degli accessi in base al ruolo che si applicano alle macchine virtuali del controller di dominio e ad altre risorse di identità. Gli amministratori con assegnazioni di ruolo controllo degli accessi in base al ruolo nel piano di controllo di Azure, ad esempio Collaboratore, Proprietario o Collaboratore macchina virtuale, possono eseguire comandi nelle macchine virtuali. Assicurarsi che solo gli amministratori autorizzati possano accedere alle macchine virtuali nella sottoscrizione Di identità e che le assegnazioni di ruolo eccessivamente permissive non vengano ereditate dai gruppi di gestione più elevati.
Mantenere le applicazioni principali vicine o nella stessa area della rete virtuale per i set di repliche per ridurre al minimo la latenza. In un'organizzazione multimultidimensionale distribuire Servizi di dominio nell'area che ospita i componenti principali della piattaforma. È possibile distribuire Servizi di dominio solo in una singola sottoscrizione. Per espandere Domain Services in altre aree, è possibile aggiungere fino a quattro set di repliche in reti virtuali separate con peering alla rete virtuale primaria.
Valutare la possibilità di distribuire controller di dominio di Active Directory Domain Services in più aree di Azure e tra zone di disponibilità per aumentare la resilienza e la disponibilità. Per altre informazioni, vedere Creare macchine virtuali nelle zone di disponibilità e Eseguire la migrazione di macchine virtuali alle zone di disponibilità.
Esplorare i metodi di autenticazione per Microsoft Entra ID come parte della pianificazione delle identità. L'autenticazione può verificarsi solo nel cloud e in locale o in locale.
È consigliabile usare l'autenticazione Kerberos per Microsoft Entra ID invece di distribuire controller di dominio nel cloud se un utente di Windows richiede Kerberos per File di Azure condivisioni file.