Azure Firewall FAQ

Azure Firewall é um serviço de segurança de rede gerido e baseado na cloud que protege os seus recursos do Azure Virtual Network. É um serviço de firewall totalmente com estado, com alta disponibilidade integrada e escalabilidade irrestrita na nuvem. Pode criar, impor e registar centralmente políticas de conectividade de rede e aplicações entre subscrições e redes virtuais.

Para uma lista detalhada das funcionalidades do Azure Firewall, veja funcionalidades do Azure Firewall.

O Azure Firewall pode ser implementado em qualquer rede virtual. No entanto, é normalmente implantado numa rede virtual central utilizando um modelo de "hub-and-spoke", com outras redes virtuais conectadas a ela. A rota padrão das redes virtuais emparelhadas é definida para apontar para essa rede virtual de firewall central. Embora o emparelhamento de rede virtual global seja suportado, ele não é recomendado devido a possíveis problemas de desempenho e latência entre regiões. Para um desempenho ideal, implante um firewall por região.

Esse modelo permite o controle centralizado sobre VNets spoke múltiplas em diferentes assinaturas e oferece economia de custos pela eliminação da necessidade de implantar um firewall em cada rede virtual. As economias de custos devem ser avaliadas em relação aos custos de peering associados com base nos padrões de tráfego.

O Azure Firewall pode ser implementado usando o portal Azure, PowerShell, REST API ou templates. Para instruções passo a passo, veja Tutorial: Deploye e configure Azure Firewall usando o portal Azure.

O Azure Firewall usa regras e coleções de regras. Uma coleção de regras é um conjunto de regras com a mesma ordem e prioridade. As coleções de regras são executadas em ordem de prioridade. As coleções de regras DNAT têm prioridade maior do que as coleções de regras de rede, que, por sua vez, têm prioridade maior do que as coleções de regras de aplicativo. Todas as regras estão terminando.

Existem três tipos de coleções de regras:

• Regras de aplicação: Configure nomes de domínio totalmente qualificados (FQDNs) que possam ser acedidos a partir de uma rede virtual.
• Regras de rede: Configurar regras com endereços de origem, protocolos, portas de destino e endereços de destino.
• Regras NAT: Configure as regras DNAT para permitir a entrada de ligações à Internet ou à intranet (pré-visualização).

Para mais informações, consulte Configurar regras do Azure Firewall.

O Azure Firewall integra-se com o Azure Monitor para visualização e análise de registos. Os registos podem ser enviados para Log Analytics, Azure Storage ou Event Hubs e analisados usando ferramentas como Log Analytics, Excel ou Power BI. Para mais informações, consulte o Tutorial: Monitorizar os registos do Azure Firewall.

Azure Firewall é um serviço gerido de segurança de rede baseado na cloud que protege recursos virtuais de rede. É um serviço de firewall totalmente com estado, com alta disponibilidade integrada e escalabilidade irrestrita na nuvem. Ele é pré-integrado com provedores de segurança como serviço (SECaaS) de terceiros para melhorar a segurança de conexões de rede virtual e de filiais à Internet. Para mais informações, consulte Azure segurança de rede.

O WAF do Application Gateway fornece proteção de entrada centralizada para aplicativos Web contra exploits e vulnerabilidades comuns. O Azure Firewall fornece proteção de entrada para protocolos não-HTTP/S (por exemplo, RDP, SSH, FTP), proteção ao nível da rede de saída para todas as portas e protocolos, e proteção ao nível da aplicação para HTTP/S de saída.

O Azure Firewall complementa os NSGs para proporcionar uma melhor segurança de rede através da "defesa em camadas". Os NSGs oferecem filtragem de tráfego de camada de rede distribuída para limitar o tráfego dentro de redes virtuais em cada assinatura. O Azure Firewall fornece proteção centralizada e totalmente de estado ao nível da rede e da aplicação entre subscrições e redes virtuais.

