Entrada da Internet: expor seu aplicativo à Internet

Este artigo ajuda você a escolher o serviço de Azure certo para tornar seu aplicativo acessível na Internet. Ele compara endereços IP públicos, Azure Load Balancer, Gateway de Aplicativo, Azure Front Door e Gerenciador de Tráfego do Azure. Escolha a opção que se ajusta aos requisitos de protocolo, escala e segurança da carga de trabalho.

O que este artigo aborda

Cada carga de trabalho Azure que atende usuários externos precisa de um caminho de entrada: uma maneira de o tráfego da Internet alcançar seu aplicativo de forma segura e confiável. Escolher o serviço de entrada incorreto leva a excesso de provisionamento, falhas de segurança ou complexidade desnecessária. Este artigo ajuda você a avaliar sete serviços Azure que aceitam conexões de entrada de usuários externos e encaminham essas conexões para seus recursos de back-end dentro de uma rede virtual. Você pode selecionar a combinação que corresponde ao protocolo, escala, geografia e postura de segurança.

Note

Este artigo se concentra em como o tráfego entra em sua rede de Azure da Internet. Para saber como equilibrar e fornecer esse tráfego entre os back-ends do aplicativo (incluindo comparações detalhadas de Azure Load Balancer, Gateway de Aplicativo e Azure Front Door), consulte a entrega e o desempenho do aplicativo.

Quem precisa deste artigo

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

• Seu aplicativo deve aceitar conexões de entrada de usuários ou sistemas na Internet.
• Você precisa escolher entre IP público, Load Balancer, Gateway de Aplicativo, Front Door ou Gerenciador de Tráfego com base no protocolo e no escopo.
• Você precisa criar um ponto de entrada público seguro para cargas de trabalho Web, API ou TCP/UDP.
• Você precisa combinar a exposição à Internet com WAF, proteção contra DDoS, terminação TLS ou distribuição de tráfego regional e global.

Tip

Seguindo um cenário específico? Selecione seu cenário na parte superior da página para obter diretrizes personalizadas. As diretrizes principais a seguir se aplicam a todos os leitores.

Foco em migração direta: seu aplicativo migrado deve ser acessível pela Internet. Avalie se você precisa do Gateway de Aplicativo, do Front Door ou de uma abordagem de IP público mais simples. Muitas cargas de trabalho de lift-and-shift são de uso exclusivamente interno, portanto você pode pular este artigo se seus aplicativos migrados não atendem usuários externos.

Leia este artigo se você:

• Estão migrando um aplicativo Web local para Azure e precisam decidir como expô-lo publicamente.
• É necessário avaliar se a entrada na Internet é necessária para suas cargas de trabalho migradas.
• Deseja entender a opção de entrada mais simples e pronta para produção para um aplicativo migrado?

Foco de modernização: Os padrões de tráfego voltados para o cliente determinam a forma externa de sua arquitetura. O Front Door manipula aplicativos Web, o Gerenciador de Tráfego manipula aplicativos móveis e de API. Suas cargas de trabalho de PaaS modernizadas (Serviço de Aplicativo, AKS) precisam de um caminho de entrada bem definido que se integre ao seu modelo de segurança hub-spoke.

Leia este artigo se você:

• Implante um aplicativo voltado para o público que os usuários externos acessam pela Internet.
• Precisa escolher entre Azure Front Door para aplicativos Web e o Gerenciador de Tráfego para cargas de trabalho móveis ou de API.
• Deseja entender como a entrada se integra ao firewall do seu hub como um alvo DNAT?
• É necessário proteger endpoints expostos à Internet com um WAF (firewall de aplicação web) ou proteção contra DDoS.

Foco em nuvem cruzada: inclua a entrada pela Internet somente se o aplicativo migrado for público. Muitas aplicações multinuvem são de uso exclusivamente interno, comunicando-se entre nuvens por rotas privadas de trânsito. Se sua carga de trabalho for voltada para o público (por exemplo, um aplicativo Web voltado para o cliente migrado de outra nuvem), você precisará de um caminho de entrada no Azure.

Leia este artigo se você:

• Estão migrando um aplicativo voltado para o público da AWS ou do Google Cloud para Azure.
• Necessita de um Gateway de Aplicativo com WAF em uma VNet spoke para a carga de trabalho migrada.
• Deseja evitar a atribuição direta de IP público para VMs durante a migração entre nuvens.

Azure serviços e recursos

Azure fornece vários serviços para entrada na Internet. Cada serviço opera em uma camada diferente da pilha de rede e atende a um caso de uso diferente.

Service	Camada	Scope	O que ele fornece	Quando usar isso
Endereço IP público (SKU Padrão)	3	Regional	Endereço IPv4 ou IPv6 roteável atribuído diretamente. Redundância de zona por padrão.	Cenários simples e de baixo tráfego. Não recomendado para produção sem um balanceador de carga.
Azure Load Balancer (Padrão, público)	4 (TCP/UDP)	Regional	Distribui o tráfego TCP/UDP de entrada entre VMs de back-end. Front-end com redundância de zona. Sondas de integridade removem instâncias com problemas.	Cargas de trabalho não HTTP/S que exigem alta disponibilidade. Servidores de jogos, dispositivos IoT ou outros serviços TCP/UDP.
Azure Load Balancer (Standard, interno)	4 (TCP/UDP)	Regional	Balanceamento de carga de camada 4 em uma rede virtual. Nenhum IP público. Roteia o tráfego entre camadas internas.	Aplicativos de várias camadas onde um front-end público distribui para VMs de back-end. Tráfego leste-oeste em modelo hub-and-spoke. Não diretamente voltado para a Internet, mas normalmente emparelhado com um serviço de entrada pública.
Gateway de Aplicativo do Azure	7 (HTTP/S)	Regional	Balanceamento de carga HTTP/S com roteamento baseado em URL, terminação SSL/TLS, afinidade de sessão e dimensionamento automático.	Aplicativos HTTP/S de região única que exigem roteamento baseado em caminho, afinidade baseada em cookie ou descarregamento SSL.
Application Gateway + WAF	7 (HTTP/S)	Regional	Gateway de Aplicação com Firewall de Aplicação Web Protege contra os 10 principais ataques do OWASP usando o DRS (Conjunto de Regras Padrão), incluindo Microsoft regras de Inteligência contra Ameaças.	Aplicações web voltadas para o público que exigem balanceamento de carga de Camada 7 e proteção WAF em uma única região.
Azure Front Door	7 (HTTP/S)	Global	Balanceador de carga HTTP/S global com CDN, WAF e roteamento de tráfego integrados. Termina o TCP/TLS em PoPs de borda próximos aos usuários usando aceleração Split TCP.	Aplicativos de várias regiões com uma base de usuário global. Cargas de trabalho que exigem cache de CDN, WAF global e failover automático.
Gerenciador de Tráfego do Azure	DNS	Global	Roteamento de tráfego baseado em DNS. Retorna um CNAME para o ponto de extremidade regional mais próximo ou mais saudável. Os clientes se conectam diretamente. O Gerenciador de Tráfego nunca vê o tráfego do aplicativo.	Failover multirregional em nível de DNS. Protocolos não HTTP/S em que o Front Door não se aplica. Roteamento por geografia, desempenho ou prioridade.

Note

Os IPs públicos do SKU Básico serão desativados (setembro de 2025). Os IPs básicos existentes permanecem operacionais, mas não contam com suporte nem com SLA. Use o SKU Standard para todas as novas implantações.

Como cada serviço funciona

Entender a arquitetura interna de cada serviço ajuda você a prever o desempenho, solucionar problemas e planejar o dimensionamento de sub-rede.

Endereço IP público

Um IP público do SKU Padrão é um recurso definido por software que mapeia um endereço IPv4 ou IPv6 roteável diretamente para uma interface de rede, front-end de Load Balancer ou gateway. O endereço é redundante em zona por padrão em regiões permitidas, o que significa que a plataforma lida com failover entre zonas de disponibilidade sem qualquer alteração da sua parte. Os IPs públicos não têm processamento de tráfego. Os pacotes fluem diretamente para o recurso anexado sem nenhuma verificação de integridade ou lógica de distribuição.

