Prevenção de exfiltração de dados: controles de saída (egress) da AWS para workloads em nuvem

O ponto cego que muitas equipes ignoram

Quando o assunto é segurança em ambientes Amazon Web Services (AWS), a tendência natural é focar no tráfego de entrada: firewalls, WAFs e políticas de acesso recebem atenção prioritária porque é de lá que vêm as ameaças mais visíveis. O tráfego de saída, por outro lado, costuma ser deixado aberto por padrão — para não quebrar dependências de aplicações — e o risco parece menos imediato.

Mas ignorar o egress significa abrir mão de uma camada essencial de defesa. Sem visibilidade sobre o que está saindo da rede, fica muito mais difícil detectar fluxos de dados não autorizados, sejam eles causados por serviços mal configurados, permissões excessivamente amplas ou workloads comprometidas.

Dois cenários do mundo real ilustram bem esse risco:

• Ambientes tradicionais: quando a vulnerabilidade CVE-2025-55182 (React2Shell) foi divulgada em dezembro de 2025, grupos organizados iniciaram tentativas de exploração em questão de horas, visando componentes React Server não atualizados para obter execução remota de código. Após comprometer uma workload, o atacante tipicamente estabelece canais de comando e controle e começa a exfiltrar dados. Sem controles de egress, esse tráfego flui livremente — e o comprometimento pode passar despercebido por meses.
• Sistemas de IA agêntica: o OWASP Top 10 para Aplicações Agênticas identifica ameaças como o Sequestro de Objetivo do Agente (ASI01), em que partes não autorizadas manipulam os objetivos de um agente autônomo para exfiltrar dados silenciosamente, e Execução de Código Inesperada (ASI05), em que um agente comprometido gera e executa código que estabelece shells reversos ou transfere dados sensíveis para endpoints externos. Agentes de IA com acesso a ferramentas, APIs e interpretadores de código tornam-se alvos de alto valor — e sua atividade de rede de saída precisa ser controlada com o mesmo rigor de qualquer outra workload.

O denominador comum dos dois cenários é o mesmo: tráfego de saída não autorizado. A AWS publicou um guia detalhando como implementar detecção e proteção de egress em camadas, reduzindo o risco de transferência não autorizada de dados independentemente da origem da ameaça.

Visão geral da arquitetura

A arquitetura proposta adota o padrão hub-and-spoke para ambientes AWS multi-contas. As workloads residem em Nuvens Privadas Virtuais (VPCs) spoke que se conectam ao AWS Transit Gateway, responsável por centralizar o roteamento do tráfego entre VPCs e em direção à internet, aplicando segmentação de rede por meio de tabelas de rotas cuidadosamente definidas.

As VPCs spoke utilizam endpoints de VPC para acessar serviços AWS de forma privada, mantendo o tráfego dentro da rede da AWS sempre que possível. Políticas de endpoint de VPC são aplicadas como controles de perímetro de dados, restringindo quais entidades podem acessar quais serviços e recursos.

O tráfego com destino à internet é roteado através de um AWS Network Firewall acoplado ao Transit Gateway, que inspeciona e filtra os fluxos de saída antes de chegarem à internet. Esse modelo centralizado escala horizontalmente com a adição de novas VPCs spoke, sem necessidade de modificar a infraestrutura de inspeção.

É fundamental entender que o Amazon Route 53 Resolver DNS Firewall precisa ser implantado em todas as VPCs para filtrar consultas DNS resolvidas pelo Route 53 VPC Resolver. Consultas DNS enviadas diretamente a outros resolvers contornam esse firewall, mas podem ser filtradas pelo AWS Network Firewall.

Os controles de perímetro de dados são aplicados em múltiplas camadas: Políticas de Controle de Serviço (SCPs) e Políticas de Controle de Recursos (RCPs) no nível do AWS Organizations, políticas de endpoint de VPC na camada de rede, e políticas de recurso em serviços individuais. O AWS IAM Access Analyzer atua no nível organizacional para detectar continuamente recursos acessíveis publicamente ou compartilhados externamente.

A camada de detecção reúne o Amazon GuardDuty, o AWS Security Hub e o IAM Access Analyzer para monitoramento contínuo. Os alertas são roteados via Amazon EventBridge, que aciona remediações automatizadas com AWS Lambda e envia notificações pelo Amazon Simple Notification Service (Amazon SNS). Essa camada de integração também retroalimenta os controles de rede, atualizando automaticamente as regras de bloqueio do Network Firewall e as listas de bloqueio do DNS Firewall com base nas ameaças detectadas.

A observabilidade centralizada é alcançada por meio do Amazon CloudWatch Logs e dos dashboards do CloudWatch, coletando logs de fluxo e alertas do Network Firewall para suportar investigações e relatórios de conformidade.