Azure Firewall é um serviço gerido com múltiplas camadas de proteção, incluindo proteção de plataforma com NSGs ao nível de NIC (não visualizável). NSGs no nível de sub-rede não são necessários na AzureFirewallSubnet e são desabilitados para evitar interrupções de serviço.

Os endpoints privados são um componente do Private Link, uma tecnologia que permite interagir com serviços PaaS do Azure usando endereços IP privados em vez de públicos. O Azure Firewall pode ser usado para impedir o acesso a endereços IP públicos, evitando assim a exfiltração de dados para serviços Azure que não utilizam o Private Link, bem como para implementar políticas de zero-trust definindo quem na sua organização precisa de aceder a esses serviços PaaS do Azure, já que o Private Link Por defeito, abre o acesso à rede para toda a tua rede corporativa.

O design correto para inspecionar tráfego para endpoints privados com Azure Firewall dependerá da sua arquitetura de rede; pode encontrar mais detalhes no artigo Azure Firewall cenários para inspecionar tráfego destinado a um endpoint privado.

Os endpoints de serviço Virtual Network são uma alternativa ao Private Link para controlar o acesso de rede aos serviços PaaS do Azure. Mesmo que o cliente ainda use endereços IP públicos para acessar o serviço PaaS, a sub-rede de origem será tornada visível para que o serviço PaaS de destino possa implementar regras de filtro e restringir o acesso por sub-rede. Pode encontrar uma comparação detalhada entre ambos os mecanismos em Comparar Endpoints Privados e Endpoints de Serviço.

As regras de aplicação do Azure Firewall podem ser usadas para garantir que não ocorre qualquer exfiltração de dados para serviços maliciosos e para implementar políticas de acesso com maior granularidade para além do nível da subrede. Normalmente, os endpoints de serviço de rede virtual precisam de estar ativados na sub-rede do cliente que se irá ligar a um serviço Azure. No entanto, ao inspecionar o tráfego para endpoints de serviço com o Azure Firewall, é necessário ativar o endpoint de serviço correspondente na sub-rede do Azure Firewall; e desativá-lo na sub-rede do cliente real (normalmente uma rede virtual spoke). Desta forma, pode usar as Regras de Aplicação no Azure Firewall para controlar a que serviços do Azure as suas cargas de trabalho do Azure terão acesso.

Para detalhes sobre preços, consulte Azure Firewall Preços.

Para limites de serviço, veja Azure limites de subscrição e serviço, quotas e restrições.

O Azure Firewall não move nem armazena dados de clientes para fora da região onde está implementado.

Não, o Azure Firewall em hubs virtuais seguros (vWAN) não é atualmente suportado no Qatar.

Sim, o Azure Firewall suporta tanto filtragem de tráfego de entrada como de saída. A filtragem de entrada é normalmente usada para protocolos não-HTTP, como RDP, SSH e FTP. Para tráfego HTTP e HTTPS de entrada, considere usar um firewall de aplicações web como Azure Web Application Firewall (WAF) ou as funcionalidades TLS de offload e inspeção profunda de pacotes do Azure Firewall Premium.

Sim, o Azure Firewall Basic suporta tunelamento forçado.

Na verdade, um ping TCP não se conecta ao FQDN de destino. O Azure Firewall bloqueia ligações a qualquer endereço IP alvo ou FQDN, a menos que seja explicitamente permitido por uma regra.

No caso de um ping TCP, se nenhuma regra permitir o tráfego, o próprio Firewall responderá à solicitação de ping TCP do cliente. Essa resposta não atinge o endereço IP ou FQDN de destino e não é registrada. Se uma regra de rede permitir explicitamente o acesso ao endereço IP ou FQDN de destino, a solicitação de ping chegará ao servidor de destino e sua resposta será retransmitida de volta ao cliente. Esse evento é registrado no log de regras de rede.

Não, o Firewall do Azure não suporta nativamente o peering BGP. No entanto, a funcionalidade Autolearn de rotas SNAT utiliza indiretamente BGP através do Azure Route Server.

