Perguntas frequentes sobre Firewall do Azure

Firewall do Azure é um serviço de segurança de rede gerenciado baseado em nuvem que protege seus recursos de Rede Virtual do Azure. É um firewall como serviço totalmente com estado com alta disponibilidade interna e escalabilidade de nuvem irrestrita. É possível criar, impor e registrar centralmente políticas de conectividade de rede e de aplicativo em assinaturas e redes virtuais.

Para obter uma lista detalhada dos recursos de Firewall do Azure, consulte Firewall do Azure recursos.

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

Este modelo permite o controle centralizado de várias VNets spoke em diferentes assinaturas e oferece economia de custos, evitando a necessidade de implantar um firewall em cada rede virtual. A redução de custos deve ser avaliada em relação aos custos de interconexão associados com base nos padrões de tráfego.

Firewall do Azure pode ser implantado usando o portal Azure, PowerShell, API REST ou modelos. Para obter instruções passo a passo, consulte Tutorial: implantar e configurar Firewall do Azure usando o portal Azure.

Firewall do Azure 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 sendo encerradas.

Há três tipos de coleções de regras:

• Regras de aplicativo: configure FQDNs (nomes de domínio totalmente qualificados) que podem ser acessados 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: Configurar regras DNAT para permitir conexões de entrada de Internet ou intranet (prévia).

Para obter mais informações, consulte Configure Firewall do Azure rules.

Firewall do Azure integra-se com Azure Monitor para exibir e analisar logs. Os logs podem ser enviados para Log Analytics, Armazenamento do Azure ou Hubs de Eventos e analisados usando ferramentas como Log Analytics, Excel ou Power BI. Para obter mais informações, consulte Tutorial: Monitorar logs de Firewall do Azure.

Firewall do Azure é um serviço de segurança de rede gerenciado baseado em nuvem que protege os recursos de rede virtual. É um firewall como serviço totalmente com estado com alta disponibilidade interna e escalabilidade de nuvem irrestrita. Ele é pré-integrado a provedores de segurança-como-serviço (SECaaS) de terceiros para aprimorar a segurança das conexões de rede virtual e das conexões de filial à Internet. Para obter mais informações, consulte Azure segurança de rede.

O WAF do Application Gateway fornece proteção centralizada de entrada para aplicativos web contra explorações e vulnerabilidades comuns. Firewall do Azure fornece proteção de entrada para protocolos não HTTP/S (por exemplo, RDP, SSH, FTP), proteção em nível de rede de saída para todas as portas e protocolos e proteção no nível do aplicativo para HTTP/S de saída.

Firewall do Azure complementa os NSGs para fornecer uma melhor segurança de rede através de uma abordagem de "defesa em profundidade". Os NSGs oferecem filtragem de tráfego de camada de rede distribuída para limitar o tráfego em redes virtuais em cada assinatura. Firewall do Azure fornece proteção centralizada, com estado completo, a nível de rede e de aplicação em assinaturas e redes virtuais.

Firewall do Azure é um serviço gerenciado com várias camadas de proteção, incluindo a proteção da plataforma com NSGs no nível de NIC (não visíveis). Os NSGs de nível de sub-rede não são necessários no AzureFirewallSubnet e estão desabilitados para evitar interrupções de serviço.

Os pontos de extremidade privados são um componente do Link Privado, uma tecnologia que permite interagir com serviços de PaaS Azure usando endereços IP privados em vez de públicos. Firewall do Azure pode ser usado para impedir o acesso a endereços IP públicos, evitando, portanto, a exfiltração de dados para Azure serviços que não aproveitam Link Privado, bem como para implementar políticas de confiança zero definindo quem em sua organização precisa acessar esses serviços de PaaS Azure, uma vez que Link Privado por padrão, abre o acesso à rede para toda a sua rede corporativa.

O design correto para inspecionar o tráfego para pontos de extremidade privados com Firewall do Azure dependerá da arquitetura de rede, você pode encontrar mais detalhes no artigo Firewall do Azure cenários para inspecionar o tráfego destinado a um ponto de extremidade privado.

