Entrada na Internet: expõe a sua aplicação à internet

Este artigo ajuda-o a escolher o serviço Azure certo para tornar a sua candidatura acessível pela internet. Compara endereços IP públicos, Balanceador de Carga do Azure, Application Gateway, Azure Front Door e Gestor de Tráfego do Azure. Escolha a opção que se adapte ao protocolo, escala e requisitos de segurança da sua carga de trabalho.

O que este artigo aborda

Cada carga de trabalho do Azure que serve utilizadores externos precisa de um caminho de entrada: uma forma de o tráfego da internet chegar à sua aplicação de forma segura e fiável. Escolher o serviço de entrada errado leva a sobreprovisionamento, falhas de segurança ou complexidade desnecessária. Este artigo ajuda-o a avaliar sete serviços Azure que aceitam ligações de entrada de utilizadores externos e encaminham essas ligações para os seus recursos de backend dentro de uma rede virtual. Pode selecionar a combinação que corresponde ao seu protocolo, escala, geografia e postura de segurança.

Note

Este artigo foca-se em como o tráfego entra na sua rede Azure a partir da internet. Para saber como equilibrar e entregar esse tráfego através dos backends das suas aplicações (incluindo comparações detalhadas do Balanceador de Carga do Azure, Application Gateway e Azure Front Door), veja entrega e desempenho das aplicações.

Quem precisa deste artigo

Leia este artigo se uma ou mais destas condições se aplicarem:

• A sua aplicação deve aceitar ligações de entrada de utilizadores ou sistemas na internet.
• Tens de escolher entre IP Público, Balanceador de Carga, Application Gateway, Front Door ou Traffic Manager, consoante o protocolo e o âmbito.
• Precisa de desenhar um ponto de entrada público seguro para cargas de trabalho web, API ou TCP/UDP.
• É necessário combinar exposição à internet com WAF, proteção DDoS, terminação TLS ou distribuição de tráfego regional e global.

Dica

Seguir um caminho de cenário? Selecione o seu cenário no topo da página para obter orientação personalizada. As orientações principais que se seguem aplicam-se a todos os leitores.

Foco em levantar e deslocar: A sua aplicação migrada deve ser acessível a partir da internet. Avalie se precisa de Application Gateway, Front Door ou uma abordagem mais simples de IP pública. Muitas cargas de trabalho lift-and-shift são apenas internas, por isso pode saltar este artigo completamente se as suas aplicações migradas não servirem utilizadores externos.

Leia este artigo se:

• Estão a migrar uma aplicação web local para o Azure e precisam de decidir como a expor publicamente.
• É necessário avaliar se a entrada na internet é necessária para as suas cargas de trabalho migradas.
• Quero perceber qual a opção de entrada mais simples pronta para produção numa aplicação elevada.

Foco na modernização: Os padrões de tráfego voltados para o cliente determinam a forma externa da sua arquitetura. A Front Door gere aplicações web, o Traffic Manager gere aplicações móveis e API. As cargas de trabalho PaaS modernizadas (App Service, AKS) precisam de um percurso de entrada bem definido que se integre no seu modelo de segurança hub-and-spoke.

Leia este artigo se:

• Implemente uma aplicação pública que os utilizadores externos acedam pela internet.
• Preciso de escolher entre Azure Front Door para aplicações web e Traffic Manager para cargas móveis ou API.
• Quero perceber como o Ingress se integra com o firewall do seu hub como alvo DNAT.
• É necessário proteger os endpoints virados para a internet com um firewall de aplicações web (WAF) ou proteção DDoS.

Foco cruzado na cloud: Só inclua acesso à internet se a aplicação migrada for pública. Muitas aplicações multinuvem são de uso exclusivamente interno, comunicando entre diferentes nuvens através de caminhos de trânsito privados. Se a sua carga de trabalho for pública (por exemplo, uma aplicação web voltada para o cliente migrada de outra nuvem), precisa de um caminho de entrada no Azure.

Leia este artigo se:

• Estão a migrar uma aplicação pública da AWS ou Google Cloud para o Azure?
• Preciso de Application Gateway com WAF num VNet spoke para a carga de trabalho migrada.
• Quero evitar a atribuição direta de IP público às VMs durante a migração cross-cloud.