O Azure Firewall não suporta nativamente ESP (Encapsulating Security Payload), mas pode permitir tráfego ESP configurando uma regra de rede da seguinte forma:

Configuração de Firewall do Azure (Regra de Rede):

• Protocolo: qualquer
• Port de origem: * (Qualquer)
• Porto de destino: * (Qualquer)
• Origem/Destino: Especifique endereços IP conforme necessário

Esta configuração permite que pacotes ESP (número de protocolo IP 50) e outro tráfego não TCP/UDP correspondam à regra. No entanto, note que o Azure Firewall não inspeciona payloads ESP.

Reference : Se usar NSG (Network Security Group) em vez de Azure Firewall: o NSG não oferece uma opção direta para especificar ESP (número do protocolo IP 50), mas os pacotes ESP podem ser permitidos usando as seguintes definições:

• Protocolo: qualquer
• Porto: * (Qualquer)
• Origem/Destino: Especifique endereços IP conforme necessário

Recommendations:

• Para configurações de VPN IPsec, recomenda-se o uso do Azure VPN Gateway.
• Considere usar um padrão NVA (Network Virtual Appliance) dependendo das suas necessidades.

Pode usar o Azure PowerShell para desalocar e alocar o Azure Firewall. O processo varia dependendo da configuração.

Para um firewall sem uma NIC de gestão:

# 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

Para um firewall com uma NIC de gestão:

# 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

Para um firewall num hub virtual seguro:

# 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

É recomendável configurar zonas de disponibilidade durante a implantação inicial. No entanto, você pode reconfigurá-los após a implantação se:

• O firewall é implantado em uma rede virtual (não suportado em hubs virtuais seguros).
• A região suporta zonas de disponibilidade.
• Todos os endereços IP públicos anexados são configurados com as mesmas zonas.

Para reconfigurar zonas de disponibilidade:

1. Desalocar o firewall:

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

2. Atualize a configuração da zona e aloque o 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
   

Sim:

• O Azure Firewall e a rede virtual devem estar no mesmo grupo de recursos.
• O endereço IP público pode estar em um grupo de recursos diferente.
• Todos os recursos (firewall Azure, rede virtual, IP público) devem estar na mesma subscrição.

Um estado de provisionamento falhado indica que uma atualização de configuração falhou numa ou mais instâncias backend. O Azure Firewall mantém-se operacional, mas a configuração pode ser inconsistente. Tente novamente a atualização até que o estado de provisionamento mude para Sucesso.

O firewall do Azure utiliza uma configuração ativo-ativo com múltiplos nós de retaguarda. Durante a manutenção planeada, o esvaziamento de ligações garante atualizações sem interrupção. Para falhas não planejadas, um novo nó substitui o falhado e a conectividade normalmente é restaurada em 10 segundos.

Sim, os nomes de firewall são limitados a 50 caracteres.

Uma sub-rede /26 garante endereços IP suficientes para escalabilidade, à medida que o Azure Firewall fornece instâncias adicionais de máquinas virtuais.

Não, uma sub-rede /26 é suficiente para todos os cenários de dimensionamento.

O Azure Firewall escala automaticamente com base no uso da CPU, throughput e número de ligações. A capacidade de taxa de transferência varia de 2,5 a 3 Gbps inicialmente a 30 Gbps (SKU Padrão) ou 100 Gbps (SKU Premium).

Sim. Para mais detalhes, consulte Azure limites de subscrição e serviços, quotas e restrições.

Não, não há suporte para mover um grupo IP para outro grupo de recursos no momento.

Um comportamento padrão de um firewall de rede é garantir que as conexões TCP sejam mantidas ativas e fechá-las imediatamente se não houver atividade. Azure Firewall TCP Idle Timeout é de quatro minutos. Esta configuração não é configurável pelo utilizador, mas pode contactar o Suporte do Azure para aumentar o tempo de espera para ligações de entrada e saída até 15 minutos. O tempo limite ocioso para o tráfego leste-oeste não pode ser alterado.

