Firewall di Azure e ispezione del traffico

Firewall di Azure è un servizio di sicurezza di rete gestito nativo del cloud che fornisce un'ispezione centralizzata del traffico e un filtro per le reti virtuali Azure. A differenza dei gruppi di sicurezza di rete che operano al livello 4, Firewall di Azure controlla il traffico a livelli da 3 a 7. Questa funzionalità consente il filtro completo dei nomi di dominio (FQDN), l'intelligence sulle minacce, il rilevamento e la prevenzione delle intrusioni (IDPS) e l'ispezione TLS. È possibile distribuire Firewall di Azure in una subnet dedicata all'interno della rete virtuale hub e instradare il traffico dai carichi di lavoro spoke attraverso il firewall per l'ispezione prima di raggiungere la destinazione.

Questo articolo illustra come selezionare lo SKU di Firewall di Azure corretto, posizionare il firewall in una topologia hub-spoke, configurare i tipi di regole e integrarsi con servizi complementari, ad esempio gateway NAT e Server di route. Firewall di Azure è uno dei tre servizi principali di sicurezza di rete Azure, insieme a Azure DDoS Protection e Web application firewall di Azure.

Informazioni su questo articolo

Questo articolo tratta l'ispezione centralizzata del traffico di rete utilizzando Firewall di Azure. Vengono fornite informazioni su:

  • Selezione del livello di SKU in base ai requisiti di sicurezza e alla sensibilità del carico di lavoro.
  • Modelli di posizionamento dell'hub e route definita dall'utente che forzano il traffico attraverso il firewall.
  • Logica di elaborazione delle regole per le regole DNAT, di rete e dell'applicazione.
  • Tunneling forzato per ambienti che richiedono l'ispezione locale.
  • Funzionalità di ispezione TLS e IDPS nel livello Premium.
  • Integrazione con il gateway NAT per il ridimensionamento delle porte SNAT e il server di route per il routing basato su BGP.

Chi ha bisogno di questo articolo

Distribuire Firewall di Azure quando i carichi di lavoro richiedono una o più delle funzionalità seguenti:

  • Controllo centralizzato del traffico in uscita: è necessario limitare gli FQDN e gli URL esterni che i carichi di lavoro possono contattare, oltre a quanto consentito dalle regole NSG basate su IP.
  • Ispezione del traffico est-ovest: il traffico tra le reti virtuali spoke deve passare attraverso un punto di ispezione con controllo dello stato prima che il firewall ne consenta il passaggio.
  • Registrazione richiesta ai fini della conformità: i quadri normativi richiedono una visibilità completa a livello 7 delle connessioni consentite e rifiutate, con granularità a livello di FQDN.
  • Protezione dalle minacce: è necessario il rilevamento e la prevenzione delle intrusioni basate sulla firma per identificare modelli di traffico dannoso, inclusi callback di comando e controllo, tentativi di exploit e spostamento laterale.
  • Ispezione TLS: è necessario decrittografare ed esaminare il traffico crittografato (HTTPS) per individuare le minacce prima che raggiunga i carichi di lavoro o lasci la rete.

Le organizzazioni che necessitano solo del filtraggio dei pacchetti di livello 4 senza supporto FQDN dovrebbero prendere in considerazione NSGs and ASGs come alternativa più semplice e meno costosa.

Focus su lift-and-shift: convertire la base delle regole del firewall locale in criteri di Firewall di Azure. Iniziare con le regole di rete per il traffico non HTTP/S e le regole dell'applicazione per il filtro basato su FQDN. Iniziare con criteri consentiti generali durante la migrazione, quindi rafforzare le regole dopo aver esaminato Firewall di Azure log.

Obiettivo di modernizzazione: Usare Firewall di Azure come punto centralizzato per SNAT e DNAT nell'hub. Ispezionare il traffico tra gli spoke applicativi e tra gli spoke e internet, utilizzare regole applicative e tag FQDN per il traffico in uscita di AKS e di Azure PaaS e pianificare l'ispezione TLS nei casi in cui i livelli applicativi scambiano traffico sensibile.

