Domande frequenti su Azure Firewall

Azure Firewall è un servizio di sicurezza di rete gestito basato sul cloud che protegge le risorse Azure Virtual Network. È un firewall con stato completo distribuito come servizio con disponibilità elevata e scalabilità cloud senza limiti. È possibile creare, applicare e registrare criteri di connettività di applicazione e di rete in modo centralizzato tra le sottoscrizioni e le reti virtuali.

Per un elenco dettagliato delle funzionalità di Azure Firewall, vedere Azure Firewall features.

Azure Firewall possono essere distribuiti in qualsiasi rete virtuale. Tuttavia, viene in genere distribuito in una rete virtuale centrale in un modello hub-spoke, con altre reti virtuali con peering. Il percorso predefinito dalle reti virtuali interconnesse è impostato per puntare a questa rete virtuale del firewall centrale. Anche se il peering di rete virtuale globale è supportato, non è consigliabile a causa di potenziali problemi di prestazioni e latenza tra aree. Per prestazioni ottimali, distribuire un firewall per area.

Questo modello consente il controllo centralizzato su più reti virtuali spoke in sottoscrizioni diverse e offre risparmi sui costi evitando la necessità di dover distribuire un firewall in ogni rete virtuale. I risparmi sui costi devono essere valutati rispetto ai costi di peering associati in base ai modelli di traffico.

Azure Firewall possono essere distribuiti usando il portale di Azure, PowerShell, l'API REST o i modelli. Per istruzioni dettagliate, vedere Tutorial: Distribuire e configurare Azure Firewall usando il portale di Azure.

Azure Firewall usa regole e raccolte di regole. Una raccolta di regole è un set di regole con lo stesso ordine e priorità. Le raccolte di regole vengono eseguite in ordine di priorità. Le raccolte regole DNAT hanno priorità più alta rispetto alle raccolte di regole di rete, che a loro volta hanno priorità più alta rispetto alle raccolte di regole dell'applicazione. L'elaborazione delle regole non avviene a ciclo continuo.

Sono disponibili tre tipi di raccolte di regole:

• Regole dell'applicazione: configurare nomi di dominio completi (FQDN) a cui è possibile accedere da una rete virtuale.
• Regole di rete: configurare regole con indirizzi di origine, protocolli, porte di destinazione e indirizzi di destinazione.
• Regole NAT: configurare le regole DNAT per consentire connessioni Internet o Intranet in ingresso (anteprima).

Per altre informazioni, vedere Configurare le regole di Azure Firewall.

Azure Firewall si integra con Azure Monitor per la visualizzazione e l'analisi dei log. I log possono essere inviati a Log Analytics, Azure Storage o Hub eventi e analizzati usando strumenti come Log Analytics, Excel o Power BI. Per altre informazioni, vedere Tutorial: Monitorare i log Azure Firewall.

Azure Firewall è un servizio di sicurezza di rete gestito basato sul cloud che protegge le risorse della rete virtuale. È un firewall con stato completo distribuito come servizio con disponibilità elevata e scalabilità cloud senza limiti. È preintegrato con provider di sicurezza come servizio (SECaaS) di terze parti per migliorare la sicurezza per la rete virtuale e le connessioni Internet di succursale. Per altre informazioni, vedere Azure sicurezza di rete.

Il WAF del gateway delle applicazioni offre una protezione in ingresso centralizzata per le applicazioni web contro exploit e vulnerabilità comuni. Azure Firewall fornisce protezione in ingresso per i protocolli non HTTP/S (ad esempio, RDP, SSH, FTP), la protezione a livello di rete in uscita per tutte le porte e i protocolli e la protezione a livello di applicazione per HTTP/S in uscita.

Azure Firewall integra i gruppi di sicurezza di rete per offrire una migliore sicurezza di rete "difesa avanzata". Gli NSG offrono un filtro del traffico a livello di rete distribuito per limitare il traffico all'interno delle reti virtuali in ogni sottoscrizione. Azure Firewall offre una rete centralizzata e completamente con stato e una protezione a livello di applicazione tra sottoscrizioni e reti virtuali.

Azure Firewall è un servizio gestito con più livelli di protezione, inclusa la protezione della piattaforma con NSG (gruppi di sicurezza di rete) a livello di scheda di interfaccia di rete (non visibili). I gruppi di sicurezza di rete a livello di subnet non sono necessari in AzureFirewallSubnet e sono disabilitati per evitare interruzioni del servizio.

