O que é o Firewall do Azure?

O Firewall do Azure é um serviço de segurança de firewall de rede inteligente e nativo de nuvem que fornece o que há de melhor em proteção contra ameaças para suas cargas de trabalho de nuvem em execução no Azure. Trata-se de um firewall como serviço, totalmente com estado, de alta disponibilidade interna e escalabilidade de nuvem irrestrita. Ele fornece inspeção de tráfego de leste a oeste e de norte a sul.

O Firewall do Azure é oferecido em três SKUs: Standard, Premium e Basic.

Firewall do Azure Standard

O Firewall do Azure Standard fornece filtragem L3-L7 e feeds de inteligência contra ameaças diretamente da Segurança Cibernética da Microsoft. A filtragem baseada em inteligência contra ameaças pode alertar e negar o tráfego de/para domínios e endereços IP mal-intencionados conhecidos que são atualizados em tempo real para proteger contra ataques novos e emergentes.

Visão geral do Firewall Standard

Para saber mais sobre os recursos do Firewall Standard, confira Recursos do Firewall do Azure Standard.

Firewall do Azure Premium

O Firewall do Azure Premium fornece funcionalidades avançadas que incluem IDPS baseado em assinatura para permitir a detecção rápida de ataques procurando padrões específicos. Esses padrões podem incluir sequências de bytes no tráfego de rede ou sequências de instruções mal-intencionadas conhecidas usadas por malwares. Há mais de 58.000 assinaturas em mais de 50 categorias que são atualizadas em tempo real para proteger contra explorações novas e emergentes. As categorias de exploração incluem malware, phishing, mineração de moedas e ataques de Troia.

Visão geral do Firewall Premium

Para saber mais sobre os recursos do Firewall Premium, confira Recursos do Firewall do Azure Premium.

Firewall do Azure Basic (versão prévia)

Importante

O Firewall do Azure Basic está atualmente em VERSÃO PRÉVIA. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.

O Firewall do Azure Basic destina-se a clientes de pequeno e médio porte (SMB) para proteger seus ambientes de nuvem do Azure. Ele fornece a proteção essencial que os clientes SMB precisam a um preço acessível.

Diagrama mostrando o Firewall Basic.

O Firewall do Azure Basic é semelhante ao Firewall Standard, mas tem as seguintes limitações:

  • Dá suporte somente ao modo de alerta intel de ameaças.
  • Unidade de escala fixa para executar o serviço em duas instâncias de back-end de máquina virtual.
  • Recomendado para ambientes com taxa de transferência máxima de 250 Mbps. A taxa de transferência pode aumentar para disponibilidade geral do recurso (GA).

Regiões com suporte

O Firewall do Azure Basic está disponível nas seguintes regiões durante a visualização:

  • Leste dos EUA
  • Leste dos EUA 2
  • Oeste dos EUA
  • Oeste dos EUA 2
  • Oeste dos EUA 3
  • Centro dos EUA
  • Centro-Norte dos EUA
  • Centro-Sul dos Estados Unidos
  • Centro-Oeste dos EUA
  • Leste dos EUA 2 EUAP
  • EUA Central EUAP
  • Norte da Europa
  • Europa Ocidental
  • Leste da Ásia
  • Sudeste Asiático
  • Leste do Japão
  • Oeste do Japão
  • Leste da Austrália
  • Sudeste da Austrália
  • Austrália Central
  • Sul do Brasil
  • Sul da Índia
  • Índia Central
  • Oeste da Índia
  • Canadá Central
  • Leste do Canadá
  • Sul do Reino Unido
  • Oeste do Reino Unido
  • Coreia Central
  • Sul da Coreia
  • França Central
  • Norte da África do Sul
  • Norte dos EAU
  • Norte da Suíça
  • Centro-Oeste da Alemanha
  • Leste da Noruega
  • Oeste da Índia JIO
  • Suécia Central
  • Catar Central

Para implantar um Firewall Básico, consulte Implantar e configurar o Firewall do Azure Básico (versão prévia) e a política usando o portal do Azure.

Gerenciador de Firewall do Azure

Você pode usar o Gerenciador de Firewall do Azure para gerenciar de maneira centralizada os Firewalls do Azure em várias assinaturas. O Gerenciador de Firewall aproveita a política de firewall para aplicar um conjunto comum de regras de rede/aplicativo e configuração aos firewalls em seu locatário.

