Kiro agora autorizado para ambientes governamentais de alta segurança
A AWS anunciou que o Kiro — seu Ambiente de Desenvolvimento Integrado (IDE) agêntico — conquistou as autorizações FedRAMP High e DoD CC SRG IL-4/5 (Guia de Requisitos de Segurança de Computação em Nuvem do Departamento de Defesa dos EUA, Níveis de Impacto 4 e 5) nas regiões AWS GovCloud (US).
Na prática, isso significa que agências federais americanas, organizações do setor público e empresas com requisitos rigorosos de conformidade podem agora utilizar o Kiro como parceiro de desenvolvimento agêntico, com a garantia de que a ferramenta atende aos padrões de segurança exigidos para cargas de trabalho sensíveis.
O que é o Kiro?
Para quem ainda não conhece, o Kiro é uma ferramenta de IA agêntica que integra um IDE e uma Interface de Linha de Comando (CLI). Seu diferencial está na abordagem de desenvolvimento orientado por especificações: em vez de simplesmente gerar código solto, o Kiro transforma prompts em especificações detalhadas e, a partir delas, produz código funcional, documentação e testes — tudo alinhado ao que foi definido desde o início.
O fluxo cobre desde tarefas simples até projetos complexos, acompanhando o desenvolvedor do protótipo até a produção. O resultado final é um produto pronto para ser compartilhado com o time, sem surpresas no caminho.
Integração com o ecossistema via MCP
Um ponto técnico relevante é o suporte nativo ao Protocolo de Contexto de Modelo (MCP). Por meio dele, o Kiro consegue se conectar a documentações, bancos de dados, APIs e outros recursos corporativos — o que amplia bastante sua capacidade de atuar em fluxos de desenvolvimento críticos para a missão da organização.
Por que essa certificação importa?
As certificações FedRAMP High e DoD IL-4/5 são referências de conformidade exigidas pelo governo federal dos Estados Unidos para sistemas que lidam com informações controladas não classificadas e dados sensíveis de defesa. Ao obtê-las, o Kiro passa a ser uma opção viável — e auditável — para ambientes onde a segurança não é negociável.
Para equipes de desenvolvimento que já operam no AWS GovCloud (US), essa novidade elimina uma barreira importante: agora é possível contar com um assistente de IA agêntico sem abrir mão das exigências de conformidade do setor público.
A AWS anunciou que os modelos OpenAI GPT, OpenAI GPT OSS e NVIDIA Nemotron, disponíveis no Amazon Bedrock, receberam aprovação para os padrões FedRAMP High e Guia de Requisitos de Segurança de Computação em Nuvem do Departamento de Defesa dos Estados Unidos (DoD CC SRG) nos níveis de impacto (IL) 4 e 5 — e tudo isso dentro das regiões do AWS GovCloud (US).
Essa é uma movimentação relevante para o mercado de inteligência artificial generativa voltado ao setor público norte-americano. Com essa certificação, agências federais, organizações do setor público e empresas que precisam atender às exigências de conformidade FedRAMP High e DoD CC SRG IL-4/5 passam a ter acesso oficial e aprovado a esses modelos dentro do Amazon Bedrock.
O que isso significa na prática
Para quem atua no setor governamental ou em projetos que exigem conformidade rigorosa com padrões de segurança norte-americanos, essa aprovação representa um passo importante. Significa que é possível construir e escalar aplicações de IA generativa usando esses modelos com a garantia de que eles atendem aos padrões de segurança e conformidade exigidos para cargas de trabalho governamentais.
Em outras palavras: as equipes não precisam mais abrir mão de modelos de ponta como os da OpenAI e da NVIDIA para manter a conformidade com as exigências do governo dos EUA. Agora é possível usar os dois ao mesmo tempo.
A tecnologia por trás: o Mantle
Vale destacar que esses modelos são executados com suporte do Mantle, descrito pela AWS como um mecanismo de inferência distribuída de nova geração dentro do Amazon Bedrock. O Mantle oferece:
Inferência serverless de alto desempenho
Zero acesso por operadores (reforço de isolamento e segurança)
Gerenciamento automatizado de capacidade
Compatibilidade nativa com as especificações da API da OpenAI
Esse conjunto de características é especialmente relevante no contexto governamental, onde o controle de acesso e o isolamento de dados são requisitos críticos.
Para quem é relevante
Embora o anúncio seja voltado ao contexto regulatório dos Estados Unidos, ele é importante para profissionais e empresas brasileiras que:
Prestam serviços ou têm operações em território norte-americano sujeitas a regulamentações federais
Desenvolvem soluções para clientes do setor público dos EUA
Acompanham o avanço da conformidade regulatória em IA como referência para outros mercados
A AWS anunciou o lançamento dos AMI Watermarks (Marcas d’água de AMI), um novo recurso do Amazon EC2 voltado para melhorar a rastreabilidade e a governança de Imagens de Máquina da Amazon (AMI — Amazon Machine Image). A proposta é simples e poderosa: você pode incorporar identificadores personalizados diretamente em suas AMIs privadas, criando uma cadeia de confiança que persiste independentemente de quantas cópias ou derivações sejam feitas a partir da imagem original.
Como funciona a propagação das marcas
Um dos pontos mais relevantes do recurso é o comportamento automático de propagação. Uma vez que uma marca d’água é aplicada a uma AMI, ela se mantém presente em todas as imagens derivadas — seja ao copiar a AMI para outra região, seja ao criar uma nova AMI a partir de uma instância em execução. As marcas também permanecem visíveis quando a AMI é compartilhada com outras contas AWS.
Cada marca d’água carrega metadados como: ID da AMI, ID do proprietário, região e timestamps de criação. Essas informações formam uma trilha de proveniência confiável que não se perde ao longo do ciclo de vida da imagem.
Benefícios para rastreamento e governança
Com os AMI Watermarks, as equipes ganham a capacidade de filtrar e localizar AMIs relacionadas entre diferentes contas, facilitando o gerenciamento em ambientes multi-conta. Do ponto de vista de governança, o recurso se torna ainda mais poderoso quando combinado com as AMIs Permitidas (Allowed AMIs): é possível restringir o lançamento de instâncias apenas para AMIs que carreguem marcas d’água aprovadas, garantindo que somente imagens confiáveis sejam utilizadas na organização. Essa restrição pode ser aplicada em escala por meio de Políticas Declarativas (Declarative Policies).
Como começar a usar
A AWS disponibilizou o recurso para uso imediato. As marcas d’água podem ser adicionadas a AMIs privadas pelo Console de Gerenciamento da AWS, pela Interface de Linha de Comando (AWS CLI) ou por meio dos Kits de Desenvolvimento de Software (SDKs). Para mais detalhes técnicos, a AWS disponibilizou a documentação oficial do recurso.
Também é possível incorporar as marcas d’água durante o processo de construção de imagens por meio do EC2 Image Builder, serviço dedicado à criação e ao gerenciamento de AMIs, integrando o recurso diretamente ao pipeline de build.
Disponibilidade e custos
Os AMI Watermarks estão disponíveis para todos os clientes AWS sem custo adicional, em todas as regiões AWS — incluindo as regiões da China (Beijing, operada pela Sinnet, e Ningxia, operada pela NWCD) e as regiões AWS GovCloud (EUA).
A AWS anunciou a disponibilidade geral do AWS IoT Device SDK para Swift, uma novidade relevante para times de desenvolvimento que trabalham com o ecossistema Apple. A partir de agora, desenvolvedores Swift podem construir aplicações IoT seguras e escaláveis de forma nativa em plataformas como macOS, iOS e tvOS, além do Linux.
Antes desse lançamento, havia uma lacuna importante: não existia suporte nativo à linguagem Swift para os serviços de Tecnologia de Internet das Coisas (IoT) da AWS. Esse SDK chega para preencher exatamente esse espaço, oferecendo APIs estáveis e prontas para produção, pensadas especialmente para times que gerenciam frotas de dispositivos IoT e precisam de soluções que funcionem de forma consistente em todo o ecossistema Apple.
Principais capacidades do SDK
O SDK entrega um conjunto abrangente de funcionalidades para gerenciamento de dispositivos em tempo real e comunicação segura. Veja os destaques:
AWS IoT Device Shadow: permite sincronizar o estado dos dispositivos entre as aplicações e o AWS IoT Core, mantendo consistência mesmo quando o dispositivo está offline.
AWS IoT Jobs: possibilita gerenciar operações remotas em dispositivos conectados em escala, facilitando atualizações e tarefas programadas.
AWS IoT Fleet Provisioning: automatiza a criação de certificados e políticas para o cadastramento seguro de novos dispositivos na frota.
Segurança de Camada de Transporte 1.3 (TLS 1.3) integrado: garante que as aplicações IoT em iOS e tvOS utilizem o padrão de segurança mais recente da indústria para proteger os dados em trânsito.
Por que isso importa para desenvolvedores brasileiros
Times que desenvolvem produtos conectados para o ecossistema Apple — seja um app iOS que se comunica com sensores, um painel macOS para monitoramento de dispositivos ou soluções embarcadas em Linux — agora contam com um SDK oficial, estável e mantido pela AWS. Isso reduz a necessidade de gambiarras ou bibliotecas de terceiros para integrar dispositivos ao AWS IoT Core usando Swift.
A inclusão do TLS 1.3 nativo para iOS e tvOS é um ponto que merece atenção: significa que a camada de segurança já vem configurada segundo as melhores práticas do setor, sem exigir configurações adicionais do desenvolvedor.
Como começar
A instalação do SDK é feita diretamente pelo Swift Package Manager, o gerenciador de pacotes nativo da linguagem Swift. Para quem quer explorar mais, a AWS disponibiliza a documentação oficial do AWS IoT Device SDK e também exemplos de código no GitHub para acelerar o aprendizado e a implementação.
A AWS anunciou uma nova capacidade para o Amazon Bedrock AgentCore Memory: o suporte a acesso entre contas, conhecido como cross-account access. Com essa novidade, passa a ser possível construir arquiteturas multi-account em que os recursos de memória e os agentes que os consomem estão em contas AWS diferentes.
Como funciona o acesso entre contas
A configuração do acesso entre contas é feita por meio de políticas baseadas em recursos (resource-based policies), que são anexadas diretamente ao recurso de memória. Essa abordagem é bastante comum no ecossistema AWS e permite um controle granular sobre quem pode acessar o quê.
Uma vez configurado, os principais (principals) da conta consumidora ganham permissão para chamar as APIs do plano de dados de memória referenciando o ARN completo do recurso de memória. Com isso, esses principals conseguem realizar as seguintes operações:
Criar eventos
Escrever registros de memória
Recuperar registros
Executar buscas semânticas
Destinos de entrega entre contas
Além do acesso direto às APIs, o recurso também permite configurar destinos de entrega entre contas (cross-account delivery destinations). Isso significa que o recurso de memória pode entregar payloads e transmitir eventos para serviços que estão em outras contas AWS, incluindo:
Amazon S3 — buckets em contas distintas
Amazon SNS — tópicos em outras contas
Amazon Kinesis Data Streams — streams em contas separadas
Essa flexibilidade é especialmente útil para organizações que adotam estratégias de múltiplas contas para separar ambientes, equipes ou domínios de negócio, e que precisam que os agentes de IA compartilhem contexto de memória de forma centralizada ou distribuída.
Disponibilidade
O suporte a cross-account access no Amazon Bedrock AgentCore Memory está disponível em todas as regiões AWS onde o Amazon Bedrock AgentCore Memory já é suportado. Não há necessidade de habilitar nada separadamente em termos de região — basta que o serviço base já esteja disponível no ambiente utilizado.
Para começar a usar o recurso, a AWS disponibiliza o guia Acesso a memória entre contas no Amazon Bedrock AgentCore Developer Guide, com o passo a passo de configuração.
A AWS anunciou, em junho de 2026, uma novidade relevante para equipes que gerenciam infraestrutura em nuvem: o Amazon CloudWatch Logs agora suporta ingestão gerenciada de syslog. Isso significa que firewalls, roteadores, switches e servidores Linux podem enviar mensagens de log diretamente para o CloudWatch Logs — sem a necessidade de instalar ou manter qualquer agente.
Como funciona a ingestão de syslog
Com esse novo recurso, é possível configurar dispositivos de rede e servidores para encaminhar mensagens de syslog via TCP, TCP+TLS ou UDP para um endpoint de Nuvem Privada Virtual (VPC) na própria conta da AWS. A ausência de agentes simplifica bastante a operação, especialmente em ambientes distribuídos onde a implantação e manutenção de coletores de log costuma gerar overhead significativo.
Formatos suportados e compatibilidade
O CloudWatch Logs passou a ser compatível com três formatos amplamente utilizados na indústria:
RFC 5424 — padrão moderno de syslog
RFC 3164 — formato legado, ainda muito presente em equipamentos mais antigos
Cisco FTD/ASA — formato proprietário de appliances Cisco de segurança de rede
Essa abrangência garante compatibilidade com uma ampla variedade de infraestruturas, o que é especialmente relevante para ambientes híbridos ou com equipamentos de diferentes fabricantes.
Parsing automático e campos estruturados
Um ponto de destaque é que o CloudWatch Logs realiza o parsing automático das mensagens de syslog recebidas, extraindo campos estruturados como facility, severity (severidade), hostname e application name (nome da aplicação). Isso elimina a necessidade de construir pipelines customizados de parsing — algo que historicamente consumia tempo e esforço das equipes de operações.
Caso de uso: investigação de eventos de segurança
Um exemplo prático mencionado pela AWS: equipes podem ingerir logs de firewalls de rede e, imediatamente, consultar esses dados por severidade ou hostname usando o Logs Analytics — seja para investigar eventos de segurança ou diagnosticar problemas de conectividade. A centralização desses logs em um único serviço facilita tanto a resposta a incidentes quanto a análise operacional do dia a dia.
Disponibilidade
O recurso já está disponível em todas as regiões comerciais da AWS, com exceção de Middle East (UAE), Middle East (Bahrain) e Israel (Tel Aviv). Para começar a utilizar, a AWS disponibiliza a documentação oficial do Amazon CloudWatch Logs.
Controle total sobre a criptografia dos dados de identidade
A AWS anunciou uma atualização importante no Amazon Cognito: o serviço agora suporta chaves gerenciadas pelo cliente (CMK) no Serviço de Gerenciamento de Chaves da AWS (AWS KMS) para criptografar dados de user pools em repouso.
Até então, o Cognito utilizava chaves de propriedade da própria AWS por padrão para proteger os dados armazenados. Esse modelo funciona bem para a maioria dos cenários, mas organizações com requisitos mais rígidos de governança de dados precisavam de um nível maior de controle — e é exatamente isso que a nova funcionalidade entrega.
O que muda na prática
Com as chaves gerenciadas pelo cliente, a organização passa a ser responsável por criar, gerenciar e controlar o ciclo de vida das chaves de criptografia diretamente no AWS KMS. Isso traz algumas vantagens concretas:
É possível definir políticas organizacionais sobre quem pode usar as chaves e em quais condições.
O acesso aos dados criptografados pode ser revogado a qualquer momento, bastando desabilitar ou excluir a chave correspondente.
Toda a utilização das chaves pode ser monitorada e auditada via AWS CloudTrail, oferecendo visibilidade completa sobre quando e como os dados de identidade são acessados.
Como configurar
A configuração é flexível: é possível definir uma chave gerenciada pelo cliente tanto na criação de um novo user pool quanto na atualização de um user pool já existente. Para começar, basta acessar o Console de Gerenciamento da AWS, ou utilizar a AWS CLI ou os SDKs da AWS. A documentação oficial para desenvolvedores traz as instruções detalhadas de configuração.
Disponibilidade e custos
O recurso está disponível nos user pools dos planos Essentials e Plus do Amazon Cognito, sem custo adicional pelo uso da funcionalidade em si. Vale lembrar que as tarifas padrão do AWS KMS continuam sendo aplicadas normalmente.
Por que isso importa para equipes brasileiras
Para times que lidam com dados sensíveis de usuários — especialmente em contextos regulatórios como a LGPD — ter controle explícito sobre as chaves de criptografia é um diferencial importante. A possibilidade de revogar acesso programaticamente e auditar cada uso da chave eleva significativamente o nível de rastreabilidade e conformidade que uma organização pode demonstrar.
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.
