Ingresso Internet: esporre l'applicazione a Internet

Questo articolo consente di scegliere il servizio di Azure appropriato per rendere l'applicazione raggiungibile da Internet. Confronta indirizzi IP pubblici, Azure Load Balancer, Application Gateway, Frontdoor di Azure e Gestione traffico di Azure. Scegliere l'opzione adatta ai requisiti di sicurezza, scalabilità e protocollo del carico di lavoro.

Informazioni su questo articolo

Ogni carico di lavoro Azure che serve gli utenti esterni necessita di un percorso di ingresso: un modo per consentire al traffico Internet di raggiungere l'applicazione in modo sicuro e affidabile. La scelta del servizio ingress sbagliato porta al sovradimensionamento, a vulnerabilità di sicurezza o a complessità inutile. Questo articolo illustra come valutare sette servizi Azure che accettano connessioni in ingresso da utenti esterni e instradano tali connessioni alle risorse back-end all'interno di una rete virtuale. È possibile selezionare la combinazione che corrisponde al protocollo, alla scalabilità, alla geografia e al comportamento di sicurezza.

Note

Questo articolo è incentrato sul modo in cui il traffico entra nella rete Azure da Internet. Per informazioni su come bilanciare e distribuire il traffico tra i back-end dell'applicazione (inclusi confronti dettagliati di Azure Load Balancer, gateway applicazione e Frontdoor di Azure), vedere Recapito e prestazioni delle applicazioni.

Chi ha bisogno di questo articolo

Leggere questo articolo se si applicano una o più di queste condizioni:

• L'applicazione deve accettare connessioni in ingresso da utenti o sistemi su Internet.
• È necessario scegliere tra Public IP, Load Balancer, Application Gateway, Front Door o Traffic Manager in base al protocollo e all'ambito di utilizzo.
• È necessario progettare un punto di ingresso pubblico sicuro per carichi di lavoro Web, API o TCP/UDP.
• È necessario combinare l'esposizione a Internet con WAF, protezione DDoS, terminazione TLS o distribuzione del traffico globale e regionale.

Tip

Si segue un percorso di scenario? Selezionare lo scenario nella parte superiore della pagina per indicazioni personalizzate. Le linee guida di base seguenti si applicano a tutti i lettori.

Focus su lift-and-shift: l'app migrata deve essere raggiungibile da Internet. Valuta se ti serve Application Gateway, Front Door o una soluzione basata su un semplice IP pubblico. Molti carichi di lavoro lift-and-shift sono solo interni, quindi è possibile ignorare completamente questo articolo se le app migrate non servono utenti esterni.

Leggere questo articolo se:

• Si esegue la migrazione di un'applicazione Web locale a Azure ed è necessario decidere come esporla pubblicamente.
• È necessario valutare se sia davvero richiesto traffico in ingresso da Internet per i carichi di lavoro migrati.
• Si vuole comprendere l'opzione di ingresso più semplice pronta per la produzione per un'applicazione lifted.

Focus sulla modernizzazione: I modelli di traffico rivolti ai clienti determinano la forma esterna dell'architettura. Frontdoor gestisce le app Web, Gestione traffico gestisce le app per dispositivi mobili e per le API. I carichi di lavoro PaaS moderni (Servizio app, servizio Azure Kubernetes) necessitano di un percorso di ingresso ben definito che si integra con il modello di sicurezza hub-spoke.

Leggere questo articolo se:

• Distribuire un'applicazione pubblica a cui gli utenti esterni accedono tramite Internet.
• È necessario scegliere tra Frontdoor di Azure per le applicazioni Web e Gestione traffico per carichi di lavoro per dispositivi mobili o API.
• Vuoi capire come Ingress si integra con il firewall dell'hub in qualità di destinazione DNAT.
• È necessario proteggere gli endpoint esposti a Internet con un Web Application Firewall (WAF) o una protezione DDoS.