A alternativa aos pontos de extremidade de serviço da Rede Virtual, para o controle do acesso de rede aos serviços Azure PaaS, é usar o Link Privado. Mesmo que o cliente ainda use endereços IP públicos para acessar o serviço PaaS, a sub-rede de origem ficará visível para que o serviço PaaS de destino possa implementar regras de filtro e restringir o acesso por sub-rede. Você pode encontrar uma comparação detalhada entre ambos os mecanismos em Comparar Pontos de Extremidade Privados e Pontos de Extremidade de Serviço.

Firewall do Azure regras de aplicações podem ser usadas para garantir que nenhuma exfiltração de dados para serviços não autorizados ocorra, bem como para implementar políticas de acesso com maior granularidade além do nível da sub-rede. Normalmente, os pontos de extremidade de serviço de rede virtual precisam ser habilitados na sub-rede do cliente que se conectará a um serviço Azure. No entanto, ao inspecionar o tráfego para pontos de extremidade de serviço com o Firewall do Azure, você precisa habilitar o ponto de extremidade de serviço correspondente na sub-rede do Firewall do Azure e, em vez disso, desabilitá-lo na sub-rede do cliente real (geralmente uma rede virtual spoke). Dessa forma, você pode usar regras de aplicativo em Firewall do Azure para controlar a quais serviços Azure suas cargas de trabalho Azure terão acesso.

Para obter detalhes de preços, consulte Firewall do Azure Pricing.

Para obter limites de serviço, consulte Azure limites de assinatura e serviço, cotas e restrições.

Firewall do Azure não move nem armazena dados do cliente fora da região em que ele é implantado.

Não, não há suporte para Firewall do Azure em hubs virtuais seguros (vWAN) no Catar.

Sim, Firewall do Azure dá suporte à filtragem de tráfego de entrada e 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 o uso de um firewall de aplicativo Web como Firewall de Aplicativo Web do Azure (WAF) ou os recursos de descarregamento do TLS e de inspeção de pacotes profundos do Firewall do Azure Premium.

Sim, o Firewall do Azure Basic dá suporte ao tunelamento forçado.

Um ping TCP realmente não se conecta ao FQDN de destino. Firewall do Azure bloqueia conexões com qualquer endereço IP de destino 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 de destino ou FQDN e não é registrada em log. Se uma regra de rede permitir explicitamente o acesso ao endereço IP de destino ou FQDN, a solicitação de ping atingirá o servidor de destino e sua resposta será retransmitida para o cliente. Esse evento é registrado no log de regras de rede.

Não, Firewall do Azure não dá suporte nativo ao emparelhamento BGP. No entanto, o recurso Autolearn SNAT routes utiliza indiretamente o BGP por intermédio de Servidor de Rota do Azure.

Firewall do Azure não dá suporte nativo ao ESP (encapsulando o conteúdo de segurança), mas você pode permitir o tráfego ESP configurando uma regra de rede da seguinte maneira:

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

• Protocolo: Qualquer
• Porta de origem: * (Qualquer)
• Porta de destino: * (Qualquer)
• Origem/Destino: especificar endereços IP conforme necessário

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

Referência: se estiver usando NSG (Grupo de Segurança de Rede) em vez de Firewall do Azure: o NSG não fornecerá uma opção direta para especificar ESP (número de protocolo IP 50), mas os pacotes ESP podem ser permitidos usando as seguintes configurações:

• Protocolo: Qualquer
• Porta: * (Qualquer)
• Origem/Destino: especificar endereços IP conforme necessário

Recommendations:

• Para configurações de VPN IPsec, é recomendável usar Gateway de VPN do Azure.
• Considere usar um padrão NVA (Solução de Virtualização de Rede) dependendo de seus requisitos.

Você pode usar Azure PowerShell para desalocar e alocar o Firewall do Azure. O processo varia dependendo da configuração.

Para um firewall sem uma NIC de Gerenciamento:

# 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 Gerenciamento:

# 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 em um 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ê poderá reconfigurá-los após a implantação se:

• O firewall é implantado em uma rede virtual (sem suporte em hubs virtuais protegidos).
• A região oferece suporte a 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 de 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 Firewall do Azure 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 (Azure firewall, rede virtual, IP público) devem estar na mesma assinatura.

Um estado de provisionamento com falha indica que uma atualização de configuração falhou em uma ou mais instâncias de backend. O Firewall do Azure permanece operacional, mas a configuração pode ser inconsistente. Repita a atualização até que o estado de provisionamento seja alterado para Bem-sucedido.

Firewall do Azure usa uma configuração ativa-ativa com vários nós de back-end. Durante a manutenção planejada, a drenagem da conexão garante atualizações tranquilas. Em caso de falhas não planejadas, um novo nó substitui o que falhou 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 dimensionamento à medida que o Firewall do Azure provisiona instâncias extras de máquina virtual.

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

Firewall do Azure dimensiona automaticamente com base no uso da CPU, na taxa de transferência e na contagem de conexões. A capacidade de taxa de transferência varia de 2,5 a 3 Gbps inicialmente a 30 Gbps (SKU Standard) ou 100 Gbps (SKU Premium).

Sim. Para obter detalhes, consulte Azure limites de assinatura e serviço, cotas e restrições.

Não, não há suporte para mover um grupo de 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 sejam fechadas imediatamente se não houver nenhuma atividade. O tempo limite de inatividade do Firewall do Azure TCP é de quatro minutos. Essa configuração não é configurável pelo usuário, mas você pode entrar em contato com Azure Suporte para aumentar o tempo limite ocioso para conexões de entrada e saída em 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 haverá nenhuma garantia de que a sessão TCP ou HTTP será mantida. Uma prática comum é usar um TCP keep alive. Essa prática mantém a conexão ativa por um período maior. Para obter mais informações, consulte os exemplos .NET.

Sim, mas você deve configurar o firewall no Modo de Túnel Forçado. Essa configuração cria uma interface de gerenciamento com um endereço IP público que é usado por Firewall do Azure para suas operações. Esse endereço IP público é para o tráfego de gerenciamento. Ele é usado exclusivamente pela plataforma Azure e não pode ser usado para nenhuma outra finalidade. 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 por túnel para outro Firewall ou completamente bloqueado.

Sim. Para obter mais informações, consulte Backup Firewall do Azure e Firewall do Azure Policy com Logic Apps.

Para obter acesso seguro aos serviços de PaaS, recomendamos ponto de extremidade de serviço. Você pode optar por habilitar pontos de extremidade de serviço na sub-rede Firewall do Azure e desabilitá-los nas redes virtuais spoke conectadas. Dessa forma, você aproveita ambos os recursos: segurança do endereço de serviço e registro centralizado de todo o tráfego.

Sim, você pode usar Firewall do Azure em uma rede virtual de hub para rotear e filtrar o tráfego entre várias redes virtuais spoke. As sub-redes em cada uma das redes virtuais spoke devem ter uma UDR apontando para o Firewall do Azure como um gateway padrão para que esse cenário funcione corretamente.

Sim. No entanto, configurar as UDRs para redirecionar o tráfego entre sub-redes na mesma rede virtual requer mais atenção. Embora o uso do intervalo de endereços de rede virtual como um prefixo de destino para a UDR seja suficiente, isso também roteia todo o tráfego de um computador para outro na mesma sub-rede por meio da instância de Firewall do Azure. Para evitar isso, inclua uma rota para a sub-rede no UDR com um tipo de próximo salto de rede virtual. O gerenciamento dessas rotas pode ser complicado e passível de erros. O método recomendado para segmentação de rede interna é usar Grupos de Segurança de Rede, o que não exige UDRs.