Focus su multi-cloud: distribuire Firewall di Azure in un hub virtuale protetto per ispezionare il traffico di transito tra cloud. Configurare le regole di rete per il traffico di tunnel IPSec da AWS o Google Cloud e usare IDPS per controllare i modelli di traffico anomali tra cloud connessi.

Livelli SKU di Firewall di Azure

Firewall di Azure è disponibile in tre livelli di SKU. Ogni livello si basa sulle funzionalità del livello precedente.

Capability Basic Standard Premium
Ispezione dei pacchetti con controllo di stato ✔ ✔ ✔
Filtro FQDN (in uscita) ✔ ✔ ✔
Regole di rete (IP, porta, protocollo) ✔ ✔ ✔
Regole dell'applicazione (FQDN, URL) ✔ ✔ ✔
Regole NAT (DNAT) ✔ ✔ ✔
Filtro dell'intelligence sulle minacce Solo avviso ✔ (Avviso e negazione) ✔ (Avviso e negazione)
Proxy DNS ✗ ✔ ✔
Categorie Web ✗ ✔ ✔
IDPS (rilevamento e prevenzione delle intrusioni) ✗ ✗ ✔
Ispezione TLS ✗ ✗ ✔
Filtro URL (percorso completo) ✗ ✗ ✔
Proxy esplicito ✗ ✔ ✔
Disponibilità della regione Aree limitate Tutte le aree geografiche Tutte le aree geografiche
Ideale per Sviluppo/test, carichi di lavoro di piccole dimensioni Produzione standard Sicurezza elevata, guidata dalla conformità

Come scegliere lo SKU

Usare i criteri decisionali seguenti:

  • Scegliere Basic quando si hanno ambienti di sviluppo/test o carichi di lavoro di piccole dimensioni che necessitano di filtri in uscita basati su FQDN senza filtri di intelligence sulle minacce (modalità di negazione) o ispezione avanzata. Lo SKU Basic comprende informazioni sulle minacce in modalità solo avviso, ma non supporta la modalità di blocco, il proxy DNS o le categorie web. Lo SKU Basic richiede un valore minimo dedicato AzureFirewallManagementSubnet (/26) insieme a AzureFirewallSubnet e è disponibile in aree limitate.
  • Scegliere Standard per i carichi di lavoro di produzione che necessitano di filtri basati su intelligence sulle minacce, proxy DNS per la risoluzione delle regole FQDN, filtro delle categorie Web e gestione centralizzata dei criteri tramite Gestione firewall di Azure. Standard fornisce un motore completo di ispezione con stato con feed di intelligence sulle minacce che bloccano le connessioni verso indirizzi IP e domini dannosi noti.
  • Scegliere Premium quando i requisiti normativi o di sicurezza impongono l'ispezione TLS del traffico crittografato, l'IDPS basato su firma con regole aggiornate continuamente (oltre 67.000 firme in più di 50 categorie, aggiornate in tempo reale) o il filtro del percorso URL completo oltre il nome di dominio completo. Premium è obbligatorio per settori come servizi finanziari, sanità e enti pubblici in cui l'ispezione del traffico crittografata è obbligatoria.

Note

Eseguire l'aggiornamento da Standard a Premium senza ridistribuire il firewall. Il downgrade da Premium a Standard richiede ridistribuzione.

Posizionamento dell'hub e modello di routing UDR

Distribuire Firewall di Azure in una subnet dedicata denominata esattamente AzureFirewallSubnet all'interno della rete virtuale hub. Questa subnet richiede una dimensione minima di /26 (59 indirizzi IP utilizzabili).

Architettura di routing

Diagramma di una topologia hub-spoke in cui il traffico della subnet spoke viene instradato attraverso Firewall di Azure nella rete virtuale hub prima di raggiungere Internet o altri spoke.

In una topologia hub-spoke, le subnet del carico di lavoro spoke non instradano il traffico direttamente a Internet o ad altri spoke. Invece, le route definite dall'utente (UDR) di ogni subnet spoke impostano la route predefinita (0.0.0.0/0) verso l'indirizzo IP privato di Firewall di Azure. Questo modello garantisce che tutto il traffico, sia nord-sud (associato a Internet) sia a est-ovest (spoke-to-spoke), passi attraverso il firewall per l'ispezione.