Essa arquitetura se aplica igualmente a workloads tradicionais e a workloads orientadas por IA. Um agente de IA rodando no Amazon Bedrock, por exemplo, normalmente reside dentro de uma VPC spoke. Quando esse agente invoca uma API externa ou tenta acessar a internet, seu tráfego percorre o mesmo caminho pelo Transit Gateway e pelo Network Firewall que qualquer workload no Amazon Elastic Compute Cloud (Amazon EC2) ou em contêineres. O agente não tem um caminho privilegiado de saída — está sujeito às mesmas listas de domínios permitidos, à mesma filtragem DNS e às mesmas políticas de perímetro de dados.

Vale destacar que agentes frequentemente precisam de acesso de saída para invocar ferramentas externas ou APIs de terceiros como parte de sua operação normal. Isso torna o design das listas de permissão (allow-lists) mais delicado: o ideal é restringir os domínios permitidos exatamente aos endpoints que os agentes legitimamente precisam acessar, evitando aberturas genéricas. Complementar os controles de rede com guardrails na camada de aplicação — como o Amazon Bedrock Guardrails, capaz de filtrar conteúdo prejudicial e detectar ataques de prompt antes que cheguem à camada de rede — adiciona mais uma camada de defesa.

Controles preventivos

Os controles preventivos bloqueiam a exfiltração de dados antes que ela ocorra. Por atuarem interrompendo ativamente o tráfego, devem ser reservados para atividades confirmadas ou com alta probabilidade de serem prejudiciais.

AWS Network Firewall

Considere dois cenários: um atacante compromete uma instância EC2 em uma das VPCs spoke e tenta exfiltrar dados para um servidor externo; ou, no cenário de IA agêntica, um atacante usa injeção de prompt para sequestrar o objetivo de um agente (OWASP ASI01) e redirecioná-lo para exfiltrar dados de treinamento para um endpoint externo.

O Network Firewall é projetado para bloquear essa tentativa porque o destino não autorizado não consta na lista de domínios aprovados — o mesmo controle que impede uma instância EC2 comprometida também detém um agente de IA manipulado. Sem inspeção centralizada de egress, esse tráfego fluiria diretamente para a internet através de um NAT gateway.

O Network Firewall oferece inspeção profunda de pacotes nas camadas 3 a 7, com capacidades avançadas de inteligência de ameaças. Suas principais funcionalidades incluem:

• Filtragem por nome de domínio: bloqueia tráfego para destinos não autorizados (como servidores de comando e controle em *.dominio-nao-confiavel.com)
• Regras de IP e porta: define listas de permissão explícitas para IPs externos que as aplicações realmente precisam
• Filtragem por categoria de domínio: bloqueia categorias inteiras de domínios com os quais as workloads nunca deveriam se comunicar
• IDS e IPS: detecta e bloqueia padrões de ataque conhecidos no tráfego de saída usando regras compatíveis com Suricata
• Aplicação de porta e protocolo: garante que apenas os protocolos esperados utilizem suas portas designadas (por exemplo, apenas HTTPS na porta TCP 443), prevenindo tunelamento de protocolos
• Filtragem geográfica de IP: bloqueia tráfego de saída para regiões geográficas onde a organização não possui relacionamentos comerciais
• Descriptografia TLS: inspeciona tráfego criptografado para detectar tentativas de exfiltração ocultas em conexões HTTPS
• Integração com inteligência de ameaças: utiliza feeds gerenciados (como o sistema de inteligência de ameaças da Amazon, MadPot) ou regras Suricata customizadas para detectar padrões inesperados
• Escalabilidade automática: suporta até 100 Gbps por Zona de Disponibilidade

Para ambientes multi-conta, o AWS Firewall Manager permite implantar e gerenciar o Network Firewall de forma centralizada em todas as contas da organização. Adicionalmente, o AWS Network Firewall Proxy (em prévia) oferece capacidades de proxy explícito com filtragem granular de HTTP/HTTPS — incluindo controles no nível de caminho de URL e método HTTP — para workloads que exigem inspeção na camada de aplicação do tráfego web de saída.

Route 53 Resolver DNS Firewall

Consultas DNS feitas pelo Route 53 VPC Resolver não passam pelo caminho de rede inspecionado pelo Network Firewall. Atacantes podem explorar isso codificando dados sensíveis dentro de consultas DNS direcionadas a servidores externos — técnica conhecida como DNS tunneling (tunelamento DNS).

Esse risco se estende a workloads de IA agêntica. Um agente com capacidades de execução de código (OWASP ASI05) pode ser induzido a executar um script que codifica dados sensíveis (como registros de clientes, pesos de modelo, chaves de API) em consultas DNS direcionadas a um servidor de nomes controlado externamente.