Serviços e funcionalidades do Azure

O Azure oferece vários serviços para entrada na internet. Cada serviço opera numa camada diferente da pilha de rede e serve um caso de uso distinto.

Serviço	Camada	Scope	O que oferece	Quando usar
Endereço IP público (SKU Padrão)	3	Regional	Endereço IPv4 ou IPv6 roteável atribuído diretamente. Redundante de zona por defeito.	Cenários simples e de pouco tráfego. Não recomendado para produção sem um balanceador de carga.
Balanceador de Carga do Azure (Standard, público)	4 (TCP/UDP)	Regional	Distribui o tráfego de entrada TCP/UDP entre as VMs de backend. Front-end com redundância entre zonas. As sondas de saúde removem casos de doença.	Cargas de trabalho não-HTTP/S que exigem alta disponibilidade. Servidores de jogos, endpoints IoT ou outros serviços TCP/UDP.
Balanceador de Carga do Azure (Standard, interno)	4 (TCP/UDP)	Regional	Balanceamento de carga da Camada 4 dentro de uma rede virtual. Sem IP público. Encaminha o tráfego entre níveis internos.	Aplicações multi-nível onde uma interface pública distribui para VMs backend. Trânsito este-oeste em cubo e raio. Não está diretamente exposto à Internet, mas é normalmente associado a um serviço de entrada público.
Gateway de Aplicação do Azure	7 (HTTP/S)	Regional	Balanceamento de carga HTTP/S com encaminhamento baseado em URL, terminação SSL/TLS, afinidade de sessão e autoescalonamento.	Aplicações HTTP/S de região única que requerem roteamento baseado em caminhos, afinidade baseada em cookies ou descarregamento SSL.
Gateway de Aplicações + WAF	7 (HTTP/S)	Regional	Porta de entrada de aplicações com firewall de aplicações Web. Protege contra os 10 principais ataques do OWASP usando o Conjunto de Regras Padrão (DRS), incluindo as regras de Inteligência de Ameaças da Microsoft.	Aplicações web públicas que requerem balanceamento de carga de Camada 7 e proteção WAF numa única região.
Azure Front Door	7 (HTTP/S)	Global	Balanceador de carga Global HTTP/S com CDN, WAF e encaminhamento de tráfego integrados. Termina as ligações TCP/TLS nos PoPs periféricos próximos dos utilizadores através da aceleração Split TCP.	Aplicações multi-região com uma base de utilizadores global. Cargas de trabalho que exijam cache de CDN, WAF global e failover automático.
Gestor de Tráfego do Azure	DNS	Global	Encaminhamento de tráfego baseado em DNS. Devolve um CNAME ao endpoint regional mais próximo ou saudável. Os clientes ligam-se diretamente. O Traffic Manager nunca vê o tráfego da aplicação.	Failover multi-região ao nível de DNS. Protocolos não-HTTP/S onde o Front Door não se aplica. Encaminhamento por geografia, desempenho ou prioridade.

Note

Os IPs públicos básicos do SKU são retirados (setembro de 2025). Os IPs Básicos existentes continuam operacionais, mas deixam de ter suporte e ficam sem SLA. Use o SKU Standard para todas as novas implementações.

Como funciona cada serviço

Compreender a arquitetura interna de cada serviço ajuda-o a prever desempenho, resolver problemas e planear o tamanho das sub-redes.

Endereço IP público

Um IP público de SKU Standard é um recurso definido por software que mapeia um endereço IPv4 ou IPv6 roteável diretamente para uma interface de rede, frontend de balanceador de carga ou gateway. O endereço tem, por predefinição, redundância entre zonas nas regiões suportadas, o que significa que a plataforma gere o failover entre zonas de disponibilidade sem que tenha de fazer qualquer alteração. IPs públicos não têm processamento de tráfego. Os pacotes fluem diretamente para o recurso associado sem lógica de verificação de saúde ou distribuição.

Balanceador de Carga do Azure (Standard, público)