Gli endpoint privati sono un componente di Private Link, una tecnologia che consente di interagire con i servizi PaaS Azure usando indirizzi IP privati anziché quelli pubblici. Azure Firewall può essere usato per impedire l'accesso agli indirizzi IP pubblici, evitando quindi l'esfiltrazione di dati ai servizi Azure non sfruttando Private Link, nonché per implementare criteri senza attendibilità definendo chi nell'organizzazione deve accedere a tali servizi PaaS Azure, dal momento che Private Link Per impostazione predefinita viene aperto l'accesso alla rete per l'intera rete aziendale.

La progettazione corretta per esaminare il traffico verso endpoint privati con Azure Firewall dipende dall'architettura di rete, è possibile trovare altri dettagli nell'articolo Azure Firewall scenari per esaminare il traffico destinato a un endpoint privato.

Virtual Network gli endpoint di servizio sono un'alternativa a Private Link per controllare l'accesso di rete ai servizi PaaS Azure. Anche se il client usa ancora indirizzi IP pubblici per accedere al servizio PaaS, la subnet di origine viene resa visibile in modo che il servizio PaaS di destinazione possa implementare regole di filtro e limitare l'accesso per ogni subnet. È possibile trovare un confronto dettagliato tra entrambi i meccanismi in Confrontare endpoint privati ed endpoint di servizio.

Azure Firewall regole dell'applicazione possono essere usate per assicurarsi che non venga eseguita alcuna esfiltrazione di dati ai servizi non autorizzati e implementare criteri di accesso con una maggiore granularità oltre il livello di subnet. In genere, gli endpoint servizio di rete virtuale devono essere abilitati nella subnet del client che si connetterà a un servizio Azure. Tuttavia, quando si esamina il traffico verso gli endpoint di servizio con Azure Firewall, è necessario abilitare l'endpoint corrispondente del servizio nella subnet di Azure Firewall e disabilitarlo sulla subnet del client effettivo (in genere una rete virtuale spoke). In questo modo è possibile usare le regole dell'applicazione in Azure Firewall per controllare a quali servizi Azure i carichi di lavoro Azure avranno accesso.

Per informazioni dettagliate sui prezzi, vedere Prezzi di Azure Firewall.

Per i limiti del servizio, vedere Azure sottoscrizione e limiti del servizio, quote e vincoli.

Azure Firewall non sposta o archivia i dati dei clienti all'esterno dell'area in cui viene distribuita.

No, Azure Firewall negli hub virtuali protetti (vWAN) non è attualmente supportato in Qatar.

Sì, Azure Firewall supporta sia il filtro del traffico in ingresso che quello in uscita. Il filtro in ingresso viene in genere usato per protocolli non HTTP, ad esempio RDP, SSH e FTP. Per il traffico HTTP e HTTPS in ingresso, è consigliabile usare un web application firewall come Azure Web Application Firewall (WAF) o l'offload TLS e le funzionalità di ispezione approfondita dei pacchetti di Azure Firewall Premium.

Sì, Azure Firewall Basic supporta il tunneling forzato.

Un ping TCP non si connette effettivamente al nome di dominio completo di destinazione. Azure Firewall blocca le connessioni a qualsiasi indirizzo IP o FQDN di destinazione, a meno che non sia esplicitamente consentito da una regola.

Nel caso di un ping TCP, se nessuna regola consente il traffico, il firewall stesso risponde alla richiesta ping TCP del client. Questa risposta non raggiunge l'indirizzo IP o il nome di dominio completo di destinazione e non viene registrato. Se una regola di rete consente esplicitamente l'accesso all'indirizzo IP o al nome di dominio completo di destinazione, la richiesta ping raggiunge il server di destinazione e la risposta viene inoltrata al client. Questo evento viene registrato nel log delle regole di rete.

No, Azure Firewall non supporta il peering BGP in modo nativo. Tuttavia, la funzionalità Autolearn route SNAT usa indirettamente BGP tramite Azure Route Server.

Azure Firewall non supporta in modo nativo ESP (Incapsuling Security Payload), ma è possibile consentire il traffico ESP configurando una regola di rete come indicato di seguito:

configurazione Azure Firewall (regola di rete):

