Firewall de Aplicativo Web para redes de Azure

Firewall de Aplicativo Web do Azure (WAF) protege seus aplicativos Web contra ataques comuns de camada HTTP, como injeção de SQL, XSS (script entre sites) e passagem de caminho. Ao contrário de Firewall do Azure, que inspeciona o tráfego nas Camadas 3 a 7 para ameaças no nível da rede, o WAF opera apenas na Camada 7 e entende a semântica HTTP, incluindo cabeçalhos de solicitação, cadeias de consulta, corpos de solicitação e cookies. Implante o WAF como uma política associada ao Gateway de Aplicativo do Azure (regional) ou ao Azure Front Door (borda global) para alinhar o escopo de proteção à arquitetura da sua aplicação. Firewall de Aplicativo Web é um dos três principais serviços de segurança de rede do Azure, junto com o Firewall do Azure e o Azure DDoS Protection.

O que este artigo aborda

Este artigo aborda a proteção de camada HTTP usando Firewall de Aplicativo Web do Azure. Você saberá mais sobre:

• Comparação de plataforma entre WAF no Gateway de Aplicativo v2 e WAF no Azure Front Door.
• Conjuntos de regras baseados em OWASP, incluindo DRS (Conjunto de Regras Padrão) e CRS (Conjunto de Regras Principais).
• Modo de detecção versus modo de prevenção e quando usar cada um.
• Opções de escopo de política do WAF: associações globais, por site e por ouvinte.
• Regras personalizadas para limitação de taxa, filtragem geográfica e lógica específica do aplicativo.
• A distinção entre WAF (CAMADA 7 HTTP) e Firewall do Azure (rede camadas 3 a 7).

Quem precisa deste artigo

Implante o WAF quando suas cargas de trabalho atenderem a um ou mais dos seguintes critérios:

• Aplicativos Web voltados para o público: Seus aplicativos aceitam o tráfego HTTP/HTTPS de entrada da Internet, expondo-os a vulnerabilidades do OWASP Top 10, incluindo ataques de injeção, abuso de autenticação interrompido e tentativas de exposição de dados confidenciais.
• Requisitos de conformidade: Estruturas regulatórias como o PCI DSS (Payment Card Industry Data Security Standard) exigem um firewall de aplicativo Web na frente de qualquer aplicativo que processe dados de cartão de pagamento.
• Proteção de API: Suas APIs são publicamente acessíveis e exigem proteção contra contrabando de solicitações, cargas superdimensionadas e ataques no nível do protocolo que os firewalls de rede não inspecionam.
• Mitigação do bot: Você precisa categorizar e controlar o tráfego automatizado, bloqueando bots mal-intencionados, permitindo rastreadores legítimos e serviços de monitoramento.

As organizações que precisam apenas de filtragem de tráfego no nível da rede (IP, porta e protocolo) sem inspeção de solicitação HTTP devem usar Firewall do Azure ou NSGs.

Comparação da plataforma WAF do Azure

Azure WAF está disponível em duas plataformas. Cada plataforma integra a inspeção do WAF em um ponto diferente no fluxo de tráfego.

Como escolher sua plataforma WAF

Use os seguintes critérios de decisão:

• Escolha WAF no Gateway de Aplicativo quando seu aplicativo é implantado em uma única região e você já usa o Gateway de Aplicativo para balanceamento de carga da Camada 7, terminação TLS ou roteamento baseado em caminho. O WAF adiciona inspeção HTTP em linha sem introduzir um salto adicional de serviço.
• Escolha WAF em Azure Front Door quando seu aplicativo abrange várias regiões, requer balanceamento de carga global ou benefícios da aceleração da CDN (rede de distribuição de conteúdo). O WAF do Front Door inspeciona o tráfego no ponto de presença de borda mais próximo (PoP). O serviço bloqueia solicitações mal-intencionadas antes que elas percorram o backbone Azure para alcançar sua origem. Essa abordagem reduz a exposição da superfície de ataque e absorve ataques volumétricos de Camada 7 na borda.
• Escolha as duas opções (em camadas) quando um aplicativo multirregional atendido pelo Front Door também exigir políticas regionais de WAF diferentes para cada back-end. O Front Door fornece proteção global na primeira linha, enquanto o WAF do Application Gateway aplica regras personalizadas específicas da região mais perto da carga de trabalho.

Considerações sobre o design

Pré-requisitos

Antes de implantar Firewall de Aplicativo Web do Azure, verifique se você tem:

• Application Gateway v2 ou recurso do Azure Front Door: o WAF é implantado como uma política associada a uma dessas plataformas. Você deve ter uma instância existente do Application Gateway v2 ou um perfil do Azure Front Door provisionado antes de criar e associar uma política de WAF.
• Carga de trabalho HTTP/HTTPS voltada para o público: Seu aplicativo deve receber tráfego HTTP/HTTPS de entrada. O WAF inspeciona a semântica no nível da solicitação e não oferece nenhum benefício para cargas de trabalho não HTTP ou serviços puramente internos.
• Noções básicas sobre padrões de tráfego HTTP: A familiaridade com os padrões normais de solicitação do aplicativo (cabeçalhos, parâmetros de consulta e conteúdo do corpo) ajuda você a configurar exclusões e ajustar regras para minimizar falsos positivos durante a transição do modo detecção para prevenção.

Conjuntos de regras e processamento de regras

O WAF usa conjuntos de regras para detectar padrões mal-intencionados em solicitações HTTP. Entender a hierarquia de regras e a ordem de processamento ajuda você a ajustar o WAF para seus aplicativos específicos.

Conjuntos de regras gerenciadas

Microsoft mantém conjuntos de regras gerenciadas com base nos padrões do CRS (Conjunto de Regras Principais do OWASP). O conjunto de regras recomendado para novas implantações é DRS 2.2 (Conjunto de Regras Padrão). O DRS 2.2 baseia-se no OWASP CRS 3.3.4 e adiciona assinaturas de Inteligência contra Ameaças da Microsoft.

Os conjuntos de regras DRS e CRS usam pontuação de anomalias. Cada regra de correspondência contribui com uma pontuação em vez de bloquear imediatamente a solicitação. Quando a pontuação de anomalia cumulativa excede um limite configurável, o WAF toma uma ação (bloquear ou registrar em log). Essa abordagem reduz os falsos positivos em comparação com o bloqueio por regra individual, porque uma única correspondência de baixa confiança não aciona a aplicação.

Regras personalizadas

As regras personalizadas são executadas antes das regras gerenciadas e usam números de prioridade para controlar a ordem de avaliação (número inferior = prioridade mais alta). Use regras personalizadas para:

• Limitação de taxa: Restrinja solicitações para cada IP do cliente dentro de uma janela de tempo para atenuar o recheio de credenciais e ataques de força bruta.
• Filtragem geográfica: Permitir ou negar o tráfego com base no país ou região de origem do cliente.
• Listas de permissão de IP e listas de bloqueio: Permitem autorizar IPs de parceiros conhecidos ou bloquear agentes mal-intencionados conhecidos antes de as regras gerenciadas serem avaliadas.
• Inspeção de cabeçalho de solicitação: Impor requisitos específicos do aplicativo, como chaves de API obrigatórias ou tipos de conteúdo esperados.

Conjunto de regras de proteção contra bots

Ambas as plataformas oferecem um conjunto de regras de proteção contra bots que categoriza o tráfego automatizado em bons bots (mecanismos de pesquisa verificados), bots incorretos (scanners mal-intencionados conhecidos) e bots desconhecidos. Configurar ações para cada categoria: permitir bots bons, bloquear bots maliciosos e submeter bots desconhecidos a desafios com limitação de taxa de requisições ou CAPTCHA.

Modo de detecção vs. modo de prevenção

As políticas do WAF operam em um dos dois modos que determinam como o sistema lida com solicitações correspondentes:

Fluxo de trabalho de ajuste recomendado

1. Implante no modo de detecção: Habilite o WAF com o conjunto de regras selecionado no modo de detecção. Direcione o tráfego de produção por meio do WAF.
2. Analise os logs: Revise os logs do WAF para identificar falsos positivos. Identifique as regras que são acionadas por tráfego legítimo de aplicativos.
3. Criar exclusões: Para regras que geram falsos positivos, defina exclusões que especificam os campos de solicitação (cabeçalhos, cookies e parâmetros de consulta) para ignorar regras específicas.
4. Alterne para o modo de Prevenção: Após 1–2 semanas de logs de detecção sem ocorrências, com taxas de falsos positivos aceitáveis, alterne para o modo de Prevenção para realizar o bloqueio ativo.
5. Monitoramento contínuo: Continue monitorando os logs depois de alternar para o modo de Prevenção. Novos recursos do aplicativo ou alterações na API podem introduzir novos padrões de falsos positivos.

Escopo e associação da política do WAF

Uma política de WAF é um recurso autônomo do Azure que contém sua seleção do modo, a configuração do conjunto de regras, regras personalizadas e exclusões. Associe a política a um ou mais destinos para controlar o escopo de proteção.

Escopo da política de WAF do Application Gateway

No Application Gateway, associe uma política WAF em três níveis de granularidade:

• Global (em todo o gateway): A política se aplica a todos os ouvintes e às regras de caminho no Gateway de Aplicativo. Use o escopo global quando todos os aplicativos por trás do gateway compartilharem os mesmos requisitos de proteção.
• Nível do ouvinte: Uma política de WAF diferente se aplica a um ouvinte específico (nome do host e combinação de porta). Use o escopo no nível do listener quando vários aplicativos compartilharem um gateway, mas precisarem de ajustes de regras ou exclusões diferentes.
• Nível da regra de caminho: Uma política de WAF é aplicada a uma regra de caminho de URL específica em um ouvinte. Use o escopo da regra de caminho para um controle mais granular sobre aplicações com diferentes níveis de sensibilidade de back-end.

Quando vários escopos se aplicam a uma única requisição, a política mais específica prevalece: a regra de caminho prevalece sobre o nível do listener, que prevalece sobre o global.

Escopo da política do WAF do Front Door

No Front Door, as políticas do WAF são associadas no nível do endpoint ou da rota. Cada endpoint do Front Door pode ter sua própria política de WAF. Essa abordagem permite perfis de proteção específicos do aplicativo em uma única instância do Front Door.

Compartilhamento de políticas entre recursos

Compartilhe uma única política de WAF entre várias instâncias do Gateway de Aplicativo ou endpoints do Front Door. Gerenciador de Firewall do Azure fornece visibilidade centralizada e gerenciamento em todas as políticas do WAF, independentemente da plataforma. Use políticas compartilhadas quando vários recursos exigirem proteção idêntica para simplificar o gerenciamento e manter a postura de segurança consistente.

Distinção de Firewall do Azure

WAF e Firewall do Azure protegem diferentes camadas da pilha de rede e desempenham funções complementares. Implemente ambos para defesa em profundidade.

Use o WAF para proteção de aplicativo HTTP e Firewall do Azure para inspeção centralizada de tráfego de rede. Em uma arquitetura hub-spoke, o tráfego da Internet para um aplicativo Web normalmente flui por Firewall do Azure (para inspeção no nível de rede e DNAT) e, em seguida, por meio do Gateway de Aplicativo com WAF (para inspeção de camada HTTP). Consulte Firewall do Azure e inspeção de tráfego para o componente de nível de rede.

Considerações de segurança

As seguintes práticas de segurança ajudam você a obter o máximo de proteção do WAF:

• Modo de prevenção para produção: Nunca deixe cargas de trabalho de produção no modo de detecção. O modo de detecção fornece visibilidade, mas nenhuma imposição, deixando os aplicativos expostos a ataques.
• O ajuste de regra está em andamento: Os aplicativos evoluem. Novos endpoints de API, parâmetros e tipos de conteúdo podem gerar falsos positivos em conjuntos de regras existentes. Examine os logs do WAF regularmente após as implantações.
• Integração com o Log Analytics: Enviar logs de diagnóstico do WAF para um workspace do Log Analytics. Use a workbook do WAF para visualizar solicitações bloqueadas, regras acionadas e a distribuição das pontuações de anomalia.
• DDoS e WAF juntos: O WAF protege contra ataques de aplicativo de camada 7, mas não reduz ataques DDoS de camada de rede volumétrica. Combine o WAF com Proteção contra DDoS do Azure para proteção em toda a pilha.
• Restrição de origem: Quando você usa o Front Door WAF, configure sua origem para aceitar tráfego somente da tag de serviço do Front Door. Sem bloqueio de origem, os invasores podem ignorar o Front Door e enviar solicitações diretamente para seu endereço IP de origem.
• Proteção de dados confidenciais: Os logs do WAF podem conter dados de solicitação. Configure regras de sanitização de logs para mascarar campos sensíveis (cabeçalhos de autorização, cookies ou conteúdo do corpo da solicitação) nos logs de diagnóstico do WAF.

Artigos relacionados

Os artigos a seguir abordam os tópicos de segurança de rede relacionados:

• Entrada da Internet e roteamento de tráfego: padrões de entrada para aplicativos voltados para o público.
• Serviços de entrega de aplicações: Application Gateway e Front Door como plataformas de entrega.
• Firewall do Azure e inspeção de tráfego: inspeção em nível de rede que complementa a proteção da Camada 7 do WAF.
• Proteção contra DDoS: proteção contra ataques volumetricos para endereços IP públicos.
• O que é Azure Network Security?: Hub de visão geral que compara Firewall do Azure, DDoS Protection e Firewall de Aplicativo Web.

Saiba mais

• Visão geral do Firewall do Aplicativo Web do Azure
• WAF no Gateway de Aplicativo
• WAF no Azure Front Door
• Visão geral da política WAF
• Grupos de regras e regras do CRS do Firewall de Aplicações Web
• Ajustando o Firewall de Aplicativo Web para o Azure Front Door

Próximas Etapas