O Balanceador de Carga Standard utiliza um algoritmo de distribuição baseado em hash ao longo de fluxos de 5 tuplas (IP de origem, porta de origem, IP de destino, porta de destino, protocolo). Opera inteiramente no caminho de dados na Camada 4, pelo que nunca termina ligações nem inspeciona cargas úteis. As sondas de saúde (TCP, HTTP ou HTTPS) sondam continuamente as instâncias do backend e removem instâncias não saudáveis da rotação em segundos. Balanceador de Carga escala automaticamente. Não há planeamento de capacidade nem dimensionamento das instâncias.

Balanceador de Carga do Azure (Standard, interno)

O Balanceador de Carga interno funciona da mesma forma que o seu equivalente público, mas utiliza um IP de frontend privado da sub-rede virtual. Distribui o tráfego entre camadas internas, como uma camada web que envia tráfego para um cluster de API de nível intermédio. Como não tem IP público, é invisível para a internet. Emparelha-o com um serviço público de entrada, como Front Door, Application Gateway ou um Balanceador de Carga público, que gere a fronteira externa.

Gateway de Aplicação do Azure

O Application Gateway é um dispositivo virtual dedicado implementado na sua sub-rede de rede virtual. Termina as ligações TLS no gateway, inspeciona cabeçalhos HTTP e URLs, e encaminha pedidos para pools de backend com base em regras de caminho, cabeçalhos de anfitrião ou sondas de estado de funcionamento personalizadas. O SKU v2 suporta dimensionamento automático (de 0 a 125 instâncias) e redundância entre zonas. Por ser residente em VNet, pode aceder a backends privados sem precisar de IPs públicos nesses backends.

Gateway de Aplicações com WAF

Quando adiciona o nível WAF, ativa o OWASP Core Rule Set e as regras de Microsoft Threat Intelligence diretamente no pipeline de processamento do Application Gateway. Cada pedido HTTP passa pelo motor WAF antes de chegar às regras de encaminhamento. O WAF suporta políticas por site, por isso pode ter diferentes configurações de regras para diferentes combinações de ouvinte ou host no mesmo gateway. O WAF funciona no modo de Deteção (apenas registo) ou no modo de Prevenção (bloqueio e registo).

Azure Front Door

O Front Door opera a partir da rede global edge da Microsoft (190+ pontos de presença). Quando um utilizador estabelece uma ligação, o handshake TCP e a negociação TLS ocorrem no ponto de presença mais próximo através do Split TCP. O ponto de presença mantém uma ligação quente persistente à sua origem, eliminando assim a latência de arranque a frio que os utilizadores experienciariam ao ligar diretamente. O Front Door efetua o encaminhamento de camada 7, a inspeção WAF, o armazenamento em cache e a compressão na periferia da rede antes de encaminhar o pedido para a origem operacional mais próxima pela rede de backbone da Microsoft.

Gestor de Tráfego do Azure

O Traffic Manager é um serviço baseado em DNS, sem envolvimento de caminhos de dados. Quando um cliente resolve o nome de anfitrião do Traffic Manager, este devolve um CNAME que aponta para o endpoint em melhor estado de funcionamento ou mais próximo, com base no método de encaminhamento que configurou (prioridade, ponderado, desempenho, geográfico, multivalor ou sub-rede). O Gestor de Tráfego sonda continuamente a saúde dos endpoints e atualiza as respostas DNS em conformidade. Como nunca detém tráfego de aplicações, funciona com qualquer protocolo: HTTP, TCP, UDP ou protocolos proprietários.

Comparação de modelos de custos

Cada serviço de entrada segue um modelo de faturação diferente. Use esta tabela para estimar os custos com o volume de tráfego esperado.