Azure Load Balancer (Padrão, público)

O Load Balancer Padrão usa um algoritmo de distribuição baseado em hash em fluxos de 5 tuplas (IP de origem, porta de origem, IP de destino, porta de destino, protocolo). Ele opera inteiramente no caminho de dados na Camada 4, portanto, ele nunca encerra conexões ou inspeciona cargas. As sondagens de integridade (TCP, HTTP ou HTTPS) consultam continuamente as instâncias de back-end e removem as instâncias com problemas da rotação em segundos. Load Balancer é dimensionado automaticamente. Não há nenhum planejamento de capacidade ou dimensionamento de instância.

Azure Load Balancer (Standard, interno)

O Load Balancer interno funciona da mesma forma que seu equivalente público, mas usa um IP de front-end privado da sub-rede de rede virtual. Ele distribui o tráfego entre camadas internas, como uma camada da Web que envia tráfego para um cluster de API de camada intermediária. Como não tem IP público, ele é invisível para a Internet. Combine-o com um serviço de entrada público, como o Front Door, o Gateway de Aplicativo ou um Load Balancer público, que gerencie o limite externo.

Gateway de Aplicativo do Azure

O Gateway de Aplicação é um appliance virtual dedicado implantado na sub-rede da sua rede virtual. Ele encerra as conexões TLS no gateway, inspeciona os cabeçalhos HTTP e URLs e encaminha as solicitações para os pools de back-end com base em regras de caminho, cabeçalhos de host ou sondagens de integridade personalizadas. O SKU v2 dá suporte ao dimensionamento automático (0 a 125 instâncias) e à redundância de zona. Como está na VNet, ele pode acessar back-ends privados sem exigir que esses back-ends tenham IPs públicos.

Gateway de Aplicações com WAF

Ao adicionar a camada do WAF, você habilita o OWASP Core Rule Set e as regras do Microsoft Threat Intelligence diretamente no pipeline de processamento do Application Gateway. Cada solicitação HTTP passa pelo mecanismo WAF antes de atingir as regras de roteamento. O WAF dá suporte a políticas por site, para que você possa ter configurações de regra diferentes para diferentes combinações de ouvintes ou host no mesmo gateway. O WAF opera em modo Detecção (apenas registro em log) ou Prevenção (bloqueio e registro em log).

Azure Front Door

O Front Door opera na rede de borda global da Microsoft (mais de 190 pontos de presença). Quando um usuário se conecta, o handshake TCP e a negociação TLS ocorrem no ponto de presença mais próximo usando o Split TCP. O ponto de presença mantém uma conexão ativa persistente com a sua origem, eliminando assim a latência de inicialização a frio que os usuários experimentariam ao se conectar diretamente. O Front Door realiza roteamento de camada 7, inspeção WAF, cache e compressão na borda antes de encaminhar a solicitação para a origem íntegra mais próxima na rede backbone da Microsoft.

Gerenciador de Tráfego do Azure

O Gerenciador de Tráfego é um serviço baseado em DNS sem envolvimento no caminho de dados. Quando um cliente resolve o nome de host do seu Gerenciador de Tráfego, ele retorna um CNAME que aponta para o ponto de extremidade mais íntegro ou mais próximo, com base no seu método de roteamento (prioridade, ponderado, desempenho, geográfico, multivalor ou sub-rede). O Gerenciador de Tráfego monitora continuamente a integridade do ponto de extremidade e atualiza as respostas de DNS de acordo. Como ele nunca vê o tráfego do aplicativo, ele funciona com qualquer protocolo: HTTP, TCP, UDP ou protocolos proprietários.

Comparação de modelo de custo

Cada serviço de entrada segue um modelo de cobrança diferente. Use esta tabela para estimar os custos em seu volume de tráfego esperado.

