Eseguire la migrazione e modernizzare il percorso di progettazione della rete

Questa guida fornisce un percorso di lettura sequenziato tramite la guida alla progettazione di rete Azure per i clienti che adottano servizi, contenitori e database gestiti della piattaforma distribuita come servizio (PaaS). Seguire i passaggi numerati per creare una rete a più livelli di sicurezza che supporta architetture di applicazioni moderne.

Overview

I progetti di migrazione e modernizzazione vanno oltre le macchine virtuali e adottano servizi nativi di Azure: Servizio Azure Kubernetes (AKS) per i container, Servizio app di Azure per le applicazioni Web, database SQL di Azure e Azure Cosmos DB per i dati gestiti e Frontdoor di Azure per la distribuzione globale del traffico. La rete deve supportare la connettività privata a questi servizi PaaS, distribuzioni attive e rigide segmentazioni di sicurezza tra i livelli applicazione.

L'architettura di destinazione usa una topologia a doppio hub che si estende su due aree Azure. Le reti virtuali dell'hub gestito dall'IT ospitano servizi condivisi come Firewall di Azure e Gateway VPN. I team delle applicazioni possiedono le reti virtuali spoke e controllano le proprie subnet di collegamento privato per la connettività PaaS. Il traffico entra tramite Frontdoor di Azure o Gestione traffico di Azure, passa attraverso l’ispezione del firewall dell’hub e raggiunge i servizi applicativi in esecuzione in spoke isolati.

Questo percorso di lettura illustra 14 articoli essenziali in cinque fasi. Il percorso è più lungo del lift and shift perché le architetture moderne richiedono decisioni sugli schemi di ingresso, sulla connettività privata PaaS, sui firewall per applicazioni web e sulla protezione DDoS che le architetture basate esclusivamente su IaaS possono rinviare. Due checkpoint principali ti aiutano a capire quando puoi passare alla fase successiva se il tuo carico di lavoro non richiede tutti i componenti.

Prerequisiti

  • Per informazioni sull'orientamento sui servizi disponibili, vedere la panoramica della progettazione e del piano di rete Azure.
  • Informati su quali servizi PaaS usano come destinazione le tue applicazioni (AKS, App Service, Azure SQL, Azure Cosmos DB o altri).
  • Determinare se la distribuzione si estende su più aree Azure (attivo-attivo o attivo-passivo).
  • Identificare il modello di ingresso: l'applicazione gestisce il traffico Web pubblico, il traffico dell'API mobile o il traffico solo interno?

Percorso di lettura

Fase 1: Fondamenti

1. Reti virtuali e subnet

Dimensionare le subnet per i pool di nodi di AKS, le subnet delegate dell'ambiente di servizio app di Azure e le subnet di collegamento privato. Quando si usa AKS Container Networking Interface (CNI) Overlay, gli indirizzi IP dei pod provengono da un CIDR Overlay separato e non consumano spazio nella subnet della rete virtuale. Solo gli indirizzi IP del nodo richiedono indirizzi subnet. Pianificare l'intervallo CIDR della rete overlay in modo da supportare la scalabilità dei pod e allocare subnet dedicate per ciascun tipo di servizio.

2. Pianificazione degli indirizzi IP

Pianificare l'allocazione IP tra due aree per una distribuzione attiva-attiva. Le regioni primaria e di backup devono disporre di spazi di indirizzi non sovrapposti che supportino il peering di reti virtuali e la replica tra aree geografiche. Allocare intervalli abbastanza ampi da ospitare future aggiunte di spoke.

3. Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni

Progettare una segmentazione rigorosa in modo che solo il traffico del servizio di bilanciamento del carico raggiunga le subnet dell'applicazione. Bloccare l'accesso diretto a Internet ai livelli dell'applicazione. Usare i gruppi di sicurezza delle applicazioni per applicare regole in base al ruolo del carico di lavoro anziché ai singoli indirizzi IP.

Fase 2: Topologia

4. Topologia hub-and-spoke

Distribuire una topologia a doppio hub per più aree. La sottoscrizione IT è proprietaria delle reti virtuali dell'hub e gestisce servizi condivisi, ad esempio Firewall di Azure, Gateway VPN e server d'inoltro DNS. I team applicativi sono responsabili delle proprie VNet spoke e gestiscono le subnet di collegamento privato, i cluster AKS e le risorse applicative all'interno dello spazio di indirizzamento loro assegnato.

5. Rete multiregionale