• Protocollo: qualsiasi
• Porta di origine: * (Qualsiasi)
• Porta di destinazione: * (Qualsiasi)
• Origine/Destinazione: specificare gli indirizzi IP in base alle esigenze

Questa configurazione consente ai pacchetti ESP (numero di protocollo IP 50) e ad altri traffico non TCP/UDP di corrispondere alla regola. Si noti tuttavia che Azure Firewall non controlla i payload ESP.

Reference: se si usa un gruppo di sicurezza di rete (gruppo di sicurezza di rete) anziché Azure Firewall: NSG non fornisce un'opzione diretta per specificare ESP (numero di protocollo IP 50), ma i pacchetti ESP possono essere consentiti usando le impostazioni seguenti:

• Protocollo: qualsiasi
• Porta: * (Qualsiasi)
• Origine/Destinazione: specificare gli indirizzi IP in base alle esigenze

Raccomandazioni:

• Per le configurazioni VPN IPsec, è consigliabile usare Azure VPN Gateway.
• Prendere in considerazione l'uso di un modello di appliance virtuale di rete (NVA) a seconda dei requisiti.

È possibile usare Azure PowerShell per deallocare e allocare il Azure Firewall. Il processo varia a seconda della configurazione.

Per un firewall senza una scheda di interfaccia di rete di gestione:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

Per un firewall con una scheda di interfaccia di rete di gestione:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Per un firewall in un hub virtuale protetto:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

È consigliabile configurare le zone di disponibilità durante la distribuzione iniziale. Tuttavia, è possibile riconfigurarli dopo la distribuzione se:

• Il firewall viene distribuito in una rete virtuale (non supportato negli hub virtuali protetti).
• La regione supporta le zone di disponibilità.
• Tutti gli indirizzi IP pubblici collegati sono configurati con le stesse zone.

Per riconfigurare le zone di disponibilità:

1. Deallocare il firewall:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. Aggiornare la configurazione della zona e allocare il firewall:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Sì:

• Il Azure Firewall e la rete virtuale devono trovarsi nello stesso gruppo di risorse.
• L'indirizzo IP pubblico può trovarsi in un gruppo di risorse diverso.
• Tutte le risorse (firewall Azure, rete virtuale, IP pubblico) devono trovarsi nella stessa sottoscrizione.

Uno stato di approvvigionamento non riuscito indica che un aggiornamento della configurazione non è riuscito in una o più istanze back-end. Il Azure Firewall rimane operativo, ma la configurazione potrebbe non essere coerente. Ripetere l'aggiornamento fino a quando lo stato di provisioning non viene modificato in Operazione completata.

Azure Firewall usa una configurazione attiva-attiva con più nodi backend. Durante la manutenzione pianificata, il drenaggio delle connessioni garantisce aggiornamenti senza interruzioni. Per gli errori non pianificati, un nuovo nodo sostituisce quello non riuscito e la connettività viene in genere ripristinata entro 10 secondi.

Sì, i nomi del firewall sono limitati a 50 caratteri.

Una subnet /26 garantisce indirizzi IP sufficienti per il ridimensionamento, in quanto l’Azure Firewall effettua il provisioning di istanze di macchine virtuali aggiuntive.

No, una subnet /26 è sufficiente per tutti gli scenari di ridimensionamento.

Azure Firewall ridimensiona automaticamente in base all'utilizzo della CPU, alla velocità effettiva e al numero di connessioni. La capacità di velocità effettiva varia da 2,5 a 3 Gbps inizialmente a 30 Gbps (SKU Standard) o da 100 Gbps (SKU Premium).

Sì. Per informazioni dettagliate, vedere Azure sottoscrizione e limiti del servizio, quote e vincoli.

No, lo spostamento di un gruppo IP in un altro gruppo di risorse non è attualmente supportato.

Un comportamento standard di un firewall di rete è garantire che le connessioni TCP siano mantenute attive e chiuderle tempestivamente in assenza di attività. Il timeout di inattività TCP di Azure Firewall è di quattro minuti. Questa impostazione non è configurabile dall'utente, ma è possibile contattare Azure supporto tecnico per aumentare il timeout di inattività per le connessioni in ingresso e in uscita fino a 15 minuti. Il timeout di inattività per il traffico est-ovest non può essere modificato.

