Share via

Preparare la zona di destinazione per la migrazione

  • Articolo

Questo articolo descrive come preparare la zona di destinazione di Azure per una migrazione. Vengono inoltre elencate le attività principali da eseguire per assicurarsi che le configurazioni siano disponibili per il progetto di migrazione.

Indipendentemente dall'implementazione di riferimento della zona di destinazione di Azure usata, è necessario eseguire alcune attività per preparare la zona di destinazione per un progetto di migrazione riuscito.

Se non è stata usata un'implementazione di riferimento alla zona di destinazione di Azure, è comunque necessario eseguire i passaggi descritti in questo articolo. Tuttavia, potrebbero essere presenti attività preliminari da eseguire per prime oppure potrebbe essere necessario adattare raccomandazioni specifiche alla progettazione.

Questo articolo descrive le attività che è necessario eseguire per la zona di destinazione di Azure esistente dopo la distribuzione. Alcune attività sono incentrate sulle distribuzioni automatizzate. Si noti se un'attività non è rilevante per gli ambienti distribuiti e gestiti manualmente.

Stabilire la connettività ibrida

Durante la distribuzione di una zona di destinazione di Azure, è possibile distribuire una sottoscrizione di Connessione ivity con una rete virtuale hub e gateway di rete, ad esempio gateway VPN di Azure, gateway Azure ExpressRoute o entrambi. Dopo la distribuzione della zona di destinazione di Azure, è comunque necessario configurare la connettività ibrida da questi gateway per connettersi alle appliance data center esistenti o al circuito ExpressRoute.

Nella fase di preparazione è stata pianificata la connettività ad Azure. Usare questo piano per determinare le connessioni da incorporare. Ad esempio, se si usa ExpressRoute, è necessario collaborare con il provider per stabilire il circuito ExpressRoute.

Per ottenere indicazioni tecniche per scenari specifici, vedere:

Nota

Per altre indicazioni, vedere anche la documentazione specifica del provider.

Se si stabilisce la connettività ibrida ad Azure tramite un'appliance virtuale di rete di terze parti distribuita nella rete virtuale, esaminare le linee guida specifiche e le linee guida generali per le appliance virtuali a disponibilità elevata.

Preparare l'identità

Durante la distribuzione della zona di destinazione di Azure, è necessario distribuire anche un'architettura di supporto per la piattaforma di gestione delle identità. È possibile avere una sottoscrizione di identità dedicata o gruppi di risorse e una rete virtuale o subnet per le macchine virtuali (VM) usate per l'identità. Tuttavia, è necessario distribuire le risorse di identità dopo la distribuzione della zona di destinazione di Azure.

Le sezioni seguenti forniscono indicazioni relative ad Active Directory. Se si usa un provider di identità diverso per l'autenticazione e le autorizzazioni, è necessario seguire le indicazioni relative all'estensione dell'identità ad Azure.

Prima di implementare queste linee guida, esaminare le decisioni relative ad Active Directory e identità ibrida prese durante la pianificazione della zona di destinazione.

È anche necessario esaminare la baseline di identità dalla fase di governance per determinare se è necessario apportare modifiche in Microsoft Entra ID.

Estendere i controller di dominio di Active Directory

Nella maggior parte degli scenari di migrazione, i carichi di lavoro di cui si esegue la migrazione ad Azure sono già aggiunti a un dominio di Active Directory esistente. Microsoft Entra ID offre soluzioni per modernizzare la gestione delle identità, anche per i carichi di lavoro delle macchine virtuali, ma può interrompere la migrazione. La riprogettazione dell'utilizzo delle identità per i carichi di lavoro viene spesso eseguita durante iniziative di modernizzazione o innovazione.

Di conseguenza, è necessario distribuire controller di dominio in Azure all'interno dell'area di rete delle identità distribuita. Dopo aver distribuito le macchine virtuali, è necessario seguire il normale processo di promozione del controller di dominio per aggiungerle al dominio. Questo processo può includere la creazione di siti aggiuntivi per supportare la topologia di replica.

Per un modello di architettura comune per distribuire queste risorse, vedere Distribuire Dominio di Active Directory Services (AD DS) in una rete virtuale di Azure.

Se si implementa l'architettura su scala aziendale per piccole aziende, i server di Active Directory Domain Services si trovano spesso in una subnet nell'hub. Se si implementa l'architettura hub-spoke su scala aziendale o l'architettura di rete WAN virtuale su scala aziendale, i server si trovano spesso nella rete virtuale dedicata.

Microsoft Entra Connect

Molte organizzazioni hanno già Microsoft Entra Connessione per popolare i servizi di Microsoft 365, ad esempio Exchange Online. Se l'organizzazione non dispone di Microsoft Entra Connessione, potrebbe essere necessario installarla e distribuirla dopo la distribuzione della zona di destinazione in modo da poter replicare le identità.

Abilitare IL DNS ibrido

La maggior parte delle organizzazioni deve essere in grado di risolvere le richieste DNS (Domain Name System) per gli spazi dei nomi che fanno parte degli ambienti esistenti. Questi spazi dei nomi richiedono spesso l'integrazione con i server Active Directory. Le risorse nell'ambiente esistente devono essere in grado di risolvere le risorse in Azure.