Progettare una distribuzione attiva-attiva tra aree primarie e di backup. Configurare il peering VNet interregionale tra hub, impostare il routing di failover e prevedere il guasto di una singola area. Entrambe le regioni gestiscono il traffico contemporaneamente, mentre Frontdoor di Azure distribuisce le richieste in base alla latenza e alle sonde di integrità.

Note

Traguardo: Topologia completata. È disponibile la topologia a doppio hub e multi-area. Se l'applicazione è solo interna senza endpoint con connessione Internet, è possibile passare al passaggio 9 (accesso a Internet in uscita) e continuare da questa posizione.

Cosa si ignora: I passaggi da 6 a 8 riguardano l'ingresso Internet, il recapito e le prestazioni delle applicazioni e l'accesso privato PaaS. Saltare è possibile se il carico di lavoro non ha endpoint pubblici e non richiede un collegamento privato.

Importante: Anche le applicazioni solo interne spesso richiedono collegamento privato (passaggio 8) se si connettono a Azure SQL, Archiviazione di Azure, Azure Key Vault o altri servizi PaaS tramite endpoint privati. Se l'applicazione utilizza uno di questi servizi, completa il passaggio 8 prima di passare al passaggio 9.

Articoli rimanenti: Sei articoli dopo aver saltato (passaggi 9–14), rispetto a nove articoli senza saltare (passaggi 6–14).

Fase 3: Connettività

6. Internet in ingresso

I modelli di traffico rivolti ai clienti determinano la forma esterna dell'architettura. Usare Frontdoor di Azure per applicazioni Web che necessitano di bilanciamento del carico globale, memorizzazione nella cache e Web application firewall (WAF). Usare Gestione traffico di Azure per applicazioni per dispositivi mobili o API in cui è sufficiente il routing basato su DNS con probe di integrità.

7. Recapito e prestazioni delle applicazioni

Scegliere tra Frontdoor di Azure e Gestione traffico di Azure in base al tipo di applicazione. Le applicazioni Web traggono vantaggio dalle funzionalità di frontdoor di livello 7: offload TLS, memorizzazione nella cache, routing basato su URL e WAF integrato. I backend per dispositivi mobili e per API usano Traffic Manager per il failover a livello DNS con overhead ridotto.

8. Accesso privato PaaS

Creare subnet di collegamento privato in ogni rete virtuale spoke per la connettività del servizio PaaS. I team applicativi gestiscono i propri endpoint privati: AKS scarica le immagini dei container tramite collegamento privato, le app Web si connettono ad Azure SQL tramite endpoint privati e nessun traffico PaaS attraversa Internet pubblico. Dedicare una subnet a ogni spoke per le risorse di collegamento privato.

Note

Traguardo: connettività completata. L'ingresso e la connettività PaaS privata sono configurati.

Passaggi rimanenti: Uscita in uscita (passaggio 9), Firewall di Azure (passaggio 10), Web application firewall (passaggio 11), protezione DDoS (passaggio 12), sicurezza DNS (passaggio 13) e monitoraggio della rete (passaggio 14), per 6 articoli totali.

Essenziale per tutte le distribuzioni: I passaggi 9–10 (traffico in uscita e Firewall di Azure) si applicano a tutte le distribuzioni di modernizzazione. Il firewall hub controlla tutto il traffico in uscita e fornisce un'ispezione centralizzata indipendentemente dal fatto che il carico di lavoro sia pubblico o solo interno.

Solo endpoint pubblici: I passaggi 11-12 (protezione WAF e DDoS) si applicano solo se l'applicazione espone endpoint esposti pubblicamente tramite Frontdoor di Azure, Application Gateway o un servizio di bilanciamento del carico pubblico. I carichi di lavoro solo interni possono ignorare questi due articoli e procedere al passaggio 13 (sicurezza DNS).

9. Accesso a Internet in uscita

Instrada tutto il traffico in uscita degli spoke al firewall dell'hub utilizzando route definite dall'utente (UDR). Il firewall hub funge da punto SNAT (Source Network Address Translation) per tutto il traffico in uscita. L'IT gestisce centralmente le regole del firewall, in modo che i team delle applicazioni non possano ignorare i controlli in uscita.

Fase 4: Sicurezza

10. Firewall di Azure

Configurare Firewall di Azure in entrambe le reti virtuali dell'hub come punto di SNAT e di conversione degli indirizzi di rete di destinazione (DNAT). Tutto il traffico in ingresso passa attraverso il firewall prima di raggiungere il livello applicazione. Usa i criteri del firewall per controllare il traffico est-ovest tra gli spoke e il traffico nord-sud verso Internet.