O Gerenciador de Firewall dá suporte a firewalls em ambientes de VNet e WANs Virtuais (Hub Virtual Seguro). Os Hubs Virtuais Seguros usam a solução de automação de rotas da WAN Virtual para simplificar o roteamento de tráfego para o firewall com alguns cliques.

Para saber mais sobre o Gerenciador de Firewall do Azure, confira Gerenciador de Firewall do Azure.

Preço e SLA

Para obter informações sobre o preço do Firewall do Azure, confira os Preços do Firewall do Azure.

Para obter informações sobre o SLA do Firewall do Azure, confira o SLA do Firewall do Azure.

Regiões com suporte

Para as regiões com suporte para o Firewall do Azure, confira produtos do Azure disponíveis por região.

Novidades

Para saber sobre as novidades do Firewall do Azure, confira as Atualizações do Azure.

Problemas conhecidos

Firewall do Azure Standard

O Firewall do Azure Standard tem os seguintes problemas conhecidos:

Observação

Qualquer problema que se aplica ao Standard também se aplica ao Premium.

Problema Descrição Atenuação
As regras de filtragem de rede para protocolos não TCP/UDP (por exemplo, ICMP) não funcionam para o tráfego vinculado à Internet As regras de filtragem de rede para protocolos não TCP/UDP não funcionam com o SNAT para seu endereço IP público. Protocolos não TCP/UDP têm suporte entre VNets e sub-redes spoke. O Firewall do Azure usa o Standard Load Balancer que não dá suporte a SNAT para protocolos IP. Estamos explorando as opções para dar suporte a esse cenário em uma versão futura.
Suporte do PowerShell e da CLI ausente para ICMP O Azure PowerShell e a CLI não dão suporte ao ICMP como um protocolo válido nas regras de rede. Ainda é possível usar o ICMP como protocolo por meio do portal e da API REST. Estamos trabalhando para adicionar o ICMP no PowerShell e na CLI em breve.
As marcas de FQDN requerem que um protocolo:porta seja definido As regras de aplicativo com marcas de FQDN exigem a definição de um protocolo:porta. Você pode usar HTTPS como o valor de porta:protocolo. Estamos trabalhando para tornar esse campo opcional quando marcas de FQDN são usadas.
Não há suporte para a movimentação de um firewall para um grupo de recursos ou uma assinatura diferente Não há suporte para a movimentação de um firewall para um grupo de recursos ou uma assinatura diferente. O suporte a essa funcionalidade está em nosso roteiro. Para mover um firewall para um grupo de recursos ou uma assinatura diferente, você precisa excluir a instância atual e recriá-la no novo grupo de recursos ou na nova assinatura.
Alertas de inteligência de ameaças podem ser mascarados As regras de rede com destino 80/443 para filtragem de saída mascaram os alertas de inteligência de ameaças quando configuradas para o modo somente alerta. Crie a filtragem de saída para 80/443 usando regras de aplicativo. Ou, alterar o modo de inteligência contra ameaças para Alertar e negar.
O DNAT de Firewall do Azure não funciona para destinos de IP privados O suporte para DNAT do Firewall do Azure é limitado à saída/entrada da Internet. No momento, o DNAT não funciona para destinos de IP privados. Por exemplo, spoke para spoke. Esta é uma limitação atual.
Não é possível remover a primeira configuração de IP público Cada endereço IP público do Firewall do Azure é atribuído a uma configuração de IP. A primeira configuração de IP é atribuída durante a implantação do firewall e geralmente também contém uma referência à sub-rede do firewall (a menos que configurado de maneira explicitamente diferente por meio de uma implantação de modelo). Não é possível excluir essa configuração de IP, pois ele desalocaria o firewall. Você ainda poderá alterar ou remover o endereço IP público associado a essa configuração de IP se o firewall tiver pelo menos um outro endereço IP público disponível para uso. Isso ocorre por design.
As Zonas de disponibilidade só podem ser configuradas durante a implantação. As Zonas de disponibilidade só podem ser configuradas durante a implantação. Você não pode configurar Zonas de Disponibilidade após a implantação de um firewall. Isso ocorre por design.
SNAT em conexões de entrada Além de DNAT, as conexões via o endereço IP público do firewall (entrada) estão no modo SNAT para um dos IPs privados do firewall. Esse requisito hoje (e também para NVAs ativa/ativa) garante o roteamento simétrico. Para preservar a fonte original para HTTP/S, use os cabeçalhos XFF. Por exemplo, use um serviço como o Azure Front Door ou o Gateway de Aplicativo do Azure na frente do firewall. Você também pode adicionar o WAF como parte Porta da frente do Azure e encadear ao firewall.
Suporte para filtragem de FQDN do SQL apenas no modo de proxy (porta 1433) Para o Banco de Dados SQL do Azure, o Azure Synapse Analytics e a Instância Gerenciada de SQL do Azure:

A filtragem de FQDN do SQL tem suporte apenas no modo de proxy (porta 1433).

Para IaaS do SQL do Azure:

Se estiver usando portas não padrão, você poderá especificar essas portas nas regras do aplicativo.
Para o SQL no modo de redirecionamento (o padrão ao se conectar de dentro do Azure), você pode filtrar o acesso usando a tag de serviço do SQL como parte das regras de rede do Firewall do Azure.
O tráfego SMTP de saída na porta TCP 25 está bloqueado As mensagens de email de saída enviadas diretamente a domínios externos (como outlook.com e gmail.com) na porta TCP 25 são bloqueadas pela plataforma do Azure. Esse é o comportamento padrão da plataforma no Azure; o Firewall do Azure não introduz nenhuma restrição específica adicional. Use serviços de retransmissão de SMTP autenticado, que normalmente se conectam por meio da porta TCP 587, mas também permitem o uso de outras portas. Para saber mais, confira Solucionar problemas de conectividade de SMTP de saída no Azure. Atualmente, o Firewall do Azure pode se comunicar com IPs públicos usando o TCP 25 de saída, mas não há garantia de que ele funcione e não tem suporte para todos os tipos de assinatura. Para IPs privados, como redes virtuais, VPNs e Azure ExpressRoute, o Firewall do Azure dá suporte a uma conexão de saída da porta TCP 25.
Esgotamento de porta SNAT Atualmente, o Firewall do Azure dá suporte a 2496 portas por endereço IP público para cada instância de conjunto de dimensionamento de máquinas virtuais. Por padrão, há duas instâncias do conjunto de dimensionamento de máquinas virtuais. Portanto, há 4992 portas por fluxo (IP de destino, porta de destino e protocolo, sendo TCP ou UDP). É possível escalar o firewall verticalmente para um máximo de 20 instâncias. Essa é uma limitação da plataforma. Para lidar com os limites, configure implantações do Firewall do Azure suscetíveis ao esgotamento de SNAT com um mínimo de cinco endereços IP públicos. Isso aumenta as portas SNAT disponíveis em cinco vezes. Aloque de um prefixo de endereço IP para simplificar as permissões de downstream. Para obter uma solução mais permanente, é possível implantar um gateway NAT a fim de superar os limites de porta SNAT. Essa abordagem tem suporte para implantações de VNET.