Per abilitare queste funzioni, è necessario configurare i servizi DNS per supportare i flussi comuni. È possibile usare le zone di destinazione di Azure per distribuire molte delle risorse necessarie. Per altre attività da esaminare e preparare, vedere Risoluzione DNS in Azure.

Risoluzione DNS personalizzata

Se si usa Active Directory per il resolver DNS o se si distribuisce una soluzione di terze parti, è necessario distribuire le macchine virtuali. È possibile usare queste macchine virtuali come server DNS se i controller di dominio vengono distribuiti nella sottoscrizione di identità e nell'spoke di rete. In caso contrario, è necessario distribuire e configurare le macchine virtuali per ospitare questi servizi.

Dopo aver distribuito le macchine virtuali, è necessario integrarle nella piattaforma DNS esistente in modo che possano eseguire ricerche negli spazi dei nomi esistenti. Per i server DNS di Active Directory, questa integrazione è automatica.

È anche possibile usare il sistema di risoluzione privato DNS di Azure, ma questo servizio non viene distribuito come parte della distribuzione della zona di destinazione di Azure.

Se la progettazione usa zone DNS private, pianificare di conseguenza. Ad esempio, se si usano zone DNS private con endpoint privati, vedere Specificare i server DNS. DNS privato zone vengono distribuite come parte della zona di destinazione. Se si usano anche endpoint privati per eseguire attività di modernizzazione, è necessario disporre di una configurazione aggiuntiva per tali endpoint.

Firewall di Azure proxy DNS

È possibile configurare Firewall di Azure come proxy DNS. Firewall di Azure può ricevere traffico e inoltrarlo a un resolver di Azure o ai server DNS. Questa configurazione può consentire l'esecuzione delle ricerche dall'ambiente locale ad Azure, ma non può essere inoltrata in modo condizionale ai server DNS locali.

Se è necessaria la risoluzione DNS ibrida, è possibile configurare il proxy DNS Firewall di Azure per inoltrare il traffico ai server DNS personalizzati, ad esempio i controller di dominio.

Questo passaggio è facoltativo, ma presenta diversi vantaggi. Riduce le modifiche di configurazione in un secondo momento se si modificano i servizi DNS e si abilitano le regole del nome di dominio completo (FQDN) in Firewall di Azure.

Configurare server DNS di rete virtuale personalizzati

Dopo aver completato le attività precedenti, è possibile configurare i server DNS per le reti virtuali di Azure nei server personalizzati usati.

Per altre informazioni, vedere Firewall di Azure impostazioni DNS.

Configurare il firewall dell'hub

Se è stato distribuito un firewall nella rete hub, è necessario tenere presenti alcune considerazioni per poter eseguire la migrazione dei carichi di lavoro. Se queste considerazioni non vengono affrontate nelle prime fasi della distribuzione, è possibile che si verifichino problemi di routing e accesso alla rete.

Nell'ambito dell'esecuzione di queste attività, esaminare l'area di progettazione della rete, in particolare le linee guida per la sicurezza di rete.

Se si distribuisce un'appliance virtuale di rete di terze parti come firewall, esaminare le indicazioni del fornitore e le linee guida generali per le appliance virtuali di rete a disponibilità elevata.

Distribuire set di regole standard

Se si usa un firewall di Azure, tutto il traffico del firewall viene bloccato fino a quando non si aggiungono regole di autorizzazione esplicite. Molti altri firewall dell'appliance virtuale di rete funzionano in modo analogo. Il traffico viene negato fino a quando non si definiscono regole che specificano il traffico consentito.

È consigliabile aggiungere singole regole e raccolte di regole in base alle esigenze del carico di lavoro. È tuttavia consigliabile pianificare anche regole standard, ad esempio l'accesso ad Active Directory o ad altre soluzioni di gestione e identità, che si applicano a tutti i carichi di lavoro abilitati.

Definizione dei percorsi di trasferimento

Azure offre il routing per gli scenari seguenti senza alcuna configurazione aggiuntiva:

  • Routing tra risorse nella stessa rete virtuale
  • Routing tra le risorse nelle reti virtuali con peering
  • Routing tra le risorse e un gateway di rete virtuale, nella propria rete virtuale o in una rete virtuale con peering configurata per l'uso del gateway

Due scenari di routing comuni richiedono una configurazione aggiuntiva. Entrambi gli scenari includono tabelle di route assegnate alle subnet per il routing delle forme. Per altre informazioni sul routing di Azure e sulle route personalizzate, vedere Routing del traffico di rete virtuale.

Routing tra spoke

Per l'area di progettazione di rete, molte organizzazioni usano una topologia di rete hub-spoke.

Sono necessarie route che trasferiscino il traffico da uno spoke a un altro. Per motivi di efficienza e semplicità, usare la route predefinita (0.0.0.0/0) per il firewall. Con questa route sul posto, il traffico verso qualsiasi posizione sconosciuta passa al firewall, che controlla il traffico e applica le regole del firewall.