11. Web application firewall

Distribuire WAF in Frontdoor di Azure o gateway applicazione di Azure per le applicazioni Web. WAF protegge dalle minacce della OWASP Top 10, dalla SQL injection, dal cross-site scripting e da altri attacchi a livello di HTTP. Usare i set di regole gestite e aggiungere regole personalizzate per i modelli specifici dell'applicazione.

12. Protezione DDoS

Abilitare Azure protezione DDoS per tutte le risorse IP pubbliche. Protezione DDoS offre il monitoraggio del traffico sempre attivo, la mitigazione automatica degli attacchi e le garanzie di protezione dei costi. Combina la protezione DDoS con un WAF per una difesa a più livelli contro gli attacchi volumetrici e quelli a livello applicativo.

13. Sicurezza DNS e risoluzione dei nomi privati

Configurate zone DNS pubbliche per i domini esposti ai clienti con record CNAME che puntano agli endpoint di Frontdoor di Azure o di Traffic Manager. Applicare Role-Based Controllo di accesso (RBAC) alle zone DNS in modo che solo i team autorizzati possano modificare i record. Abilitare DNS Security Extensions (DNSSEC) per le zone che richiedono la convalida crittografica.

Fase 5: Operazioni

14. Monitoraggio e osservabilità della rete

L'idoneità per la produzione richiede il monitoraggio dal primo giorno. Abilitare Azure Network Watcher per la diagnostica della connettività, Monitor prestazioni di rete per il rilevamento della latenza e i log dei flussi per l'analisi del traffico. I team applicativi monitorano i propri carichi di lavoro AKS e ASE. Il team della piattaforma monitora l'infrastruttura hub e la connettività tra aree.

Articoli condizionali

Includere questi articoli in base ai requisiti specifici:

Condition Articolo Quando includere
Coesistenza ibrida Connettività ibrida Le applicazioni modernizzate devono coesistere con i sistemi locali durante il periodo di transizione
Accesso amministratore alla VM necessario Accesso per sviluppatori e amministratori Il patrimonio include macchine virtuali che necessitano di accesso RDP/SSH sicuro insieme ai carichi di lavoro PaaS
Grande patrimonio governato Gestione centralizzata della rete Gestisci un ambiente VNet con più sottoscrizioni e più team che richiede l'applicazione centralizzata dei criteri
Cross-cloud Connettività tra aree e multicloud L'architettura richiede connettività privata esplicita tra aree oltre a ciò che offre la rete in più aree
Carico di lavoro molto piccolo Topologia di rete flat Si dispone di un singolo carico di lavoro che non giustifica la complessità della topologia hub-spoke

Sommario

Seguendo questo percorso di lettura, è stata progettata un'architettura di rete a più livelli di sicurezza per i carichi di lavoro PaaS. La progettazione include una topologia a doppio hub con servizi condivisi gestiti dall'IT, un'architettura multiregione attiva-attiva con Frontdoor di Azure o Gestione traffico di Azure, con connettività collegamento privato per i servizi PaaS, ispezione centralizzata tramite firewall per tutti i flussi di traffico, protezione WAF e DDoS per gli endpoint pubblici e DNS con RBAC e DNSSEC. Questa architettura supporta i modelli di applicazione moderni mantenendo al contempo la governance centralizzata della sicurezza.

Elenco di controllo di convalida

Usare questo elenco di controllo per verificare che la progettazione della rete di modernizzazione sia stata completata:

  • Topologia a doppio hub distribuita tra aree primarie e di backup.
  • Spazi indirizzi non sovrapposti allocati sia per le aree che per gli spoke futuri.
  • Frontdoor di Azure o Gestione traffico di Azure configurati per l'ingresso globale, se il carico di lavoro è esposto al pubblico.
  • Subnet di collegamento privato di cui è stato effettuato il provisioning in ogni rete virtuale spoke che ospita le dipendenze PaaS.
  • Route definite dall'utente inviano traffico in uscita spoke attraverso il firewall hub.
  • Firewall di Azure distribuito in entrambe le reti virtuali dell'hub per l'ingresso, l'area est-ovest e l'ispezione in uscita.
  • I criteri WAF applicati agli endpoint Web pubblici, se applicabile.
  • Protezione DDoS abilitata nelle risorse IP pubbliche, se applicabile.
  • Zone DNS e risoluzione DNS privata configurate per gli endpoint privati.
  • Network Watcher, log dei flussi e monitoraggio della connettività tra aree abilitati.

Passaggi successivi

  • Last updated on