O DNS Firewall bloqueia essas consultas independentemente de sua origem — workload tradicional ou agente de IA — porque a filtragem ocorre no nível do resolver, antes que qualquer conexão seja estabelecida. Suas principais capacidades incluem:

• Bloqueio de domínios não autorizados: a AWS fornece listas de domínios gerenciadas, incluindo uma Lista Agregada de Ameaças cobrindo malware, ransomware, botnets, spyware e DNS tunneling
• Aplicação de listas de permissão: permite apenas consultas a domínios aprovados, bloqueando todo o restante
• DNS Firewall Advanced: detecção baseada em IA/ML de DNS tunneling, Algoritmos de Geração de Domínio (DGAs) e DGAs de dicionário

A configuração é direta: crie grupos de regras com listas de correspondência de domínios e ações (bloquear, permitir e alertar), depois associe-os às suas VPCs. Para uma análise mais aprofundada sobre os riscos de exfiltração via DNS e as capacidades avançadas do DNS Firewall, consulte Proteção contra ameaças DNS avançadas com o Amazon Route 53 Resolver DNS Firewall.

Perímetros de dados

Um perímetro de dados é um conjunto de guardrails preventivos que permitem apenas identidades confiáveis acessarem recursos confiáveis a partir de redes esperadas. Enquanto os controles anteriores protegem os caminhos de rede para fora do ambiente, os perímetros de dados protegem os caminhos em nível de API — garantindo que, mesmo que um atacante obtenha credenciais válidas, não consiga usar as APIs de serviços AWS para mover dados para fora da organização.

Essa abordagem utiliza três capacidades principais da AWS trabalhando em conjunto:

• Políticas de Controle de Serviço (SCPs): controles preventivos em nível organizacional que restringem o que identidades podem fazer. No contexto de proteção de egress, as SCPs podem impedir usuários de criar recursos que contornem os controles de saída (por exemplo, impedindo a criação de VPCs sem associações ao DNS Firewall ou bloqueando o uso de serviços que possam estabelecer caminhos alternativos de saída).
• Políticas de Controle de Recursos (RCPs): controles que restringem o acesso via API aos seus recursos. Embora as RCPs não sejam controles de egress diretamente, atuam como camada complementar. Por exemplo, podem bloquear tentativas de acesso aos buckets do Amazon Simple Storage Service (Amazon S3) de fora da organização, no nível do recurso.
• Políticas de endpoint de VPC: endpoints de VPC habilitam comunicação privada com serviços AWS sem que o tráfego passe pela internet. As políticas de endpoint de VPC são políticas de AWS Identity and Access Management (IAM) baseadas em recurso que governam o que pode ser acessado por meio desse endpoint. É aqui que os perímetros de dados funcionam mais diretamente como controle de egress.

O exemplo a seguir mostra uma política de endpoint de VPC que restringe o acesso ao Amazon S3 por meio do endpoint apenas a buckets S3 dentro da organização, impedindo diretamente que uma workload comprometida copie dados para um bucket externo:

{
  "Statement": [{
    "Sid": "DenyAccessToNonOrgBuckets",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:ResourceOrgID": "<my-org-id>"
      }
    }
  }]
}

Essa política nega qualquer operação do Amazon S3 por meio desse endpoint de VPC, a menos que o bucket S3 de destino pertença à organização. Sem esse controle, uma workload comprometida poderia usar aws s3 cp para copiar dados sensíveis para um bucket controlado externamente em uma conta AWS diferente.

As políticas de perímetro de dados não concedem novas permissões — elas restringem o que é acessível, estabelecendo guardrails e atuando como uma segunda camada de autorização. Ao implementar esses perímetros usando chaves de condição IAM como aws:PrincipalOrgID, aws:ResourceOrgID, aws:SourceVpc e aws:SourceVpce, cria-se guardrails de permissão em camadas que ajudam a prevenir padrões de acesso não intencionais e erros de configuração. Para mais informações sobre a implementação de controles de perímetro, consulte o whitepaper Construindo um Perímetro de Dados na AWS.

Controles detectivos

Os controles detectivos identificam tentativas de exfiltração de dados após sua ocorrência. Por observarem o tráfego sem interrompê-lo, podem ser aplicados amplamente para sinalizar atividades inesperadas para investigação. Os alertas gerados ajudam a identificar padrões recorrentes não autorizados que podem evoluir para controles preventivos.

Amazon GuardDuty

O GuardDuty atua como a camada crítica de detecção para proteção de egress, monitorando continuamente ameaças de saída que escapam ou exploram os controles preventivos. Ele identifica anomalias comportamentais e padrões de ataque que indicam tentativas ativas de exfiltração de dados. Suas capacidades de detecção focadas em egress incluem:

• Detecção de exfiltração via DNS: o alerta Trojan:EC2/DNSDataExfiltration é disparado quando instâncias EC2 estão transferindo dados por canais DNS. O GuardDuty também identifica consultas a domínios DGA comumente usados para comunicação de comando e controle.
• Detecção de atores maliciosos conhecidos: Exfiltration:S3/MaliciousIPCaller é acionado quando APIs de dados do Amazon S3, como GetObject ou CopyObject, são invocadas a partir de endereços IP presentes nos feeds de inteligência de ameaças da AWS.
• Correlação de sequências de ataque em múltiplos estágios: o GuardDuty Extended Threat Detection correlaciona múltiplos eventos inesperados para identificar campanhas de exfiltração em múltiplas etapas. Por exemplo, AttackSequence:S3/CompromisedData detecta quando atacantes modificam políticas de bucket S3 para ampliar o acesso e depois extraem dados sistematicamente usando credenciais roubadas.

Os alertas do GuardDuty servem a dois propósitos na estratégia de egress. Alertas sobre tentativas de exfiltração que falharam confirmam que as camadas preventivas (Network Firewall, DNS Firewall e perímetros de dados) estão funcionando efetivamente. Já alertas indicando exfiltração bem-sucedida acionam fluxos imediatos de resposta a incidentes, permitindo conter incidentes ativos, revogar credenciais roubadas e isolar recursos afetados antes que danos significativos ocorram.

IAM Access Analyzer

O IAM Access Analyzer ajuda a identificar possíveis caminhos de exfiltração de dados detectando recursos acessíveis de fora da conta AWS ou da organização. Ele usa tecnologia de raciocínio automatizado para analisar políticas baseadas em recurso e identificar quais recursos podem ser acessados por entidades externas, monitorando continuamente acessos públicos e entre contas.

Por exemplo, quando um bucket S3 é configurado para permitir acesso fora da zona de confiança por meio de políticas de bucket, ACLs ou pontos de acesso, o IAM Access Analyzer gera um alerta com detalhes sobre o caminho de acesso. As equipes de segurança podem responder removendo imediatamente o acesso não intencional ou configurando notificações automatizadas via EventBridge para envolver as equipes de desenvolvimento na remediação.

AWS Security Hub

O Security Hub fornece uma visão abrangente dos riscos de segurança potenciais, correlacionando dados de múltiplos serviços de segurança da AWS. Seus alertas identificam quando recursos podem estar vulneráveis à exfiltração de dados, integrando inteligência do GuardDuty (detecção de ameaças), do Amazon Inspector (avaliação de vulnerabilidades), do Security Hub CSPM (conformidade de configuração) e do Amazon Macie (descoberta de dados sensíveis).

Por exemplo, o Security Hub pode identificar quando um bucket S3 exposto publicamente contém dados sensíveis e não está criptografado em repouso, sinalizando-o como risco potencial de exfiltração que requer atenção imediata. O AWS Shield network security director (em prévia) complementa o Security Hub descobrindo e analisando a topologia de rede para identificar recursos com acesso irrestrito à internet de saída, ajudando a detectar pontos cegos de egress em todo o ambiente.

Estratégia de segurança de egress em fases

Não é necessário implementar todos esses controles de uma vez. A AWS sugere uma abordagem em fases que permite construir a postura de segurança de egress de forma incremental, em um ritmo compatível com a maturidade operacional e a tolerância a riscos da organização:

• Fase 1 – Ganhos rápidos: habilite o Route 53 DNS Firewall em todas as VPCs para eliminar a lacuna de exfiltração via DNS. Habilite o GuardDuty em todas as contas para detecção básica de ameaças.
• Fase 2 – Fundação: implante perímetros de dados em nível organizacional (SCPs, RCPs e políticas de endpoint de VPC). Implante o Network Firewall como firewall acoplado ao Transit Gateway.
• Fase 3 – Eficiência: habilite o IAM Access Analyzer para detecção contínua de acesso externo. Implemente remediação automatizada via EventBridge e Lambda para atualizar regras de firewall em tempo real. Centralize os alertas no Security Hub com notificações automatizadas.

Conclusão

A segurança de egress não é um controle único — é uma estratégia em camadas. O ponto de partida é avaliar a postura atual em relação a filtragem de rede, segurança DNS, perímetros de dados e controles detectivos. A partir daí, identificam-se as lacunas e adota-se a abordagem em fases para fechá-las incrementalmente. Testes regulares por meio de simulações de tentativas de exfiltração validam que os controles funcionam efetivamente.

Esses controles se aplicam com igual força a workloads de IA agêntica, onde agentes manipulados podem se tornar vetores não intencionais de exfiltração. Colocar o egress sob controle significa transformar pontos cegos de saída em checkpoints monitorados.

Fonte

Prevent data exfiltration: AWS egress controls for cloud workloads (https://aws.amazon.com/blogs/security/prevent-data-exfiltration-aws-egress-controls-for-cloud-workloads/)