Azure Firewall e inspeção de tráfego

O Azure Firewall é um serviço de segurança de rede gerido e nativo na cloud que fornece inspeção centralizada de tráfego e filtragem para as suas redes virtuais Azure. Ao contrário dos grupos de segurança de rede que operam na Camada 4, o Azure Firewall inspeciona o tráfego nas Camadas 3 a 7. Esta capacidade permite filtragem totalmente qualificada de nomes de domínio (FQDN), inteligência de ameaças, deteção e prevenção de intrusões (IDPS) e inspeção TLS. Implementas o Azure Firewall numa sub-rede dedicada dentro da tua rede virtual do hub e encaminhas o tráfego das cargas de trabalho spoke através do firewall para inspeção antes de chegar ao destino.

Este artigo explica como selecionar o SKU correto do Azure Firewall, posicionar o firewall numa topologia hub-and-spoke, configurar os tipos de regras e integrar com serviços complementares como o NAT Gateway e o Route Server. O Azure Firewall é um dos três principais serviços de segurança de rede do Azure, juntamente com o Azure DDoS Protection e o Firewall de Aplicações Web do Azure.

O que este artigo aborda

Este artigo aborda a inspeção centralizada do tráfego de rede utilizando o Azure Firewall. Você aprende sobre:

  • Seleção de níveis SKU com base nos requisitos de segurança e sensibilidade à carga de trabalho.
  • Posicionamento do hub e padrões de rota definidos pelo utilizador (UDR) que forçam o tráfego a passar pelo firewall.
  • Lógica de processamento de regras para DNAT, rede e regras de aplicação.
  • Tunelamento forçado para ambientes que exigem inspeção no local.
  • Inspeção de TLS e capacidades de IDPS no escalão Premium.
  • Integração com NAT Gateway para escalonamento de portas SNAT e Route Server para roteamento baseado em BGP.

Quem precisa deste artigo

Implemente o Azure Firewall quando as suas cargas de trabalho exigirem uma ou mais das seguintes capacidades:

  • Controlo centralizado do tráfego de saída: Precisa de restringir a quais FQDNs e URLs externos as suas cargas de trabalho podem aceder, para além do que as regras NSG baseadas em IP permitem.
  • Inspeção este-oeste: O tráfego entre redes virtuais spoke deve passar por um ponto de inspeção com estado antes que o firewall o permita.
  • Registo obrigatório por conformidade: Os quadros regulamentares exigem total visibilidade da Camada 7 sobre ligações permitidas e recusadas com granularidade ao nível de FQDN.
  • Proteção contra ameaças: Precisa de deteção e prevenção de intrusões baseadas em assinaturas para identificar padrões de tráfego maliciosos, incluindo callbacks de comando e controlo, tentativas de exploração e movimentos laterais.
  • Inspeção TLS: Tem de desencriptar e inspecionar o tráfego encriptado (HTTPS) em busca de ameaças antes de este chegar às cargas de trabalho ou sair da rede.

Organizações que necessitem apenas de filtragem de pacotes de Camada 4 sem conhecimento de FQDN devem considerar NSGs e ASGs como uma alternativa mais simples e de menor custo.

Foco em levantar e deslocar: Traduza a base de regras do firewall local para a política do Azure Firewall. Comece com regras de rede para tráfego não-HTTP/S e regras de aplicação para filtragem baseada em FQDN. Comece com políticas gerais de permissão durante a migração, depois ajuste as regras depois de rever os registos do Azure Firewall.

Modernizar o foco: Use o Azure Firewall como ponto centralizado SNAT e DNAT no hub. Inspecionar o tráfego entre os spokes de aplicação e entre os spokes e a Internet, utilizar regras de aplicação e etiquetas FQDN para o tráfego de saída do AKS e dos serviços PaaS do Azure, e planear a inspeção de TLS nos casos em que as camadas da aplicação trocam tráfego sensível.