Firewall do Azure não realiza SNAT quando o endereço IP de destino está em um intervalo de IP privado conforme IANA RFC 1918 ou IANA RFC 6598 para redes privadas. Se sua organização utiliza um intervalo de endereços IP públicos para redes privadas, o Firewall do Azure realiza SNAT no tráfego para um dos endereços IP privados do firewall no AzureFirewallSubnet. Você pode configurar o Firewall do Azure para não fazer SNAT ao seu intervalo de endereços IP públicos. Para obter mais informações, consulte intervalos de endereços IP privados SNAT do Firewall do Azure.

Além disso, o tráfego processado por regras de aplicativo é sempre submetido a SNAT. Se você quiser ver o endereço IP de origem inicial nos seus logs para tráfego FQDN, poderá usar regras de rede com o FQDN de destino.

Há suporte para túneis forçados ao criar um novo firewall, e firewalls existentes também têm suporte para essa funcionalidade ao se adicionar uma interface de rede (NIC) de gerenciamento para o túnel forçado. Para obter mais detalhes sobre novas implantações, consulte túnel forçado do Firewall do Azure. Para firewalls existentes, consulte Firewall do Azure MANAGEMENT NIC.

Firewall do Azure deve ter conectividade direta com a Internet. Se seu AzureFirewallSubnet aprender uma rota padrão para sua rede local via BGP, você deve substituir isso por um UDR 0.0.0.0/0 com o valor NextHopType definido como Internet para manter a conectividade direta com a Internet.

Se a configuração exigir o túnel forçado para uma rede local e você puder determinar os prefixos de IP de destino para os destinos da Internet, você poderá configurar esses intervalos com a rede local como o próximo salto por meio de uma rota definida pelo usuário no AzureFirewallSubnet. Ou você pode usar o BGP para definir essas rotas.

• URL – Os asteriscos funcionam quando colocados no lado mais à direita ou à esquerda. Se ele estiver à esquerda, ele não poderá fazer parte do FQDN.
• FQDN – Os asteriscos funcionam quando colocados no lado mais à esquerda.
• GERAL: Os asteriscos no lado mais à esquerda significam literalmente qualquer coisa para as correspondências à esquerda, o que significa que vários subdomínios e/ou variações de nome de domínio possivelmente indesejados terão correspondências — veja os exemplos abaixo.

Exemplos:

Não. Firewall do Azure bloqueia o acesso Active Directory por padrão. Para permitir o acesso, configure a marca de serviço AzureActiveDirectory. Para obter mais informações, consulte Firewall do Azure marcas de serviço.

Sim, você pode usar Azure PowerShell para fazer 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 de TCP não está realmente se conectando ao FQDN de destino. Firewall do Azure não permite uma conexão com nenhum endereço IP de destino/FQDN, a menos que haja uma regra explícita que permita isso.

O ping TCP é um caso de uso exclusivo em que, se não houver nenhuma regra permitida, o próprio Firewall responderá à solicitação de ping TCP do cliente, mesmo que o ping TCP não atinja o endereço IP de destino/FQDN. 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 atingirá o servidor de destino e sua resposta será retransmitida para o cliente. Esse evento é registrado no log de regras de rede.

Firewall do Azure atua como ouvinte passivo para as portas 80, 443 e 1433. Firewall do Azure não registra pacotes TCP SYN nessas portas, a menos que haja tráfego de aplicativo. A solicitação HTTP GET e o cliente hello do TLS são registrados no Firewall do Azure.

Sim. Para obter mais informações, consulte Azure limites de assinatura e serviço, cotas e restrições

Não, não há suporte para mover um grupo de 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 sejam fechadas imediatamente se não houver nenhuma atividade. Firewall do Azure tempo limite de inatividade TCP é de quatro minutos. Essa configuração não é configurável pelo usuário, mas você pode entrar em contato com Azure Suporte para aumentar o tempo limite ocioso para conexões de entrada e saída em 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 haverá nenhuma garantia de que a sessão TCP ou HTTP será mantida. Uma prática comum é usar um TCP keep alive. Essa prática mantém a conexão ativa por um período maior. Para obter mais informações, consulte os exemplos .NET.