Service	Modelo de cobrança	Principais fatores de custo	Plano gratuito ou recursos incluídos
Endereço IP público	Por hora (anexado) + por GB de saída	Número de horas vinculadas; tarifas de saída	Primeiros 100 GB de saída por mês gratuitos (global)
Standard Load Balancer	Por hora por regra + por GB processado	Número de regras de balanceamento de carga; dados processados por meio do LB	Nenhum
Application Gateway	Por hora por instância + unidades de capacidade consumidas	Horas de instância; Unidades de capacidade de computação, conexão e taxa de transferência	Nenhum
Application Gateway + WAF	Por hora por instância (preços da camada WAF) + unidades de capacidade	Igual ao Gateway de Aplicativo, mas com a taxa horária da camada WAF	Nenhum
Azure Front Door	Por solicitação + por GB de transferência + solicitações WAF	Solicitações de roteamento, transferência de dados da borda para o cliente, avaliações de regra do WAF	O nível Standard inclui algum roteamento básico.
Gerenciador de Tráfego do Azure	Por milhão de consultas DNS + por ponto de extremidade de verificação de integridade	Volume de consultas DNS; número de endpoints monitorados	O primeiro 1 bilhão de consultas tem preços escalonados

Tip

Para cargas de trabalho de baixo tráfego (abaixo de 1 milhão de solicitações por mês), o modelo de cobrança por solicitação do Front Door pode ser mais econômico do que o custo fixo por hora do Application Gateway. À medida que o tráfego aumenta, os modelos por hora se tornam mais previsíveis. Use a Calculadora de Preços do Azure com a taxa de transferência esperada para comparar.

Como escolher

Use as tabelas de decisão a seguir para selecionar o serviço de entrada correto para sua carga de trabalho. Comece com a tabela de decisão de alto nível e use a comparação detalhada para confirmar sua escolha.

Gateway de Aplicativo vs. Front Door vs. Gerenciador de Tráfego

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

Sua necessidade	Serviço recomendado	Por que
Tráfego HTTP/S, região única, proteção do WAF	Gateway de Aplicações com WAF	Serviço regional de Camada 7 com roteamento baseado em caminho e WAF. É executado dentro de sua rede virtual.
Tráfego HTTP/S, várias regiões, usuários globais, CDN + WAF	Azure Front Door	Serviço global de Camada 7 que termina em PoPs de borda. CDN, WAF e failover automático integrados.
Roteamento de várias regiões para protocolos não HTTP/S ou somente roteamento de nível DNS	Gerenciador de Tráfego do Azure	Roteamento baseado em DNS que funciona com qualquer protocolo. Nenhuma terminação de conexão.
HTTP/S de várias regiões com requisitos regionais de processamento associados à VNet	Gateway de Aplicativo + Gerenciador de Tráfego	Válido para cargas de trabalho que exigem integração profunda com VNet ou soberania de dados regional com inspeção WAF regional. Para a maioria dos cenários HTTP/S de várias regiões, prefira o Front Door.

Tip

Para a maioria das cargas de trabalho multirregionais de HTTP e HTTPS, o Front Door é a opção preferida em vez do Application Gateway combinado com o Traffic Manager. O Front Door fornece WAF integrado, CDN e failover automático sem que você precise gerenciar várias instâncias regionais do Application Gateway. A combinação de Application Gateway + Traffic Manager continua válida para cargas de trabalho que exigem processamento regional vinculado à VNet, origens do Link Privado acessíveis apenas de dentro de uma VNet ou requisitos regulatórios que determinem soberania regional dos dados.

Comparação de serviços de entrada

Use esta comparação detalhada quando precisar entender os recursos de cada serviço.

Service	Camada	Global ou regional	Encerramento da conexão	WAF disponível	Sondas de saúde	Melhor para
Endereço IP público	3	Regional	Não (direto para VM)	No	No	Desenvolvimento/teste, cargas de trabalho de instância única sem nenhum requisito de HA
Standard Load Balancer (público)	4	Regional	Não (passagem direta)	No	Sim (TCP, HTTP, HTTPS)	Cargas de trabalho não HTTP: jogos, IoT, TCP/UDP personalizado
Standard Load Balancer (interno)	4	Regional	Não (passagem direta)	No	Sim (TCP, HTTP, HTTPS)	Camada interna por trás de um serviço de entrada público
Application Gateway	7	Regional	Sim (encerramento do TLS)	Não (adicionar camada de WAF)	Sim (HTTP/S personalizado)	HTTP/S de região única com roteamento de caminho
Application Gateway + WAF	7	Regional	Sim (encerramento do TLS)	Sim (conjunto de regras do DRS)	Sim (HTTP/S personalizado)	Aplicativos Web de região única que precisam de WAF
Azure Front Door	7	Global	Sim (TCP dividido no PoP)	Sim (integrado)	Sim (HTTP/S)	HTTP/S de várias regiões com aceleração global
Gerenciador de Tráfego do Azure	DNS	Global	Não (somente DNS)	No	Sim (HTTP/S, TCP)	Failover multirregional em nível de DNS, qualquer protocolo

