Domande frequenti su Firewall di Azure

Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud che consente di proteggere le risorse della rete virtuale di Azure. È 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 Firewall di Azure, vedere Funzionalità di Firewall di Azure.

Firewall di Azure può essere distribuito 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. La route predefinita dalle reti virtuali con peering è impostata in modo che punti 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 tra sottoscrizioni diverse e offre risparmi sui costi evitando la necessità di 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.

Firewall di Azure può essere distribuito usando il portale di Azure, PowerShell, l'API REST o i modelli. Per istruzioni dettagliate, vedere Esercitazione: Distribuire e configurare Firewall di Azure usando il portale di Azure.

Firewall di Azure usa regole e raccolte regole. Una raccolta di regole è un set di regole con lo stesso ordine e priorità. Le raccolte 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. Tutte le regole terminano.

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: configurano le regole DNAT per consentire connessioni Internet o Intranet (anteprima) in ingresso.

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

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

Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud che protegge le risorse di 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 network security (Sicurezza della rete di Azure).

Il WAF del gateway applicazione offre una protezione in ingresso centralizzata per le applicazioni Web da exploit e vulnerabilità comuni. Firewall di Azure fornisce la 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 tutti i protocolli e la protezione a livello di applicazione per HTTP/S in uscita.

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

Firewall di Azure è un servizio gestito con più livelli di protezione, inclusa la protezione della piattaforma con gruppi di sicurezza di rete a livello di scheda di interfaccia di rete (non visualizzabili). 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 del collegamento privato, una tecnologia che consente di interagire con i servizi PaaS di Azure usando indirizzi IP privati anziché quelli pubblici. Firewall di Azure può essere usato per impedire l'accesso agli indirizzi IP pubblici, evitando quindi l'esfiltrazione dei dati ai servizi di Azure non sfruttando il collegamento privato, nonché per implementare criteri senza attendibilità definendo chi nell'organizzazione deve accedere a tali servizi PaaS di Azure, poiché il collegamento privato per impostazione predefinita apre l'accesso alla rete per l'intera rete aziendale.

La progettazione corretta per esaminare il traffico verso endpoint privati con Firewall di Azure dipende dall'architettura di rete. Per altri dettagli, vedere l'articolo Scenari di Firewall di Azure per esaminare il traffico destinato a un endpoint privato.

Gli endpoint servizio di rete virtuale sono un'alternativa al collegamento privato per controllare l'accesso di rete ai servizi PaaS di 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.

Le regole dell'applicazione di Firewall di Azure 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 di Azure. Tuttavia, quando si esamina il traffico verso gli endpoint di servizio con Firewall di Azure, è necessario abilitare l'endpoint di servizio corrispondente nella subnet di Firewall di Azure e disabilitarli nella subnet del client effettivo (in genere una rete virtuale spoke). In questo modo è possibile usare le regole dell'applicazione in Firewall di Azure per controllare i servizi di Azure a cui avranno accesso i carichi di lavoro di Azure.

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

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

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

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

Sì, Firewall di Azure 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 Web application firewall (WAF) di Azure o le funzionalità di offload TLS e analisi approfondita dei pacchetti di Firewall di Azure Premium.

Sì, Firewall di Azure Basic supporta il tunneling forzato.

Un ping TCP non si connette effettivamente al nome di dominio completo di destinazione. Firewall di Azure 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, Firewall di Azure non supporta in modo nativo il peering BGP. Tuttavia, la funzionalità route SNAT a livello automatico usa indirettamente BGP tramite il server di route di Azure.

È possibile usare Azure PowerShell per deallocare e allocare Firewall di Azure. 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).
• L'area 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 firewall di Azure 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 di Azure, rete virtuale, IP pubblico) devono trovarsi nella stessa sottoscrizione.

Uno stato di provisioning non riuscito indica che un aggiornamento della configurazione non è riuscito in una o più istanze back-end. Firewall di Azure 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.

Firewall di Azure usa una configurazione attiva-attiva con più nodi back-end. Durante la manutenzione pianificata, lo svuotamento delle connessioni garantisce aggiornamenti normale. 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 Firewall di Azure effettua il provisioning di istanze aggiuntive di macchine virtuali.

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

Firewall di Azure viene ridimensionato 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 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 Firewall di Azure è di quattro minuti. Questa impostazione non può essere configurata dall'utente, ma è possibile contattare il supporto tecnico di Azure per aumentare il timeout di inattività delle 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 una connessione TCP keep-alive per mantenere la connessione attiva per un periodo più lungo. Per altre informazioni, vedere gli esempi per .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 Firewall di Azure per le sue operazioni. Tale indirizzo IP pubblico è destinato al traffico di gestione. Viene usato esclusivamente dalla piattaforma di Azure e non è possibile utilizzarlo 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 altre informazioni, vedere Eseguire il backup di Firewall di Azure e dei criteri di Firewall di Azure con App per la logica.

