FAQ sobre a Azure Firewall

O Azure Firewall é um serviço de segurança de rede gerido e com base na cloud que protege os recursos da Rede Virtual do Azure. É um firewall como serviço totalmente stateful 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 obter uma lista detalhada dos recursos do Firewall do Azure, consulte Recursos do Firewall do Azure.

O 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 emparelhadas a ele. 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 de raios múltiplos em diferentes assinaturas e oferece economia de custos ao evitar a 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 Firewall do Azure pode ser implantado usando o portal do Azure, PowerShell, API REST ou modelos. Para obter instruções passo a passo, consulte Tutorial: Implantar e configurar o Firewall do Azure usando o portal do Azure.

O 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 terminando.

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

• Regras de aplicação: configure FQDNs (nomes de domínio totalmente qualificados) que podem ser acessados a partir de uma rede virtual.
• Regras de rede: configure regras com endereços de origem, protocolos, portas de destino e endereços de destino.
• Regras NAT: Configure regras DNAT para permitir conexões de entrada na Internet ou intranet (visualização).

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

O Firewall do Azure integra-se ao Azure Monitor para exibir e analisar logs. Os logs podem ser enviados para o Log Analytics, o 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 do Firewall do Azure.

O Firewall do Azure é um serviço de segurança de rede gerenciado e baseado em nuvem que protege os recursos da rede virtual. É um firewall como serviço totalmente stateful 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 obter mais informações, consulte Segurança de rede do Azure.

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

O Firewall do Azure complementa os NSGs para fornecer melhor segurança de rede de "defesa em profundidade". 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 Firewall do Azure fornece proteção centralizada e totalmente stateful de rede e nível de aplicativo em assinaturas e redes virtuais.

O Firewall do Azure é um serviço gerenciado com várias camadas de proteção, incluindo proteção de plataforma com NSGs de nível NIC (não visíveis). 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 pontos de extremidade privados são um componente do Private Link, uma tecnologia que permite interagir com os serviços PaaS do Azure usando endereços IP privados em vez de endereços públicos. O Firewall do Azure pode ser usado para impedir o acesso a endereços IP públicos, evitando assim a exfiltração de dados para serviços do Azure que não utilizam o Private Link, bem como para implementar políticas de confiança zero definindo quem em sua organização precisa acessar esses serviços PaaS do Azure, já que o Private Link por padrão abre acesso à rede para toda a sua rede corporativa.

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

Os pontos de extremidade do serviço de Rede Virtual são uma alternativa ao Link Privado para controlar o acesso à 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. Você pode encontrar uma comparação detalhada entre ambos os mecanismos em Comparar pontos de extremidade privados e pontos de extremidade de serviço.

As regras de aplicativo do Firewall do Azure podem ser usadas para garantir que nenhuma exfiltração de dados para serviços não autorizados ocorra e para implementar políticas de acesso com maior granularidade além do nível de 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 do 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 desabilitá-los na sub-rede do cliente real (geralmente uma rede virtual falada). Dessa forma, você pode usar as Regras de Aplicativo no Firewall do Azure para controlar a quais serviços do Azure suas cargas de trabalho do Azure terão acesso.

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

Para limites de serviço, consulte Subscrição do Azure e limites de serviço, quotas e restrições.

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

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

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

Sim, o Firewall do Azure Basic dá suporte ao túnel forçado.

Na verdade, um ping TCP não se conecta ao FQDN de destino. O Firewall do Azure bloqueia conexões com qualquer endereço IP ou FQDN de destino, a menos que 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 oferece suporte nativo ao emparelhamento BGP. No entanto, o recurso de rotas SNAT de aprendizado automático usa indiretamente o BGP por meio do Azure Route Server.

Você pode usar o 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ê 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. Desaloque 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 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 (firewall do Azure, 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 back-end. O Firewall do Azure permanece operacional, mas a configuração pode ser inconsistente. Tente novamente a atualização até que o estado de provisionamento mude para Succeeded.

O 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 graciosas. 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 dimensionamento à medida que o Firewall do Azure provisiona instâncias de máquina virtual extras.

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

O Firewall do Azure é dimensionado 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 Padrão) ou 100 Gbps (SKU Premium).

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

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. O tempo limite de inatividade TCP do Firewall do Azure é de quatro minutos. Essa configuração não é configurável pelo usuário, mas você pode entrar em contato com o Suporte do Azure 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 há garantia de que a sessão TCP ou HTTP seja mantida. Uma prática comum é usar um TCP keep-alive. Essa prática mantém a conexão ativa por um período mais longo. Para obter mais informações, consulte os exemplos do .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 pelo Firewall do Azure para suas operações. Este endereço IP público destina-se à gestão de tráfego. Ele é usado exclusivamente pela plataforma Azure e não pode ser usado para qualquer 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 a ser encapsulado para outro Firewall ou completamente bloqueado.

Sim. Para obter mais informações, consulte Backup do Firewall do Azure e Política do Firewall do Azure com Aplicativos Lógicos.

Para acesso seguro aos serviços PaaS, recomendamos pontos de extremidade de serviço. Pode optar por ativar pontos finais de serviço na sub-rede do Azure Firewall e desativá-los nas redes virtuais spoke 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, você pode usar o Firewall do Azure em uma rede virtual de hub para rotear e filtrar o tráfego entre várias redes virtuais. As sub-redes em cada uma das redes virtuais spoke devem ter um UDR apontando para o Firewall do Azure como um gateway padrão para que esse 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 o uso do intervalo de endereços de rede virtual como um prefixo de destino para o UDR seja suficiente, isso também roteia todo o tráfego de uma máquina para outra máquina na mesma sub-rede por meio da instância do 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 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.