Arquitetura de entrada da Internet

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

Padrões comuns de entrada

Os padrões a seguir combinam vários serviços para uma arquitetura de entrada completa. Escolha o padrão que corresponde aos requisitos de protocolo, ao escopo regional e à postura de segurança.

Padrão 1: aplicativo Web global com segurança de borda

Serviços: Front Door → Gateway de Aplicativo (com WAF) → VMs/containers

Cenário: Um aplicativo SaaS que atende clientes na América do Norte, Europa e Ásia precisa de aceleração global, proteção contra DDoS na borda e roteamento regional baseado em caminho para microsserviços diferentes.

O Front Door encerra as conexões de usuário no ponto de presença mais próximo (PoP), aplica regras de WAF globais e armazena em cache conteúdo estático. O tráfego roteia pelo backbone Microsoft para o Gateway de Aplicativo regional, que executa o roteamento baseado em URL (por exemplo, /api/* para o pool de API, /static/* para um back-end de armazenamento). Esse padrão fornece duas camadas de inspeção de WAF: uma na borda e outra na região.

Padrão 2: multirregional não-HTTP com failover de DNS

Serviços: Traffic Manager → Standard Load Balancer (por região) → VMs

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

O Gerenciador de Tráfego usa o método de roteamento de desempenho para retornar o registro DNS para a região de menor latência. Cada região tem um Load Balancer Padrão distribuindo o tráfego UDP em um Conjunto de Dimensionamento de Máquinas Virtuais. Se as investigações de integridade detectarem uma falha regional, o Gerenciador de Tráfego atualizará o DNS para rotear os jogadores para a região mais próxima.

Padrão 3: aplicativo Web regional simples com WAF

Serviços: Gateway de Aplicativo (com WAF) → VMs

Cenário: Um aplicativo de linha de negócios interno que está sendo exposto a parceiros externos. Região única, tráfego moderado, requer proteção da OWASP e terminação TLS.

O Gateway de Aplicativo fornece roteamento baseado em caminho, afinidade de cookies para gerenciamento de sessão e proteção WAF, tudo a partir de um único recurso regional dentro da rede virtual. Esse padrão evita a complexidade e o custo de um serviço global quando o tráfego está geograficamente concentrado.

Padrão 4: Front Door com origens privadas bloqueadas

Serviços: Front Door Premium → Link Privado → Load Balancer interno → VMs

Cenário: Um aplicativo de serviços financeiros com requisitos estritos de que a origem não deve ter exposição de IP público. Todo o tráfego deve percorrer a rede de backbone da Microsoft, sem passar por saltos na Internet pública.

O Front Door Premium conecta-se à origem via um endpoint do Link Privado. O back-end de origem não tem endereço IP público nem exposição à Internet. Esse padrão fornece a segurança de uma origem totalmente privada combinada com os benefícios de desempenho da rede de borda global do Front Door.

Entrada multirregional com Front Door

O diagrama a seguir mostra o Azure Front Door como um ponto de entrada global, roteando usuários para a origem regional íntegra mais próxima com failover automático.

Pré-requisitos

Antes de expor seu aplicativo à Internet, verifique se você tem os seguintes componentes em vigor:

• Rede virtual implantada: Seus recursos de back-end devem ser executados dentro de uma rede virtual Azure com sub-redes de tamanho adequado. Consulte Projetar sua rede virtual e sub-redes para obter diretrizes de planejamento de sub-rede.
• Executando a carga de trabalho: Você precisa de pelo menos um recurso de back-end (máquina virtual, contêiner ou serviço de plataforma) pronto para atender ao tráfego.
• Nome DNS: Um nome DNS público que os usuários externos usam para acessar seu aplicativo. Você pode usar DNS do Azure ou um provedor DNS de terceiros.
• Planejamento de sub-rede para serviços de entrada: o Gateway de Aplicativo requer uma sub-rede dedicada (mínimo /24 recomendado para produção). As instâncias de back-end do Standard Load Balancer podem compartilhar uma sub-rede com outros recursos.

Considerações sobre o design

Avalie se a entrada pela Internet é necessária para suas cargas de trabalho migradas. Muitos aplicativos locais são somente internos e permanecem assim após a migração. Se a entrada for necessária, mantenha a arquitetura simples:

• Gateway de Aplicativo com WAF fornece entrada de Camada 7 de região única com terminação TLS e proteção OWASP. Essa abordagem é a mais comum para aplicativos Web migrados que estavam anteriormente atrás de um proxy reverso local.
• O IP público com NSG é aceitável para cargas de trabalho não HTTP de baixo tráfego (por exemplo, um serviço TCP ao qual os parceiros se conectam). Restrinja o NSG a IPs de origem conhecidos.
• Evite atribuir IPs públicos diretamente a VMs. Coloque um balanceador de carga ou Gateway de Aplicativo entre a Internet e seu back-end.

Se os seus aplicativos migrados não atendem usuários externos, ignore este artigo e continue para Acesso de saída pela Internet.

Suas cargas de trabalho modernizadas têm padrões de entrada distintos com base no tipo de aplicativo:

• Azure Front Door para aplicativos Web voltados para o cliente (por exemplo, ContosoBiz). O Front Door fornece aceleração global, WAF integrado, cache de CDN e failover automático entre regiões. Use roteamento ponderado para implantações ativo-ativo.
• Gerenciador de Tráfego do Azure para aplicativos móveis e de API (por exemplo, ContosoCare). O Gerenciador de Tráfego fornece roteamento baseado em DNS para protocolos não HTTP ou quando os clientes precisam de conectividade regional direta.
• Firewall de hub como destino de DNAT: todo o tráfego de entrada passa pelo Firewall do Azure de hub antes de chegar às camadas de aplicação. O firewall realiza NAT de destino (DNAT) para rotear o tráfego filtrado para o spoke correto. Esse padrão garante que nenhum tráfego de Internet não limpo ignore seus controles de segurança centralizados.

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

Para aplicações voltadas ao público migradas da AWS ou do Google Cloud, implante o Application Gateway com WAF na VNet spoke onde a carga de trabalho está hospedada:

• Gateway de Aplicativo + WAF na VNet spoke: implante um Gateway de Aplicativo regional com o WAF habilitado no modo de prevenção. Essa abordagem mantém a entrada próxima à carga de trabalho sem exigir que o tráfego percorra o hub para inspeção HTTP.
• Não há IPs públicos diretos em VMs: Nunca atribua IPs públicos diretamente a VMs migradas. Todo o tráfego voltado para a Internet entra por meio do Gateway de Aplicativo.
• Bloqueie origens: se o aplicativo estava anteriormente atrás de um AWS Application Load Balancer (ALB) ou Google Cloud Load Balancing, mapeie esse padrão de entrada para o Gateway de Aplicativo para cargas de trabalho regionais ou para o Front Door para cargas de trabalho globais.

Se sua carga de trabalho entre nuvens for apenas interna (comunicação entre nuvens por meio de trânsito privado), ignore este artigo e continue para Firewall do Azure e inspeção de tráfego.

Considerações de segurança

A entrada da Internet é a porta de entrada do seu aplicativo. É o limite em que o tráfego de Internet não confiável entra em seu ambiente de Azure. Siga estas práticas para proteger seu caminho de entrada.

Nunca exponha VMs diretamente com IPs públicos

Não atribua um endereço IP público diretamente ao adaptador de rede de uma máquina virtual para atender ao tráfego de aplicativos nas portas 80 ou 443. Em vez disso, coloque um balanceador de carga ou Gateway de Aplicativo entre a Internet e suas VMs. Essa abordagem oferece a você:

• Sondas de integridade para remover instâncias com falha da rotação
• Um único ponto para terminação SSL ou TLS
• Um local para aplicar regras de WAF e limitação de taxa
• Registro em log centralizado de todo o tráfego de entrada

Caution

Um IP público diretamente em uma VM expõe todas as portas abertas para a Internet. Se o grupo de segurança de rede da VM tiver uma regra configurada incorretamente, os invasores obterão acesso direto ao sistema operacional.

Habilitar o WAF no modo de prevenção

Se você implantar o Gateway de Aplicativo com WAF ou o Azure Front Door com WAF, defina o WAF para o modo Prevenção para cargas de trabalho de produção. O modo de prevenção bloqueia solicitações mal-intencionadas antes que elas cheguem ao seu aplicativo. O modo de detecção registra apenas ameaças sem bloqueá-las. Use o modo de detecção somente durante o teste inicial para ajustar regras e identificar falsos positivos.

O DRS (Conjunto de Regras Padrão) do WAF protege contra os 10 principais ataques do OWASP, incluindo injeção de SQL, script entre sites e execução de código remoto. O DRS também inclui regras de Inteligência contra Ameaças da Microsoft que detectam IPs mal-intencionados conhecidos e cargas maliciosas.

Habilitar a proteção contra DDoS

Todas as redes virtuais com recursos voltados para o público devem ter a proteção contra DDoS habilitada. Azure Proteção de Rede DDoS fornece ajuste adaptável, telemetria de ataque e proteção de custo para seus IPs públicos. Sem a proteção contra DDoS, um ataque volumetrico pode saturar sua largura de banda de entrada e tornar seu aplicativo inacessível.

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

Use NSGs para defesa em profundidade

Mesmo quando você usa um balanceador de carga ou Gateway de Aplicativo, configure regras de grupo de segurança de rede em suas sub-redes de back-end para restringir quais fontes de tráfego podem acessar suas VMs. Um NSG configurado corretamente:

• Permite tráfego somente da sub-rede ou da tag de serviço do balanceador de carga
• Nega o tráfego de entrada direto da Internet para as VMs de back-end
• Registre o tráfego negado para monitoramento de segurança

Para planejamento de NSG, consulte grupos de segurança de rede e grupos de segurança de aplicativos.

Impor o TLS 1.2 ou posterior

Configure todos os serviços de entrada para aceitar apenas tls 1.2 ou TLS 1.3. Desabilite o TLS 1.0 e 1.1, que têm vulnerabilidades conhecidas. Tanto o Application Gateway quanto o Front Door dão suporte à configuração da versão mínima do TLS por meio de suas configurações de política de TLS. Use políticas predefinidas, como AppGwSslPolicy20220101 para o Gateway de Aplicativo, em vez de configurações de criptografia personalizadas, a menos que você tenha requisitos de conformidade específicos.

Restrinja as origens do Front Door

Quando você usa Azure Front Door, restrinja os servidores de origem para aceitar o tráfego somente do Front Door. Se sua origem aceita tráfego de qualquer origem, agentes mal-intencionados podem contornar o WAF do Front Door conectando-se diretamente ao IP de origem, fazendo com que todo o seu investimento no WAF se torne ineficaz.

O bloqueio de origem usa dois mecanismos de verificação independentes. Use ambos para defesa em profundidade:

Restrição de tag de serviço (camada de rede)

Configure o NSG ou o Firewall do Azure da origem para permitir tráfego de entrada HTTP/HTTPS proveniente apenas da tag de serviço AzureFrontDoor.Backend. Essa marca de serviço contém todos os intervalos de IP usados pelo Front Door para se conectar às origens. Aplique essa regra na sub-rede ou na NIC onde sua origem está localizada:

• Regra NSG: Prioridade 100, Origem = Tag de Serviço AzureFrontDoor.Backend, Destino = sua sub-rede de backend, Portas = 80, 443, Ação = Permitir.
• Negação padrão: Verifique se nenhuma outra regra permite o tráfego de entrada nas portas 80/443 da Internet. A regra DenyAllInbound padrão do NSG lida com isso, a menos que você adicione uma regra de permissão mais ampla.

A tag de serviço, por si só, é insuficiente porque todas as instâncias do Front Door de todos os clientes do Azure compartilham os mesmos intervalos de IP da tag de serviço. Um agente mal-intencionado pode criar seu próprio perfil do Front Door e direcioná-lo para seu IP de origem, ignorando suas regras de WAF.

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

Cada solicitação do Front Door inclui um X-Azure-FDID cabeçalho que contém o GUID (identificador exclusivo) da instância do Front Door que enviou a solicitação. Valide este cabeçalho em seu aplicativo ou proxy reverso para confirmar se a solicitação veio do seu perfil do Front Door e não de um agente malicioso:

1. Encontre a ID do Front Door no portal do Azure, na página Visão geral do seu perfil do Front Door (o campo "ID do Front Door").
2. No código do aplicativo ou na configuração do servidor web, rejeite qualquer solicitação em que X-Azure-FDID não corresponda ao GUID esperado.
3. Retornar HTTP 403 para solicitações com um valor de cabeçalho ausente ou incorreto.

Combinar a tag de serviço (bloqueia o tráfego que não é do Front Door na rede) com a validação do cabeçalho (bloqueia o tráfego do Front Door de outros clientes no aplicativo) garante que somente sua instância do Front Door possa alcançar sua origem.

Origens de Link Privado (bloqueio mais rígido)

Para cargas de trabalho que exigem o mais alto nível de isolamento de origem, o Front Door Premium dá suporte a origens do Link Privado. Sua origem não precisa de endereço IP público. O Front Door se conecta por meio de um ponto de extremidade privado na infraestrutura da Microsoft. Essa abordagem elimina a necessidade de regras de marca de serviço ou validação de cabeçalho porque a origem é inacessível totalmente da Internet pública.

Artigos relacionados

• Projete sua rede virtual e sub-redes: Dimensionamento de sub-redes para back-ends do Application Gateway e do Load Balancer
• Grupos de segurança de rede e grupos de segurança de aplicativos: regras NSG para restringir o acesso de back-end após a entrada
• Entrega e desempenho do aplicativo: Ajuste de desempenho depois que o caminho de entrada é estabelecido
• Acesso de saída à internet: Controle o tráfego de saída, o equivalente de saída ao tráfego de entrada
• Acesso administrativo seguro: padrões de acesso de administrador, distintos da entrada da Internet para usuários de aplicativo
• Firewall do aplicativo Web: configuração detalhada do WAF e ajuste de regra
• Proteção contra DDoS para sua rede: planejamento de proteção contra DDoS para todos os recursos voltados para o público

Saiba mais

• O que é Azure Load Balancer?
• O que é Gateway de Aplicativo do Azure?
• O que é o Azure Front Door?
• O que é Gerenciador de Tráfego do Azure?
• Endereços IP públicos no Azure
• Firewall de Aplicativo Web do Azure no Gateway de Aplicativo
• Visão Geral da Proteção contra DDoS de Rede do Azure

Próximas Etapas 

Tip

Explorando por conta própria? Retorne ao navegador de visão geral para encontrar seu próximo artigo por funcionalidade.

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

Entrega e desempenho do aplicativo: adicione balanceamento de carga da Camada 7 e entrega global para sua carga de trabalho migrada.

Se a sua carga de trabalho migrada não precisar de balanceamento de carga na Camada 7, pule para Acesso de saída à Internet.

A seguir, em sua jornada de modernização:

Entrega e desempenho do aplicativo: otimizar a entrega e o desempenho globais para suas cargas de trabalho de PaaS voltadas para o cliente.

A seguir, em sua jornada multinuvem:

Firewall de Aplicativo Web: proteja aplicativos voltados para o público contra ataques de camada HTTP em sua propriedade de nuvem.

Se sua carga de trabalho não usar HTTP/HTTPS, pule para Firewall do Azure e inspeção de tráfego.