Foco entre clouds: Implemente o Azure Firewall num hub virtual protegido para inspecionar o tráfego em trânsito entre clouds. Configure regras de rede para o tráfego de túneis IPSec a partir da AWS ou Google Cloud, e use o IDPS para observar padrões de tráfego anómalos entre clouds ligadas.

Escalões de SKU do Azure Firewall

O Azure Firewall está disponível em três níveis de SKU. Cada nível baseia-se nas capacidades do nível anterior.

Capacidade Básico Standard Premium
Inspeção de pacotes com estado ✔ ✔ ✔
Filtragem por FQDN (de saída) ✔ ✔ ✔
Regras de rede (IP, porta, protocolo) ✔ ✔ ✔
Regras de aplicação (FQDN, URL) ✔ ✔ ✔
Regras NAT (DNAT) ✔ ✔ ✔
Filtragem de inteligência de ameaças Apenas alerta ✔ (Alerta + Negar) ✔ (Alerta + Negar)
Proxy DNS ✗ ✔ ✔
Categorias da Web ✗ ✔ ✔
IDPS (deteção e prevenção de intrusões) ✗ ✗ ✔
Inspeção de TLS ✗ ✗ ✔
Filtragem de URL (caminho completo) ✗ ✗ ✔
Proxy explícito ✗ ✔ ✔
Disponibilidade da região Regiões limitadas Todas as regiões Todas as regiões
Melhor para Desenvolvimento/teste, cargas de trabalho pequenas Produção padrão Alta segurança, orientada pela conformidade

Como escolher o seu SKU

Use os seguintes critérios de decisão:

  • Escolha Básico quando tiver ambientes de desenvolvimento/teste ou pequenas cargas de trabalho que necessitem de filtragem de saída baseada em FQDN, sem filtragem de inteligência de ameaças (modo de recusa) ou inspeção avançada. O SKU básico inclui inteligência de ameaças apenas em modo de alerta, mas não suporta modo de recusa, proxy DNS ou categorias web. O SKU básico requer um valor dedicado AzureFirewallManagementSubnet (/26 mínimo) juntamente com o AzureFirewallSubnet e está disponível em regiões limitadas.
  • Escolha Standard para cargas de trabalho de produção que necessitem de filtragem baseada em inteligência de ameaças, proxy DNS para resolução de regras FQDN, filtragem de categorias web e gestão centralizada de políticas através do Azure Firewall Manager. A edição Standard inclui o motor completo de inspeção com monitorização de estado, com fluxos de inteligência sobre ameaças que bloqueiam as ligações a endereços IP e domínios maliciosos conhecidos.
  • Escolha Premium quando requisitos regulatórios ou de segurança exigem a inspeção TLS do tráfego encriptado, IDPS baseados em assinaturas com regras continuamente atualizadas (mais de 67.000 assinaturas em mais de 50 categorias, atualizadas em tempo real), ou filtragem completa do caminho URL para além do FQDN. O prémio é exigido para indústrias como serviços financeiros, saúde e governo, onde a inspeção de tráfego encriptado é obrigatória.

Note

Atualize de Standard para Premium sem ter de voltar a instalar o firewall. Fazer downgrade de Premium para Standard requer reimplantação.

Posicionamento do hub e padrão de encaminhamento UDR

Implementa o Azure Firewall numa sub-rede dedicada com o nome exato AzureFirewallSubnet dentro da tua rede virtual do hub. Esta sub-rede requer um tamanho mínimo de /26 (59 endereços IP utilizáveis).

Arquitetura de encaminhamento

Diagrama de uma topologia em hub-and-spoke em que o tráfego das sub-redes spoke é encaminhado através do Azure Firewall na rede virtual hub antes de chegar à Internet ou a outras spokes.

Numa topologia hub-and-spoke, as sub-redes de carga de trabalho dos spokes não encaminham tráfego diretamente para a Internet nem para outros spokes. Em vez disso, os UDRs em cada sub-rede spoke definem a rota predefinida (0.0.0.0/0) para o endereço IP privado do Azure Firewall. Este padrão garante que todo o tráfego, tanto norte-sul (destinado à Internet) como este-oeste (de spoke para spoke), passe pelo firewall para ser inspecionado.