Para saber mais, veja Dimensionar portas SNAT com o NAT da Rede Virtual do Azure.
O DNAT não é compatível com o Túnel Forçado habilitado Os firewalls implantados com o Túnel Forçado habilitado não são compatíveis com acesso de entrada proveniente da Internet devido ao roteamento assimétrico. Isso ocorre por design devido ao roteamento assimétrico. O caminho de retorno para conexões de entrada passa pelo firewall local, que não viu a conexão estabelecida.
O FTP Passivo de Saída pode não funcionar com os firewalls de vários endereços IP públicos, dependendo da configuração do servidor FTP. O FTP Passivo estabelece conexões diferentes para canais de controle e de dados. Quando um Firewall com vários endereços IP públicos envia dados de saída, ele seleciona aleatoriamente um de seus endereços IP públicos para o endereço IP de origem. O FTP pode falhar quando os canais de controle e de dados usam endereços IP de origem diferentes, dependendo da configuração do servidor FTP. Uma configuração SNAT explícita está em planejamento. Enquanto isso, você pode configurar o servidor FTP para aceitar canais de controle e de dados de diferentes endereços IP de origem (confira um exemplo do IIS). Como alternativa, considere usar um só endereço IP nessa situação.
O FTP Passivo de Entrada pode não funcionar, dependendo da configuração do servidor FTP O FTP Passivo estabelece conexões diferentes para canais de controle e de dados. As conexões de entrada no Firewall do Azure estão no modo SNAT para um dos endereços IP privados do firewall a fim de garantir o roteamento simétrico. O FTP pode falhar quando os canais de controle e de dados usam endereços IP de origem diferentes, dependendo da configuração do servidor FTP. A preservação do endereço IP de origem original está sendo investigada. Enquanto isso, você pode configurar o servidor FTP para aceitar canais de controle e de dados de diferentes endereços IP de origem.
O FTP ativo não funcionará quando o cliente FTP precisar acessar um servidor FTP pela Internet. O FTP ativo usa um comando PORT do cliente FTP que informa ao servidor FTP qual IP e porta usar para o canal de dados. Esse comando de porta usa o IP privado do cliente, que não pode ser alterado. O tráfego do lado do cliente que atravessa o Firewall do Azure será NAT para comunicações baseadas na Internet, o que faz com que o comando PORT seja visto como inválido pelo servidor FTP. Essa é uma limitação geral do FTP ativo quando usado com um NAT do lado do cliente.
A métrica NetworkRuleHit não tem uma dimensão de protocolo A métrica ApplicationRuleHit permite o protocolo baseado em filtragem, mas essa funcionalidade está ausente na métrica NetworkRuleHit correspondente. Uma correção está sendo investigada.
Não há suporte para regras NAT com portas entre 64000 e 65535 O Firewall do Azure permite qualquer porta no intervalo de 1 a 65535 nas regras de rede e de aplicativo, no entanto, as regras de NAT dão suporte apenas a portas no intervalo de 1 a 63999. Esta é uma limitação atual.
As atualizações de configuração podem levar cinco minutos em média Uma atualização de configuração do Firewall do Azure pode levar de três a cinco minutos em média e não há suporte para atualizações paralelas. Uma correção está sendo investigada.
O Firewall do Azure usa cabeçalhos de TLS SNI para filtrar tráfego HTTPS e MSSQL Se o navegador ou o software para servidores não der suporte à extensão SNI (Indicação de Nome do Servidor), você não poderá se conectar por meio do Firewall do Azure. Se o navegador ou o software para servidores não der suporte à SNI, você poderá controlar a conexão usando uma regra de rede em vez de uma regra de aplicativo. Consulte Indicação de Nome de Servidor para conhecer software que seja compatível com a SNI.
Não é possível adicionar marcas de política de firewall usando o portal ou Azure Resource Manager (ARM) A Política de Firewall do Azure tem uma limitação de suporte de patch que impede a adição de marcação usando o portal do Azure ou os modelos do ARM. O seguinte erro é gerado:Não foi possível salvar as marcações para o recurso. Uma correção está sendo investigada. Como alternativa, você pode usar o cmdlet Set-AzFirewallPolicy do Azure PowerShell para atualizar as marcas.
IPv6 sem suporte no momento Se você adicionar um endereço IPv6 a uma regra, o firewall falhará. Use somente endereços IPv4. O suporte a IPv6 está em investigação.
A atualização de vários grupos de IP falha com um erro de conflito. Quando você atualiza dois ou mais Grupos de IP anexados ao mesmo firewall, um dos recursos entra em um estado de falha. Esse é um problema conhecido e uma limitação conhecida.

Quando você atualiza um Grupo de IP, ele dispara uma atualização em todos os firewalls aos quais o IPGroup está anexado. Se uma atualização em um segundo Grupo de IP for iniciada enquanto o firewall ainda estiver no estado Atualizando, a atualização do IPGroup falhará.