Per l'accesso sicuro ai servizi PaaS, è consigliabile usare gli endpoint di servizio. È possibile scegliere di abilitare gli endpoint di servizio nella subnet di Firewall di Azure 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 Firewall di Azure in una rete virtuale hub per instradare e filtrare il traffico tra più reti virtuali spoke. Per il corretto funzionamento di questo scenario, alle subnet in ognuna delle reti virtuali spoke deve essere associato il routing definito dall'utente che punta verso il Firewall di Azure come gateway predefinito.

Sì. Tuttavia, la configurazione delle route definite dall'utente per reindirizzare il traffico tra subnet nella stessa rete virtuale richiede maggiore attenzione. Anche se l'uso dell'intervallo di indirizzi di rete virtuale come prefisso di destinazione per la route definita dall'utente è sufficiente, questo instrada anche tutto il traffico da un computer a un altro computer nella stessa subnet tramite l'istanza di Firewall di Azure. Per evitare questo problema, includere una route per la subnet nella route definita dall'utente 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.

Firewall di Azure non esegue SNAT quando l'indirizzo IP di destinazione è un intervallo IP privato per ogni IANA RFC 1918 o IANA RFC 6598 per reti private. Se l'organizzazione usa un intervallo di indirizzi IP pubblici per le reti private, Firewall di Azure invierà il traffico tramite SNAT a uno degli indirizzi IP privati firewall in AzureFirewallSubnet. È possibile configurare Firewall di Azure in modo da non usare SNAT per l'intervallo di indirizzi IP pubblici. Per altre informazioni, vedere Intervalli di indirizzi IP privati SNAT di Firewall di Azure.

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

Il tunneling forzato è supportato quando si crea un nuovo firewall. Non è possibile configurare un firewall esistente per il tunneling forzato. Per altre informazioni, vedere Tunneling forzato di Firewall di Azure.

Connettività diretta al Firewall di Azure. 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 se posizionati all'estrema destra o all'estrema sinistra. Se si trovano a sinistra, non possono far parte del nome FQDN.
• FQDN: gli asterischi funzionano se posizionati sul lato più a sinistra.
• GENERALE: se si usano gli asterischi nella parte sinistra, qualsiasi elemento che si trova a sinistra corrisponde, quindi anche più sottodomini e/o varianti di nomi di dominio potenzialmente indesiderate. Vedere gli esempi seguenti.

Esempi:

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

Sì, è possibile usare Azure PowerShell per eseguire questa operazione:

# 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. Firewall di Azure non consente una connessione ad alcun indirizzo IP o nome di dominio completo di destinazione, a meno che non esista una regola esplicita che lo autorizzi.

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 dei servizi.

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 Firewall di Azure è di quattro minuti. Questa impostazione non può essere configurata dall'utente, ma è possibile contattare il supporto tecnico di Azure per aumentare il timeout di inattività delle 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 una connessione TCP keep-alive per mantenere la connessione attiva per un periodo più lungo. Per altre informazioni, vedere gli esempi per .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 Firewall di Azure per le sue operazioni. Tale indirizzo IP pubblico è destinato al traffico di gestione. Viene usato esclusivamente dalla piattaforma di Azure e non è possibile utilizzarlo 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.

Firewall di Azure non sposta o archivia i dati dei clienti al di fuori dell'area in cui è distribuito.

Sì. Per altre informazioni, vedere Eseguire il backup di Firewall di Azure e dei criteri di Firewall di Azure con App per la logica.

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

Firewall di Azure usa Macchine virtuali di Azure sottostanti che dispongono di un numero di connessioni con un limite rigido. 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. Firewall di Azure inizia con due macchine virtuali e aumenta il numero di macchine virtuali in base all'utilizzo e alla velocità effettiva della CPU.

Firewall di Azure usa attualmente porte di origine TCP/UDP per il traffico SNAT in uscita, senza tempi di attesa inattivi. 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 tramite il gateway NAT con Firewall di Azure 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 altre informazioni, vedere Comportamenti di NAT di Firewall di Azure.

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

Durante la riduzione del set di scalabilità di una macchina virtuale o durante l'aggiornamento del software della flotta, è possibile che si verifichi l'arresto dell'istanza di una macchina virtuale di Firewall di Azure. 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 Reimpostazione TCP e timeout di inattività di Load Balancer.

Firewall di Azure viene ridimensionato gradualmente quando la velocità effettiva media o l'utilizzo della CPU medio è pari al 60% oppure il numero di connessioni è pari all'80%. Il ridimensionamento inizia ad esempio quando Firewall di Azure raggiunge il 60% della sua velocità effettiva massima. I numeri di velocità effettiva massima variano in base allo SKU di Firewall di Azure e alle funzionalità abilitate. Per altre informazioni, vedere Prestazioni di Firewall di Azure.

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

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

I servizi di Azure 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 la manutenzione di Firewall di Azure non sono disponibili.

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

No, le finestre di manutenzione sono attualmente configurate per la ripetizione giornaliera.

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 firewall di Azure.

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

La pianificazione della manutenzione dopo l'associazione dei criteri di manutenzione potrebbe richiedere fino a 24 ore prima che firewall di Azure segua la pianificazione della manutenzione.

Le attività di manutenzione in Firewall di Azure 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.