O Firewall do Azure não SNAT quando o endereço IP de destino é um intervalo de IP privado por IANA RFC 1918 ou IANA RFC 6598 para redes privadas. Se sua organização usa um intervalo de endereços IP públicos para redes privadas, SNATs do Firewall do Azure o tráfego para um dos endereços IP privados do firewall no AzureFirewallSubnet. Você pode configurar o Firewall do Azure para não SNAT seu intervalo de endereços IP públicos. Para obter mais informações, veja SNAT do Azure Firewall para intervalos de endereços IP privados.

Além disso, o tráfego processado pelas regras do aplicativo é sempre SNAT-ed. 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 túnel forçado é suportado quando você cria um novo firewall. Não é possível configurar um firewall existente para tunelamento forçado. Para obter mais informações, veja Túnel forçado do Azure Firewall.

O Azure Firewall tem de ter conectividade Internet direta. 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 sua configuração exigir túnel forçado para uma rede local e você puder determinar os prefixos IP de destino para seus destinos da Internet, poderá configurar esses intervalos com a rede local como o próximo salto por meio de uma rota definida pelo usuário na AzureFirewallSubnet. Ou, você pode usar BGP para definir essas rotas.

• URL - Asteriscos funcionam quando colocados no lado mais à direita ou mais à esquerda. Se estiver à esquerda, não pode fazer parte do FQDN.
• FQDN - Asteriscos funcionam quando colocados no lado mais esquerdo.
• GERAL - Asteriscos no lado mais à esquerda significam literalmente qualquer coisa à esquerda corresponde, o que significa que vários subdomínios e/ou variações de nomes de domínio potencialmente indesejadas são combinados - veja os exemplos a seguir.

Exemplos:

N.º O Azure Firewall bloqueia o acesso ao Ative Directory, por predefinição. Para permitir o acesso, configure a marca de serviço AzureActiveDirectory. Para obter mais informações, consulte Tags de serviço do Firewall do Azure.

Sim, você pode usar o 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 TCP não está realmente se conectando ao FQDN de destino. O Firewall do Azure não permite uma conexão com nenhum endereço IP/FQDN de destino, 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 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 obter mais informações, veja Subscrição do Azure e limites, quotas e restrições do serviço

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. O tempo limite de inatividade TCP do Firewall do Azure é de quatro minutos. Essa configuração não é configurável pelo usuário, mas você pode entrar em contato com o Suporte do Azure 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 há garantia de que a sessão TCP ou HTTP seja mantida. Uma prática comum é usar um TCP keep-alive. Essa prática mantém a conexão ativa por um período mais longo. Para obter mais informações, consulte os exemplos do .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 pelo Firewall do Azure para suas operações. Este endereço IP público destina-se à gestão de tráfego. Ele é usado exclusivamente pela plataforma Azure e não pode ser usado para qualquer 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 a ser encapsulado para outro Firewall ou completamente bloqueado.

O 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 Aplicativos Lógicos.

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

O Firewall do Azure usa Máquinas Virtuais do Azure abaixo que têm um número limite rígido de conexõ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 Firewall do Azure começa com duas máquinas virtuais e é dimensionado com base no uso e na taxa de transferência da CPU.

Atualmente, o Firewall do Azure 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 solução alternativa para determinadas arquiteturas, você pode implantar e dimensionar com o Gateway NAT com o Firewall do Azure para fornecer um pool 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 NAT do Firewall do Azure.

Para qualquer manutenção planejada, a lógica de drenagem de conexão atualiza graciosamente os nós de back-end. O Firewall do Azure aguarda 90 segundos para que as conexões existentes sejam fechadas. Nos primeiros 45 segundos, o nó de back-end não aceita novas conexões e, no tempo restante, responde com RST todos os pacotes recebidos. Se necessário, os clientes podem restabelecer automaticamente a conectividade com outro nó de back-end.

Um desligamento de instância de VM do Firewall do Azure pode ocorrer durante a escala do Conjunto de Dimensionamento de Máquina Virtual (redução de escala) ou durante a atualização do software da frota. Nesses casos, as novas conexões de entrada têm balanceamento de carga para as instâncias de firewall restantes e não são encaminhadas para a instância de firewall inativa. 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 Redefinição de TCP do balanceador de carga e tempo limite de inatividade.

O Azure Firewall é escalonado gradualmente quando a taxa de transferência média ou o consumo de CPU está em 60%, ou o número de conexões utilizadas está em 80%. Por exemplo, começa a ser escalonado quando atinge 60% do seu débito máximo. 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 Desempenho do Firewall do Azure.

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

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

Os serviços do Azure passam por atualizações de manutenção regulares para melhorar a funcionalidade, a confiabilidade, o desempenho e a 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 Firewall do Azure 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 substituir seu controle da 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 Firewall do Azure.

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

Pode levar até 24 horas para que o Firewall do Azure siga o cronograma de manutenção depois que a política de manutenção for 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. 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 obter mais informações, consulte Configurar a manutenção controlada pelo cliente.