Se um período de inatividade for maior do que o valor de tempo limite, não há garantia de que a sessão TCP ou HTTP seja mantida. Uma prática comum é usar o TCP Keep-Alive. Essa prática mantém a conexão ativa por um período mais longo. Para mais informações, consulte os exemplos .NET.

Sim, mas você deve configurar o firewall no Modo de Túnel Forçado. Esta configuração cria uma interface de gestão com um endereço IP público que é utilizado pelo Azure Firewall para as suas operações. Este endereço IP público destina-se à gestão de tráfego. É usado exclusivamente pela plataforma Azure e não pode ser usado para outro propósito. A rede de caminho de dados do locatário pode ser configurada sem um endereço IP público, e o tráfego da Internet pode ser forçado a passar por túnel para outro firewall ou completamente bloqueado.

Sim. Para mais informações, consulte Backup Azure Firewall e Política do Azure Firewall com Logic Apps.

Para garantir o acesso seguro aos serviços PaaS, recomendamos a utilização de pontos de extremidade de serviço. Pode optar por ativar os endpoints de serviço na sub-rede do Azure Firewall e desativá-los nas redes virtuais de hub ligadas. Desta forma, beneficia de ambas as funcionalidades: segurança do ponto final do serviço e registo central para todo o tráfego.

Sim, pode usar o Azure Firewall numa rede virtual hub para encaminhar e filtrar o tráfego entre redes virtuais de spoke múltiplas. As sub-redes em cada uma das redes virtuais spoke devem ter um UDR apontado para o Azure Firewall como gateway predefinido para que este cenário funcione corretamente.

Sim. No entanto, configurar os UDRs para redirecionar o tráfego entre sub-redes na mesma rede virtual requer mais atenção. Embora usar o intervalo de endereços de rede virtual como prefixo de alvo para o UDR seja suficiente, isto também encaminha todo o tráfego de uma máquina para outra máquina na mesma subrede através da instância do Azure Firewall. Para evitar isto, inclua uma rota para a sub-rede no UDR com um tipo de rede virtual do tipo next hop. O gerenciamento dessas rotas pode ser complicado e propenso a erros. O método recomendado para segmentação de rede interna é usar grupos de segurança de rede, que não exigem UDRs.

Azure Firewall não faz SNAT quando o endereço IP de destino é um intervalo de IP privado segundo IANA RFC 1918 ou IANA RFC 6598 para redes privadas. Se a sua organização usar um intervalo público de endereços IP para redes privadas, o Azure Firewall SNAT o tráfego para um dos endereços IP privados do firewall no AzureFirewallSubnet. Podes configurar a Azure Firewall para não aplicar SNAT ao teu intervalo de endereços IP públicos. Para mais informações, consulte Azure Firewall SNAT intervalos de endereços IP privados.

Além disso, o tráfego processado pelas regras da aplicação é sempre submetido a SNAT. Se você quiser ver o endereço IP de origem original em seus logs para tráfego FQDN, você pode usar regras de rede com o FQDN de destino.

O tunelamento forçado é suportado na criação de um novo firewall, e também é suportado para firewalls existentes através da adição de uma NIC de gestão para tunelamento forçado. Para mais informações sobre novas implementações, consulte tuneamento forçado do Azure Firewall. Para firewalls existentes, veja Azure Firewall Management NIC.

O Azure Firewall deve ter ligação direta à Internet. Se o AzureFirewallSubnet aprender uma rota padrão para sua rede local via BGP, você deverá substituí-la por uma UDR 0.0.0.0/0 com o valor NextHopType definido como Internet para manter a conectividade direta com a Internet.

Se a sua configuração exigir um túnel forçado para uma rede on-premises e você puder determinar os prefixos IP de destino para seus destinos da Internet, pode configurar esses intervalos com a rede on-premises como o próximo salto por meio de uma rota definida pelo utilizador na AzureFirewallSubnet. Ou, você pode usar BGP para definir essas rotas.