Serviço	Modelo de faturação	Principais fatores de custo	Nível gratuito ou funcionalidades incluídas
Endereço IP público	Por hora (anexado) + por GB de saída	Número de horas associadas; custos de saída	Primeiros 100 GB de tráfego de saída por mês gratuitos (global)
Balanceador de Carga Standard	Por hora por regra + por GB processado	Número de regras de balanceamento de carga; dados processados através do LB	None
Gateway de Aplicação	Por hora por instância + unidades de capacidade consumidas	Horas de instância; Unidades de Capacidade de Computação, Ligação e Débito	None
Gateway de Aplicações + WAF	Por hora e por instância (preços por escalão do WAF) + unidades de capacidade	Igual ao Application Gateway, mas com a tarifa horária do nível WAF	None
Azure Front Door	Por solicitação + transferência por GB + solicitações do WAF	Pedidos de encaminhamento, transferência de dados do edge para o cliente, avaliação das regras de WAF	O nível padrão inclui algum encaminhamento básico
Gestor de Tráfego do Azure	Por milhão de consultas DNS + por ponto terminal de verificação de estado	Volume de consultas DNS; Número de pontos finais monitorizados	As primeiras 1 mil milhões de consultas têm preços escalonados

Dica

Para cargas de trabalho de baixo tráfego (menos de 1 milhão de pedidos por mês), o modelo por pedido do Front Door pode ser mais económico do que o custo fixo por hora do Application Gateway. À medida que o tráfego cresce, os modelos por hora tornam-se mais previsíveis. Execute a Calculadora de Preços do Azure com o seu throughput esperado para comparar.

Como escolher

Use as seguintes tabelas de decisão para selecionar o serviço de entrada adequado para a sua carga de trabalho. Começa pela tabela de decisão de alto nível, depois usa a comparação detalhada para confirmar a tua escolha.

Comparação entre o Application Gateway, o Front Door e o Traffic Manager

Esta tabela ajuda-o a escolher entre os três serviços de entrada HTTP e HTTPS mais comuns.

A sua necessidade	Serviço recomendado	Porquê
Tráfego HTTP/S, região única, proteção WAF	Gateway de Aplicações com WAF	serviço regional de camada 7 com encaminhamento baseado no caminho e WAF. É executado na sua rede virtual.
Tráfego HTTP/S, multi-região, utilizadores globais, CDN + WAF	Azure Front Door	Serviço global de camada 7 terminado nos PoPs de edge. CDN, WAF e failover automático integrados.
Encaminhamento multi-região para protocolos não-HTTP/S, ou apenas encaminhamento ao nível de DNS	Gestor de Tráfego do Azure	Encaminhamento baseado em DNS que funciona com qualquer protocolo. Sem terminação da ligação.
HTTP/S multirregional com requisitos regionais de processamento vinculados a uma VNet	Gateway de Aplicações + Gestor de Tráfego	Válido para cargas de trabalho que requerem integração profunda na VNet ou soberania regional de dados com inspeção regional por WAF. Na maioria dos cenários HTTP/S em várias regiões, prefira o Front Door em vez disso.

Dica

Para a maioria das cargas de trabalho HTTP e HTTPS multirregião, o Front Door é a escolha preferida em relação ao Application Gateway combinado com o Traffic Manager. O Front Door oferece WAF, CDN e failover automático integrados, sem necessidade de gerir várias instâncias regionais do Application Gateway. A combinação Application Gateway + Traffic Manager mantém-se válida para cargas de trabalho que requerem processamento regional ligado a VNet, origens Private Link acessíveis apenas dentro de um VNet, ou requisitos regulatórios que exigem soberania regional de dados.

Comparação de serviços de entrada

Use esta comparação detalhada quando precisar de compreender as capacidades de cada serviço.

Serviço	Camada	Global ou regional	Terminação da ligação	WAF disponível	Sondas de saúde	Melhor para
Endereço IP público	3	Regional	Não (direto para a VM)	No	No	Cargas de trabalho de desenvolvimento/teste, instância única sem necessidade de HA
Balanceador de Carga Standard (público)	4	Regional	Não (passo)	No	Sim (TCP, HTTP, HTTPS)	Cargas de trabalho não-HTTP: jogos, IoT, TCP/UDP personalizado
Balanceador de Carga Standard (interno)	4	Regional	Não (passagem direta)	No	Sim (TCP, HTTP, HTTPS)	Nível interno atrás de um serviço público de entrada
Gateway de Aplicação	7	Regional	Sim (terminação de TLS)	Não (adicionar nível WAF)	Sim (HTTP/S personalizado)	HTTP/S de região única com encaminhamento de caminho
Gateway de Aplicações + WAF	7	Regional	Sim (terminação TLS)	Sim (conjunto de regras DRS)	Sim (HTTP/S personalizado)	Aplicações web de região única que necessitam de WAF
Azure Front Door	7	Global	Sim (divisão de TCP no PoP)	Sim (integrado)	Sim (HTTP/S)	HTTP/S multirregional com aceleração global
Gestor de Tráfego do Azure	DNS	Global	Não (apenas DNS)	No	Sim (HTTP/S, TCP)	Failover multi-região ao nível DNS, qualquer protocolo