Para evitar a falha, os Grupos de IP anexados ao mesmo firewall precisam ser atualizados um de cada vez. Permita tempo suficiente entre as atualizações para que o firewall saia do estado Atualizando.
Não há suporte para a remoção do RuleCollectionGroups usando modelos do ARM. Não há suporte para a remoção de um RuleCollectionGroup usando modelos ARM e isto resulta em falha. Não há suporte para esta operação.
A regra DNAT para permitir qualquer (*) permitirá o tráfego no modo SNAT. Se uma regra DNAT permitir qualquer (*) como o endereço IP de origem, uma regra de rede implícita corresponderá ao tráfego VNet-VNet e sempre fará o tráfego no modo SNAT. Esta é uma limitação atual.
Não há suporte para a adição de uma regra DNAT a um hub virtual seguro com um provedor de segurança. Isso resulta em uma rota assíncrona para o tráfego DNAT que retorna, que vai para o provedor de segurança. Não há suporte.
Erro encontrado ao criar mais de 2.000 coleções de regras. O número máximo de coleções de regra de NAT/Aplicativo ou de Rede é 2.000 (limite do Resource Manager). Esta é uma limitação atual.
Não é possível ver o nome da regra de rede nos logs do Firewall do Azure Os dados de log da regra de rede do Firewall do Azure não mostram o nome da regra para o tráfego de rede. O log de nome da regra de rede está em versão prévia. Para obter informações, confira Versão prévia dos recursos do Firewall do Azure.
Cabeçalho XFF em HTTP/S Os cabeçalhos XFF são substituídos pelo endereço IP de origem original, como visto pelo firewall. Isso é aplicável para os seguintes casos de uso:
- Solicitações HTTP
- Solicitações HTTPS com terminação TLS
Uma correção está sendo investigada.
Não é possível fazer a atualização para o Premium com zonas de disponibilidade na região do Sudeste Asiático No momento, não é possível atualizar para o Firewall do Azure Premium com Zonas de Disponibilidade na região do Sudeste da Ásia. Implante um novo firewall Premium no Sudeste da Ásia sem Zonas de Disponibilidade ou em uma região que dá suporte a Zonas de Disponibilidade.
Não é possível implantar um firewall com zonas de disponibilidade com um endereço IP público recém-criado Ao implantar um firewall com zonas de disponibilidade, não é possível usar um endereço IP público recém-criado. Primeiro, crie um endereço IP público com redundância de zona e atribua esse endereço IP criado anteriormente durante a implantação do firewall.
Não há suporte para a zona DNS privada do Azure com Firewall do Azure A zona DNS privada do Azure não funcionará com Firewall do Azure, independentemente das configurações de DNS do Firewall do Azure. Para alcançar o estado desejado de usar um servidor DNS privado, use o proxy DNS do Firewall do Azure em vez de uma zona DNS privada do Azure.

Firewall do Azure Premium

O Firewall do Azure Premium tem os seguintes problemas conhecidos:

Problema Descrição Atenuação
Suporte de ESNI para a resolução de FQDN em HTTPS Não há suporte para SNI criptografada no handshake HTTPS. Atualmente, somente o Firefox dá suporte a ESNI por meio de configuração personalizada. A solução alternativa sugerida é desabilitar o recurso.
A Autenticação de Certificação do Cliente não é suportada Os certificados de cliente são usados para criar uma confiança de identidade mútua entre o cliente e o servidor. Eles são usados durante uma negociação de TLS. O Firewall do Azure renegocia uma conexão com o servidor e não tem acesso à chave privada dos certificados do cliente. Nenhum
QUIC/HTTP3 QUIC é a nova versão principal do HTTP. É um protocolo baseado em UDP sobre 80 (PLAN) e 443 (SSL). Não haverá suporte para a inspeção de FQDN/URL/TLS. Faça a configuração transmitindo UDP 80/443 como regras de rede.
Certificados assinados de cliente não confiáveis O Firewall não confia nos certificados assinados pelo cliente quando os recebe de um servidor Web baseado na intranet. Uma correção está sendo investigada.
Endereço IP de origem errado em Alertas com o IDPS para HTTP (sem a inspeção de TLS). Quando o tráfego HTTP de texto sem formatação está em uso, o IDPS emite um novo alerta e o destino é um endereço IP público, o endereço IP de origem exibido está errado (o endereço IP interno é exibido em vez do original). Uma correção está sendo investigada.
Propagação de Certificado Quando um certificado de autoridade de certificação é aplicado no firewall, pode levar de cinco a dez minutos para que o certificado entre em vigor. Uma correção está sendo investigada.
Suporte a TLS 1.3 O TLS 1.3 tem suporte parcial. O túnel TLS do cliente para o firewall é baseado no TLS 1.2 e do firewall para o servidor Web externo é baseado no TLS 1.3. Atualizações estão sendo investigadas.
Zonas de Disponibilidade firewall Premium na região do Sudeste Asiático No momento, não é possível implantar Firewall do Azure Premium com Zonas de Disponibilidade região do Sudeste Asiático. Implante o firewall no Sudeste Asiático sem Zonas de Disponibilidade ou implante em uma região que dá suporte a Zonas de Disponibilidade.

Próximas etapas