Focus sul multi-cloud: includere l'ingresso Internet solo se l'app migrata è pubblica. Molte applicazioni multi-cloud sono esclusivamente interne e comunicano tra cloud attraverso percorsi di transito privati. Se il carico di lavoro è pubblico(ad esempio, un'app Web rivolta al cliente migrata da un altro cloud), è necessario un percorso in ingresso in Azure.

Leggere questo articolo se:

• Si sta eseguendo la migrazione di un'applicazione pubblica da AWS o Google Cloud a Azure.
• È necessario un gateway applicativo con WAF in una rete virtuale spoke per il carico di lavoro migrato.
• Si vuole evitare l'assegnazione diretta di indirizzi IP pubblici alle macchine virtuali durante la migrazione tra cloud.

Azure servizi e funzionalità

Azure offre diversi servizi per l'ingresso internet. Ogni servizio opera a un livello diverso dello stack di rete e serve un caso d'uso diverso.

Service	Livello	Scope	Elementi forniti	Quando usarlo
Indirizzo IP pubblico (SKU Standard)	3	Regionale	Indirizzo IPv4 o IPv6 instradabile assegnato direttamente. Ridondanza della zona per impostazione predefinita.	Scenari semplici e a basso traffico. Non consigliato per la produzione senza un servizio di bilanciamento del carico.
Azure Load Balancer (Standard, public)	4 (TCP/UDP)	Regionale	Distribuisce il traffico TCP/UDP in ingresso tra macchine virtuali back-end. Front-end con ridondanza tra zone. I controlli di integrità rimuovono le istanze non integre.	Carichi di lavoro non HTTP/S che richiedono disponibilità elevata. Server di gioco, endpoint IoT o altri servizi TCP/UDP.
Azure Load Balancer (Standard, interno)	4 (TCP/UDP)	Regionale	Bilanciamento del carico di livello 4 all'interno di una rete virtuale. Nessun indirizzo IP pubblico. Instrada il traffico tra i livelli interni.	App multilivello in cui un front-end pubblico viene distribuito alle macchine virtuali back-end. Traffico hub-spoke est-ovest. Non direttamente con connessione Internet, ma comunemente abbinata a un servizio di ingresso pubblico.
Gateway di applicazioni Azure	7 (HTTP/S)	Regionale	Bilanciamento del carico HTTP/S con routing basato su URL, terminazione SSL/TLS, affinità di sessione e scalabilità automatica.	App HTTP/S a singola area geografica che richiedono instradamento basato sul percorso, affinità basata sui cookie o offload SSL.
Application Gateway + WAF	7 (HTTP/S)	Regionale	Gateway applicazione di Azure con Web application firewall. Protegge dai 10 principali attacchi OWASP tramite il set di regole predefinito (DRS), incluse le regole di Microsoft Threat Intelligence.	App Web pubbliche che richiedono il bilanciamento del carico di livello 7 e la protezione WAF in una singola area.
Frontdoor di Azure	7 (HTTP/S)	Globale	Servizio di bilanciamento del carico HTTP/S globale con rete CDN integrata, WAF e routing del traffico. Termina le connessioni TCP/TLS nei PoP di edge in prossimità degli utenti utilizzando l'accelerazione Split TCP.	App in più aree con una base di utenti globale. Carichi di lavoro che richiedono cache CDN, WAF globale e failover automatico.
Gestione traffico di Azure	DNS	Globale	Routing del traffico basato su DNS. Restituisce un CNAME all'endpoint regionale più vicino o più integro. I client si connettono direttamente. Gestione traffico non vede mai il traffico dell'applicazione.	Failover a livello di DNS in più aree. Protocolli non HTTP/S in cui Frontdoor non è applicabile. Instradamento in base all'area geografica, alle prestazioni o alla priorità.

Note

Gli INDIRIZZI IP pubblici dello SKU Basic vengono ritirati (settembre 2025). Gli indirizzi IP Basic esistenti continuano a essere operativi, ma non sono supportati e non dispongono di alcun SLA. Usare lo SKU Standard per tutte le nuove distribuzioni.

Funzionamento di ogni servizio

Comprendere l'architettura interna di ogni servizio consente di prevedere le prestazioni, risolvere i problemi e pianificare il dimensionamento della subnet.

Indirizzo IP pubblico

Un IP pubblico SKU Standard è una risorsa definita dal software che associa direttamente un indirizzo IPv4 o IPv6 instradabile a un'interfaccia di rete, al front-end di un servizio di bilanciamento del carico o a un gateway. Per impostazione predefinita, l'indirizzo è ridondato tra zone nelle aree supportate, il che significa che la piattaforma gestisce il failover tra le zone di disponibilità senza che sia necessario alcun intervento da parte dell'utente. Gli indirizzi IP pubblici non dispongono di elaborazione del traffico. I pacchetti vengono trasmessi direttamente alla risorsa associata senza controlli di integrità o logica di distribuzione.

Azure Load Balancer (Standard, public)

Load Balancer Standard usa un algoritmo di distribuzione basato su hash tra flussi a 5 tuple (IP di origine, porta di origine, IP di destinazione, porta di destinazione, protocollo). Funziona interamente nel percorso dei dati al livello 4, quindi non termina mai le connessioni o controlla i payload. Le probe di integrità (TCP, HTTP o HTTPS) controllano continuamente le istanze back-end e rimuovono dalla rotazione quelle non integre entro pochi secondi. Load Balancer ridimensiona automaticamente. Non esiste alcuna pianificazione della capacità o ridimensionamento delle istanze.

Azure Load Balancer (Standard, interno)

Il bilanciatore del carico interno funziona allo stesso modo della controparte pubblica, ma utilizza un indirizzo IP frontend privato della subnet della rete virtuale. Distribuisce il traffico tra livelli interni, ad esempio un livello Web che invia traffico a un cluster API di livello intermedio. Poiché non ha un indirizzo IP pubblico, è invisibile a Internet. Abbinalo a un servizio di ingresso pubblico, come Front Door, Application Gateway o un servizio di bilanciamento del carico pubblico, che gestisce il perimetro esterno.

Gateway di applicazioni Azure

Gateway applicazione è un'appliance virtuale dedicata distribuita all'interno della subnet della rete virtuale. Termina le connessioni TLS sul gateway, esamina le intestazioni HTTP e gli URL e instrada le richieste ai pool back-end in base a regole di percorso, header Host o probe di integrità personalizzate. SKU v2 supporta la scalabilità automatica (da 0 a 125 istanze) e la ridondanza della zona. Poiché risiede nella VNet, può raggiungere backend privati senza richiedere indirizzi IP pubblici su tali backend.

Gateway applicativo con WAF

Quando aggiungi il livello WAF, abiliti il Core Rule Set di OWASP e le regole di Microsoft Threat Intelligence direttamente nella pipeline di elaborazione di Application Gateway. Ogni richiesta HTTP passa attraverso il motore WAF prima di raggiungere le regole di routing. WAF supporta i criteri per sito, pertanto è possibile avere configurazioni di regole diverse per diverse combinazioni di listener o host nello stesso gateway. WAF funziona in modalità rilevamento (solo log) o prevenzione (blocco e log).

Frontdoor di Azure

Frontdoor opera dalla rete perimetrale globale Microsoft (oltre 190 punti di presenza). Quando un utente si connette, l'handshake TCP e la negoziazione TLS si verificano nel punto di presenza più vicino usando Split TCP. Il punto di presenza mantiene una connessione persistente già attiva con l’origine, eliminando così la latenza da avvio a freddo che gli utenti sperimenterebbero collegandosi direttamente. Frontdoor esegue il routing di livello 7, l'ispezione WAF, la memorizzazione nella cache e la compressione all'edge prima di inoltrare la richiesta all'origine disponibile più vicina tramite il backbone di rete Microsoft.

Gestione traffico di Azure

Gestione traffico è un servizio basato su DNS senza coinvolgimento del percorso dati. Quando un client risolve il nome host di Gestione traffico, viene restituito un record CNAME che punta all'endpoint più affidabile o più vicino in base al metodo di routing scelto (priorità, ponderato, prestazioni, geografico, multivalore o subnet). Traffic Manager monitora continuamente lo stato di integrità degli endpoint e aggiorna di conseguenza le risposte DNS. Poiché non vede mai il traffico dell'applicazione, funziona con qualsiasi protocollo: HTTP, TCP, UDP o protocolli proprietari.

Confronto tra modelli di costo

Ogni servizio di ingresso segue un modello di fatturazione diverso. Usare questa tabella per stimare i costi del volume di traffico previsto.

Service	Modello di fatturazione	Principali driver di costo	Livello gratuito o funzionalità incluse
Indirizzo IP pubblico	Per ora (allegato) + per GB in uscita	Numero di ore associate; costi di uscita	Primi 100 GB in uscita al mese gratuiti (globale)
Bilanciatore di carico standard	Per ora per regola + per GB elaborato	Numero di regole di bilanciamento del carico; dati elaborati tramite LB	Nessuno
Application Gateway	Per ora per istanza + unità di capacità consumate	Ore di istanza; unità di capacità di calcolo, connessione e capacità effettiva	Nessuno
WAF + gateway applicazione	Per ora per istanza (prezzi del piano WAF) + unità di capacità	Come Application Gateway, ma con la tariffa oraria del piano WAF	Nessuno
Frontdoor di Azure	Per richiesta + trasferimento dati per GB + richieste WAF	Instradamento delle richieste, trasferimento dei dati dall'edge ai client, valutazioni delle regole WAF	Il livello Standard include alcune funzionalità di routing di base
Gestione traffico di Azure	Query DNS per milione + endpoint per ogni controllo di integrità	Volume delle query DNS; numero di endpoint monitorati	Per il primo miliardo di query si applica una tariffazione a livelli

Tip

Per carichi di lavoro a basso traffico (inferiori a 1 milione di richieste al mese), il modello per richiesta di Front Door può risultare più conveniente rispetto al costo orario fisso di Application Gateway. Con l’aumentare del traffico, i modelli orari diventano più prevedibili. Usa il Calcolatore prezzi di Azure con il throughput previsto per fare un confronto.

Come scegliere

Usare le tabelle decisionali seguenti per selezionare il servizio di ingresso appropriato per il carico di lavoro. Iniziare con la tabella delle decisioni di alto livello, quindi usare il confronto dettagliato per confermare la scelta.

Gateway applicazione vs. Frontdoor vs. Gestione traffico

Questa tabella consente di scegliere tra i tre servizi di ingresso HTTP e HTTPS più comuni.

Le tue esigenze	Servizio consigliato	Perché
Traffico HTTP/S, singola area, protezione WAF	Gateway applicativo con WAF	Servizio Layer 7 regionale con instradamento basato sul percorso e WAF. Viene eseguito all'interno della rete virtuale.
Traffico HTTP/S, multi-regione, utenti in tutto il mondo, CDN + WAF	Frontdoor di Azure	Servizio globale di livello 7 che si attesta presso i PoP di edge. Rete CDN predefinita, WAF e failover automatico.
Routing in più aree per protocolli non HTTP/S o solo routing a livello DNS	Gestione traffico di Azure	Routing basato su DNS che funziona con qualsiasi protocollo. Nessuna terminazione della connessione.
HTTP/S multiregione con requisiti di elaborazione regionali vincolati alla VNet	Gateway applicazione + Gestione traffico	Valido per i carichi di lavoro che richiedono un'integrazione avanzata con la VNet o la sovranità dei dati regionale con ispezione WAF regionale. Per la maggior parte degli scenari HTTP/S in più aree, preferisce invece Frontdoor.

Tip

Per la maggior parte dei carichi di lavoro HTTP e HTTPS multiregion, Front Door è la scelta preferita rispetto ad Application Gateway usato insieme a Traffic Manager. Front Door offre WAF, CDN e failover automatico integrati senza dover gestire più istanze regionali di Application Gateway. La combinazione di Application Gateway + Traffic Manager rimane valida per i carichi di lavoro che richiedono un'elaborazione regionale vincolata alla VNet, origini collegamento privato accessibili solo all'interno di una VNet o requisiti normativi che impongono la sovranità regionale dei dati.

Confronto tra i servizi in ingresso

Usare questo confronto dettagliato quando è necessario comprendere le funzionalità di ogni servizio.

Service	Livello	Globale o regionale	Terminazione della connessione	WAF disponibile	Sonde di monitoraggio della salute	Ideale per
Indirizzo IP pubblico	3	Regionale	No (diretto alla macchina virtuale)	No	No	Carichi di lavoro di sviluppo/test con singola istanza senza requisiti di alta disponibilità
Load Balancer Standard (pubblico)	4	Regionale	No (pass-through)	No	Sì (TCP, HTTP, HTTPS)	Carichi di lavoro non HTTP: giochi, IoT, TCP/UDP personalizzati
Load Balancer Standard (interno)	4	Regionale	No (trasferimento diretto)	No	Sì (TCP, HTTP, HTTPS)	Livello interno dietro un servizio di ingresso pubblico
Application Gateway	7	Regionale	Sì (terminazione TLS)	No (aggiungi livello WAF)	Sì (HTTP/S personalizzato)	HTTP/S a regione singola con instradamento basato sul percorso
WAF + gateway applicazione	7	Regionale	Sì (terminazione TLS)	Sì (set di regole DRS)	Sì (HTTP/S personalizzato)	App web a regione singola che richiedono WAF
Frontdoor di Azure	7	Globale	Sì (Split TCP al PoP)	Sì (predefinito)	Sì (HTTP/S)	HTTP/S in più aree con accelerazione globale
Gestione traffico di Azure	DNS	Globale	No (solo DNS)	No	Sì (HTTP/S, TCP)	Failover a livello DNS multi-area, qualsiasi protocollo

Architettura di ingresso Internet

Il diagramma seguente illustra i modelli comuni di concatenamento dei servizi per il traffico in ingresso verso i carichi di lavoro Azure. Ogni modello combina i servizi di livello 7 e livello 4 in modo che corrispondano a un protocollo specifico, all'ambito a livello di area e al comportamento di sicurezza.

Modelli di ingresso comuni

I modelli seguenti combinano più servizi per un'architettura di ingresso completa. Scegli lo schema che corrisponde ai requisiti del protocollo, all'ambito geografico e al livello di sicurezza.

Modello 1: Applicazione Web globale con sicurezza perimetrale

Servizi: Front Door → Application Gateway (con WAF) → VM/contenitori

Scenario: Un'applicazione SaaS che gestisce i clienti in America del Nord, Europa e Asia necessita di accelerazione globale, protezione DDoS nei dispositivi perimetrali e routing basato sul percorso a livello di area a microservizi diversi.

Frontdoor termina le connessioni utente al punto di presenza (PoP) più vicino, applica regole WAF globali e memorizza nella cache il contenuto statico. Il traffico viene instradato sulla dorsale Microsoft verso l'Application Gateway regionale, che esegue il routing basato su URL (ad esempio, /api/* nel pool API, /static/* in un back-end di archiviazione). Questo modello fornisce due livelli di ispezione WAF: uno al bordo e uno nell'area.

Modello 2: multi-area non HTTP con failover DNS

Servizi: Traffic Manager → Load Balancer Standard (per area geografica) → VM

Scenario: Una società di giochi esegue server di gioco dedicati sulla porta UDP 7777 in tre aree. I giocatori si connettono automaticamente all'area sana più vicina.

Traffic Manager utilizza il metodo di instradamento in base alle prestazioni per restituire il record DNS dell'area geografica con la latenza più bassa. Ogni area dispone di Load Balancer standard che distribuisce il traffico UDP a un set di scalabilità di macchine virtuali. Se i probe di integrità rilevano un guasto a livello di area geografica, Traffic Manager aggiorna il DNS per instradare i giocatori all'area geografica successiva più vicina.

Modello 3: Semplice app Web a livello di area con WAF

Servizi: gateway applicazione (con WAF) → macchine virtuali

Scenario: Applicazione aziendale interna esposta a partner esterni. Regione singola, traffico moderato, necessita di protezione OWASP e terminazione TLS.

Application Gateway offre instradamento basato sul percorso, affinità dei cookie per la gestione delle sessioni e protezione WAF, il tutto da un'unica risorsa regionale all'interno della rete virtuale. Questo modello evita la complessità e il costo di un servizio globale quando il traffico viene concentrato geograficamente.

Modello 4: Frontdoor con origini private bloccate

Servizi: Front Door Premium → collegamento privato → Load Balancer interno → macchine virtuali

Scenario: Un'applicazione di servizi finanziari con requisiti rigorosi che l'origine non deve avere un'esposizione IP pubblica. Tutto il traffico deve transitare sulla rete backbone di Microsoft senza passaggi tramite Internet pubblico.

Frontdoor Premium si connette all'origine tramite un endpoint collegamento privato. Il back-end di origine non ha un indirizzo IP pubblico e nessuna esposizione a Internet. Questo modello offre la sicurezza di un'origine completamente privata combinata con i vantaggi delle prestazioni della rete perimetrale globale di Frontdoor.

Ingresso in più aree con Frontdoor

Il diagramma seguente mostra Frontdoor di Azure come un punto di ingresso globale, che instrada gli utenti verso l'origine regionale disponibile più vicina con failover automatico.

Prerequisiti

Prima di esporre l'applicazione a Internet, assicurarsi di disporre dei componenti seguenti:

• Rete virtuale distribuita: Le risorse back-end devono essere eseguite all'interno di una rete virtuale Azure con subnet con dimensioni appropriate. Per indicazioni sulla pianificazione della subnet, vedere Progettare la rete virtuale e le subnet .
• Carico di lavoro in esecuzione: È necessaria almeno una risorsa back-end (macchina virtuale, contenitore o servizio della piattaforma) pronta per gestire il traffico.
• Nome DNS: Nome DNS pubblico usato dagli utenti esterni per raggiungere l'applicazione. È possibile usare DNS di Azure o un provider DNS di terze parti.
• Pianificazione della subnet per i servizi in ingresso: Application Gateway richiede una subnet dedicata (si consiglia almeno una /24 per gli ambienti di produzione). Le istanze back-end del Load Balancer Standard possono condividere una subnet con altre risorse.

Considerazioni relative alla progettazione

Valutare se è necessario l'accesso in ingresso da Internet per i carichi di lavoro migrati. Molte applicazioni locali sono solo interne e rimangono in questo modo dopo la migrazione. Se è necessario l'ingresso, mantenere semplice l'architettura:

• Gateway applicazione con WAF fornisce un ingresso di livello 7 a regione singola con terminazione TLS e protezione OWASP. Questo approccio è il più comune per le app Web migrate che in precedenza si trovavano dietro un proxy inverso locale.
• IP pubblico con NSG è accettabile per carichi di lavoro non HTTP con traffico ridotto, ad esempio un servizio TCP a cui si collegano i partner. Limitare l'NSG agli indirizzi IP di origine noti.
• Evitare di assegnare indirizzi IP pubblici direttamente alle macchine virtuali. Posiziona un bilanciatore del carico o un Application Gateway tra internet e il tuo back-end.

Se le applicazioni migrate non servono utenti esterni, saltate questo articolo e proseguite con l'accesso a Internet in uscita.

I carichi di lavoro modernizzati hanno modelli di ingresso distinti in base al tipo di applicazione:

• Frontdoor di Azure per le applicazioni Web rivolte ai clienti, ad esempio ContosoBiz. Front Door offre accelerazione globale, WAF integrato, memorizzazione nella cache della rete CDN e failover automatico tra aree geografiche. Usare il routing ponderato per implementazioni attive-attive.
• Gestione traffico di Azure per applicazioni per dispositivi mobili e API (ad esempio, ContosoCare). Gestione traffico fornisce il routing basato su DNS per protocolli non HTTP o quando i client necessitano di connettività a livello di area diretta.
• Firewall di hub come destinazione DNAT: Tutto il traffico in ingresso passa attraverso l'hub Firewall di Azure prima di raggiungere i livelli applicativi. Il firewall esegue il NAT di destinazione (DNAT) per instradare il traffico filtrato allo spoke corretto. Questo modello garantisce che nessun traffico Internet senza scrupoli ignori i controlli di sicurezza centralizzati.

Combina Front Door con Application Gateway in ogni regione per un'ispezione WAF a due livelli: una al perimetro globale e una al confine regionale.

Per le applicazioni esposte a Internet migrate da AWS o Google Cloud, distribuire Application Gateway con WAF nella spoke VNet in cui risiede il carico di lavoro:

• Gateway applicazione + WAF nella macchina virtuale spoke: Distribuire un gateway applicazione regionale con WAF abilitato in modalità di prevenzione. Questo approccio mantiene l'ingresso vicino al carico di lavoro senza richiedere il traffico per attraversare l'hub per l'ispezione HTTP.
• Nessun indirizzo IP pubblico diretto nelle macchine virtuali: Non assegnare mai indirizzi IP pubblici direttamente alle macchine virtuali di cui è stata eseguita la migrazione. Tutto il traffico esposto a Internet passa attraverso Application Gateway.
• Proteggere gli endpoint di origine: Se l'applicazione era precedentemente protetta da un AWS Application Load Balancer (ALB) o da Google Cloud Load Balancing, ricondurre tale modello di ingresso del traffico ad Application Gateway per i carichi di lavoro regionali o a Front Door per i carichi di lavoro globali.

Se il workload cross-cloud è esclusivamente interno (con comunicazione tra cloud tramite rete privata), saltate questo articolo e passate a Firewall di Azure e ispezione del traffico.

Considerazioni relative alla sicurezza

Il traffico in ingresso da Internet è la porta d'ingresso della tua applicazione. È il limite in cui il traffico Internet non attendibile entra nell'ambiente di Azure. Seguire queste procedure per proteggere il percorso di ingresso.

Non esporre mai le macchine virtuali direttamente con indirizzi IP pubblici

Non assegnare un indirizzo IP pubblico direttamente all'interfaccia di rete di una macchina virtuale per gestire il traffico dell'applicazione sulle porte 80 o 443. Posizionare invece un bilanciatore del carico o un Application Gateway tra Internet e le VM. Questo approccio offre:

• Controlli di integrità per rimuovere dalla rotazione le istanze non funzionanti
• Un singolo punto per la terminazione SSL o TLS
• Un luogo in cui applicare le regole WAF e la limitazione della velocità
• Registrazione centralizzata di tutto il traffico in ingresso

Attenzione

Un indirizzo IP pubblico direttamente in una macchina virtuale espone tutte le porte aperte a Internet. Se il gruppo di sicurezza di rete della macchina virtuale ha una regola non configurata correttamente, gli utenti malintenzionati ottengono l'accesso diretto al sistema operativo.

Abilitare WAF in modalità prevenzione

Se si distribuiscono Application Gateway con WAF o Frontdoor di Azure con WAF, impostare il WAF sulla modalità Prevenzione per i carichi di lavoro di produzione. La modalità di prevenzione blocca le richieste dannose prima che raggiungano l'applicazione. La modalità di rilevamento registra solo le minacce senza bloccarle. Usare la modalità rilevamento solo durante i test iniziali per ottimizzare le regole e identificare i falsi positivi.

Il set di regole predefinite (DRS) del WAF protegge dai 10 principali attacchi OWASP, tra cui SQL injection, cross-site scripting ed esecuzione di codice remoto. DRS include anche regole di Microsoft Threat Intelligence che rilevano indirizzi IP e payload dannosi noti.

Abilitare Protezione DDoS

Per tutte le reti virtuali con risorse pubbliche deve essere abilitata la protezione DDoS. La Protezione di rete DDoS di Azure offre ottimizzazione dinamica, telemetria degli attacchi e protezione dai costi per i tuoi IP pubblici. Senza la protezione DDoS, un attacco volumetrico può saturare la larghezza di banda in ingresso e rendere l'applicazione non raggiungibile.

Per informazioni dettagliate, vedere Protezione DDoS per la rete.

Usare gli NSG per la difesa in profondità

Anche quando si utilizza un bilanciatore del carico o Application Gateway, configurare le regole del gruppo di sicurezza di rete nelle subnet di back-end per limitare le sorgenti di traffico che possono raggiungere le macchine virtuali. Un gruppo di sicurezza di rete configurato correttamente:

• Consente il traffico solo dalla subnet o dal tag del servizio di bilanciamento del carico
• Nega il traffico in ingresso diretto da Internet alle macchine virtuali back-end
• Registra il traffico negato per il monitoraggio della sicurezza

Per la pianificazione del gruppo di sicurezza di rete, vedere Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni.

Applicare TLS 1.2 o versione successiva

Configurare tutti i servizi di ingresso per accettare solo TLS 1.2 o TLS 1.3. Disabilitare TLS 1.0 e 1.1, che presentano vulnerabilità note. Sia Application Gateway che Front Door supportano la configurazione della versione minima di TLS tramite le impostazioni dei criteri TLS. Usare criteri predefiniti, ad esempio AppGwSslPolicy20220101 per il gateway applicazione, anziché configurazioni di crittografia personalizzate, a meno che non si disponga di requisiti di conformità specifici.

Bloccare le origini per Frontdoor

Quando si usa Frontdoor di Azure, limitare i server di origine per accettare il traffico solo da Frontdoor. Se l'origine accetta traffico da qualsiasi origine, gli attori malintenzionati possono ignorare il WAF di Frontdoor connettendosi direttamente all'IP di origine, rendendo inefficace l'intero investimento WAF.

Il blocco dell'origine usa due meccanismi di verifica indipendenti. Applica entrambi per una difesa a più livelli:

Restrizione dei tag di servizio (livello di rete)

Configura l'NSG dell'origine o Firewall di Azure per consentire il traffico HTTP/HTTPS in ingresso solo dal tag di servizio AzureFrontDoor.Backend. Questo tag di servizio contiene tutti gli intervalli IP usati da Frontdoor per connettersi alle origini. Applicare questa regola alla subnet o alla scheda di rete in cui si trova l'origine:

• Regola NSG: Priorità 100, Origine = Service Tag AzureFrontDoor.Backend, Destinazione = subnet del back-end, Porte = 80, 443, Azione = Consenti.
• Nega predefinita: Verificare che nessun'altra regola consenta il traffico in ingresso sulle porte 80/443 da Internet. La regola DenyAllInbound predefinita del gruppo di sicurezza di rete gestisce questo caso, a meno che non venga aggiunta una regola Allow più ampia.

Il tag del servizio da solo non è sufficiente perché tutte le istanze di Frontdoor in tutti i Azure clienti condividono gli stessi intervalli IP dei tag di servizio. Un attore malintenzionato potrebbe creare il proprio profilo Front Door e indirizzarlo all'indirizzo IP di origine, aggirando le regole WAF.

Convalida dell'intestazione X-Azure-FDID (livello applicazione)

Ogni richiesta da Frontdoor include un'intestazione X-Azure-FDID contenente l'identificatore univoco (GUID) dell'istanza di Frontdoor che ha inviato la richiesta. Convalidare questa intestazione nella propria applicazione o nel proxy inverso per confermare che la richiesta provenga dal profilo Frontdoor e non da quello di un utente malintenzionato:

1. Trova l'ID di Front Door nel portale di Azure nella pagina Panoramica del tuo profilo Front Door (campo "Front Door ID").
2. Nel codice dell'applicazione o nella configurazione del server Web rifiutare qualsiasi richiesta in cui X-Azure-FDID non corrisponda al GUID previsto.
3. Restituisce HTTP 403 per le richieste con un valore dell'header mancante o errato.

La combinazione del tag di servizio (che blocca a livello di rete il traffico che non proviene da Front Door) con la convalida dell'header (che blocca a livello di applicazione il traffico proveniente da Front Door di altri clienti) garantisce che solo la tua istanza di Front Door possa raggiungere l'origine.

Origini collegamento privato (blocco più restrittivo)

Per i carichi di lavoro che richiedono il massimo livello di isolamento dell’origine, Front Door Premium supporta origini collegamento privato. L'origine non necessita di alcun indirizzo IP pubblico. Frontdoor si connette tramite un endpoint privato sul backbone Microsoft. Questo approccio elimina la necessità di regole di tag di servizio o convalida dell'intestazione perché l'origine non è raggiungibile interamente dalla rete Internet pubblica.

Articoli correlati

• Progetta la rete virtuale e le subnet: dimensionamento della subnet per Application Gateway e i backend di Load Balancer
• Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni: regole del gruppo di sicurezza di rete per limitare l'accesso back-end dopo l'ingresso
• Recapito e prestazioni dell'applicazione: Ottimizzazione delle prestazioni dopo la creazione del percorso di ingresso
• Accesso Internet in uscita: Controlla il traffico in uscita, la controparte in uscita del traffico in entrata
• Proteggere l'accesso amministrativo: modelli di accesso amministratore, distinti dall'ingresso Internet per gli utenti dell'applicazione
• Web application firewall: configurazione dettagliata di WAF e ottimizzazione delle regole
• Protezione DDoS per la rete: pianificazione della protezione DDoS per tutte le risorse pubbliche

Ulteriori informazioni

• Informazioni su Azure Load Balancer
• Che cos'è gateway applicazione di Azure?
• Che è Frontdoor di Azure?
• Che cos'è Gestione traffico di Azure?
• Indirizzi IP pubblici in Azure
• Web Application Firewall di Azure su Application Gateway
• Panoramica di Azure Protezione DDoS della rete

Passaggi successivi

Tip

Esplorazione da sola? Tornare allo strumento di navigazione di panoramica per trovare l'articolo successivo in base alla funzionalità.

Successivamente, nel viaggio in modalità lift-and-shift:

Distribuzione e prestazioni dell'applicazione: aggiungere il bilanciamento del carico di livello 7 e il recapito globale per il carico di lavoro migrato.

Se il carico di lavoro sollevato non richiede il bilanciamento del carico di livello 7, passare direttamente all'accesso Internet in uscita.

Nel prossimo percorso di modernizzazione:

Distribuzione e prestazioni delle applicazioni: ottimizzare la distribuzione e le prestazioni globali per i carichi di lavoro PaaS rivolti ai clienti.

Il prossimo passo nel tuo percorso multicloud:

Web application firewall: proteggere le applicazioni pubbliche da attacchi a livello HTTP nel cloud.

Se il carico di lavoro non usa HTTP/HTTPS, passare alla Firewall di Azure e all'ispezione del traffico.