Se si vuole consentire l'uscita internet, è anche possibile assegnare un'altra route per lo spazio IP privato al firewall, ad esempio 10.0.0.0/8. Questa configurazione non esegue l'override di route più specifiche. Ma è possibile usarlo come percorso semplice in modo che il traffico inter-spoke possa instradarsi correttamente.

Per altre informazioni sulla rete spoke-to-spoke, vedere Modelli e topologie per la comunicazione tra spoke.

Routing dalla subnet del gateway

Se si usano reti virtuali per l'hub, è necessario pianificare come gestire l'ispezione del traffico proveniente dai gateway.

Se si intende controllare il traffico, sono necessarie due configurazioni:

  • Nella sottoscrizione Connessione ivity è necessario creare una tabella di route e collegarla alla subnet del gateway. La subnet del gateway richiede una route per ogni rete spoke che si intende collegare, con un hop successivo dell'indirizzo IP del firewall.

  • In ogni sottoscrizione della zona di destinazione è necessario creare una tabella di route e collegarla a ogni subnet. Disabilitare la propagazione BGP (Border Gateway Protocol) nelle tabelle di route.

Per altre informazioni sulle route personalizzate e definite da Azure, vedere Routing del traffico di rete virtuale di Azure.

Se si intende controllare il traffico verso endpoint privati, abilitare i criteri di rete di routing appropriati nella subnet in cui sono ospitati gli endpoint privati. Per altre informazioni, vedere Gestire i criteri di rete per gli endpoint privati.

Se non si intende controllare il traffico, non sono necessarie modifiche. Tuttavia, se si aggiungono tabelle di route alle subnet di rete spoke, abilitare la propagazione BGP in modo che il traffico possa instradarsi al gateway.

Configurare il monitoraggio e la gestione

Nell'ambito della distribuzione della zona di destinazione, è stato effettuato il provisioning dei criteri che registrano le risorse nei log di Monitoraggio di Azure. È tuttavia necessario creare avvisi anche per le risorse della zona di destinazione.

Per implementare gli avvisi, è possibile distribuire la baseline di Monitoraggio di Azure per le zone di destinazione. Usare questa distribuzione per ottenere avvisi basati su scenari comuni per la gestione della zona di destinazione, ad esempio le risorse di connettività e l'integrità dei servizi.

È anche possibile distribuire avvisi personalizzati per le risorse se le esigenze si discostono da ciò che si trova nella baseline.

Preparare la zona di destinazione per le migrazioni del carico di lavoro sovrano

Se è necessario soddisfare i requisiti di sovranità, è possibile valutare se Microsoft Cloud for Sovranità soddisfa i requisiti. Microsoft Cloud for Sovereignty offre un livello aggiuntivo di funzionalità di controllo e criteri che rispondono alle esigenze dei singoli settori pubblici e dei clienti pubblici.

È possibile abilitare queste funzionalità distribuendo la zona di destinazione sovrana. L'architettura della zona di destinazione sovrana è allineata alle progettazioni consigliate della zona di destinazione di Azure.

Portfolio dei criteri di Microsoft Cloud for Sovranità

Usando Criteri di Azure, è possibile abilitare il controllo centralizzato tra le risorse di Azure per applicare configurazioni specifiche. È possibile assegnare le iniziative dei criteri di Microsoft Cloud for Sovranità alle zone di destinazione per assicurarsi di rispettare i criteri locali e i requisiti normativi nel paese o nell'area geografica.

Se tali iniziative di criteri non sono ancora assegnate alla distribuzione della zona di destinazione sovrana, valutare la possibilità di assegnare le iniziative che corrispondono ai requisiti normativi.

Abilitare vendita di abbonamenti

Questa sezione si applica alle organizzazioni che vogliono automatizzare il processo di provisioning delle sottoscrizioni. Se si gestiscono manualmente la zona di destinazione e la creazione di sottoscrizioni, è necessario stabilire un processo personalizzato per la creazione di sottoscrizioni.

Quando si inizia la migrazione, è necessario creare sottoscrizioni per i carichi di lavoro. Abilitare vendita di abbonamenti per automatizzare e accelerare questo processo. Quando viene stabilita vendita di abbonamenti, dovrebbe essere possibile creare rapidamente sottoscrizioni.

Prepararsi per Microsoft Defender per il cloud

Quando si distribuisce la zona di destinazione, si impostano anche i criteri per abilitare Defender per il cloud per le sottoscrizioni di Azure. Defender per il cloud fornisce raccomandazioni sul comportamento di sicurezza nel punteggio di sicurezza, che valuta le risorse distribuite rispetto alla baseline di sicurezza Microsoft.

Non è necessario implementare configurazioni tecniche aggiuntive, ma è consigliabile esaminare le raccomandazioni e progettare un piano per migliorare il comportamento di sicurezza durante la migrazione delle risorse. Quando si inizia la migrazione delle risorse in Azure, è necessario essere pronti per implementare miglioramenti della sicurezza come parte dell'ottimizzazione della migrazione.

Prendere in considerazione queste risorse aggiuntive per prepararsi alla migrazione:

Passaggi successivi

Preparare gli strumenti e un backlog di migrazione iniziale