Sim, mas você deve configurar o firewall no Modo de Túnel Forçado. Essa configuração cria uma interface de gerenciamento com um endereço IP público que é usado por Firewall do Azure para suas operações. Esse endereço IP público é para o tráfego de gerenciamento. Ele é usado exclusivamente pela plataforma Azure e não pode ser usado para nenhuma outra finalidade. 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 por túnel para outro Firewall ou completamente bloqueado.

Firewall do Azure não move nem armazena dados do cliente para fora da região em que está implantado.

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

Não, atualmente não há suporte para Firewall do Azure em hubs virtuais seguros (vWAN) no Catar.

Firewall do Azure usa máquinas virtuais do Azure que têm um número limite definido de conexões. O número total de conexões ativas por máquina virtual é de 250 mil.

O limite total por firewall é o limite de conexão da máquina virtual (250 mil) x o número de máquinas virtuais no pool de back-end do firewall. Firewall do Azure começa com duas máquinas virtuais e é dimensionada com base no uso e na taxa de transferência da CPU.

Firewall do Azure atualmente usa 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 uma solução alternativa para determinadas arquiteturas, você pode implantar e dimensionar com NAT Gateway com Firewall do Azure para fornecer um pool mais amplo de portas SNAT para variabilidade e disponibilidade.

Comportamentos específicos da NAT 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 por meio do firewall.

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

Em qualquer manutenção planejada, a lógica de esvaziamento da conexão atualiza os nós do back-end normalmente. Firewall do Azure espera 90 segundos para que as conexões existentes fechem. Nos primeiros 45 segundos, o nó de back-end não aceita novas conexões e, no tempo restante, ele responde com RST a todos os pacotes de entrada. Se necessário, os clientes podem restabelecer automaticamente a conectividade com outro nó do back-end.

Um desligamento da instância de VM Firewall do Azure pode ocorrer durante o escalonamento do Conjunto de Dimensionamento de Máquinas Virtuais (redução) ou durante a atualização de software do conjunto. Nesses casos, novas conexões de entrada são balanceadas por carga para as instâncias de firewall restantes e não são encaminhadas para a instância de firewall inoperante. Após 45 segundos, o firewall começa a rejeitar as conexões existentes enviando pacotes de TCP RST. Após mais 45 segundos, a VM do firewall será desligada. Para obter mais informações, consulte Redefinição de TCP do Load Balancer e Tempo Limite de Inatividade.

Firewall do Azure escala gradualmente quando a taxa de transferência média ou o consumo de CPU está em 60%ou o número de conexões é de 80%. Por exemplo, ele começa a escalar horizontalmente quando atinge 60% da taxa de transferência máxima. Os números máximos de taxa de transferência variam com base na SKU do Firewall do Azure e nos recursos habilitados. Para obter mais informações, consulte Firewall do Azure performance.

O aumento de escala horizontal leva de cinco a sete minutos. Ao testar o desempenho, verifique se você testa por pelo menos 10 a 15 minutos e inicie novas conexões para aproveitar os nós de Firewall do Azure recém-criados.

Quando uma conexão tem um tempo limite ocioso (quatro minutos sem atividade), Firewall do Azure termina normalmente a conexão enviando um pacote TCP RST.

Azure serviços passam por atualizações de manutenção regulares para aprimorar a funcionalidade, a confiabilidade, o desempenho e a segurança. Com um período de manutenção configurado, a manutenção do sistema operacional convidado e a manutenção do serviço são executadas 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.

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

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

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

A manutenção controlada pelo cliente dá suporte a atualizações de serviço e sistema operacional convidado, que representam a maioria dos itens de manutenção preocupantes para 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 substituir seu controle da janela de manutenção para resolver problemas de segurança de alta gravidade.

Sim.

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

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

Pode levar até 24 horas para que o Firewall do Azure siga o agendamento de manutenção depois que a política de manutenção estiver associada.

As atividades de manutenção no Firewall do Azure não são pausadas durante o período anterior à janela de manutenção agendada. Durante dias que não estão incluídos em seu agendamento de manutenção, as operações de manutenção regulares continuam normalmente no recurso.

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