• URL - Os asteriscos funcionam quando colocados no lado mais direito ou mais à esquerda. Se estiver à esquerda, não pode fazer parte do nome de domínio totalmente qualificado (FQDN).
• FQDN - Os asteriscos funcionam quando colocados no lado mais à esquerda.
• GERAL - Asteriscos do lado mais à esquerda significam literalmente tudo o que está à esquerda corresponde, o que significa que múltiplos subdomínios e/ou variações de nomes de domínio potencialmente indesejadas são correspondentes - consulte os exemplos seguintes.

Exemplos:

N.º O Azure Firewall bloqueia o acesso ao Active Directory por defeito. Para permitir o acesso, configure a marca de serviço AzureActiveDirectory. Para mais informações, consulte Azure Firewall etiquetas de serviço.

Sim, pode usar o Azure PowerShell para isso:

# 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

Um ping TCP não está realmente se conectando ao FQDN de destino. O Azure Firewall não permite ligação a qualquer endereço IP alvo/FQDN a menos que exista uma regra explícita que o permita.

O ping TCP é um caso de uso exclusivo em que, se não houver uma regra permitida, o próprio Firewall responde à solicitação de ping TCP do cliente, mesmo que o ping TCP não atinja o endereço IP/FQDN de destino. Nesse caso, o evento não é registrado. Se houver uma regra de rede que permita o acesso ao endereço IP de destino/FQDN, a solicitação de ping chegará ao servidor de destino e sua resposta será retransmitida de volta ao cliente. Esse evento é registrado no log de regras de rede.

Sim. Para mais informações, consulte Azure limites de subscrição e serviços, quotas e restrições

Não, não há suporte para mover um grupo IP para outro grupo de recursos no momento.

Um comportamento padrão de um firewall de rede é garantir que as conexões TCP sejam mantidas ativas e fechá-las imediatamente se não houver atividade. Azure Firewall TCP Idle Timeout é de quatro minutos. Esta configuração não é configurável pelo utilizador, mas pode contactar o Suporte do Azure para aumentar o tempo de espera para ligações de entrada e saída até 15 minutos. O tempo limite ocioso para o tráfego leste-oeste não pode ser alterado.

Se um período de inatividade for maior do que o valor de tempo limite, não há garantia de que a sessão TCP ou HTTP seja mantida. Uma prática comum é usar o TCP Keep-Alive. Essa prática mantém a conexão ativa por um período mais longo. Para mais informações, consulte os exemplos .NET.

Sim, mas você deve configurar o firewall no Modo de Túnel Forçado. Esta configuração cria uma interface de gestão com um endereço IP público que é utilizado pelo Azure Firewall para as suas operações. Este endereço IP público destina-se à gestão de tráfego. É usado exclusivamente pela plataforma Azure e não pode ser usado para outro propósito. A rede de caminho de dados do locatário pode ser configurada sem um endereço IP público, e o tráfego da Internet pode ser forçado a passar por túnel para outro firewall ou completamente bloqueado.

O Azure Firewall não move nem armazena dados de clientes para fora da região onde está implementado.

Sim. Para mais informações, consulte Backup Azure Firewall e Política do Azure Firewall com Logic Apps.

Não, atualmente o Azure Firewall em hubs virtuais seguros (vWAN) não é suportado no Qatar.

Azure Firewall usa Azure Virtual Machines abaixo que têm um número limite rígido de ligações. O número total de conexões ativas por máquina virtual é de 250k.

O limite total por firewall é o limite de conexão da máquina virtual (250k) x o número de máquinas virtuais no pool de back-end do firewall. O Azure Firewall começa com duas máquinas virtuais e faz o escalonamento baseado no uso da CPU e na largura de banda.

O Azure Firewall utiliza atualmente portas de origem TCP/UDP para tráfego SNAT de saída, sem tempo de espera ocioso. Quando uma conexão TCP/UDP é fechada, a porta TCP usada é imediatamente vista como disponível para conexões futuras.