Modello di configurazione UDR:

Tabella di instradamento (applicata) Prefisso dell’indirizzo Tipo di passaggio successivo Indirizzo del prossimo passaggio
Subnet spoke A 0.0.0.0/0 Dispositivo virtuale IP privato del firewall
Subnet spoke A 10.1.0.0/16 (altro spoke) Dispositivo virtuale IP privato del firewall
Subnet spoke B 0.0.0.0/0 Dispositivo virtuale IP privato del firewall
Subnet spoke B 10.0.0.0/16 (altro spoke) Dispositivo virtuale IP privato del firewall

AzureFirewallSubnet stesso non richiede UDR nella maggior parte degli scenari perché il firewall utilizza le route di sistema per raggiungere le reti spoke tramite il peering di rete virtuale. Quando si esegue l'integrazione con Server di route Azure, la subnet del firewall apprende le route tramite BGP. Questo approccio elimina la necessità di manutenzione manuale delle route man mano che aumenta la rete.

Tip

gestione rete virtuale di Azure può automatizzare la configurazione delle tabelle di routing per usare Firewall di Azure come hop successivo, riducendo la gestione manuale delle UDR in molte sottoscrizioni spoke.

Requisiti della subnet

Sottorete Dimensioni minime Purpose Note
AzureFirewallSubnet /26 Ospita istanze di Firewall di Azure Deve essere denominato esattamente AzureFirewallSubnet
AzureFirewallManagementSubnet /26 Traffico di gestione (solo SKU Basic) Obbligatorio per SKU Basic; facoltativo per il tunneling forzato negli altri SKU

Per altre informazioni sulla progettazione della rete virtuale hub e sulla pianificazione della subnet, vedere Topologia hub-spoke.

Tipi di regole e logica di elaborazione

Firewall di Azure elabora le regole attraverso Firewall di Azure Policy. Le regole sono organizzate in raccolte regole, raggruppate in gruppi di raccolte regole. Il firewall valuta le regole nell'ordine di priorità seguente:

  1. Regole DNAT (Destination Network Address Translation): vengono elaborate per prime. Convertire il traffico in ingresso da un indirizzo IP pubblico a un indirizzo IP privato dietro il firewall.
  2. Regole di rete: secondo elaborato. Consentire o negare il traffico in base a IP di origine, IP di destinazione, porta e protocollo (livello 3/4).
  3. Regole dell'applicazione: elaborato per ultimo. Consentire o negare il traffico in uscita in base a FQDN, URL o categoria Web (livello 7).

All'interno di ogni tipo di regola, i gruppi di raccolta regole vengono valutati in base alla priorità (numero più basso = priorità più alta). All'interno di un gruppo, le raccolte regole vengono valutate in base alla priorità. La prima regola corrispondente determina l'azione (Consenti o Nega) e interrompe ogni ulteriore valutazione.

Regole DNAT

Usare le regole DNAT per pubblicare i servizi interni tramite l'indirizzo IP pubblico del firewall. Il firewall converte l'indirizzo di destinazione dal relativo indirizzo IP pubblico all'indirizzo IP privato del servizio back-end. Gli scenari comuni includono:

  • Esposizione di un server Web interno tramite l'indirizzo IP pubblico del firewall sulla porta 443
  • Fornire accesso RDP o SSH controllato a una jump box senza assegnare un indirizzo IP pubblico alla macchina virtuale
  • Pubblicazione di servizi non HTTP/S che richiedono l'accesso in ingresso da Internet
Example: Translate inbound TCP 443 on firewall public IP → 10.1.2.4:443 (internal web server)

Le regole DNAT aggiungono in modo implicito una regola di rete corrispondente per consentire il traffico convertito. Quando una regola DNAT corrisponde, il traffico viene convertito e consentito senza ulteriori elaborazioni delle regole di rete. Per la sicurezza, limitare l'indirizzo IP di origine nelle regole DNAT a origini Internet specifiche anziché usare caratteri jolly.

Regole di rete