Padrão de configuração UDR:

Tabela de rotas (aplicada a) Prefixo de endereço Tipo de salto seguinte Endereço para o próximo salto
Sub-rede de raios A 0.0.0.0/0 Dispositivo virtual IP privado de firewall
Sub-rede de raios A 10.1.0.0/16 (outros falados) Dispositivo virtual IP privado de firewall
Sub-rede de ramo B 0.0.0.0/0 Dispositivo virtual IP privado de firewall
Sub-rede de ramo B 10.0.0.0/16 (outro raio) Dispositivo virtual IP privado de firewall

O próprio AzureFirewallSubnet não requer UDRs na maioria dos cenários, porque a firewall usa rotas do sistema para chegar às redes spoke através do emparelhamento de rede virtual. Quando integras com o Azure Route Server, a sub-rede do firewall aprende rotas através do BGP. Esta abordagem elimina a necessidade de manutenção manual das rotas à medida que a sua rede cresce.

Dica

O Azure Virtual Network Manager pode automatizar a configuração das tabelas de roteamento para usar o Azure Firewall como o próximo salto, reduzindo a gestão manual de UDR em várias subscrições spoke.

Requisitos de sub-rede

Sub-rede Tamanho mínimo Purpose Notes
AzureFirewallSubnet /26 Aloja instâncias do Azure Firewall Tem de ser denominado exatamente AzureFirewallSubnet
AzureFirewallManagementSubnet /26 Tráfego de gestão (apenas SKU básico) Obrigatório para SKU Básico; opcional para tunelamento forçado noutros SKUs

Para obter mais informações sobre a conceção da rede virtual de hub e o planeamento de sub-redes, consulte Topologia hub-and-spoke.

Tipos de regras e lógica de processamento

Azure Firewall processa regras através do Azure Firewall Policy. As regras estão organizadas em coleções de regras, que são agrupadas em grupos de recolha de regras. O firewall avalia as regras na seguinte ordem de prioridade:

  1. Regras DNAT (Tradução de Endereços de Rede de Destino): Processadas primeiro. Traduz o tráfego de entrada de um IP público para um IP privado atrás do firewall.
  2. Regras de rede: Processadas em segundo lugar. Permitir ou negar o tráfego com base no IP de origem, IP de destino, porta e protocolo (Camada 3/4).
  3. Regras da aplicação: Processadas em último lugar. Permitir ou negar o tráfego de saída com base em FQDN, URL ou categoria web (Camada 7).

Dentro de cada tipo de regra, os grupos de recolha de regras são avaliados por prioridade (menor número = prioridade máxima). Dentro de um grupo, as coleções de regras são avaliadas por prioridade. A primeira regra de correspondência determina a ação (Permitir ou Rejeitar) e impede uma avaliação adicional.

Regras DNAT

Use as regras DNAT para publicar serviços internos através do endereço IP público do firewall. O firewall traduz o endereço de destino do seu IP público para o IP privado do serviço backend. Cenários comuns incluem:

  • Exposição de um servidor web interno através do IP público do firewall na porta 443
  • Fornecer acesso RDP ou SSH controlado a uma jump box sem atribuir um IP público à VM
  • Exposição de serviços que não utilizam HTTP/S e requerem acesso de entrada a partir da Internet
Example: Translate inbound TCP 443 on firewall public IP → 10.1.2.4:443 (internal web server)

As regras DNAT adicionam implicitamente uma regra de rede correspondente para permitir o tráfego traduzido. Uma vez que uma regra DNAT coincide, o tráfego é traduzido e permitido sem processamento adicional das regras de rede. Por segurança, restrinja o endereço IP de origem nas tuas regras de DNAT a fontes específicas da internet em vez de usar wildcards.

Regras de rede