Como solução alternativa para certas arquiteturas, pode implementar e escalar com NAT Gateway com Azure Firewall para fornecer um conjunto mais amplo de portas SNAT para variabilidade e disponibilidade.

Comportamentos NAT específicos dependem da configuração do firewall e do tipo de NAT configurado. Por exemplo, o firewall tem regras DNAT para tráfego de entrada e regras de rede e regras de aplicativo para tráfego de saída através do firewall.

Para obter mais informações, consulte Comportamentos de NAT do Azure Firewall.

Para qualquer manutenção planejada, a lógica de eliminação de conexões atualiza graciosamente os nós de backend. O Azure Firewall espera 90 segundos pelo fecho das ligações existentes. Nos primeiros 45 segundos, o nó backend não aceita novas ligações e, no tempo restante, responde a RST todos os pacotes recebidos. Se necessário, os clientes podem restabelecer automaticamente a conectividade com outro nó de back-end.

Um encerramento de instância de VM do Azure Firewall pode ocorrer durante a redução da escala do Virtual Machine Scale Set (reduzir a escala) ou durante a atualização de software da frota. Nesses casos, as novas conexões de entrada são balanceadas entre as instâncias de firewall restantes e não são encaminhadas para a instância de firewall em baixo. Após 45 segundos, o firewall começa a rejeitar conexões existentes enviando pacotes TCP RST. Após mais 45 segundos, a VM do firewall é desligada. Para obter mais informações, consulte Load Balancer TCP Reset and Idle Timeout.

Azure Firewall escala gradualmente quando a largura de banda média ou o consumo da CPU atinge 60%, ou quando o número de ligações em uso atinge 80%. Por exemplo, começa a expandir quando atinge 60% da sua capacidade máxima. Os números de rendimento máximo variam consoante o SKU do Azure Firewall e as funcionalidades ativadas. Para mais informações, consulte desempenho do Azure Firewall.

A expansão horizontal leva de cinco a sete minutos. Ao testar desempenho, certifique-se de testar durante pelo menos 10 a 15 minutos e iniciar novas ligações para tirar partido dos nós Azure Firewall recém-criados.

Quando uma ligação tem um Timeout de inatividade (quatro minutos sem atividade), o Azure Firewall termina a ligação de forma gradual enviando um pacote TCP RST.

Os serviços Azure são submetidos a atualizações regulares de manutenção para melhorar a funcionalidade, fiabilidade, desempenho e segurança. Com um período de manutenção configurado, a manutenção do SO convidado e a manutenção do serviço são realizadas durante essa janela. No entanto, a manutenção controlada pelo cliente não inclui atualizações de host ou atualizações de segurança críticas.

As notificações avançadas para manutenção do Azure Firewall não estão disponíveis.

Não, é necessária uma janela de manutenção mínima de cinco horas.

Não, as janelas de manutenção estão atualmente configuradas para se repetirem diariamente.

A manutenção controlada pelo cliente suporta SO convidado e atualizações de serviço, que representam a maioria dos itens de manutenção que preocupam os clientes. No entanto, algumas atualizações, como atualizações de host, estão fora do escopo da manutenção controlada pelo cliente. Em casos raros, podemos anular o seu controle sobre a janela de manutenção para resolver problemas de segurança de alta gravidade.

Sim.

N.º Atualmente, apenas uma configuração de manutenção pode ser associada a um Azure Firewall.

Todos os SKUs Azure Firewall - Básico, Standard e Premium suportam manutenção controlada pelo cliente.

Pode demorar até 24 horas para o Azure Firewall seguir o calendário de manutenção após a política de manutenção estar associada.

As atividades de manutenção no seu Azure Firewall não são pausadas durante o período anterior à janela de manutenção programada. Para os dias que não estão incluídos no seu cronograma de manutenção, as operações de manutenção regulares continuam como de costume no recurso.

Para mais informações, consulte Configurar manutenção controlada pelo cliente.