Se un periodo di inattività è più lungo del valore di timeout, non vi sono garanzie che venga mantenuta la sessione TCP o HTTP. Una prassi comune consiste nell'usare un meccanismo TCP keep-alive. Questa pratica mantiene la connessione attiva per un periodo più lungo. Per altre informazioni, vedere gli esempi .NET.

Sì, ma è necessario configurare il firewall in modalità Tunneling forzato. Questa configurazione crea un'interfaccia di gestione con un indirizzo IP pubblico usato da Azure Firewall per le operazioni. Tale indirizzo IP pubblico è destinato al traffico di gestione. Viene usato esclusivamente dalla piattaforma Azure e non può essere usato per altri scopi. La rete del percorso dati del tenant può essere configurata senza un indirizzo IP pubblico ed è possibile forzare il tunneling del traffico Internet verso un altro firewall o bloccarlo completamente.

Sì. Per ulteriori informazioni, consultare Backup di Azure Firewall e dei criteri di Azure Firewall con le App di Logica.

Per l'accesso sicuro ai servizi PaaS, è consigliabile usare gli endpoint di servizio. È possibile scegliere di abilitare gli endpoint di servizio nella subnet Azure Firewall e disabilitarli nelle reti virtuali spoke connesse. In questo modo è possibile sfruttare entrambe le funzionalità, ovvero sicurezza degli endpoint di servizio e registrazione centrale per tutto il traffico.

Sì, è possibile usare Azure Firewall in una rete virtuale hub per instradare e filtrare il traffico tra più reti virtuali spoke. Per il corretto funzionamento di questo scenario, le subnet in ognuna delle reti virtuali spoke devono avere una UDR che punti all'Azure Firewall come gateway predefinito.

Sì. Tuttavia, la configurazione delle UDRs per reindirizzare il traffico tra sottoreti nella stessa rete virtuale richiede maggiore attenzione. Anche se utilizzare l'intervallo degli indirizzi di rete virtuale come prefisso di destinazione per l'UDR è sufficiente, ciò comporta anche l'instradamento di tutto il traffico da un computer a un altro nella stessa subnet attraverso l'istanza di Azure Firewall. Per evitare questo problema, includere una route per la subnet nell'UDR con un tipo di hop successivo di rete virtuale. La gestione di queste route può essere complessa e soggetta a errori. Il metodo consigliato per la segmentazione della rete interna prevede l'uso di gruppi di sicurezza di rete, che non richiedono routing definiti dall'utente.

Azure Firewall non esegue SNAT quando l'indirizzo IP di destinazione è un intervallo IP privato per IANA RFC 1918 o IANA RFC 6598 per le reti private. Se l'organizzazione utilizza un intervallo di indirizzi IP pubblici per le reti private, Azure Firewall esegue il SNAT del traffico verso uno degli indirizzi IP privati del firewall in AzureFirewallSubnet. È possibile configurare Azure Firewall affinché non effettui SNAT sulla gamma di indirizzi IP pubblici. Per ulteriori informazioni, vedere gli intervalli di indirizzi IP privati SNAT del Firewall di Azure.

Inoltre, al traffico elaborato dalle regole dell'applicazione viene sempre applicata la conversione SNAT. Se si desidera visualizzare l'indirizzo IP sorgente originale nei log relativi al traffico FQDN, è possibile utilizzare le regole di rete con il nome FQDN di destinazione.

Il tunneling forzato è supportato quando si crea un nuovo firewall ed è supportato anche per i firewall esistenti aggiungendo una scheda di interfaccia di rete di gestione per il tunneling forzato. Per ulteriori dettagli sulle nuove distribuzioni, consultare Azure Firewall tunnel forzato. Per i firewall esistenti, vedere Azure Firewall Management NIC.

Azure Firewall deve avere connettività Internet diretta. Se AzureFirewallSubnet apprende una route predefinita alla rete locale tramite BGP è necessario sostituirla con una route UDR 0.0.0.0/0 con il valore NextHopType impostato come Internet per mantenere connettività diretta a Internet.

Se la configurazione richiede il tunneling forzato in una rete locale ed è possibile determinare i prefissi IP di destinazione per le destinazioni Internet, è possibile configurare questi intervalli con la rete locale come hop successivo tramite una route definita dall'utente in AzureFirewallSubnet. In alternativa, per definire queste route, è possibile usare BGP.

