ALB interno com nome DNS público: está realmente exposto?

Execute uma consulta DNS pública contra um balanceador de carga interno e pode receber um endereço privado de volta, o que parece uma configuração errada até verificar para que serve o registo. A AWS documenta que os nomes de balanceadores internos podem ser resolvíveis publicamente enquanto os seus nós têm apenas endereços privados. O resolvedor respondeu onde está o serviço; não criou uma rota, não abriu um grupo de segurança nem autenticou ninguém. Se essa resposta é um problema depende de factos que pode verificar por ordem.

Passo um: leia o esquema, não o IP

O campo do esquema é a própria declaração do balanceador sobre a sua fronteira. aws elbv2 describe-load-balancers --names app-internal devolve um Scheme com o valor internal ou internet-facing, mais um tipo de endereço para IPv4 ou pilha dupla. Um balanceador virado para a internet ainda pode encaminhar para destinos privados, por isso ver endereços de backend privados não prova nada sobre a frente.

Anote o esquema antes de olhar para qualquer outra coisa, porque cada julgamento posterior depende dele. Também indica que controlos existem, desde grupos de segurança e regras de listener até ao conjunto de funcionalidades desse tipo de balanceador. Um esquema copiado de uma captura de ecrã antiga da consola é pior do que nenhuma nota. Volte a lê-lo da API e cole o valor no ticket.

Passo dois: veja para onde o nome resolve

Consulte de fora da VPC com dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com e anote se as respostas estão em 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16. Uma resposta privada de um resolvedor público é o comportamento esperado para um nome de balanceador interno; não é prova de que o endereço seja encaminhável a partir da internet.

Resolva o mesmo nome de dentro da VPC e compare. Se as duas respostas diferirem, está perante nomes split-horizon, e essa diferença é um detalhe de conceção, não uma fuga.

Passo três: enumere os caminhos que o podem alcançar

Um endereço privado é alcançável onde existam uma rota e uma regra de segurança. Enumere-as deliberadamente: VPN site-to-site, VPN de cliente, VPC peering, ligações de transit gateway, Direct Connect e qualquer proxy ou bastion dentro da VPC. Uma delas é o caminho pretendido, e as restantes são as que um atacante procuraria.

Depois verifique os controlos em cada caminho: grupos de segurança no balanceador, ACL de rede nas sub-redes e o encaminhamento que faz existir o caminho. A maioria dos casos reportados de serviço interno exposto resolve-se aqui, ou porque existia um peering não pretendido ou porque o caminho era pretendido e a aplicação não tinha autenticação.

Passo quatro: teste o listener e a aplicação em separado

Tente ligar-se a partir de uma rede que não deveria alcançar o serviço e confirme que não consegue. Depois tente a partir de uma que deveria, e confirme que alcança um listener. Esses dois resultados separam a alcançabilidade de rede do comportamento da aplicação, e são a única evidência que importa para a questão da exposição.

Um listener alcançável não é o mesmo que uma aplicação acessível. Verifique o certificado TLS e a política de protocolo, depois a autenticação e autorização da própria aplicação. Uma ferramenta interna que aceita qualquer chamador na VPN corporativa fica exposta a cada portátil comprometido nessa VPN, o que é um risco diferente de um exposto à internet mas continua a ser risco.

Lembre-se de que os controlos variam consoante o tipo. As firewalls de camada de aplicação ligam-se a uma família de balanceadores e não à outra, por isso confirme o que está realmente disponível para o esquema e o tipo à sua frente em vez de assumir paridade.

Passo cinco: decida se o nome em si importa

A resolubilidade pública pode divulgar um nome de serviço, uma região e um intervalo de endereços. Trate isso como uma questão de divulgação de informação com resposta de política, não como um incidente automático: mantenha termos de negócio sensíveis fora dos nomes de recursos e registe a divulgação no seu registo de riscos se a convenção de nomes revelar mais do que deseja.

Se a organização quiser uma experiência de nomes privada, uma zona alojada privada pode servir um alias que só resolve dentro das VPC associadas. Isso altera o nome que os utilizadores veem; não torna secreto o nome gerado pelo fornecedor nem remove qualquer caminho de rede.

Não tente fixar endereços para esconder a resposta. Os endereços do balanceador mudam, a fixação quebra os hábitos de validação TLS, e o controlo de que realmente precisa é quem pode estabelecer a ligação e o que a aplicação exige dele. Verifique os quatro factos, anote-os, e a pergunta deixa de ser ambígua.