Le regole di rete filtrano il traffico al livello 3 e al livello 4. Usare le regole di rete quando è necessario consentire o negare il traffico in base all'indirizzo IP di origine, all'indirizzo IP di destinazione, alla porta di destinazione e al protocollo. Le regole di rete non eseguono la risoluzione FQDN. Operano rigorosamente sugli indirizzi IP. I casi d'uso comuni includono:

  • Consentire la comunicazione spoke-to-spoke per porte specifiche(ad esempio, SQL Server su TCP 1433).
  • Consentire NTP (UDP 123) verso server orari specifici.
  • Blocco del traffico verso intervalli IP dannosi noti tramite regole di negazione.
  • Consentire ICMP per la diagnostica di rete tra subnet specifiche.

Le regole di rete supportano i tipi di protocollo TCP, UDP, ICMP e Any. È possibile specificare indirizzi IP, intervalli IP, tag del servizio e gruppi IP come origine e destinazione.

Regole di applicazione

Le regole dell'applicazione filtrano il traffico HTTP/S e MSSQL in uscita in base a FQDN, URL e categorie Web. Le regole dell'applicazione richiedono la funzionalità proxy DNS per la risoluzione FQDN. Usare le regole dell'applicazione quando:

  • È necessario consentire l'accesso a nomi di dominio completi specifici (ad esempio, *.microsoft.com o storage.blob.core.windows.net).
  • Si vuole filtrare in base al percorso URL (solo SKU Premium), ad esempio consentire github.com/myorg/* ma bloccare altri percorsi di GitHub.
  • È necessario consentire o bloccare intere categorie Web (ad esempio, consentire "Strumenti di sviluppo" e bloccare "Gioco d'azzardo").

Le regole dell'applicazione forniscono tag FQDN per i servizi di Azure comuni, ad esempio Windows Update, Backup di Azure e HDInsight, che semplificano la creazione di regole raggruppando i nomi di dominio completi necessari in un singolo tag.

Importante

Quando si abilita il proxy DNS in Firewall di Azure, il firewall funge da resolver DNS per i carichi di lavoro. Configura le impostazioni DNS della rete virtuale per puntare all'IP privato del firewall in modo che le regole basate su FQDN si risolvano correttamente. Per informazioni dettagliate sull'architettura DNS, vedere Sicurezza DNS e risoluzione dei nomi privati.

Comportamento di SNAT

Per impostazione predefinita, Firewall di Azure applica SNAT (Source Network Address Translation) al traffico in uscita destinato agli indirizzi IP pubblici. Il firewall non esegue lo SNAT traffico quando la destinazione è un intervallo IP privato (RFC 1918) o uno spazio indirizzi condiviso (RFC 6598). Il firewall converte l'indirizzo IP di origine delle connessioni associate a Internet a uno dei relativi indirizzi IP pubblici. Ogni indirizzo IP pubblico fornisce 2.496 porte SNAT per ogni istanza back-end.

Per i carichi di lavoro con velocità di connessione in uscita elevate, eseguire l'integrazione con il gateway NAT per ridimensionare fino a 64.512 porte per indirizzo IP pubblico (fino a 16 indirizzi IP pubblici, circa un milione di porte SNAT totali).

Quando si associa il gateway NAT a AzureFirewallSubnet, tutto il traffico Internet in uscita usa automaticamente gli indirizzi IP pubblici del gateway NAT. Il firewall continua a controllare il traffico, ma il gateway NAT gestisce la conversione SNAT. Non si verifica alcun double NAT.

Note

Il gateway NAT con Firewall di Azure con ridondanza della zona richiede lo SKU del gateway NAT StandardV2. Il gateway NAT non è supportato nelle architetture di hub protette rete WAN virtuale.

Gestione firewall e ereditarietà dei criteri

Gestione firewall di Azure offre criteri di sicurezza centralizzati e gestione delle route tra più istanze di Firewall di Azure. Le funzionalità principali includono:

  • Gerarchia dei criteri: creare un criterio di base (padre) con regole valide per l'intera organizzazione e consentire ai team subordinati di creare criteri secondari che ereditano dal criterio padre. Le regole padre hanno sempre la precedenza indipendentemente dai valori di priorità figlio.
  • Gestione tra aree geografiche: un criterio del firewall è una risorsa globale che può essere associata ai firewall in qualsiasi area geografica o sottoscrizione.
  • Governance multi firewall: applicare un comportamento di sicurezza coerente tra firewall hub in aree diverse o tra hub rete WAN virtuale protetti.

Le regole NAT sono specifiche del firewall e non vengono ereditate dai criteri principali. La modalità intelligence per le minacce viene ereditata, ma può essere sostituita solo con una modalità più restrittiva nei criteri figlio. Un criterio con una o nessuna associazione a un firewall è incluso senza costi aggiuntivi. Le associazioni aggiuntive comportano la fatturazione.

Tunneling forzato

In alcuni ambienti normativi, tutto il traffico associato a Internet deve prima instradarsi attraverso un punto di ispezione locale prima di raggiungere Internet. Firewall di Azure supporta il tunneling forzato per soddisfare questo requisito.

Quando si abilita il tunneling forzato:

  • porta AzureFirewallManagementSubnet il traffico di gestione del firewall direttamente verso Internet. Questa sottorete deve avere una route a 0.0.0.0/0 con hop successivo a Internet. Non è possibile forzare il traffico di gestione tramite l'ispezione locale.
  • Il AzureFirewallSubnet instrada il traffico dei carichi di lavoro destinato a Internet verso un firewall locale o un dispositivo virtuale di rete (NVA) di terze parti tramite ExpressRoute o Gateway VPN.
  • Le regole DNAT non sono supportate in modalità di tunneling forzato perché il traffico in ingresso non può raggiungere direttamente l'indirizzo IP pubblico del firewall.
  • Il firewall non richiede un indirizzo IP pubblico su AzureFirewallSubnet quando si configura il tunneling forzato, perché tutto il traffico in uscita passa attraverso il percorso locale (on-premises).

Usare il tunneling forzato quando i requisiti di conformità richiedono visibilità locale di tutto il traffico associato a Internet o quando è necessario concatenare Firewall di Azure con uno stack di sicurezza locale esistente. Gli scenari comuni includono ambienti di servizi finanziari soggetti alle normative di residenza dei dati e alle reti governative con requisiti centralizzati di interruzione internet.

Importante

In modalità di tunneling forzato, AzureFirewallManagementSubnet richiede un proprio indirizzo IP pubblico e una route definita dall'utente (UDR) con 0.0.0.0/0 che usa Internet come hop successivo. Questa configurazione garantisce che Azure possa mantenere il canale di gestione al firewall.

Ispezione TLS (Premium)

Firewall di Azure Premium intercetta le connessioni HTTPS in uscita, decrittografa il traffico, lo controlla in base alle firme IDPS e alle regole dell'applicazione, quindi crittografa e lo inoltra. Questo processo richiede un certificato CA intermedio archiviato in Azure Key Vault.

Requisiti per i certificati

Requisito Specificazione
Tipo di certificato CA intermedia
Dimensioni chiave RSA minimo a 2048 bit
Flag CA TRUE
Utilizzo delle chiavi KeyCertSign
Validità Almeno 1 anno in avanti
Storage Azure Key Vault (deve essere esportabile)

Il firewall usa il certificato CA intermedio per generare dinamicamente i certificati server per le connessioni intercettate. I browser e le applicazioni degli utenti finali devono considerare attendibile la CA radice dell'organizzazione o la CA intermedia nell'archivio certificati per evitare avvisi di attendibilità.

IDPS

Lo SKU Premium include un motore IDPS completamente gestito con oltre 67.000 regole in più di 50 categorie. Le signature vengono aggiornate continuamente con 20–40 o più nuove regole rilasciate ogni giorno. IDPS opera in due modalità:

  • Modalità avviso: registra le corrispondenze di firma senza bloccare il traffico. Utilizzare durante la distribuzione iniziale e la messa a punto.
  • Modalità avviso e negazione: registra e blocca il traffico che corrisponde alle firme IDPS. Utilizzare in produzione dopo l'ottimizzazione.

Le categorie IDPS riguardano malware command-and-control, phishing, trojan, botnet, exploit kit, vulnerabilità e protocolli SCADA/ICS.

Attenzione

L'ispezione TLS introduce la latenza e ha implicazioni sulla privacy. Assicurarsi che i team legali e di conformità dell'organizzazione approvino l'ispezione del traffico crittografato. Escludere categorie sensibili (settore sanitario, bancario) in base alle esigenze tramite regole di bypass.

Filtro del traffico in uscita di AKS

Quando i cluster Servizio Azure Kubernetes (AKS) richiedono un'uscita controllata, Firewall di Azure fornisce il filtro in uscita basato su FQDN per i nodi del cluster. Senza filtri in uscita, i nodi del servizio Azure Kubernetes possono raggiungere qualsiasi endpoint Internet, aumentando così la superficie di attacco per gli attacchi di supply chain ed esfiltrazione di dati.

Per implementare questo modello:

  1. Distribuire AKS con outboundType impostato su userDefinedRouting e una tabella di route personalizzata nella subnet del nodo.
  2. Impostare la route predefinita (0.0.0.0/0) sull'indirizzo IP privato Firewall di Azure.
  3. Creare regole applicative nei criteri del firewall che consentano gli FQDN AKS necessari (registri di contenitori, endpoint del server API, repository di pacchetti Microsoft).
  4. Creare regole di rete per gli endpoint non HTTP/S necessari (NTP, DNS, connettività tunnel).

Questo schema offre ai team di sicurezza visibilità e controllo su quali endpoint esterni i nodi AKS possono raggiungere, consentendo al contempo al cluster di funzionare correttamente. Gli FQDN richiesti variano in base al set di funzionalità di AKS. I cluster che usano nodi GPU, Monitoraggio di Azure o Criteri di Azure richiedono voci di elenco approvate aggiuntive.

Per esempi dettagliati relativi ai requisiti e alle regole FQDN, vedere Usare Firewall di Azure per proteggere le distribuzioni del servizio Azure Kubernetes.

Note

Il filtro del traffico in uscita di AKS con Firewall di Azure richiede un attento coordinamento tra i team della piattaforma e delle applicazioni. Le regole FQDN mancanti causano errori di pianificazione dei pod e errori di download delle immagini. Iniziare con un criterio permissivo e rafforzare dopo aver osservato i modelli di traffico nei log del firewall.

Considerazioni relative alla progettazione

Focus sulla progettazione del firewall lift-and-shift

  • Convertire le regole del firewall locale in criteri di Firewall di Azure: usare regole di rete per protocolli non HTTP/S e regole dell'applicazione per le destinazioni HTTP/S o MSSQL che necessitano di filtri FQDN.
  • Iniziare con le regole di autorizzazione generali che rispecchiano il comportamento di sicurezza corrente, quindi restringerle dopo la migrazione usando i log di Firewall di Azure per identificare le destinazioni e le porte necessarie.
  • Usare i gruppi IP per modellare le zone di origine e di destinazione in modo che la manutenzione delle regole segua i limiti di segmentazione esistenti.
  • Abilitare le impostazioni di diagnostica al primo giorno in modo da poter confrontare Azure modelli di traffico con la baseline locale prima di limitare l'accesso.

Modernizzare l'approccio alla progettazione dei firewall

  • Usare il firewall dell'hub come punto centralizzato di SNAT e DNAT per gli spoke applicativi, in modo che le policy di traffico in ingresso e in uscita restino nell'hub gestito dall'IT.
  • Abilitare Firewall di Azure Premium quando è necessaria l'ispezione TLS east-west o l'imposizione dell'IDPS di produzione tra i livelli applicazione.
  • Usare i tag FQDN e le regole applicative per consentire le dipendenze di AKS e dei servizi PaaS di Azure senza dover gestire lunghi elenchi di indirizzi IP di destinazione.
  • Verificare i requisiti DNAT nell'ambito della progettazione di Frontdoor o del gateway applicazione, in modo che i flussi in ingresso raggiungano gli spoke di back-end solo tramite percorsi di ispezione approvati.

Focus sulla progettazione di firewall tra cloud

  • Distribuire Firewall di Azure in un hub virtuale protetto quando Azure è il punto di transito per branch, Azure e altre reti cloud.
  • Usare le regole di rete per ispezionare il traffico del tunnel IPSec da AWS Transit Gateway, gateway privati virtuali AWS o connessioni VPN di Google Cloud dopo che le route sono arrivate in Azure.
  • Abilitare IDPS per rilevare modelli di traffico anomalo a est-ovest e tra cloud che possono indicare lo spostamento laterale tra ambienti cloud.
  • Attiva il filtraggio basato sull’intelligence sulle minacce per bloccare le destinazioni note come dannose in tutti gli ambienti cloud connessi con un unico criterio.

Prerequisiti

Prima di distribuire Firewall di Azure:

  • AzureFirewallSubnet: la rete virtuale hub deve includere una subnet dedicata denominata AzureFirewallSubnet con una dimensione minima di /26. Per indicazioni sulla pianificazione della subnet, vedere Progettazione di rete virtuale e subnet .
  • Topologia hub-spoke o rete WAN virtuale: distribuire Firewall di Azure in un hub centrale che instrada il traffico dalle reti spoke. Per le opzioni della topologia, vedere Topologia hub-spoke o rete WAN virtuale.
  • Piano di indirizzi IP: riservare lo spazio degli indirizzi per la subnet del firewall, la subnet di gestione (se si usa il tunneling forzato) e gli indirizzi IP pubblici. Vedere Pianificazione degli indirizzi IP.
  • Gestione firewall di Azure: usare Gestione firewall di Azure se è necessaria una gerarchia di criteri che condivide le regole di base tra più istanze del firewall.
  • Area di lavoro Log Analytics: crea un'area di lavoro per i log di diagnostica del firewall prima della distribuzione, in modo da poter monitorare il traffico e risolvere i problemi relativi alle regole fin dal primo giorno.

Considerazioni relative alla sicurezza

  • Registrazione: abilitare le impostazioni di diagnostica per inviare i log di Firewall di Azure a un'area di lavoro Log Analytics. I log strutturati offrono visibilità a livello di FQDN in ogni connessione consentita e negata, supportando l'analisi di controllo e forense.
  • Disponibilità: distribuire Firewall di Azure tra zone di disponibilità per ottimizzare il contratto di servizio per la disponibilità. Per le percentuali correnti del contratto di servizio, vedere Contratto di servizio per Firewall di Azure.
  • Difesa a più livelli: Firewall di Azure integra, ma non sostituisce, gli NSG. Applica i gruppi di sicurezza di rete (NSG) a livello di subnet e di NIC per la microsegmentazione. Utilizza il firewall per criteri centralizzati, intelligence sulle minacce e ispezione di livello 7.
  • Dimensiona correttamente ciò che ispezioni: Forzare ogni flusso attraverso il firewall, inclusi i livelli interni all’applicazione come dal web all’app e dall’app al database, aggiunge latenza e costi di elaborazione per gigabyte. Usa i gruppi di sicurezza di rete (NSG) e i gruppi di sicurezza delle applicazioni (ASG) per il traffico est-ovest tra tier attendibili e riserva l'ispezione del firewall al traffico che attraversa un confine di attendibilità: diretto a Internet, multi-spoke, ibrido o multi-cloud. Questo approccio mantiene il firewall incentrato sul traffico che trae vantaggio dall'ispezione ed evita costi non necessari.
  • Protezione DDoS: proteggere gli indirizzi IP pubblici associati a Firewall di Azure usando Azure Protezione DDoS. Vedere Protezione DDoS.
  • Traffico di ExpressRoute: quando si utilizza ExpressRoute, configurare le UDR (route definite dall'utente) per instradare il traffico di peering privato attraverso Firewall di Azure per l'ispezione dei flussi di traffico ibrido.

Ulteriori informazioni

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:

Configurare il monitoraggio per la rete migrata: convalidare la connettività e le prestazioni con Network Watcher dopo aver configurato il firewall.

Nel prossimo percorso di modernizzazione:

Proteggi le tue applicazioni web con WAF: aggiungi Web application firewall in Front Door o in Application Gateway per le tue app web destinate ai clienti.

Il prossimo passo nel tuo percorso multicloud:

Configura il monitoraggio multi-cloud: gli ambienti multi-cloud sono operativamente più difficili da diagnosticare e risolvere. Il monitoraggio è essenziale, non facoltativo.

  • Last updated on