• URL : gli asterischi funzionano quando vengono posizionati sul lato più a destra o a sinistra. Se si trova a sinistra, non può far parte del FQDN.
• FQDN : gli asterischi funzionano quando vengono posizionati sul lato più a sinistra.
• GENERALE - Gli asterischi sul lato sinistro indicano letteralmente che qualsiasi cosa a sinistra corrisponde, cioè vengono abbinati più sottodomini e/o possibili varianti indesiderate di nomi di dominio. Vedere gli esempi seguenti.

Esempi:

No. Azure Firewall blocca l'accesso Active Directory per impostazione predefinita. Per consentire l'accesso, configurare il tag del servizio AzureActiveDirectory. Per altre informazioni, vedere tag del servizio Azure Firewall.

Sì, è possibile usare Azure PowerShell per farlo:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Un ping TCP non si connette effettivamente al nome di dominio completo di destinazione. Azure Firewall non consente una connessione a un indirizzo IP/FQDN di destinazione, a meno che non esista una regola esplicita che lo consenta.

Il ping TCP è un caso d'uso univoco in cui, se non esiste alcuna regola consentita, il firewall stesso risponde alla richiesta di ping TCP del client anche se il ping TCP non raggiunge l'indirizzo IP o il nome di dominio completo della destinazione. In questo caso, l'evento non viene registrato. Se esiste una regola di rete che consente l'accesso all'indirizzo IP o al nome di dominio completo di destinazione, la richiesta di ping raggiunge il server di destinazione e la sua risposta viene inoltrata al di nuovo al client. Questo evento viene registrato nel log delle regole di rete.

Sì. Per altre informazioni, vedere sottoscrizione di Azure e limiti, quote e vincoli del servizio

No, lo spostamento di un gruppo IP in un altro gruppo di risorse non è attualmente supportato.

Un comportamento standard di un firewall di rete è garantire che le connessioni TCP siano mantenute attive e chiuderle tempestivamente in assenza di attività. Il timeout di inattività TCP di Azure Firewall è di quattro minuti. Questa impostazione non è configurabile dall'utente, ma è possibile contattare Azure supporto tecnico per aumentare il timeout di inattività per le connessioni in ingresso e in uscita fino a 15 minuti. Il timeout di inattività per il traffico est-ovest non può essere modificato.

Se un periodo di inattività è più lungo del valore di timeout, non vi sono garanzie che venga mantenuta la sessione TCP o HTTP. Una prassi comune consiste nell'usare un meccanismo TCP keep-alive. Questa pratica mantiene la connessione attiva per un periodo più lungo. Per altre informazioni, vedere gli esempi .NET.

Sì, ma è necessario configurare il firewall in modalità Tunneling forzato. Questa configurazione crea un'interfaccia di gestione con un indirizzo IP pubblico usato da Azure Firewall per le operazioni. Tale indirizzo IP pubblico è destinato al traffico di gestione. Viene usato esclusivamente dalla piattaforma Azure e non può essere usato per altri scopi. La rete del percorso dati del tenant può essere configurata senza un indirizzo IP pubblico ed è possibile forzare il tunneling del traffico Internet verso un altro firewall o bloccarlo completamente.

Azure Firewall non sposta o archivia i dati dei clienti dall'area in cui viene distribuita.

Sì. Per ulteriori informazioni, consultare Backup di Azure Firewall e dei criteri di Azure Firewall con le App di Logica.

No, attualmente Azure Firewall negli hub virtuali protetti (vWAN) non è supportato in Qatar.

Azure Firewall usa Azure Virtual Machines sottostanti che hanno un numero massimo di connessioni. Il numero totale di connessioni attive per ogni macchina virtuale è 250.000.

Il limite totale per ogni firewall corrisponde al limite di connessioni della macchina virtuale (250.000) x il numero di macchine virtuali nel pool back-end del firewall. Azure Firewall inizia con due macchine virtuali e aumenta il numero di istanze in base all'utilizzo e alla velocità effettiva della CPU.

Azure Firewall attualmente usa porte di origine TCP/UDP per il traffico SNAT in uscita, senza tempi di attesa inutilizzati. Quando una connessione TCP/UDP viene chiusa, la porta TCP usata viene immediatamente visualizzata come disponibile per le connessioni future.

Come soluzione alternativa per determinate architetture, è possibile distribuire e ridimensionare con NAT Gateway con Azure Firewall per offrire un pool più ampio di porte SNAT per la variabilità e la disponibilità.