Arquitetura de entrada da Internet

O diagrama seguinte mostra padrões comuns de encadeamento de serviços para tráfego de entrada para cargas de trabalho do Azure. Cada padrão combina serviços da Camada 7 e da Camada 4 para corresponder a um protocolo específico, âmbito regional e postura de segurança.

Padrões de entrada comuns

Os padrões seguintes combinam múltiplos serviços para uma arquitetura de entrada completa. Escolha o padrão que corresponda aos requisitos do seu protocolo, âmbito regional e postura de segurança.

Padrão 1: Aplicação web global com segurança na periferia

Serviços: Front Door → Application Gateway (com WAF) → VMs/contentores

Cenário: Uma aplicação SaaS que serve clientes na América do Norte, Europa e Ásia necessita de aceleração global, proteção DDoS na periferia e roteamento regional baseado em caminhos para diferentes microserviços.

O Front Door termina as ligações dos utilizadores no ponto de presença (PoP) mais próximo, aplica regras WAF globais e armazena em cache conteúdo estático. O tráfego é encaminhado através da rede principal da Microsoft para o gateway de aplicações regional, que efetua o encaminhamento com base no URL (por exemplo, /api/* para o pool da API, /static/* para um backend de armazenamento). Este padrão fornece duas camadas de inspeção WAF: uma na borda e outra na região.

Padrão 2: Multirregional não HTTP com failover de DNS

Serviços: Gestor de Tráfego → Balanceador de Carga Standard (por região) → VMs

Cenário: Uma empresa de jogos gere servidores dedicados na porta UDP 7777 em três regiões. Os jogadores ligam-se automaticamente à região saudável mais próxima.

O Traffic Manager utiliza o método de encaminhamento de desempenho para devolver o registo DNS da região de menor latência. Cada região tem um Balanceador de Carga Standard que distribui o tráfego UDP através de um Conjunto de Escala de Máquina Virtual. Se as sondas de saúde detetarem uma falha regional, o Gestor de Tráfego atualiza o DNS para encaminhar os jogadores para a região próxima mais próxima.

Padrão 3: Aplicação web regional simples com WAF

Serviços: Application Gateway (com WAF) → VMs

Cenário: Uma aplicação interna de linha de negócio exposta a parceiros externos. Região única, tráfego moderado, necessita de proteção OWASP e terminação TLS.

O Application Gateway fornece encaminhamento baseado em caminhos, afinidade de cookies para gestão de sessões e proteção contra WAF, tudo a partir de um único recurso regional dentro da rede virtual. Este padrão evita a complexidade e o custo de um serviço global quando o tráfego está geograficamente concentrado.

Padrão 4: Porta de entrada com origens privadas bloqueadas

Serviços: Front Door Premium → Private Link → Balanceador de Carga interno → VMs

Cenário: Uma aplicação de serviços financeiros com requisitos rigorosos de que a origem não deve ter exposição pública à propriedade intelectual. Todo o tráfego deve atravessar a rede dorsal da Microsoft sem saltos públicos na internet.

O Front Door Premium liga-se à origem através de um endpoint Private Link. O backend de origem não tem endereço IP público nem exposição à internet. Este padrão proporciona a segurança de uma origem totalmente privada combinada com os benefícios de desempenho da rede global de edge da Front Door.

Entrada multi-região com Porta Frontal

O diagrama seguinte mostra o Azure Front Door como ponto de entrada global, encaminhando os utilizadores para a origem regional saudável mais próxima com failover automático.

Pré-requisitos

Antes de expor a sua candidatura à internet, certifique-se de que tem os seguintes componentes implementados:

• Rede virtual implementada: Os seus recursos backend devem correr dentro de uma rede virtual Azure com sub-redes de tamanho adequado. Consulte Desenhe a sua rede virtual e sub-redes para orientações sobre planeamento de sub-redes.
• Carga de trabalho em execução: Precisa de pelo menos um recurso backend (máquina virtual, contentor ou serviço de plataforma) pronto para servir o tráfego.
• Nome DNS: Um nome DNS público que utilizadores externos usam para aceder à sua aplicação. Pode usar o DNS do Azure ou um fornecedor de DNS de terceiros.
• Planeamento de sub-redes para serviços de entrada: O Application Gateway requer uma sub-rede dedicada (mínimo /24 recomendado para produção). As instâncias backend do Balanceador de Carga Standard podem partilhar uma sub-rede com outros recursos.

Considerações de design

Avalie se a entrada na internet é necessária para as suas cargas de trabalho elevadas. Muitas aplicações on-premises são apenas internas e mantêm-se assim após a migração. Se for necessária entrada, mantenha a arquitetura simples:

• Application Gateway com WAF fornece um ponto de entrada de Camada 7 numa única região com terminação TLS e proteção OWASP. Esta abordagem é a mais comum para aplicações Web migradas que estavam anteriormente atrás de um proxy inverso local.
• IP público com NSG é aceitável para cargas de trabalho de baixo tráfego e não HTTP (por exemplo, um serviço TCP ao qual os parceiros se ligam). Restrinja o NSG a IPs de origem conhecidas.
• Evite atribuir IPs públicos diretamente às VMs. Coloque um balanceador de carga ou um Gateway de Aplicações entre a internet e o seu backend.

Se as suas aplicações removidas não servirem utilizadores externos, evite este artigo e continue com acesso à internet de saída.

As suas cargas de trabalho modernizadas têm padrões de entrada distintos consoante o tipo de aplicação:

• Azure Front Door para aplicações web voltadas para clientes (por exemplo, ContosoBiz). O Front Door oferece aceleração global, WAF incorporado, cache CDN e failover automático entre regiões. Use o encaminhamento ponderado para implantações ativo-ativas.
• Gestor de Tráfego do Azure para aplicações móveis e API (por exemplo, ContosoCare). O Traffic Manager fornece encaminhamento baseado em DNS para protocolos não HTTP ou quando os clientes necessitam de conectividade regional direta.
• Firewall do hub como alvo DNAT: Todo o tráfego de entrada passa pelo hub Azure Firewall antes de chegar aos níveis de aplicação. A firewall executa NAT de destino (DNAT) para encaminhar o tráfego filtrado para o spoke correto. Este padrão garante que nenhum tráfego de internet não limpo contorna os seus controlos centralizados de segurança.

Combine o Front Door com o Application Gateway em cada região para uma inspeção WAF em duas camadas: uma na borda global e outra na fronteira regional.

Para aplicações expostas ao público migradas da AWS ou do Google Cloud, implemente o Application Gateway com WAF na VNet spoke onde se encontra a carga de trabalho:

• Application Gateway + WAF na VNet spoke: Implemente um Application Gateway regional com o WAF ativado no modo de Prevenção. Esta abordagem mantém a entrada próxima da carga de trabalho sem exigir que o tráfego atravesse o hub para inspeção HTTP.
• Não há IPs públicos diretos em VMs: Nunca atribuas IPs públicos diretamente a VMs migradas. Todo o tráfego virado para a internet entra através do Application Gateway.
• Restringir as origens: Se a aplicação estava anteriormente atrás de um AWS Application Balanceador de Carga (ALB) ou do Google Cloud Load Balancing, mapeie esse padrão de entrada de tráfego no Application Gateway, para cargas de trabalho regionais, ou no Front Door, para cargas de trabalho globais.

Se a sua carga de trabalho entre clouds for exclusivamente interna (com comunicação entre clouds através de trânsito privado), ignore este artigo e continue para Azure Firewall e inspeção de tráfego.

Considerações de segurança

O acesso à Internet é a porta de entrada da sua aplicação. É o limite onde o tráfego da internet não confiável entra no seu ambiente Azure. Siga estas práticas para proteger o seu caminho de entrada.

Nunca exponha as VMs diretamente com IPs públicos

Não atribua um endereço IP público diretamente à interface de rede de uma máquina virtual para servir o tráfego de aplicações nas portas 80 ou 443. Em vez disso, coloque um balanceador de carga ou um Gateway de Aplicações entre a internet e as suas VMs. Esta abordagem dá-lhe:

• Sondas de saúde para remover instâncias falhadas da rotação
• Um ponto único para terminação de SSL ou TLS
• Um espaço para aplicar regras WAF e limitação de taxas
• Registo centralizado de todo o tráfego de entrada

Atenção

Um IP público diretamente numa VM expõe todas as portas abertas à internet. Se o grupo de segurança de rede da VM tiver uma regra mal configurada, os atacantes obtêm acesso direto ao sistema operativo.

Ativar WAF no modo de Prevenção

Se implementares o Application Gateway com WAF ou o Azure Front Door com WAF, define o WAF em modo Prevenção para cargas de trabalho de produção. O modo de prevenção bloqueia pedidos maliciosos antes que cheguem à sua aplicação. O modo de deteção apenas regista ameaças sem as bloquear. Use o modo de deteção apenas durante os testes iniciais para ajustar regras e identificar falsos positivos.

O WAF Default Rule Set (DRS) protege contra ataques top 10 do OWASP, incluindo injeção SQL, scripting cross-site e execução remota de código. O DRS inclui também regras de Inteligência de Ameaças da Microsoft que detetam IPs e cargas úteis maliciosas conhecidas.

Ativar proteção contra DDoS

Todas as redes virtuais com recursos públicos devem ter proteção DDoS ativada. O Azure DDoS Network Protection fornece ajuste adaptativo, telemetria de ataque e proteção de custos para os seus IPs públicos. Sem proteção DDoS, um ataque volumétrico pode saturar a largura de banda de entrada e tornar a sua aplicação inacessível.

Para mais detalhes, consulte proteção DDoS para a sua rede.

Usar NSGs para defesa em profundidade

Mesmo quando usa um balanceador de carga ou um Gateway de Aplicações, configure regras de grupo de segurança de rede nas suas sub-redes backend para restringir que fontes de tráfego podem chegar às suas VMs. Um NSG corretamente configurado:

• Permite apenas tráfego proveniente da sub-rede ou tag de serviço do balanceador de carga
• Impede o tráfego de entrada direto proveniente da Internet para as VMs de backend
• Registos negados ao tráfego para monitorização de segurança

Para planeamento NSG, veja grupos de segurança de rede e grupos de segurança de aplicações.

Aplicar TLS 1.2 ou posterior

Configure todos os serviços de entrada para aceitarem apenas TLS 1.2 ou TLS 1.3. Desative o TLS 1.0 e 1.1, que têm vulnerabilidades conhecidas. Tanto o Application Gateway como o Front Door suportam configuração mínima de versões TLS através das suas definições de políticas TLS. Use políticas pré-definidas, como AppGwSslPolicy20220101 as do Application Gateway, em vez de configurações personalizadas de cifra, a menos que tenha requisitos específicos de conformidade.

Restringir origens para o Front Door

Quando usar o Azure Front Door, restrinja os seus servidores originários a aceitarem apenas tráfego do Front Door. Se a sua origem aceitar tráfego de qualquer fonte, os agentes mal-intencionados podem contornar o WAF da Front Door ligando-se diretamente ao IP de origem, tornando todo o seu investimento em WAF ineficaz.

O confinamento do Origin utiliza dois mecanismos de verificação independentes. Aplica ambos para defesa em profundidade:

Restrição da etiqueta de serviço (camada de rede)

Configura o NSG ou o Azure Firewall do teu Origin para permitir tráfego HTTP/HTTPS de entrada apenas a partir da AzureFrontDoor.Backend etiqueta de serviço. Esta etiqueta de serviço contém todos os intervalos de IP usados pela Front Door para se ligar às origens. Aplique esta regra na sub-rede ou NIC onde reside a sua origem:

• Regra NSG: Prioridade 100, Fonte = Etiqueta de Serviço AzureFrontDoor.Backend, Destino = a sub-rede do seu backend, Portas = 80, 443, Ação = Permitir.
• Negação por defeito: Certifique-se de que nenhuma outra regra permite tráfego de entrada nas portas 80/443 a partir da internet. A regra padrão DenyAllInbound da NSG trata disto, a menos que adicione uma regra mais ampla de Permite.

A etiqueta de serviço, por si só, não é suficiente, porque todas as instâncias do Front Door de todos os clientes do Azure partilham os mesmos intervalos de IP da etiqueta de serviço. Um agente mal-intencionado pode criar o seu próprio perfil Front Door e encaminhá-lo para o teu IP de origem, contornando as regras do teu WAF.

Validação de cabeçalho X-Azure-FDID (camada de aplicação)

Cada pedido do Front Door inclui um X-Azure-FDID cabeçalho contendo o identificador único (GUID) da instância do Front Door que enviou o pedido. Valide este cabeçalho na sua aplicação ou reverse proxy para confirmar que o pedido veio do seu perfil Front Door, e não de um mau ator:

1. Encontre o ID do Front Door no portal do Azure, na página Descrição Geral do perfil do Front Door (no campo "ID do Front Door").
2. No código da sua aplicação ou configuração do servidor web, rejeite qualquer pedido que X-Azure-FDID não corresponda ao seu GUID esperado.
3. Devolver HTTP 403 para solicitações com um valor do cabeçalho em falta ou incorreto.

A combinação da etiqueta de serviço (bloqueia, ao nível da rede, o tráfego que não passa pelo Front Door) com a validação do cabeçalho (bloqueia, ao nível da aplicação, o tráfego do Front Door de outros clientes) garante que apenas a sua instância do Front Door pode aceder à sua origem.

Origens do Private Link (confinamento mais forte)

Para cargas de trabalho que requerem o mais alto nível de isolamento de origem, o Front Door Premium suporta origens Private Link. A sua origem não precisa de endereço IP público. O Front Door liga-se através de um endpoint privado através do backbone da Microsoft. Esta abordagem elimina a necessidade de regras de etiquetas de serviço ou validação de cabeçalhos, pois a origem é totalmente inacessível a partir da internet pública.

Artigos relacionados

• Conceba a sua rede virtual e sub-redes: Dimensionamento das sub-redes para servidores de back-end do Application Gateway e do Balanceador de Carga
• Grupos de segurança de rede e grupos de segurança de aplicações: regras NSG para restringir o acesso ao backend após a entrada
• Fornecimento e desempenho de aplicações: Ajuste do desempenho após o estabelecimento do percurso de entrada
• Acesso de saída à Internet: Controlo do tráfego de saída, o equivalente de saída ao tráfego de entrada
• Acesso administrativo seguro: Padrões de acesso administrativo, distintos da entrada na internet para utilizadores de aplicações
• Firewall de aplicações web: Configuração detalhada do WAF e ajuste de regras
• Proteção DDoS para a sua rede: Planeamento de proteção DDoS para todos os recursos públicos

Saiba mais

• O que é Balanceador de Carga do Azure?
• O que é o Gateway de Aplicação do Azure?
• O que é o Azure Front Door?
• O que é o Gestor de Tráfego do Azure?
• Endereços IP públicos no Azure
• Firewall de Aplicativo Web do Azure no Gateway de Aplicativo
• Azure Visão geral da Proteção de Rede DDoS

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:

Entrega e desempenho da aplicação: Adicione balanceamento de carga da Camada 7 e entrega global para a sua carga de trabalho migrada.

Se a tua carga de trabalho reduzida não precisar de balanceamento de carga da Camada 7, avança para acesso à internet de saída.

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

Entrega e desempenho de aplicações: Otimize a entrega global e o desempenho para as suas cargas de trabalho PaaS voltadas para o cliente.

A seguir na sua jornada através da cloud:

Firewall de Aplicações Web: Proteja aplicações públicas contra ataques na camada HTTP em todo o seu património cloud.

Se a tua carga de trabalho não usar HTTP/HTTPS, avança para o Azure Firewall e a inspeção de tráfego.