As regras de rede filtram o tráfego na Camada 3 e na Camada 4. Use regras de rede quando precisar de permitir ou negar tráfego com base no endereço IP de origem, endereço IP de destino, porta de destino e protocolo. As regras de rede não realizam resolução FQDN. Operam estritamente com endereços IP. Os casos de uso comuns incluem:

  • Permitindo comunicação spoke-to-spoke para portas específicas (por exemplo, SQL Server no TCP 1433).
  • Permitir NTP (UDP 123) para servidores de hora específicos.
  • Bloquear tráfego para intervalos de IP maliciosos conhecidos usando regras de negação.
  • Permitir ICMP para diagnósticos de rede entre sub-redes específicas.

As regras de rede suportam TCP, UDP, ICMP e quaisquer tipos de protocolo. Pode especificar endereços IP, intervalos de IP, etiquetas de serviço e grupos de IP como origem e destino.

Regras de aplicação

As regras de aplicação filtram o tráfego HTTP/S e MSSQL de saída com base em FQDNs, URLs e categorias web. As regras de aplicação requerem a funcionalidade de proxy DNS para resolução FQDN. Use as regras de aplicação quando:

  • É necessário permitir o acesso a FQDNs específicos (por exemplo, *.microsoft.com ou storage.blob.core.windows.net).
  • Pretende filtrar por caminho do URL (apenas SKU Premium), por exemplo, permitir github.com/myorg/* mas bloquear outros caminhos do GitHub.
  • É necessário permitir ou bloquear categorias inteiras da web (por exemplo, permitir "Ferramentas para Desenvolvedores" e bloquear "Jogos").

As regras de aplicação fornecem etiquetas FQDN para serviços comuns do Azure (como Windows Update, Azure Backup e HDInsight) que simplificam a criação de regras agrupando as FQDNs necessárias numa única etiqueta.

Importante

Quando ativas o proxy DNS no Azure Firewall, o firewall atua como o resolvedor DNS para cargas de trabalho. Configure as definições do DNS da sua rede virtual para apontar para o IP privado do firewall para que as regras baseadas em FQDN sejam resolvidas corretamente. Para detalhes da arquitetura DNS, consulte segurança DNS e resolução privada de nomes.

Comportamento do SNAT

Por defeito, o Azure Firewall aplica SNAT (Source Network Address Translation) ao tráfego de saída destinado a endereços IP públicos. A firewall não aplica SNAT ao tráfego quando o destino é um intervalo de endereços IP privados (RFC 1918) ou um espaço de endereços partilhado (RFC 6598). O firewall traduz o IP de origem das ligações à internet para um dos seus endereços IP públicos. Cada IP público fornece 2.496 portas SNAT por instância backend.

Para cargas de trabalho com taxas elevadas de ligações de saída, integre-o com o NAT Gateway para expandir até 64 512 portas por IP público (até 16 IPs públicos, num total aproximado de um milhão de portas SNAT).

Quando associa o NAT Gateway ao AzureFirewallSubnet, todo o tráfego de internet de saída utiliza automaticamente os endereços IP públicos do NAT Gateway. O firewall continua a inspecionar o tráfego, mas o NAT Gateway trata da tradução do SNAT. Não ocorre nenhum duplo NAT.

Note

O NAT Gateway com redundância entre zonas do Azure Firewall requer o SKU StandardV2 do NAT Gateway. O NAT Gateway não é suportado em arquiteturas de hub seguras por WAN Virtual.

Gestor de firewall e herança de políticas

O Azure Firewall Manager fornece políticas de segurança centralizadas e gestão de rotas entre múltiplas instâncias do Azure Firewall. As capacidades-chave incluem:

  • Hierarquia de políticas: Criar uma política base (pai) com regras organizacionais e permitir que equipas filhas criem políticas filhas que herdem do pai. As regras pais têm sempre prioridade, independentemente dos valores de prioridade para filhos.
  • Gestão entre regiões: Uma política de firewall é um recurso global que pode ser associada a firewalls em qualquer região ou subscrição.
  • Governação multi-firewall: Aplique uma postura de segurança consistente entre firewalls de hub em diferentes regiões ou entre hubs WAN Virtual seguros.

As regras NAT são específicas do firewall e não são herdadas das políticas principais. O modo de inteligência contra ameaças é herdado, mas só pode ser substituído por um modo mais restritivo nas políticas subordinadas. Uma política com zero ou uma associação de firewall está incluída sem custo adicional. As associações adicionais estão sujeitas a faturação.

Túneis obrigatórios

Em alguns ambientes regulatórios, todo o tráfego dirigido à internet deve primeiro passar por um ponto de inspeção local antes de chegar à internet. O Azure Firewall suporta tunelamento forçado para acomodar este requisito.

Quando ativas o tunneling forçado:

  • O AzureFirewallManagementSubnet transporta o tráfego de gestão do firewall diretamente para a internet. Esta sub-rede deve ter uma rota para 0.0.0.0/0 com próximo salto para a Internet. Não se pode forçar o tráfego de gestão a passar por inspeção local.
  • O AzureFirewallSubnet encaminha o tráfego de cargas de trabalho com destino à Internet para um firewall no local ou um dispositivo virtual de rede (NVA) de terceiros através do ExpressRoute ou do Gateway de VPN.
  • As regras DNAT não são suportadas no modo de tunelamento forçado porque o tráfego de entrada não consegue aceder diretamente ao IP público do firewall.
  • A firewall não necessita de um IP público no AzureFirewallSubnet quando configura o tunelamento forçado, porque todo o tráfego de saída é encaminhado através da via local.

Utilize o tunelamento forçado quando os requisitos de conformidade exigirem visibilidade no local de todo o tráfego destinado à Internet, ou quando for necessário encadear o Azure Firewall com uma pilha de segurança no local existente. Cenários comuns incluem ambientes de serviços financeiros sujeitos a regulamentos de residência de dados e redes governamentais com requisitos centralizados de integração da internet.

Importante

No modo de tunelamento forçado, o AzureFirewallManagementSubnet requer um endereço IP público próprio e uma UDR com 0.0.0.0/0 que aponta para a Internet como próximo salto. Esta configuração garante que o Azure pode manter o canal de gestão para o firewall.

Inspeção de TLS (Premium)

O Azure Firewall Premium interceta ligações HTTPS de saída, desencripta o tráfego, inspeciona-o contra assinaturas IDPS e regras de aplicação, e depois volta a encriptá-lo e encaminha-o. Este processo requer um certificado de CA intermédio armazenado no Azure Key Vault.

Requisitos de certificação

Requisito Especificação
Tipo de certificado CA Intermédio
Tamanho da chave RSA mínimo de 2048 bits
Bandeira da Califórnia TRUE
Utilização da chave KeyCertSign
Validade Pelo menos 1 ano daqui
Armazenamento Azure Key Vault (deve ser exportável)

O firewall utiliza o certificado intermédio da CA para gerar dinamicamente certificados de servidor para ligações intercetadas. Os navegadores e as aplicações dos utilizadores finais devem confiar na CA raiz da organização ou na CA intermédia no respetivo repositório de certificados para evitar avisos de confiança.

IDPS

A SKU Premium inclui um motor de IDPS totalmente gerido com mais de 67.000 regras em mais de 50 categorias. As assinaturas são atualizadas continuamente com mais de 20 a 40 novas regras introduzidas diariamente. O IDPS opera em dois modos:

  • Modo de alerta: Regista correspondências de assinatura sem bloquear tráfego. Uso durante a implantação inicial e afinação.
  • Modo de Alerta e Negação: Regista e bloqueia o tráfego que corresponde às assinaturas IDPS. Uso em produção após a afinação.

As categorias IDPS abrangem comando e controlo de malware, phishing, trojans, botnets, kits de exploração, vulnerabilidades e protocolos SCADA/ICS.

Atenção

A inspeção TLS introduz latência e tem implicações para a privacidade. Assegure que as equipas jurídicas e de conformidade da sua organização aprovam a inspeção do tráfego encriptado. Exclua categorias sensíveis (saúde, banca) conforme necessário, utilizando regras de bypass.

Filtragem de saída AKS

Quando os clusters do Azure Kubernetes Service (AKS) requerem tráfego de saída controlado, o Azure Firewall fornece filtragem de saída baseada em FQDN para os nós do cluster. Sem filtragem de saída, os nós AKS podem alcançar qualquer endpoint da internet, o que aumenta a superfície de ataque para ataques de cadeia de abastecimento e exfiltração de dados.

Para implementar este padrão:

  1. Implementar o AKS com outboundType definido como userDefinedRouting e uma tabela de rotas personalizada na sub-rede do nó.
  2. Defina a rota padrão (0.0.0.0/0) para o IP privado do Azure Firewall.
  3. Crie regras de aplicação na política de firewall que permitam os FQDNs necessários do AKS (registos de contentores, pontos finais do servidor de API, repositórios de pacotes da Microsoft).
  4. Criar regras de rede para os endpoints obrigatórios não HTTP/S (NTP, DNS, conectividade por túnel).

Este padrão dá às equipas de segurança visibilidade e controlo sobre o que os endpoints externos dos nós AKS podem alcançar, permitindo ao mesmo tempo que o cluster funcione corretamente. Os FQDNs exigidos variam consoante o conjunto de funcionalidades do AKS. Os clusters que utilizam nós com GPU, o Azure Monitor ou o Azure Policy exigem entradas adicionais na lista de permissões aprovada.

Para obter requisitos detalhados de FQDN e exemplos de regras, consulte Utilizar o Azure Firewall para proteger implementações do AKS.

Note

A filtragem de saída do AKS com o Azure Firewall requer uma coordenação cuidadosa entre as equipas da plataforma e da aplicação. A falta de regras de FQDN causa falhas no agendamento de pods e erros ao obter imagens. Comece com uma política permissiva e endureça depois de observar padrões de tráfego nos registos de firewall.

Considerações de design

Foco na conceção de firewalls em lift-and-shift

  • Traduza regras de firewall on-premises para a política Azure Firewall: use regras de rede para protocolos não HTTP/S e regras de aplicação para destinos HTTP/S ou MSSQL que necessitem de filtragem FQDN.
  • Comece com regras gerais de permitir que reflitam a sua postura de segurança atual, depois aperte-as após a migração usando os logs do Azure Firewall para identificar os destinos e portas necessários.
  • Use Grupos IP para modelar as zonas de origem e destino para que a manutenção das regras siga os limites de segmentação existentes.
  • Ative as definições de diagnóstico no primeiro dia para poder comparar os padrões de tráfego do Azure com a sua linha de base local antes de restringir o acesso.

Modernizar o foco do design de firewalls

  • Utilize o firewall do hub como ponto centralizado de SNAT e DNAT para os spokes de aplicações, para que a política de tráfego de entrada e de saída permaneça no hub gerido pela equipa de TI.
  • Ative o Azure Firewall Premium quando for necessária a inspeção TLS leste-oeste ou a aplicação do IDPS em ambiente de produção entre as camadas da aplicação.
  • Utilize etiquetas FQDN e regras de aplicação para permitir dependências PAAS do AKS e do Azure sem manter grandes listas de IP de destino.
  • Reveja os requisitos de DNAT no contexto da arquitetura do Front Door ou do Application Gateway, para garantir que o tráfego de entrada chega aos segmentos spoke de back-end apenas através de percursos de inspeção aprovados.

Foco na conceção de firewalls entre clouds

  • Implemente o Azure Firewall num hub virtual seguro quando o Azure for o ponto de trânsito para branch, Azure e outras redes cloud.
  • Utilize regras de rede para inspecionar o tráfego do túnel IPSec proveniente do AWS Transit Gateway, de gateways privados virtuais da AWS ou de ligações da VPN do Google Cloud após as rotas chegarem ao Azure.
  • Permitir que os IDPs detetem padrões anómalos de tráfego este-oeste e trans-nuvens que possam indicar movimentos laterais entre ambientes cloud.
  • Ative o filtro de inteligência de ameaças para bloquear destinos maliciosos conhecidos em todas as clouds ligadas com uma única superfície de política.

Pré-requisitos

Antes de implementar o Azure Firewall:

  • AzureFirewallSubnet: A sua rede virtual hub deve incluir uma sub-rede dedicada nomeada AzureFirewallSubnet com um tamanho mínimo de /26. Consulte Design de redes virtuais e sub-redes para orientações sobre planeamento de sub-redes.
  • Topologia hub-spoke ou WAN Virtual: Implemente o Azure Firewall num hub central que encaminha o tráfego proveniente de redes spoke. Consulte Topologia Hub-spoke ou WAN Virtual para opções de topologia.
  • Plano de endereços IP: Reserve espaço de endereçamento para a sub-rede do firewall, sub-rede de gestão (se usar tunelamento forçado) e quaisquer endereços IP públicos. Ver planeamento de endereços IP.
  • Azure Firewall Manager: Use o Azure Firewall Manager se precisar de uma hierarquia de políticas que partilhe regras base entre várias instâncias de firewall.
  • Espaço de trabalho Log Analytics: Crie um espaço de trabalho para registos de diagnóstico do firewall antes da implementação, para que possa monitorizar o tráfego e resolver regras desde o primeiro dia.

Considerações de segurança

  • Logs: Ative as definições de diagnóstico para enviar os logs do Azure Firewall para um espaço de trabalho do Log Analytics. Registos estruturados fornecem visibilidade ao nível de FQDN sobre todas as ligações permitidas e negadas, apoiando auditoria e análise forense.
  • Disponibilidade: Implemente o Azure Firewall em várias zonas de disponibilidade para maximizar o seu SLA de disponibilidade. Para as percentagens atuais de SLA, veja SLA for Azure Firewall.
  • Defesa em camadas: Azure Firewall complementa, mas não substitui, os NSGs. Aplicar NSGs ao nível da sub-rede e da interface de rede (NIC) para a microssegmentação. Use o firewall para políticas centralizadas, inteligência de ameaças e inspeção de Camada 7.
  • Dimensione corretamente o que inspeciona: Forçar todos os fluxos a passar pelo firewall, incluindo camadas internas da aplicação, como web para aplicação e aplicação para base de dados, acrescenta latência e custos de processamento por gigabyte. Utilize NSGs e ASGs para o tráfego este-oeste entre camadas de confiança e reserve a inspeção pelo firewall para o tráfego que atravessa um limite de confiança: destinado à Internet, entre spokes, híbrido ou entre nuvens. Esta abordagem mantém o firewall focado no tráfego que beneficia da inspeção e evita custos desnecessários.
  • Proteção DDoS: Proteja IPs públicos associados ao Azure Firewall usando o Azure DDoS Protection. Veja proteção DDoS.
  • Tráfego do ExpressRoute: Quando utilizar o ExpressRoute, configure UDRs para direcionar o tráfego de peering privado através do Azure Firewall, para inspecionar os fluxos de tráfego híbrido.

Saiba mais

Passos seguintes

Dica

Explorar sozinho? Volte ao navegador de visão geral para encontrar o seu próximo artigo por capacidade.

A seguir na sua jornada de levantar e deslocar:

Configure monitorização para a sua rede migrada: Valide a conectividade e o desempenho com o Observador de Rede depois de configurar o firewall.

Próximo passo na sua jornada de modernização:

Proteja as suas aplicações web com WAF: Adicione Firewall de Aplicações Web na Front Door ou Application Gateway para as suas aplicações web voltadas para o cliente.

A seguir na sua jornada através da cloud:

Configure a monitorização multicloud: Os ambientes multicloud são operacionalmente mais difíceis de diagnosticar e resolver. A monitorização é essencial, não opcional.

  • Last updated on