I comportamenti specifici di NAT dipendono dalla configurazione del firewall e dal tipo di NAT configurato. Ad esempio, il firewall dispone di regole DNAT per il traffico in ingresso, nonché di regole di rete e regole di applicazione per il traffico in uscita tramite il firewall.

Per ulteriori informazioni, vedere Comportamenti NAT di Azure Firewall.

Per ogni manutenzione pianificata, la logica di svuotamento delle connessioni aggiorna correttamente i nodi back-end. Azure Firewall attende 90 secondi per la chiusura delle connessioni esistenti. Nei primi 45 secondi, il nodo back-end non accetta nuove connessioni e nel tempo rimanente risponde con RST a tutti i pacchetti in ingresso. Se necessario, i client possono ristabilire automaticamente la connettività a un altro nodo back-end.

Un arresto dell'istanza di macchina virtuale Azure Firewall può verificarsi durante il ridimensionamento (riduzione) del set di macchine virtuali o durante l'aggiornamento del software del parco. In questi casi, il carico delle nuove connessioni in ingresso viene bilanciato rispetto alle istanze del firewall rimanenti e le nuove connessioni non vengono inoltrate all'istanza del firewall inattiva. Dopo 45 secondi, il firewall inizia a rifiutare le connessioni esistenti inviando pacchetti TCP RST. Dopo altri 45 secondi, la macchina virtuale del firewall viene arrestata. Per altre informazioni, vedere Load Balancer TCP Reset and Idle Timeout.

Azure Firewall ridimensiona gradualmente quando la velocità effettiva media o il consumo di CPU è pari a 60%oppure il numero di connessioni è pari a 80%. Ad esempio, inizia a ridimensionarsi quando raggiunge il 60% della sua massima capacità di elaborazione. I numeri di throughput massimo variano in base all'SKU di Azure Firewall e alle funzionalità abilitate. Per altre informazioni, vedere prestazioni di Azure Firewall.

L'aumento delle istanze richiede da cinque a sette minuti. Quando si esegue il test delle prestazioni, assicurarsi di testare almeno da 10 a 15 minuti e avviare nuove connessioni per sfruttare i vantaggi dei nuovi nodi Azure Firewall creati.

Quando una connessione ha un timeout di inattività (quattro minuti di nessuna attività), Azure Firewall termina normalmente la connessione inviando un pacchetto TCP RST.

Azure i servizi vengono sottoposti a aggiornamenti di manutenzione regolari per migliorare funzionalità, affidabilità, prestazioni e sicurezza. Con un periodo di manutenzione configurato, la manutenzione del sistema operativo guest e la manutenzione del servizio vengono eseguite durante tale finestra. Tuttavia, la manutenzione controllata dal cliente non include aggiornamenti dell'host o aggiornamenti critici della sicurezza.

Le notifiche avanzate per Azure Firewall manutenzione non sono disponibili.

No, è necessaria una finestra di manutenzione minima di cinque ore.

No, le finestre di manutenzione sono attualmente configurate per ripetersi quotidianamente.

La manutenzione controllata dal cliente supporta gli aggiornamenti del sistema operativo e del servizio guest, che rappresentano la maggior parte degli elementi di manutenzione che interessano i clienti. Tuttavia, alcuni aggiornamenti, ad esempio gli aggiornamenti host, non rientrano nell'ambito della manutenzione controllata dal cliente. In rari casi, è possibile eseguire l'override del controllo della finestra di manutenzione per risolvere i problemi di sicurezza con gravità elevata.

Sì.

No. Attualmente, è possibile associare una sola configurazione di manutenzione a un Azure Firewall.

Tutti gli SKU Azure Firewall- Basic, Standard e Premium supportano la manutenzione controllata dal cliente.

Potrebbe essere necessario un massimo di 24 ore affinché l'Azure Firewall segua il programma di manutenzione dopo l'associazione della politica di manutenzione.

Le attività di manutenzione sul Azure Firewall non vengono sospese durante il periodo precedente alla finestra di manutenzione pianificata. Per i giorni non inclusi nella pianificazione della manutenzione, le normali operazioni di manutenzione continuano come di consueto nella risorsa.

Per altre informazioni, vedere Configurare la manutenzione controllata dal cliente.