A AWS anunciou o Lambda MicroVMs, uma nova primitiva de computação serverless que combina isolamento em nível de máquina virtual (VM), inicialização quase instantânea e preservação de estado de execução. Com esse lançamento, desenvolvedores podem oferecer a cada usuário ou tarefa um ambiente de computação próprio e seguro — sem precisar gerenciar infraestrutura de virtualização por conta própria.
Por que esse recurso importa?
Cada vez mais equipes estão construindo aplicações multi-tenant que executam código enviado por usuários finais ou gerado por Inteligência Artificial (IA). Casos de uso típicos incluem ambientes interativos de programação, plataformas de análise de dados, assistentes de código e ferramentas de varredura de vulnerabilidades.
Nesse tipo de aplicação, é fundamental isolar cada sessão ou usuário para que um código incorreto ou malicioso não afete outros processos em execução simultânea. Até então, os desenvolvedores precisavam escolher entre três características que raramente coexistiam: isolamento forte, tempo de inicialização rápido e retenção de estado. O Lambda MicroVMs elimina esse compromisso.
Principais capacidades
Isolamento em nível de VM: cada MicroVM roda em um ambiente completamente separado, limitando o impacto de qualquer código problemático.
Inicialização quase instantânea: o tempo de cold start é mínimo, viabilizando experiências responsivas para o usuário final.
Suspensão e retomada de execução: é possível suspender e retomar uma MicroVM por até 8 horas, preservando o estado da execução.
Tecnologia Firecracker: o serviço é construído sobre a virtualização Firecracker, a mesma tecnologia que sustenta mais de 15 trilhões de invocações mensais do Lambda.
Conectividade moderna: cada MicroVM recebe uma URL HTTPS dedicada com suporte a protocolos populares como HTTP/2, gRPC e WebSockets.
Como começar
Para usar o Lambda MicroVMs, o fluxo básico é: criar uma imagem MicroVM a partir de um Dockerfile e, em seguida, inicializar MicroVMs a partir dessa imagem. Cada usuário ou tarefa pode receber sua própria MicroVM com uma URL HTTPS dedicada.
O Lambda MicroVMs já está disponível nas seguintes regiões da AWS: Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon), Ásia-Pacífico (Tóquio) e Europa (Irlanda).
O modelo de cobrança considera os recursos de computação de base enquanto a MicroVM está em execução, e cobra apenas pela duração ativa dos recursos adicionais consumidos quando a carga de trabalho ultrapassa o nível base. Para detalhes completos, consulte a página de preços do Lambda MicroVMs.
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 Firewallacoplado 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.
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:
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.
A AWS anunciou uma atualização importante no AWS Network Firewall: a ação stateful padrão para novas políticas de firewall agora é “Application drop established (server-directed only)”, substituindo o comportamento anterior chamado “Application drop established (bidirectional)” — que anteriormente era conhecido como “Application layer drop established”.
A mudança vale automaticamente para todas as políticas criadas a partir de agora. Quem está criando novas políticas não precisa fazer nada para aproveitar o comportamento mais seguro e confiável.
Por que a configuração anterior era problemática
O padrão antigo — o modo bidirecional — tinha um comportamento silencioso e perigoso: ele podia descartar pacotes Protocolo de Controle de Transmissão (TCP) legítimos enviados do servidor para o cliente. Entre os pacotes afetados estavam window updates, keep-alives e resets — elementos essenciais para o controle de fluxo de uma conexão TCP saudável.
O resultado prático era a ocorrência de falhas de conexão intermitentes, difíceis de diagnosticar justamente porque o descarte acontecia de forma silenciosa, sem alertas óbvios. Esse tipo de problema é especialmente frustrante para equipes de operações, pois os sintomas aparecem de forma irregular e sem uma causa aparente.
O que muda com o novo padrão
Com o novo padrão “server-directed only” (somente direcionado pelo servidor), as novas políticas de firewall deixam de bloquear indevidamente pacotes de controle de fluxo legítimos originados no servidor. Isso reduz significativamente o risco de quedas de conexão causadas por esse comportamento.
Para quem está criando políticas novas, a melhoria é automática — nenhuma ação é necessária.
Atenção para ambientes com criptografia pós-quântica
Existe um cenário específico que merece atenção: ambientes que utilizam Criptografia Pós-Quântica (PQC) com handshakes TLS fragmentados podem depender do comportamento bidirecional para funcionar corretamente. Para esses casos, a AWS orienta que os times consultem a documentação oficial e avaliem duas opções:
Migrar para o modo “Application drop established (server-directed only)”; ou
Adicionar a flag to_server nas regras de bloqueio TCP, garantindo que pacotes legítimos de controle de fluxo não sejam bloqueados.
Disponibilidade
A atualização está disponível em todas as regiões da AWS onde o Network Firewall é oferecido. Para entender como funciona a ordem de avaliação das regras compatíveis com Suricata, a AWS recomenda consultar a documentação Gerenciamento da ordem de avaliação para regras compatíveis com Suricata.
Quando um evento de segurança ocorre em um ambiente Amazon Web Services (AWS), a velocidade de resposta é determinante. O problema é que as equipes de segurança frequentemente perdem tempo valioso em processos manuais: precisam lembrar a sintaxe exata da Interface de Linha de Comando da AWS (AWS CLI), correlacionar manualmente alertas do Amazon GuardDuty com logs do AWS CloudTrail, documentar cada passo para fins de conformidade e ainda tomar decisões críticas enquanto a ameaça está ativa.
Para analistas sem domínio profundo de AWS, esse cenário é ainda mais desafiador e cria gargalos sérios nas operações de segurança. É exatamente esse problema que o Kiro busca resolver.
O que é o Kiro CLI
O Kiro é um assistente de codificação com inteligência artificial (IA) que ajuda usuários a escrever, entender e otimizar código por meio de integrações com Ambientes de Desenvolvimento Integrado (IDE) e linha de comando. Além das tarefas tradicionais de desenvolvimento, ele oferece expertise específica em AWS: orientação de arquitetura, boas práticas, recomendações de otimização de custos e navegação na documentação de serviços.
O Kiro CLI leva todas essas capacidades para o terminal, tornando-o uma ferramenta natural para fluxos de trabalho de operações de segurança. Com seus recursos integrados, ele pode auxiliar na investigação de uma descoberta do GuardDuty — propondo os comandos AWS CLI adequados, explicando o que cada um faz e aguardando a aprovação do analista antes de executar.
O framework de referência: AWS Security Incident Response Guide
A AWS publicou um post demonstrando como usar o Kiro CLI para conduzir investigações de segurança seguindo o Guia de Resposta a Incidentes de Segurança da AWS. Esse framework organiza a resposta em cinco fases:
Preparação: ter as ferramentas e processos certos antes de um incidente ocorrer
Detecção e análise: identificar eventos de segurança e entender seu escopo
Contenção: limitar o impacto e evitar danos adicionais
Erradicação e recuperação: remover ameaças e restaurar operações normais
Atividade pós-incidente: aprender com o ocorrido para melhorar respostas futuras
Pré-requisitos para começar
Para usar o Kiro CLI em investigações de segurança, é necessário:
O Kiro CLI utiliza o perfil padrão da AWS CLI (ou o perfil especificado pela variável de ambiente AWS_PROFILE) para interagir com os recursos AWS, sempre solicitando aprovação antes de executar qualquer ação.
A investigação na prática: do alerta à resolução
Descoberta: uma descoberta de alta severidade no GuardDuty
A investigação de exemplo começa com uma descoberta do GuardDuty que exige atenção imediata. Em vez de construir manualmente os comandos AWS CLI, o analista usa a interface em linguagem natural do Kiro CLI para solicitar a análise da descoberta, pedir que cada passo seja proposto com explicação e aguardar confirmação antes de prosseguir, além de documentar tudo em um arquivo findings.md estruturado para audiências técnicas e executivas.
Esse único prompt já estabelece todo o framework da investigação. Ao solicitar aprovação passo a passo, o analista mantém o controle enquanto se beneficia da orientação da IA. A exigência de documentação garante que uma trilha de auditoria seja construída em tempo real, para fins de conformidade.
Após a execução dos comandos aprovados, o Kiro CLI revelou informações críticas sobre a descoberta de exemplo:
Tipo:CryptoCurrency:EC2/BitcoinTool.B!DNS
Severidade: ALTA (8.0)
Instância:i-05447e6dacd0a7e7e (m5.xlarge)
Ameaça: 617 consultas DNS para pool.minergate.com
Linha do tempo: atividade de mineração iniciada 9 minutos após o lançamento da instância
O fato de a atividade maliciosa ter começado apenas 9 minutos após o lançamento da instância sugere uma ação automatizada, não manual — um padrão importante que o Kiro CLI destaca automaticamente para ajudar as equipes a entenderem o comportamento da ameaça.
Análise de recursos e escopo
O Kiro CLI propôs investigar a configuração da instância Amazon Elastic Compute Cloud (Amazon EC2), os grupos de segurança e as permissões do AWS Identity and Access Management (IAM). Essa sugestão proativa demonstra que a ferramenta entende o fluxo de uma investigação de segurança — ela sabe que avaliar o impacto potencial exige examinar não apenas o que o invasor fez, mas o que ele poderia fazer a seguir.
Os resultados da análise revelaram:
Configuração da instância: AMI Amazon Linux 2023, Serviço de Metadados de Instância versão 2 (IMDSv2) obrigatório (boa postura de segurança), IP público com acesso irrestrito de saída e perfil de instância IAM anexado
Grupo de segurança: sem regras de entrada, mas com acesso de saída irrestrito para 0.0.0.0/0, habilitando o tráfego de mineração
Permissões IAM — descoberta crítica: a política AdministratorAccess estava anexada ao perfil de instância, concedendo acesso total à conta AWS a partir de uma instância comprometida — risco real de comprometimento completo da conta
Embora a atividade observada fosse mineração de criptomoeda, a política AdministratorAccess anexada significa que o invasor poderia ter exfiltrado dados, criado backdoors ou comprometido outros recursos. Isso reforça por que políticas IAM com privilégio mínimo são fundamentais.
O Kiro CLI também verificou atividades adicionais inesperadas e descobriu sete descobertas de segurança nessa única instância, indicando um ataque de múltiplos vetores.
Isolamento da instância: o Kiro CLI gerou comandos para criar um grupo de segurança de isolamento sem regras de entrada ou saída e aplicá-lo à instância comprometida. Essa etapa interrompe novas conexões sem destruir evidências. No entanto, é importante entender que grupos de segurança são stateful e usam rastreamento de conexão. Quando as regras são alteradas, conexões existentes não são interrompidas imediatamente — elas continuam até expirar. Para interrupção imediata de todo o tráfego, incluindo conexões ativas, recomenda-se também implementar Listas de Controle de Acesso de Rede (NACLs), que são stateless e podem quebrar conexões existentes imediatamente quando as regras são aplicadas.
Esse cenário ilustra um princípio importante: embora ferramentas com IA como o Kiro CLI acelerem a resposta, é essencial manter um humano no ciclo que entenda essas nuances e valide as recomendações.
Revogação de privilégios: o Kiro CLI gerou comandos para anexar uma política de negação total à função IAM comprometida. O assistente explicou que, mesmo com a política AdministratorAccess ainda anexada, a política de negação tem precedência pela lógica de avaliação do IAM — negações explícitas sempre substituem permissões. Isso revogou imediatamente todos os acessos enquanto preservou a configuração original para análise forense.
Preservação de evidências
Antes de fazer alterações destrutivas, o Kiro CLI recomendou criar um snapshot forense do volume Amazon Elastic Block Store (Amazon EBS) da instância comprometida. Esse passo costuma ser negligenciado quando as equipes estão sob pressão para conter uma ameaça ativa, mas é crítico para análise pós-incidente e possíveis processos legais.
No exemplo, a decisão foi manter a instância em execução em seu estado isolado, em vez de pará-la imediatamente. Parar uma instância EC2 resulta na perda da memória volátil, que pode conter evidências forenses como processos em execução, conexões de rede, malware carregado e chaves de criptografia.
Para entender o escopo completo do comprometimento, o Kiro CLI foi utilizado para analisar os logs do AWS CloudTrail. O assistente identificou as trilhas disponíveis e propôs consultas para encontrar chamadas de API feitas a partir da instância comprometida usando suas credenciais temporárias.
A análise do CloudTrail frequentemente é a parte mais demorada de uma investigação de incidente. O Kiro CLI automatiza esse processo, identificando imediatamente as fontes de log relevantes e propondo as consultas adequadas.
No exemplo, nenhuma chamada de API inesperada foi encontrada originada das credenciais da instância — nenhum usuário IAM criado, nenhum bucket S3 acessado, nenhum segredo roubado. O evento pareceu limitado à atividade de mineração de criptomoeda via consultas DNS, sem evidências de exfiltração de dados ou movimentação lateral. Isso demonstra o valor da análise completa do CloudTrail: mesmo quando os achados iniciais sugerem uma ameaça contida, confirmar a ausência de comprometimento mais amplo é essencial antes de encerrar uma investigação.
Construindo defesas proativas
Com a ameaça imediata contida, o Kiro CLI foi utilizado para fortalecer a fase de preparação, estabelecendo alertas automatizados para incidentes futuros. Usando linguagem natural, foi solicitada a criação de um sistema de notificação para descobertas de alta severidade ou superior.
Criar uma regra no EventBridge para disparar em descobertas de alta severidade (severidade maior ou igual a 7.0)
Configurar o tópico SNS como destino do EventBridge
Conceder permissões ao EventBridge para publicar no tópico SNS
Quando comandos falham por problemas de permissão, referências incorretas de Nome de Recurso da Amazon (ARN) ou políticas JSON malformadas, o Kiro CLI detecta automaticamente as falhas e propõe comandos corrigidos. Esse tratamento inteligente de erros permite que as equipes de segurança implementem automações com confiança, sem precisar de troubleshooting manual.
Criando workflows de investigação reutilizáveis com steering files
Com a ameaça contida e as defesas proativas estabelecidas, o Kiro CLI foi usado para criar um arquivo de direcionamento (steering file) reutilizável que codifica o workflow de investigação para incidentes futuros.
Steering files são arquivos Markdown armazenados em .kiro/steering/ que funcionam como memória persistente para o Kiro CLI, ajudando as equipes de segurança a capturar conhecimento institucional e padronizar procedimentos de resposta. Para compartilhá-los com toda a equipe, basta adicioná-los a um repositório Git ou publicá-los em sistemas de documentação como o Confluence.
O Kiro CLI gerou um steering file detalhado em .kiro/steering/guardduty-incident-response.md contendo:
Fases de investigação alinhadas ao Guia de Resposta a Incidentes de Segurança da AWS
Padrões de comandos AWS CLI para GuardDuty, Amazon EC2, IAM e CloudTrail
Requisitos de documentação e pontos de aprovação
Procedimentos de contenção, erradicação e preservação de evidências
Abaixo, o exemplo de steering file gerado pelo Kiro CLI:
---
inclusion: manual
---
# GuardDuty Incident Response Workflow
This steering file guides systematic investigation of GuardDuty findings following AWS Security Incident Response Guide best practices.
## Investigation Phases
### Detection and Analysis
1. Retrieve GuardDuty finding details using finding ID
2. Extract finding type, severity, affected resources, and threat indicators
3. Document timeline of events (instance launch, threat detection)
### Resource Analysis
4. Investigate EC2 instance configuration (AMI, IMDS version, network access)
5. Analyze security group rules (inbound/outbound access)
6. Review IAM permissions attached to instance profile
7. Check for additional findings on the same resource
### Containment
8. Create isolation security group with no inbound/outbound rules
9. Apply isolation security group to compromised instance
10. Create forensic snapshot before making destructive changes
11. Preserve volatile memory by keeping instance running if forensic analysis needed
### Eradication
12. Revoke excessive IAM permissions
13. Document all actions in findings.md with technical and executive summaries
### Analysis
14. Query CloudTrail for API calls from compromised instance credentials
15. Assess scope of compromise and potential lateral movement
## Documentation Requirements
- Finding summary with severity and type
- Investigation steps with timestamps
- Evidence collected (security groups, IAM policies, CloudTrail logs)
- Remediation actions taken
- Recommendations for prevention
## AWS CLI Command Patterns
- GuardDuty: `aws guardduty get-findings`
- EC2: `aws ec2 describe-instances`, `aws ec2 describe-security-groups`
- IAM: `aws iam get-instance-profile`, `aws iam list-attached-role-policies`
- CloudTrail: `aws cloudtrail lookup-events`
## Approval Gates
Always propose commands with explanations before execution and wait for approval.
Diferente de playbooks tradicionais de resposta a incidentes, que são documentos estáticos e rapidamente ficam desatualizados, os steering files do Kiro CLI são playbooks executáveis que guiam investigações assistidas por IA com consistência, permanecendo flexíveis o suficiente para se adaptar a cenários específicos. Atualizar o steering file faz parte do próprio workflow — ao final de cada sessão, basta pedir ao Kiro CLI que incorpore os ajustes feitos durante a investigação.
Conclusão
Incidentes de segurança exigem resposta rápida e precisa, mas os workflows tradicionais de investigação criam gargalos que aumentam o Tempo Médio de Resposta (MTTR). Seguindo o framework do Guia de Resposta a Incidentes de Segurança da AWS e utilizando as capacidades de IA do Kiro CLI, é possível transformar a resposta a incidentes de um processo reativo em operações proativas e bem documentadas.
O Kiro CLI acelera cada fase do ciclo de vida da resposta a incidentes — da detecção e análise inicial, passando pela contenção e erradicação, até a recuperação. A capacidade de steering files ajuda as equipes a incorporar o conhecimento adquirido em workflows reutilizáveis que beneficiam analistas de todos os níveis de experiência. Quando comandos falham ou configurações estão incorretas, o Kiro CLI identifica o problema e o corrige, reduzindo o tempo gasto em troubleshooting.
A AWS anunciou que o Amazon MQ para RabbitMQ passa a suportar conectividade de rede privada. Com isso, os brokers conseguem se comunicar com recursos internos da sua Nuvem Privada Virtual (VPC) sem precisar expor esses recursos à internet pública — um requisito comum em ambientes com exigências rigorosas de segurança e conformidade.
Por que isso importa
Antes dessa novidade, quem precisava conectar brokers RabbitMQ a provedores de identidade privados — como LDAP ou OAuth 2.0 — ou a outros brokers RabbitMQ (hospedados no Amazon MQ ou de forma autônoma) tinha que recorrer a soluções alternativas pouco elegantes: configurar um Network Load Balancer combinado com um NAT Gateway só para viabilizar essa comunicação. Isso adicionava complexidade operacional, custo e pontos extras de manutenção.
Agora, a AWS resolve esse problema de forma nativa, sem que o time precise montar esse tipo de contorno manual. Os casos de uso mais beneficiados são:
Conectividade para RabbitMQ Federation e Shovel
Autenticação via provedores de identidade privados (LDAP, OAuth 2.0)
Comunicação entre brokers Amazon MQ e brokers RabbitMQ auto-hospedados
Como a AWS implementou essa funcionalidade
A conectividade privada é estabelecida pela AWS utilizando três serviços em conjunto:
Amazon VPC Lattice — responsável pelo roteamento de rede entre os recursos
AWS Resource Access Manager (AWS RAM) — para empacotar e compartilhar as configurações de recursos
AWS PrivateLink — para garantir que o tráfego não saia pela internet pública
O ponto positivo é que a AWS gerencia toda a infraestrutura subjacente automaticamente. O time não precisa se preocupar com a configuração de baixo nível desses componentes.
Como começar a usar
Para habilitar a conectividade privada no seu broker, o fluxo básico é:
Criar um resource gateway no VPC Lattice
Empacotar as configurações de recursos em um resource share do AWS RAM
Associar esse resource share ao seu broker
A funcionalidade está disponível exclusivamente para brokers Amazon MQ para RabbitMQ, em todas as regiões da AWS onde o Amazon VPC Lattice já está disponível.
AWS disponibiliza relatórios SOC em formato legível por máquina
A Amazon Web Services (AWS) anunciou a disponibilização dos relatórios de Controles de Sistema e Organização (SOC) 1 e 2 referentes à primavera de 2026 em formato OSCAL — um formato legível por máquina — além da versão tradicional em PDF. Essa é uma novidade relevante para equipes de segurança e conformidade que buscam automatizar processos de auditoria.
O que cobre esse relatório?
Os relatórios abrangem 188 serviços da AWS ao longo de um período de 12 meses, de 1º de abril de 2025 a 31 de março de 2026. Isso significa que os clientes têm um ano completo de garantias de conformidade documentadas em um único pacote.
O que é o formato OSCAL?
O Linguagem Aberta de Avaliação de Controles de Segurança (OSCAL) é um padrão aberto desenvolvido pelo Instituto Nacional de Padrões e Tecnologia (NIST) dos Estados Unidos. Em termos práticos, trata-se de um formato JSON de código aberto para representar informações de segurança de maneira estruturada e processável por sistemas automatizados.
A AWS se destaca como a primeira grande provedora de nuvem a oferecer relatórios-chave de conformidade nesse formato — marco registrado em junho de 2026.
Por que isso importa para quem trabalha com conformidade?
Ter o relatório SOC em formato legível por máquina abre caminho para automação de fluxos de trabalho, reduzindo o tempo gasto em processamentos manuais e modernizando os processos de segurança e conformidade. Em vez de extrair dados manualmente de um PDF, equipes podem integrar o conteúdo diretamente em suas ferramentas e pipelines de auditoria.
O pacote dos relatórios SOC 1 e SOC 2 em formato OSCAL já está disponível como um pacote separado no AWS Artifact, o portal de autoatendimento da AWS para acesso sob demanda a relatórios de conformidade.
A AWS continua expandindo a lista de serviços cobertos por seus programas de conformidade. A lista atualizada de serviços dentro do escopo pode ser consultada na página de Serviços em Escopo. Para uma visão mais ampla sobre os programas de segurança e conformidade da AWS, vale conferir os Programas de Conformidade da AWS.
A AWS anunciou uma nova capacidade do AWS DevOps Agent: o gerenciamento de releases, agora disponível em preview. Com essa adição, o agente passa a atuar tanto na entrega quanto nas operações, cobrindo o ciclo completo — desde a validação das mudanças de código até a manutenção das aplicações em produção.
Como funciona na prática
A nova funcionalidade se divide em dois pilares principais: revisão de prontidão para release e testes automatizados de release.
Revisão de prontidão para release
Antes mesmo de um commit ser feito, o AWS DevOps Agent avalia se as mudanças de código estão prontas para ir a produção com segurança. Esse processo inclui:
Verificação de desvios em relação aos padrões internos da equipe;
Análise de impactos em dependências;
Checagem de controles de acesso;
Mapeamento de dependências entre repositórios para identificar breaking changes antes do commit;
Uso de provas determinísticas para garantir que mudanças de infraestrutura não se afastem das boas práticas do AWS Well-Architected.
Testes de release
O agente também gera e executa planos de teste para aplicações web e baseadas em API, rodando esses testes em ambientes provisionados pelo próprio cliente. O objetivo é capturar regressões, problemas de experiência do usuário (UX) e falhas de integração que um revisor humano poderia deixar passar.
Por que isso importa para times de engenharia
Com esse conjunto de capacidades, a AWS posiciona o DevOps Agent como uma ferramenta que cobre ambientes AWS, multicloud e on-premises. O benefício direto é a aceleração do ciclo de entrega com mais segurança, redução do Tempo Médio para Recuperação (MTTR) e busca pela excelência operacional — tudo sem depender exclusivamente de revisões manuais.
Disponibilidade e custos
O gerenciamento de releases do AWS DevOps Agent está disponível atualmente na região US East (Norte da Virgínia) e sem custo adicional durante o período de preview. Para começar, basta conectar os repositórios de código e pipelines no espaço do AWS DevOps Agent.
Para consultar as regiões onde as operações de produção do AWS DevOps Agent estão disponíveis, acesse a tabela de regiões suportadas. Para informações sobre preços das funcionalidades de operações de produção, que já estão em disponibilidade geral, consulte a página de preços do AWS DevOps Agent.
O modelo de segurança que conhecemos está ficando para trás
A AWS tem refletido profundamente sobre segurança corporativa — e a conclusão é direta: o modelo operacional que funcionou na última década não está mais acompanhando o ritmo atual. O ciclo tradicional de coletar telemetria, armazená-la, consultá-la e construir dashboards para monitoramento já não é suficiente.
A mudança necessária vai em outra direção: telemetria, contexto, raciocínio e ações. Uma abordagem orientada a resultados concretos, não apenas a visibilidade.
O que tornou essa transição ainda mais urgente foi o avanço dos modelos de cibersegurança de fronteira. Modelos como o Claude Mythos já conseguem encontrar vulnerabilidades de software e raciocinar sobre caminhos complexos de ataque em velocidade de máquina — o que gera um backlog de vulnerabilidades que cresce de forma exponencial. Times humanos simplesmente não conseguem acompanhar esse ritmo sozinhos.
O que é o AWS Continuum
Em resposta a esse cenário, a AWS anunciou o AWS Continuum para vulnerabilidades de código, agora disponível em prévia fechada (gated preview). A proposta do Continuum é endereçar o ciclo completo de uma vulnerabilidade de código em velocidade de máquina: da descoberta até as ações corretivas.
O sistema raciocina sobre o ambiente completo do cliente, confirma o que é real e conduz o processo em direção à resolução. Uma característica importante: ele é agnóstico em relação a modelos, ou seja, utiliza múltiplos modelos de fronteira, aproveitando cada um onde ele performa melhor, e foi construído para incorporar os modelos mais recentes e capazes à medida que surgem.
O Continuum foi desenvolvido a partir de lições aprendidas pela própria AWS ao proteger suas operações internas e as da Amazon.com. Proteger negócios de diferentes setores exigiu um sistema capaz de entender o contexto do negócio, em vez de aplicar regras genéricas de forma uniforme.
Como o AWS Continuum funciona
O Continuum para vulnerabilidades de código opera em quatro fases contínuas:
1. Descoberta
Times de segurança lidam diariamente com um backlog de vulnerabilidades, e muitos já usam modelos de fronteira para encontrar mais. O Continuum começa ingerindo esse backlog existente e realizando sua própria varredura de vulnerabilidades no ambiente. Isso cria uma visão mais abrangente das vulnerabilidades e dos caminhos de ataque associados.
2. Priorização
O Continuum usa contexto para avaliar, enriquecer e priorizar cada achado. O componente afetado está em produção? Ele é alcançável? Qual seria o impacto para o negócio se fosse explorado? O resultado é uma lista de prioridades baseada em evidências, permitindo que o time foque no que realmente importa.
3. Validação
Antes de desperdiçar o tempo do time com falsos positivos, o Continuum valida os achados. Ele contextualiza as vulnerabilidades em relação ao ambiente real e constrói exemplos funcionais de exploração em um ambiente isolado (sandbox), fornecendo evidências concretas e reproduzíveis do problema.
4. Mitigação e Remediação
Com uma vulnerabilidade validada em mãos, o Continuum avalia as defesas existentes — incluindo controles de bloqueio, controles compensatórios e mecanismos de detecção. Em seguida, com base no entendimento da base de código, do contexto e dos achados, ele recomenda a mitigação ou remediação da vulnerabilidade por meio de uma mudança de rede, mudança de política ou patch de código.
A recomendação de patch é validada pelo mesmo sistema que confirmou a vulnerabilidade. O Continuum também oferece visibilidade sobre o raio de impacto (blast radius) e caminhos de rollback onde viável.
Confiança graduada: do modo de aprendizado ao modo de execução
O Continuum começa em modo de aprendizado (learn mode), com um humano no loop. Cada recomendação inclui o raciocínio por trás dela, o que permite que o time entenda e valide as sugestões antes de qualquer ação.
À medida que a confiança é construída, é possível avançar o Continuum para o modo de execução (enforce mode), habilitando remediações que podem ser cada vez mais automatizadas com base em categorias e perfis de risco definidos pelo próprio time.
Capacidades do AWS Continuum
Além do Continuum para vulnerabilidades de código, o AWS Continuum reúne outras capacidades que alguns profissionais já podem conhecer:
Continuum pen testing e Continuum code scanning (Preview): as funcionalidades de teste de penetração e varredura de código do AWS Security Agent foram integradas ao Continuum sob esses novos nomes.
Continuum threat modeling (Preview): gera automaticamente modelos de ameaças abrangentes a partir de documentos de design ou código-fonte, com resultados no formato STRIDE.
Essas capacidades funcionam como fontes de detecção e análise que alimentam o loop mais amplo do Continuum: descoberta, priorização, validação e remediação.
Quem está usando e como começar
A AWS está trabalhando com clientes dos setores financeiro, automotivo e de tecnologia para moldar o AWS Continuum. O feedback dos clientes confirma a direção: times de segurança querem ferramentas que conquistem confiança e tomem ações.
O AWS Continuum para vulnerabilidades de código está disponível em prévia fechada. Para solicitar acesso, é possível se inscrever diretamente na página oficial do AWS Continuum.
O que é um registro DNS “dangling” e por que isso importa
Imagine que sua equipe configurou um subdomínio amigável — como api.suaempresa.com — apontando para um bucket do Amazon S3 via registro CNAME (Nome Canônico). Em algum momento, o bucket é deletado, mas ninguém lembrou de remover o registro DNS. Esse registro que ficou para trás, apontando para um recurso que não existe mais, é chamado de dangling record (registro pendente ou órfão).
O problema real começa quando um agente malicioso percebe esse estado. Como certos recursos da AWS utilizam namespaces globais — ou seja, qualquer conta pode reivindicar o mesmo nome de recurso após ele ser deletado — o atacante pode simplesmente recriar o recurso com o mesmo nome e passar a servir conteúdo malicioso para qualquer usuário que ainda acesse aquele subdomínio.
Essa técnica é classificada pelo MITRE ATT&CK como T1584.001: Comprometimento de Infraestrutura – Domínios. Vale reforçar: não se trata de uma vulnerabilidade nos serviços da AWS em si, mas de uma má configuração operacional que pode ser explorada.
Quais recursos AWS são afetados
Nem todo recurso da AWS é suscetível a esse tipo de ataque. O risco existe apenas nos serviços que operam em namespaces globalmente compartilhados, onde qualquer conta pode reivindicar o nome após a exclusão. Os principais são:
Amazon S3 (namespace global): nomes de buckets como meubucket.s3.amazonaws.com são globalmente únicos e podem ser reclamados por qualquer conta após a exclusão. Importante: buckets criados com namespaces regionais por conta (lançados em março de 2026) ficam restritos à conta do proprietário e não são afetados por esse problema.
Amazon CloudFront: os nomes de distribuição como d111111abcdef8.cloudfront.net são atribuídos pela AWS e não podem ser escolhidos por um atacante. Porém, se uma distribuição for deletada e outra conta receber o mesmo nome gerado automaticamente, um CNAME pendente pode acabar resolvendo para o conteúdo de terceiros.
AWS Elastic Beanstalk: nomes de ambiente como meuapp.elasticbeanstalk.com são globalmente únicos e podem ser reivindicados por qualquer conta após o encerramento do ambiente.
Recursos como Amazon VPC, instâncias Amazon EC2 ou zonas hospedadas privadas não são afetados, pois não expõem namespaces DNS globalmente reivindicáveis.
Como o ataque acontece na prática
O time AWS CIRT publicou um cenário ilustrativo que ajuda a entender o problema de ponta a ponta. Considere o seguinte fluxo:
Uma equipe cria um bucket S3 com nome global único — por exemplo, subdomain.example — e o configura para hospedar um site estático.
Um registro CNAME no Amazon Route 53 é criado para que subdomain.example.com resolva para subdomain.example.s3-website-us-east-1.amazonaws.com, dando um endereço amigável aos usuários.
Até aqui, tudo normal. O problema surge quando o administrador decide desativar o site e deleta o bucket S3 — mas esquece de remover o registro CNAME no Route 53.
Com o bucket deletado e o CNAME ainda ativo, o registro fica “dangling”. Um agente malicioso que identifica esse estado pode criar um novo bucket S3 com exatamente o mesmo nome global — subdomain.example — em uma conta que ele controla, e passar a servir qualquer conteúdo a partir daí. Os usuários finais continuam acessando subdomain.example.com sem perceber que o destino mudou.
Os riscos não são teóricos. O AWS CIRT lista os principais impactos observados:
Risco reputacional: sua organização perde o controle sobre o conteúdo servido a partir de um domínio que carrega sua marca.
Exposição a campanhas de phishing: usuários que têm o subdomínio salvo nos favoritos podem ser direcionados para páginas que capturam credenciais ou distribuem malware sem nenhum sinal de alerta visível.
Bloqueio por fornecedores de segurança: se o domínio for sinalizado como malicioso, isso pode impactar diretamente suas operações de negócio.
Perda financeira: além do dano direto, há custos associados à resposta ao incidente e à interrupção de serviços.
Detecção proativa com AWS Config
A abordagem recomendada pela AWS para detectar registros CNAME órfãos é usar o AWS Config para monitorar continuamente as zonas hospedadas do Route 53 e verificar se os recursos-alvo ainda existem na sua conta.
Um ponto importante que o artigo destaca: verificar se um CNAME resolve para um endpoint válido não é suficiente. Se um atacante já reivindicou o recurso, a resolução DNS vai funcionar — mas para o recurso do atacante, não o seu. Você não teria como saber a diferença apenas pela resolução. A abordagem correta é consultar o inventário do AWS Config para confirmar se o recurso existe na sua conta.
A ideia central é criar uma regra personalizada no AWS Config que consulta as zonas hospedadas do Route 53, identifica registros CNAME que apontam para padrões conhecidos de recursos AWS (S3, CloudFront, Elastic Beanstalk) e cruza cada alvo com o inventário do Config. Se o recurso não for encontrado, o CNAME é marcado como NON_COMPLIANT.
Pré-requisito: o gravador do AWS Config precisa estar habilitado para os tipos de recurso que você deseja monitorar. Para mais informações, consulte a documentação oficial sobre como configurar o AWS Config pelo console.
Escopo: conta única vs. organização
A implementação de referência opera no escopo de uma única conta. Isso significa que se um CNAME na Conta A aponta para um recurso que legitimamente existe na Conta B (dentro da mesma organização AWS), a regra vai sinalizá-lo como NON_COMPLIANT. Para ambientes com compartilhamento de recursos entre contas, é possível adaptar a solução usando um AWS Config Aggregator, que consulta o inventário de todas as contas da organização.
As ocorrências NON_COMPLIANT podem ser encaminhadas ao AWS Security Hub para visibilidade centralizada ou acionar notificações via Amazon SNS para alertar o time de segurança.
Implementação de referência
A AWS publicou uma solução completa e open source para esse caso de uso. Ela implanta uma função Lambda que varre os registros CNAME de todas as zonas hospedadas do Route 53, usa correspondência de padrões para identificar alvos que apontam para S3, CloudFront e Elastic Beanstalk, e consulta o inventário do AWS Config para verificar se cada recurso ainda existe na conta. Quando um registro órfão é detectado, a solução gera uma ocorrência de severidade ALTA no Security Hub e pode enviar notificações via SNS. Um painel no CloudWatch também é incluído para acompanhamento contínuo.
O deploy pode ser feito com os seguintes comandos:
# Clone the repository
git clone https://github.com/aws-samples/sample-dangling-dns-detection
cd sample-dangling-dns-detection
# Build the Lambda deployment package
./scripts/package.sh
# Upload to S3
aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/
# Deploy the CloudFormation stack
aws cloudformation deploy \
--template-file infrastructure/template.yaml \
--stack-name dangling-dns-detection \
--parameter-overrides \
LambdaCodeS3Bucket=YOUR_BUCKET \
EvaluationFrequency=TwentyFour_Hours \
--capabilities CAPABILITY_NAMED_IAM
A stack cria uma regra personalizada no AWS Config que roda no intervalo configurado (padrão: a cada 24 horas), avaliando todos os registros CNAME e reportando o status de conformidade.
Como mitigar: prevenção e resposta
Procedimento operacional padrão
A mitigação mais eficaz é um procedimento operacional claro para o descomissionamento de recursos. A ordem correta é sempre:
Remova o registro CNAME da zona DNS antes de desprovisionar o recurso.
Aguarde o TTL (Tempo de Vida — Time to Live) do registro expirar. Resolvedores DNS armazenam registros em cache pelo tempo do TTL (por exemplo, um TTL de 3600 significa que resolvedores podem servir o registro antigo por até uma hora). Deletar o recurso antes da expiração do TTL abre uma janela de vulnerabilidade.
Desprovisione o recurso.
Execute uma verificação DNS para confirmar que o CNAME não está mais resolvendo.
Princípio-chave: sempre delete o DNS primeiro, espere o TTL expirar e só então delete o recurso.
Buckets existentes não são migrados: buckets já criados no namespace global permanecem globalmente únicos e reivindicáveis por qualquer conta após a exclusão.
O namespace global ainda é o padrão: ao criar um novo bucket pelo console, CLI ou SDK, o namespace global continua sendo a seleção padrão.
Templates de IaC precisam ser atualizados: templates existentes de infraestrutura como código (CloudFormation, CDK, Terraform) que não optarem explicitamente pelo namespace regional de conta continuarão provisionando buckets no namespace global. No CloudFormation, isso exige configurar a propriedade BucketNamespace como account-regional.
Por essas razões, a abordagem de detecção via AWS Config continua sendo essencial — especialmente para organizações com infraestrutura S3 existente e para recursos como CloudFront e Elastic Beanstalk, onde não existe equivalente de escopo por namespace.
Notificação e remediação
Quando um registro DNS órfão é detectado, a solução de referência cria automaticamente uma ocorrência de severidade ALTA no AWS Security Hub e marca o CNAME como NON_COMPLIANT no AWS Config. Se um ARN (Nome de Recurso da Amazon — Amazon Resource Name) de tópico SNS for fornecido durante o deploy, a solução também envia notificações para o time de segurança via e-mail, Slack ou outros canais.
Para ambientes de produção, é recomendável adotar um fluxo com revisão humana antes de qualquer deleção automática de registro DNS. Remediação totalmente automatizada carrega risco: um falso positivo pode interromper serviços legítimos. O ponto de partida ideal é detecção e notificação; automação pode ser avaliada conforme a maturidade operacional do time.
Conclusão
O sequestro de subdomínio é uma misconfiguração evitável, mas com impacto potencialmente significativo. A defesa em camadas recomendada pela AWS combina:
Prevenção: procedimento operacional padrão que garante a remoção do DNS antes do descomissionamento do recurso.
Detecção: regras personalizadas no AWS Config para identificar proativamente CNAMEs que apontam para recursos inexistentes.
Resposta: notificações via SNS ou Security Hub para que o time reaja rapidamente quando registros órfãos forem detectados.
Monitoramento: visibilidade contínua via painéis no CloudWatch para acompanhar a saúde do DNS e o status de conformidade.
A boa higiene de DNS — saber quando seus registros CNAME apontam para recursos inexistentes — é a primeira linha de defesa. A detecção automatizada via AWS Config funciona como rede de segurança quando os procedimentos operacionais falham. E ter um playbook pronto para resposta reduz o tempo médio de recuperação quando um incidente é identificado.
A AWS anunciou uma atualização relevante para quem gerencia acesso ao Console de Gerenciamento: o AWS Sign-in agora oferece suporte a políticas baseadas em recursos e a Políticas de Controle de Recursos (RCPs — Resource Control Policies). A novidade permite que equipes de segurança restrinjam o login no console apenas a redes previamente autorizadas.
Como as políticas funcionam
As políticas são avaliadas em dois momentos distintos: durante o processo de autenticação e sempre que a sessão do console solicita novas credenciais. Isso garante que a verificação de rede não aconteça apenas no login inicial, mas de forma contínua ao longo da sessão.
Políticas baseadas em recursos
As políticas baseadas em recursos atuam no nível de contas individuais da AWS. São ideais para cenários em que o controle precisa ser aplicado de forma granular, conta a conta.
Políticas de Controle de Recursos (RCPs)
Já as RCPs operam em um escopo mais amplo: são aplicadas em toda a organização via AWS Organizations. Isso significa que uma única política pode cobrir múltiplas contas ao mesmo tempo, simplificando a gestão de segurança em ambientes corporativos maiores.
De quais redes os usuários podem fazer login no console
Quais contas esses usuários podem acessar após autenticados
Isso oferece uma camada extra de controle para organizações que precisam garantir que o acesso ao ambiente AWS ocorra exclusivamente por caminhos de rede confiáveis e controlados.
Disponibilidade e custos
As políticas baseadas em recursos e as RCPs do AWS Sign-in estão disponíveis sem custo adicional em todas as regiões comerciais da AWS. Não há cobrança extra para adotar o recurso.
Saiba mais
Para aprofundar o entendimento sobre o funcionamento e a configuração dessas políticas, a AWS disponibiliza o Guia do Usuário do AWS Sign-in. Para quem precisa de detalhes sobre integração via API, a referência técnica está disponível na Referência de API do AWS Sign-in.
