Category: Uncategorized

O problema: correlacionar dados manualmente custa tempo

Quando um administrador altera uma regra no AWS Network Firewall e a conectividade cai, identificar a causa exige inspecionar vários pontos ao longo do caminho do tráfego. O firewall oferece motores de regras stateless e stateful, regras de domínio e roteamento até o endpoint do firewall dentro da Rede Virtual Privada da Amazon (Amazon VPC). Para a carga de trabalho, uma queda de pacotes parece idêntica independentemente de onde se originou. Isolar a causa significa cruzar logs de alertas e de fluxo com a configuração do firewall, tabelas de rotas e chamadas de API recentes no AWS CloudTrail que possam ter modificado algum desses recursos.

É exatamente nessa correlação manual que o AWS DevOps Agent entra. Funcionando como um parceiro de operações sempre disponível, ele resolve e previne proativamente problemas operacionais em ambientes AWS, multicloud e on-premises. Quando um alarme do Amazon CloudWatch dispara, ele chega ao agente via webhook. O agente lê a configuração e os logs do firewall pelas APIs da AWS, associa a queda à atividade recente de API e devolve uma causa raiz acompanhada de um plano de mitigação — que você revisa antes de aplicar.

A arquitetura do ambiente de demonstração

A AWS disponibilizou um aplicativo AWS Cloud Development Kit (AWS CDK) que implanta todo o ambiente na sua própria conta, permitindo reproduzir cada falha e acompanhar o passo a passo. A carga de trabalho consiste em uma instância t3.micro em uma sub-rede protegida que verifica conectividade com um endpoint de teste em loop contínuo e publica os resultados no CloudWatch. O tráfego percorre o caminho de saída pela internet através do Network Firewall, do gateway NAT e do gateway de internet.

O endpoint de teste roda em uma VPC separada implantada pelo mesmo aplicativo CDK, servindo HTTPS na porta 443 e TCP na porta 9142. O pipeline de alarmes corre do CloudWatch pelo Amazon Simple Notification Service (Amazon SNS) e por uma função AWS Lambda de webhook até o DevOps Agent.

Para usar o mesmo padrão com sua própria carga de trabalho, você precisa de um alarme no CloudWatch que detecte o problema de conectividade e do pipeline de webhook (tópico SNS e função Lambda) que o entrega ao DevOps Agent. O agente lê configuração do firewall, logs e CloudTrail pelas APIs da AWS — sem necessidade de instrumentação adicional no lado do firewall.

Pré-requisitos e implantação

Para seguir o guia, são necessários:

• Uma conta AWS com permissões para implantar Amazon VPC, Network Firewall, Amazon Elastic Compute Cloud (Amazon EC2), CloudWatch, Amazon SNS, Lambda, Amazon CloudFront e recursos de AWS Identity and Access Management (IAM)
• Acesso ao AWS DevOps Agent com permissão para configurar o webhook
• Node.js 18 ou superior e npm instalados
• AWS Command Line Interface (AWS CLI) 2.x configurado com credenciais
• AWS CDK 2.x

O deploy é feito clonando o repositório e executando o script abaixo, que verifica pré-requisitos, instala dependências, compila, testa, faz o bootstrap do CDK se necessário e implanta todas as stacks:

git clone https://github.com/aws-samples/sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent.git
cd sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent
bash scripts/deploy.sh

Após o deploy, abra o link da página de status (um endereço https://<random-id>.cloudfront.net) e confirme que os três cards mostram o status Healthy (saudável) em verde.

Como o pipeline de alarmes funciona

Todos os cenários chegam ao DevOps Agent pelo mesmo caminho: um alarme do CloudWatch muda para o estado ALARM e notifica o tópico SNS. O SNS invoca a função Lambda, que lê a URL do webhook e o segredo de assinatura do AWS Secrets Manager, assina o payload do alarme e faz um POST para o webhook do DevOps Agent.

Há dois tipos de alarme no ambiente de demonstração:

• Alarm-1 — usa a métrica nativa AWS/NetworkFirewall DroppedPackets, somada nos fluxos stateful. Não exige nenhuma instrumentação adicional na carga de trabalho, mas só informa que o firewall está descartando pacotes, sem identificar qual regra é responsável.
• Alarm-2 e Alarm-3 — usam uma métrica customizada de verificação de conectividade. São úteis para alarmes vinculados ao impacto real no usuário ou para distinguir um caminho de tráfego de outro.

Cenário 1: lista de negação de domínio bloqueando um endpoint legítimo

Na baseline, o grupo de regras Suricata rg-domain nega apenas um placeholder não utilizado, mantendo o endpoint de teste acessível. O grupo inspeciona o Indicador de Nome do Servidor TLS (TLS SNI) em cada conexão de saída e descarta as que correspondem a um domínio negado.

Para introduzir a falha, adiciona-se uma regra drop no grupo rg-domain que corresponde ao nome DNS do endpoint de teste no SNI do TLS:

drop tls $HOME_NET any -> $EXTERNAL_NET any (ssl_state:client_hello; tls.sni; content:"<app-endpoint-dns>"; startswith; nocase; endswith; msg:"S1 domain denylist"; flow:to_server, established; sid:2000002; rev:1;)

Após salvar, a verificação HTTPS da carga de trabalho para o endpoint expira, a métrica DroppedPackets sobe acima da baseline e o Alarm-1 entra em ALARM. Os cenários 2 e 3 permanecem saudáveis.

O DevOps Agent executa várias linhas de investigação em paralelo:

• Lê a métrica DroppedPackets e correlaciona o pico com uma queda simultânea em pacotes passados, confirmando que o firewall está bloqueando tráfego ativamente.
• Lê o log de ALERTA e encontra as conexões TLS da carga de trabalho bloqueadas pela regra S1 domain denylist.
• Compara o estado atual com uma janela de baseline onde o mesmo endpoint era acessível sem alertas.
• Busca no CloudTrail e identifica a chamada UpdateRuleGroup que adicionou a regra de negação, com usuário, papel assumido e timestamp — aproximadamente um minuto antes do início dos descartes.
• Reporta a causa raiz como aquela alteração manual no grupo de regras e recomenda remover a entrada de negação ou adicionar uma exceção de permissão, além de habilitar FirewallPolicyChangeProtection para evitar alterações não autorizadas.

Atenção: em um ambiente real, esse tipo de regra normalmente existe por um motivo. Antes de removê-la, verifique se foi intencional mas com escopo muito amplo. Se for o caso, refine a regra para bloquear apenas endpoints não autorizados em vez de removê-la inteiramente.

Cenário 2: inversão de prioridade em regra stateless

Na baseline, o grupo de regras stateless rg-stateless-priority mantém a regra de permissão na prioridade 100 e a regra de descarte na prioridade 200 para a classe de tráfego TCP na porta de destino 9142. Como o Network Firewall avalia os números de prioridade menores primeiro, a regra de permissão vence.

Para introduzir a falha, inverte-se as duas prioridades: a regra de permissão passa para a prioridade 300 e a regra de descarte permanece em 200. Isso faz com que a regra de descarte seja avaliada primeiro — exatamente o tipo de erro que uma edição apressada pode introduzir.

Como um descarte stateless ocorre antes de o tráfego alcançar o motor de inspeção stateful, não há entradas de ALERTA nos logs. O agente recorre à configuração e aos logs de fluxo:

• Lê o estado do grupo de regras stateless e encontra a regra de descarte com número de prioridade menor, à frente da regra de permissão.
• Lê os logs de fluxo e observa os pacotes passados caírem a zero dentro de um minuto após a mudança.
• Busca no CloudTrail e identifica a chamada UpdateRuleGroup que inverteu as prioridades.
• Reporta a causa raiz como essa inversão de prioridade e recomenda remover a regra de descarte redundante e gerenciar o grupo de regras por infraestrutura como código (IaC) para evitar erros manuais.

Cenário 3: descarte por roteamento assimétrico entre Zonas de Disponibilidade

Na baseline, a sub-rede protegida em cada Zona de Disponibilidade (AZ) roteia sua saída pelo endpoint do firewall na mesma AZ. Assim, um endpoint vê as duas direções do fluxo e o motor stateful completa o handshake.

Para criar a falha, são necessárias duas edições de tabela de rotas: a saída da sub-rede protegida em us-east-1a é apontada para o endpoint do firewall em us-east-1b, e a rota de retorno na sub-rede pública de us-east-1b é apontada para o endpoint do firewall em us-east-1a. Com isso, a saída de um fluxo passa por um endpoint enquanto o retorno chega ao outro — nenhum endpoint vê o fluxo completo e o handshake falha.

Diferente dos cenários anteriores, esse problema afeta toda a sub-rede e faz com que o Alarm-2 e o Alarm-3 disparem ao mesmo tempo. O Alarm-1 (baseado em DroppedPackets) permanece silencioso, pois nenhum endpoint toma uma decisão de descarte — o fluxo simplesmente se perde pelo roteamento assimétrico. Isso ilustra por que monitorar a conectividade da aplicação é fundamental: uma falha de roteamento é invisível para o contador de descartes do próprio firewall.

O DevOps Agent reconhece os dois alarmes como relacionados e os une em uma única investigação:

• Lê os logs de fluxo e observa as conexões TLS bidirecionais parando abruptamente, com apenas tráfego unidirecional restante e nenhum fluxo atingindo o estado estabelecido.
• Lê as métricas do firewall e percebe que os pacotes recebidos e passados mudam de uma AZ para a outra no momento da alteração.
• Chama DescribeRouteTables e encontra a rota de saída apontando para o endpoint do firewall em uma AZ enquanto a rota de retorno aponta para a outra.
• Busca no CloudTrail e identifica as chamadas ReplaceRoute e CreateRoute pelo mesmo usuário, cerca de um minuto antes dos dois alarmes.
• Reporta a causa raiz como a mudança de roteamento assimétrico e recomenda restaurar o roteamento simétrico na mesma AZ.

Atenção: o plano de mitigação é uma recomendação para você revisar, não uma mudança automática. A correção correta depende do design pretendido. O agente infere um destino plausível com base no que pode observar — revise a rota específica proposta em relação à sua topologia pretendida antes de aplicar.

Considerações adicionais

Em produção, uma única mudança pode disparar vários alarmes ao mesmo tempo, como o Cenário 3 demonstra. O DevOps Agent vincula investigações relacionadas e as trabalha como uma só, permitindo que você valide os achados ou desvincule um alarme para investigá-lo de forma independente. Também é possível adicionar lógica de correlação na função Lambda de ponte, agrupando alarmes por firewall antes que cheguem ao agente.

O agente pode trabalhar com mais contexto quando conectado a repositórios de código-fonte e pipelines de CI/CD, integrando-se com GitHub (incluindo GitHub Enterprise Server e GitLab Self-Managed via conexão privada). Ele pode associar recursos AWS a implantações de AWS CloudFormation, AWS CDK, imagens do Amazon Elastic Container Registry (Amazon ECR) e Terraform. Com configuração implantada e eventos recentes de deploy em mãos, o agente correlaciona a interrupção com a mudança que a introduziu e recomenda uma correção alinhada ao design pretendido.

O DevOps Agent também suporta prevenção proativa de incidentes: analisa padrões em investigações anteriores e entrega recomendações para evitar problemas similares, incluindo sugestões de governança que fortalecem processos de deploy e controles de pipeline. Para mudanças em regras do Network Firewall, isso significa que o agente pode recomendar guardrails para o pipeline de CI/CD com base nas classes de erros que já resolveu. Essas recomendações ficam acessíveis na página de Melhorias (Improvements) no Operator Web App do DevOps Agent.

O padrão descrito não é exclusivo do Network Firewall. O mesmo fluxo se aplica a qualquer serviço que emita métricas e logs no CloudWatch, como AWS WAF, security groups e listas de controle de acesso à rede (NACLs).

Limpeza do ambiente

Para remover todos os recursos implantados, basta executar:

bash scripts/destroy.sh

O script reverte qualquer cenário ativo, executa cdk destroy para todas as stacks e busca recursos remanescentes pela tag Project = nf-devops-agent. Os principais geradores de custo são os dois endpoints do Network Firewall, os gateways NAT e os load balancers do endpoint de teste — todos cobrados por hora enquanto provisionados, independentemente de haver tráfego. Executar os cenários e destruir a stack no mesmo dia limita o custo a poucas horas ativas.

Conclusão

A AWS demonstrou como o DevOps Agent acelera o troubleshooting de três problemas comuns de conectividade no Network Firewall: lista de negação de domínio, inversão de prioridade stateless e descarte por roteamento assimétrico entre AZs. Em cada caso, o agente investigou a queda e retornou uma causa raiz com um plano de mitigação para aprovação antes da aplicação.

O primeiro cenário disparou com base em uma métrica nativa do Network Firewall; os outros dois, com base em métricas de saúde da aplicação — mostrando as duas formas de alarmar sobre um problema de firewall pelo mesmo pipeline.

Para explorar a solução, clone o repositório de exemplo e aplique o que aprender ao seu próprio firewall, aplicação e alarmes. Para mais detalhes, consulte o Guia do Desenvolvedor do AWS Network Firewall e a página de preços do AWS Network Firewall. Para começar, acesse o guia de introdução ao AWS DevOps Agent para conectar seu primeiro webhook.

Fonte

Accelerating AWS Network Firewall troubleshooting with AWS DevOps Agent (https://aws.amazon.com/blogs/security/accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent/)

Amazon MWAA adiciona suporte ao Apache Airflow 2.11.2

A AWS anunciou que o Amazon MWAA — Fluxos de Trabalho Gerenciados para Apache Airflow (MWAA) — passou a oferecer suporte ao Apache Airflow versão 2.11.2. Para quem não conhece o serviço, o Amazon MWAA é uma solução gerenciada que executa o Apache Airflow em escala, eliminando a necessidade de gerenciar manualmente a infraestrutura subjacente.

O que muda com o Apache Airflow 2.11.2

O Apache Airflow 2.11.2 é uma versão de manutenção, ou seja, seu foco está em estabilidade, segurança e correções — e não em grandes funcionalidades novas. Ainda assim, as mudanças são relevantes para quem opera pipelines de dados em produção. Confira o que foi atualizado:

• Dependências principais atualizadas com patches de segurança e melhorias de estabilidade nas camadas do servidor web e de execução de tarefas do Airflow.
• Correções no gerenciamento do ciclo de vida de tarefas para tarefas em estado de fila (queued tasks).
• Mascaramento aprimorado de segredos nos logs, reduzindo o risco de exposição acidental de informações sensíveis.
• Correções na interface do usuário na visualização de lista de Instâncias de Tarefas (Task Instances list view).
• Atualizações nos pacotes de provedores para entrega de logs via S3 e CloudWatch.

Como migrar ou criar um novo ambiente

A AWS facilita a adoção da nova versão: é possível tanto criar um novo ambiente com o Apache Airflow 2.11.2 quanto atualizar ambientes existentes, tudo com poucos cliques diretamente no Console de Gerenciamento da AWS. A atualização está disponível em todas as regiões onde o Amazon MWAA já está disponível.

Para saber mais, a AWS disponibiliza os seguintes recursos:

• Documentação oficial do Amazon MWAA
• Notas de versão do Apache Airflow 2.11.2
• Lista de versões disponíveis do Airflow no MWAA

Fonte

Amazon MWAA now supports Apache Airflow version 2.11.2 (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-mwaa-now-supports-apache-airflow-version-2-11-2)

O que mudou no AWS Entity Resolution

A AWS anunciou uma expansão importante no AWS Entity Resolution: os fluxos de correspondência avançada (advanced matching workflows) agora são compatíveis com processamento em tempo real. Isso significa que é possível comparar e identificar registros em milissegundos usando regras complexas, diretamente pela API GenerateMatchId.

Qual era a limitação anterior

Até então, o processamento em tempo real do serviço suportava apenas fluxos de regras simples. Já os conjuntos de regras avançadas — que permitem combinar operadores como Exact e ExactManyToMany com lógica AND/OR — estavam disponíveis somente para processamento em lote (batch), o que podia levar de minutos a horas para retornar resultados.

Essa lacuna era um problema real para quem precisava de resolução de entidades sofisticada com resposta imediata. As equipes acabavam tendo que manter infraestruturas de correspondência separadas ou reformular suas aplicações para contornar essa restrição.

O que o novo suporte resolve na prática

Com essa atualização, quem trabalha com detecção de fraude, consulta de contas em tempo real ou personalização de sites pode definir regras de correspondência avançadas e obter resultados instantâneos — sem precisar manter infraestrutura separada ou refatorar aplicações existentes.

Como habilitar a correspondência avançada em tempo real

A ativação é direta e não exige novos endpoints nem migração. O processo envolve dois passos:

• Definir o parâmetro enableRealTimeMatching como true no fluxo de correspondência configurado;
• Chamar a API GenerateMatchId normalmente, como já era feito antes.

Ou seja, quem já usa o serviço não precisa aprender novos endpoints nem alterar a arquitetura da aplicação — basta ajustar o parâmetro e a funcionalidade já entra em operação.

Disponibilidade

A correspondência avançada em tempo real está disponível em todas as regiões da AWS onde o AWS Entity Resolution já opera.

Para começar a usar, a AWS disponibiliza o guia Como usar o GenerateMatchId no AWS Entity Resolution User Guide. Informações gerais sobre o serviço podem ser encontradas na página oficial do produto.

Fonte

AWS Entity Resolution now supports advanced real-time matching (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-entity-resolution/)

O que mudou

A AWS anunciou que o Lambda Durable Functions agora oferece suporte à criptografia dos dados de execução durável utilizando uma chave gerenciada pelo cliente por meio do Serviço de Gerenciamento de Chaves (KMS) da AWS. Até então, o serviço já criptografava os dados em repouso por padrão, mas utilizando uma chave de propriedade da própria AWS — sem que o cliente tivesse controle sobre ela.

Como funciona o Lambda Durable Functions

Para quem ainda não conhece o recurso: o Lambda Durable Functions permite construir fluxos de trabalho de longa duração e confiáveis diretamente no código de uma função Lambda, com gerenciamento automático de estado. Em vez de orquestrar serviços externos para manter o contexto de uma execução, o próprio Lambda cuida disso — o que simplifica bastante a arquitetura de aplicações que precisam de processos longos e resilientes.

O que muda com o suporte a chaves gerenciadas pelo cliente

Com essa novidade, é possível configurar uma Chave Gerenciada pelo Cliente (CMK — Customer Managed Key) especificamente para os dados de execução durável. Isso traz um nível adicional de controle: você decide qual chave usar, quando rotacioná-la e quem pode acessar o histórico e o estado das execuções.

Um ponto importante destacado pela AWS: a chave de execução durável opera de forma independente da chave configurada no nível da função — aquela que protege variáveis de ambiente e snapshots do SnapStart. Ou seja, é possível gerenciar o acesso aos dados de execução separadamente das configurações da função, o que oferece uma granularidade maior de controle de acesso.

Por que isso importa para setores regulados

Organizações que atuam em setores como serviços financeiros ou saúde frequentemente precisam atender a políticas de governança de dados que exigem o uso de chaves de criptografia de propriedade do próprio cliente. Com essa atualização, o Lambda Durable Functions passa a se adequar a esses requisitos de conformidade, tornando o recurso viável para um conjunto mais amplo de casos de uso corporativos e regulados.

Disponibilidade e custos

O recurso já está disponível em todas as regiões da AWS onde o Lambda Durable Functions está presente. Do ponto de vista de custos, as cobranças padrão do AWS KMS se aplicam para chaves gerenciadas pelo cliente — não há cobranças adicionais do Lambda pelo uso dessa funcionalidade.

Para saber mais sobre como configurar a criptografia, a AWS disponibilizou documentação específica no Guia do Desenvolvedor: Criptografando dados de execução durável do Lambda.

Fonte

AWS Lambda durable functions now supports customer managed key encryption (https://aws.amazon.com/about-aws/whats-new/2026/07/durablefunctions-cmk/)

O problema com labels estáticas no AWS WAF

O AWS WAF classifica o tráfego web anexando metadados a cada requisição avaliada. Grupos de regras gerenciadas como o AWS WAF Bot Control e o AWS WAF Fraud Control de prevenção de tomada de conta (ATP) aplicam labels que descrevem o que foi detectado — se uma requisição veio de uma categoria conhecida de bot, por exemplo, ou se ela corresponde a um padrão de credential stuffing.

Esses metadados podem ser encaminhados à sua origem como headers de requisição, dando ao backend visibilidade sobre as decisões tomadas pelo WAF na borda. Também é possível construir políticas em camadas: um sinal de bot de baixa confiança pode disparar um desafio CAPTCHA, enquanto um sinal de alta confiança bloqueia a requisição diretamente.

Com o AWS WAF AI Activity Dashboard, lançado em 24 de fevereiro de 2026, o Bot Control passou a identificar mais de 650 bots e agentes — incluindo crawlers de motores de busca, coletores de dados, assistentes de IA e crawlers de treinamento de modelos de linguagem de grande porte (LLM) — e esse número continua crescendo.

Em um post anterior, a AWS mostrou como agrupar labels do Bot Control em níveis de confiança para criar experiências adaptativas. Essa abordagem funciona bem quando você consegue listar as labels que importam. Mas quando o catálogo cresce além do que é razoável enumerar, escrever uma regra por label vira um fardo de manutenção e consome capacidade de regras que poderia ser usada em outro lugar.

É exatamente esse problema que a interpolação dinâmica de labels resolve.

Como funciona a interpolação dinâmica

Com a interpolação dinâmica, você referencia labels por namespace em vez de pelo nome individual. Uma única regra resolve para qualquer label que tenha correspondido durante a avaliação — sem necessidade de enumeração. A sintaxe usa uma cláusula ${namespace:} no valor de um header ou no corpo de uma resposta customizada, e o AWS WAF substitui os valores correspondentes em tempo de avaliação.

Onde pode ser usado

• Headers de requisição customizados: insere os valores resolvidos das labels em headers que o WAF encaminha à sua origem.
• Corpos de resposta customizados: embute valores de labels e labels sintéticas (como IP do cliente ou ID da requisição) em páginas de bloqueio, desafios e outras respostas customizadas.
• Headers de resposta customizados: insere valores de labels em headers de resposta, como o header Location para redirecionamentos.

Regras de resolução da sintaxe

O dois-pontos ao final do namespace é o sinal para o AWS WAF realizar a interpolação. O comportamento segue três regras:

• Correspondência única: a cláusula resolve para o valor terminal da label. Se a requisição carrega awswaf:managed:aws:bot-control:bot:category:scraping, então ${awswaf:managed:aws:bot-control:bot:category:} resolve para scraping.
• Múltiplas correspondências: o AWS WAF remove o prefixo do namespace e retorna os valores como lista separada por vírgulas, como scraping,advertising.
• Sem correspondência: a cláusula resolve para string vazia. Isso garante compatibilidade retroativa — qualquer valor sem a sintaxe ${...} passa inalterado.

Não há novos campos de API para configurar. A sintaxe é escrita diretamente nos valores de string existentes.

Labels sintéticas

Nem todo valor útil vem de uma correspondência de regra. Labels sintéticas são derivadas da própria requisição e interpoladas com a mesma sintaxe:

• ${awswaf:request_id:} — identificador único da requisição no AWS WAF
• ${awswaf:ip:} — endereço IP do cliente
• ${awswaf:ja3:} — fingerprint TLS JA3
• ${awswaf:ja4:} — fingerprint TLS JA4

É possível combinar labels sintéticas com labels baseadas em namespace em um único valor e passar tudo para a origem no formato que melhor atender à sua aplicação.

Cenários de uso práticos

1. Sinalização para a aplicação (Application Signaling)

O padrão de sinalização usa as labels e as encaminha à origem como headers de requisição customizados. Assim, sua aplicação recebe a classificação feita pelo WAF e decide como agir com base nela.

Enumerar cada label individualmente não escala. Só o nível de proteção comum do Bot Control rastreia mais de 650 bots e agentes auto-identificáveis. Mapear apenas o namespace bot:category para headers exigiria centenas de regras idênticas, cada uma com um valor diferente fixo no código.

Se você seguiu os passos do post How to use AWS WAF Bot Control for Targeted Bots signals and mitigate evasive bots with adaptive user experience, já mapeou labels para níveis de confiança dessa forma. Veja como era uma regra estática para uma única categoria:

{
  "name": "add-header-for-bot-category-advertising",
  "statement": {
    "label_match_statement": {
      "scope": "LABEL",
      "key": "awswaf:managed:aws:bot-control:bot:category:advertising"
    }
  },
  "rule_action": {
    "count": {
      "custom_request_handling": {
        "insert_headers": [
          {
            "name": "bot-category",
            "value": "advertising"
          }
        ]
      }
    }
  }
}

Com interpolação, isso colapsa em uma única regra. O escopo muda de LABEL para NAMESPACE, e o valor usa uma cláusula ${...} em vez de uma string fixa:

{
  "name": "forward-waf-signals",
  "statement": {
    "label_match_statement": {
      "scope": "NAMESPACE",
      "key": "awswaf:managed:aws:bot-control:bot:category:"
    }
  },
  "rule_action": {
    "count": {
      "custom_request_handling": {
        "insert_headers": [
          {
            "name": "x-waf-bot-category",
            "value": "${awswaf:managed:aws:bot-control:bot:category:}"
          },
          {
            "name": "x-waf-bot-name",
            "value": "${awswaf:managed:aws:bot-control:bot:name:}"
          },
          {
            "name": "x-waf-bot-signals",
            "value": "${awswaf:managed:aws:bot-control:signal:}"
          },
          {
            "name": "x-waf-fingerprint",
            "value": "${awswaf:managed:token:fingerprint:}"
          },
          {
            "name": "x-waf-token-id",
            "value": "${awswaf:managed:token:id:}"
          },
          {
            "name": "x-waf-client-ip",
            "value": "${awswaf:ip:}"
          }
        ]
      }
    }
  }
}

O header x-waf-bot-signals demonstra a resolução de múltiplos valores: o namespace signal: pode conter várias labels ao mesmo tempo, como non_browser_user_agent e automated_browser, que resolvem para uma lista separada por vírgulas. Os headers x-waf-fingerprint e x-waf-token-id carregam valores derivados de token únicos por dispositivo, que sua origem pode usar para correlação de sessão e detecção de fraude. E o x-waf-client-ip usa uma label sintética para passar o IP do cliente como o WAF o enxerga.

Com esses headers, sua aplicação pode tomar decisões que o WAF não consegue tomar sozinho: um cliente autenticado com sinal de bot pode receber uma página simplificada, enquanto uma sessão anônima com o mesmo sinal é bloqueada. Uma requisição com múltiplos sinais de bot durante uma promoção relâmpago pode ser colocada em fila em vez de rejeitada. Um balanceador de carga pode ler os headers e rotear tráfego de search_engine para um serviço de renderização otimizado para crawlers.

Esses headers também estão disponíveis para Amazon CloudFront Functions, permitindo lógica customizada antes mesmo de a requisição chegar à sua origem.

2. Páginas de bloqueio e desafio com informações de diagnóstico

Falsos positivos são um custo inevitável da mitigação de bots. O problema mais difícil geralmente é diagnosticá-los depois que ocorreram. Labels sintéticas ajudam nisso ao embutir o IP do cliente e o ID da requisição do AWS WAF no corpo de uma resposta customizada:

{
  "CustomResponseBodies": {
    "BlockPage": {
      "Content": "Your request was blocked.\n\nIP: ${awswaf:ip:}\nRequestID: ${awswaf:request_id:}\n\nIfyou believe this is an error, contact support with the Request ID above.",
      "ContentType": "TEXT_PLAIN"
    }
  }
}

Isso agiliza o fluxo de suporte: um usuário bloqueado que reporta o problema pode fornecer o ID da requisição exibido na página. Você busca esse ID nos logs do AWS WAF, analisa as regras e labels que corresponderam, e decide se foi um falso positivo — sem precisar pedir ao usuário que reproduza o problema ou tentar adivinhar quando aconteceu.

3. Redirecionamentos de verificação com contexto embutido

Às vezes a resposta certa não é um bloqueio, mas um desvio — enviar tráfego suspeito para uma página de verificação antes de deixá-lo continuar. É possível construir isso no AWS WAF interpolando o IP do cliente e o ID da requisição no destino do redirecionamento:

{
  "Action": {
    "Block": {
      "CustomResponse": {
        "ResponseCode": 302,
        "ResponseHeaders": [
          {
            "Name": "Location",
            "Value": "/verify?ip=${awswaf:ip:}&rid=${awswaf:request_id:}"
          }
        ]
      }
    }
  }
}

O header Location resolve para algo como /verify?ip=203.0.113.42&rid=a1b2c3d4-.... O endpoint de verificação pode usar o IP para uma verificação de geo ou rate-limit, e o ID da requisição para alinhar a visita com os logs do WAF. Como o redirecionamento é construído no próprio AWS WAF, esse comportamento é obtido sem alterar a aplicação de origem.

4. Segmentação de cache do CloudFront com labels do WAF

Quando o AWS WAF é usado na frente do Amazon CloudFront, um header inserido por uma regra fica disponível para o CloudFront ao calcular a chave de cache. Isso significa que é possível segmentar o cache por classificação de bot.

Usando o header x-waf-bot-category da regra de encaminhamento, você instrui o CloudFront a incluir esse header na chave de cache e manter uma resposta em cache separada por categoria. Na prática: uma requisição de search_engine recebe uma versão pré-renderizada e cacheada na borda, otimizada para crawling. Uma requisição sem label de bot recebe a página dinâmica completa. Uma requisição de scraping recebe uma resposta mínima, também do cache. Crawlers recebem conteúdo indexável, scrapers param de consumir capacidade da origem, e visitantes humanos não percebem diferença alguma.

Também é possível aplicar a mesma abordagem na origem para controle mais fino de atualização: configure sua aplicação para ler o header de classificação e definir o Cache-Control adequadamente — no-store para tráfego humano sem label, e TTLs mais longos para respostas direcionadas a bots.

Um exemplo com labels customizadas

A interpolação não se limita a grupos de regras gerenciadas. Ela funciona com a maioria dos namespaces, incluindo labels de outras AWS Managed Rules (como prevenção de tomada de conta, prevenção de fraude na criação de conta e listas de reputação de IP), grupos de regras gerenciadas do AWS Marketplace, e também com labels customizadas definidas nas suas próprias regras.

Considere uma configuração que classifica requisições em tiers com base em um header de chave de API. A primeira regra identifica requisições cujo header x-api-key começa com pk_enterprise_ e aplica a label app:tier:enterprise:

{
  "name": "classify-tier",
  "priority": 100,
  "statement": {
    "byte_match_statement": {
      "search_string": "pk_enterprise_",
      "field_to_match": {
        "single_header": {
          "name": "x-api-key"
        }
      },
      "positional_constraint": "STARTS_WITH",
      "text_transformations": [
        {
          "priority": 0,
          "type": "NONE"
        }
      ]
    }
  },
  "rule_labels": [
    {
      "name": "app:tier:enterprise"
    }
  ],
  "action": {
    "count": {}
  }
}

A segunda regra corresponde a labels no namespace app:tier e encaminha o valor resolvido, enterprise, no header x-customer-tier:

{
  "name": "forward-tier",
  "priority": 200,
  "statement": {
    "label_match_statement": {
      "scope": "NAMESPACE",
      "key": "app:tier:"
    }
  },
  "action": {
    "count": {
      "custom_request_handling": {
        "insert_headers": [
          {
            "name": "x-customer-tier",
            "value": "${awswaf::webacl::app:tier:}"
          }
        ]
      }
    }
  }
}

Vale notar: em rule_labels, você usa o nome curto da label (app:tier:enterprise), e o AWS WAF o prefixa com o contexto da web ACL para produzir a label totalmente qualificada. Em uma instrução de correspondência de label, o namespace curto é aceito — mas em uma referência de interpolação, é necessário usar o namespace totalmente qualificado com o contexto de conta e ACL.

O ganho aqui é que você pode adicionar app:tier:standard, app:tier:trial ou outros tiers depois, e a regra de encaminhamento os captura automaticamente, sem alterações.

Conclusão

A interpolação dinâmica de labels não muda como as labels funcionam — ela muda a quantidade de configuração de regras necessária para agir sobre elas. Um namespace que antes exigia uma regra por valor agora exige apenas uma regra total, e ela continua funcionando conforme o catálogo do Bot Control cresce além das 650 entradas atuais.

Junto a isso, o recurso entrega páginas de bloqueio com contexto específico por requisição, redirecionamentos que carregam seu próprio contexto, e segmentação de cache baseada em classificação. Nenhuma dessas capacidades é dramática isoladamente, mas combinadas permitem parear a classificação na borda com julgamento na sua aplicação.

O recurso se encaixa no AWS WAF da forma como você já o usa — sem quebrar nada, tornando a adoção uma questão de editar configurações de regras em vez de reconstruir qualquer coisa.

Para começar, consulte a documentação de labels do AWS WAF e o guia de configuração de requisições e respostas customizadas. Exemplos adicionais estão disponíveis no repositório AWS Samples, e discussões podem ser iniciadas no AWS re:Post.

Fonte

Do more with AWS WAF labels using dynamic label interpolation (https://aws.amazon.com/blogs/security/do-more-with-aws-waf-labels-using-dynamic-label-interpolation/)

O problema com o firmware original

Os dispositivos AWS DeepRacer são carrinhos autônomos em escala 1/18 movidos por modelos treinados com aprendizado por reforço. Combinados com um ambiente de nuvem para treino e avaliação de redes neurais, eles formam uma plataforma educacional bastante popular para quem quer dar os primeiros passos em aprendizado de máquina (ML).

O problema é que, desde o início, o firmware seguro embarcado nesses dispositivos só permitia inicializar sistemas operacionais assinados pela própria AWS — especificamente versões do Ubuntu 16.04 e 20.04. Ambas já estão fora do ciclo de suporte oficial, o que tornava difícil continuar experimentando e pesquisando com esses hardwares. Sem a possibilidade de atualizar o sistema operacional (SO), os dispositivos iam ficando para trás tecnologicamente.

Para resolver isso sem abandonar o hardware, a AWS desenvolveu e disponibilizou um novo bootloader para desenvolvedores, que permite instalar SOs customizados nesses carrinhos e, assim, prolongar sua vida útil.

A solução: o developer shim

O bootloader lançado pela AWS é baseado no projeto open source shim. Chamado de developer shim, ele oferece acesso de autoatendimento para desenvolvedores que queiram instalar distribuições customizadas ou de terceiros nos dispositivos DeepRacer.

O público-alvo são desenvolvedores familiarizados com processos de boot Linux e gerenciamento de certificados — especialmente membros da comunidade que queiram criar e distribuir suas próprias imagens de instalação para o DeepRacer.

Com esse bootloader, passa a ser possível:

• Instalar distribuições Linux modernas;
• Adicionar drivers de hardware personalizados;
• Executar stacks de software mais atuais;
• Construir projetos educacionais inovadores;
• Desenvolver protótipos de novos algoritmos veiculares.

E caso o desenvolvedor precise retornar à configuração original, o processo é completamente reversível. Basta seguir as instruções de atualização e restauração do veículo para voltar ao estado de fábrica.

Como o developer shim funciona

O funcionamento do bootloader se apoia em três elementos principais:

1. Gerenciamento de certificados por autoatendimento

Quando a verificação de assinatura embutida falha (porque o SO não é assinado pela AWS), o developer shim procura por certificados de desenvolvedor no caminho /EFI/DEVELOPER/certs/ na partição de boot do dispositivo. O desenvolvedor pode gerenciar seus próprios certificados usando ferramentas padrão como OpenSSL e sbsign, mantendo a verificação criptográfica adequada.

2. Avisos visuais claros

Quando certificados de desenvolvedor estão em uso, o sistema sinaliza isso de forma explícita:

• Aviso na tela (via HDMI): informa que o modo desenvolvedor está ativo;
• Indicação por hardware: as luzes do dispositivo piscam “DEVELOPER MODE” em código Morse;
• Atraso no boot: dá tempo suficiente para observar a ativação do modo desenvolvedor.

A ideia é garantir transparência total: sempre que o modo desenvolvedor estiver ativo, o dispositivo deixa isso bem claro.

3. Fluxo de verificação padrão

A solução utiliza ferramentas de assinatura baseadas em certificados já conhecidas do mercado, tornando-a acessível a quem já trabalha com processos de boot seguro. O desenvolvedor fornece seus próprios certificados enquanto mantém a integridade criptográfica da cadeia de boot e do sistema operacional.

Sequência de boot esperada

Ao ligar o dispositivo, o processo segue as seguintes etapas:

• O firmware carrega o developer shim (BOOTX64.EFI) e transfere a execução para ele;
• O shim exibe um aviso na tela (se um monitor HDMI estiver conectado) e pisca “DEVELOPER MODE” em Morse nas luzes do dispositivo — essa etapa leva aproximadamente 21 segundos;
• O bootloader carrega o kernel do sistema operacional;
• O shim verifica a assinatura do kernel contra o repositório de certificados local em /EFI/DEVELOPER/certs;
• Se a assinatura bater, a execução é transferida para o kernel e o boot continua normalmente.

Impacto na comunidade open source

A comunidade open source do AWS DeepRacer, em deepracing.io, já aproveitou o developer shim para criar uma nova distribuição customizada. Ela é construída sobre Ubuntu 24.04 com o stack ROS2 Jazzy e traz uma interface de usuário baseada em Cloudscape.

Pensada para ser uma demonstração prática da abordagem do bootloader de autoatendimento, a distribuição vem pronta para uso, com um processo de instalação muito similar ao da distribuição original da AWS. A comunidade priorizou desempenho nas corridas, removendo pacotes não essenciais — incluindo o sistema gráfico X Window System. Quem precisar da experiência de desktop pode adicioná-la posteriormente. As instruções de instalação estão disponíveis no README do repositório.

A distribuição pode ser encontrada em https://github.com/aws-deepracer-community/deepracer-custom-car.

Como usar o bootloader

O bootloader pode ser utilizado de três formas diferentes, dependendo do nível de controle desejado pelo desenvolvedor:

Opção A: Instalar uma distribuição da comunidade

A forma mais simples de começar é instalando a Distribuição da Comunidade Ubuntu 24.04. Essa opção dispensa a necessidade de instalar o Linux manualmente e reconfigurar os processos de boot do zero.

Opção B: Distribuições de terceiros

Para quem quer mais controle sobre o processo de instalação, é possível usar o developer shim com uma distribuição de terceiros, como o Ubuntu padrão. Após instalar o SO, basta substituir o arquivo BOOTX64.EFI pelo developer shim e adicionar os certificados adequados. Esse passo pode precisar ser feito duas vezes: uma na mídia de instalação e outra após a instalação no dispositivo. O arquivo USAGE.md incluso no pacote do developer shim contém as orientações detalhadas.

Opção C: SO completamente customizado

Para quem está construindo um SO do zero para o DeepRacer, o processo envolve criar um volume de boot no dispositivo, posicionar o developer shim em EFI/BOOT/BOOTX64.EFI, colocar o kernel ou bootloader do SO em EFI/BOOT/GRUBX64.EFI e instalar o certificado público em DEVELOPER/certs. O arquivo USAGE.md do pacote do developer shim também cobre esse cenário.

Integração com a solução self-managed

Com o developer shim e a solução de gerenciamento próprio lançada em 26 de janeiro de 2026, os desenvolvedores passam a ter controle total tanto sobre os ambientes de treinamento em nuvem quanto sobre os dispositivos físicos. É possível customizar o stack de software embarcado, experimentar novos pacotes ROS2 e iterar sobre modelos de corrida com flexibilidade completa de ponta a ponta. Mais detalhes sobre a solução self-managed estão disponíveis na página do DeepRacer on AWS.

Como começar

Para dar os primeiros passos, a AWS recomenda explorar primeiro a Solução DeepRacer on AWS e depois baixar o developer shim em deepracer-developer-shim.zip.

Para criar ou modificar a mídia de boot do novo SO customizado:

• Coloque o arquivo shim BOOTX64.EFI no diretório EFI/BOOT;
• Armazene o kernel do SO escolhido como GRUBX64.EFI;
• Armazene o certificado público do kernel em EFI/DEVELOPER/CERTS no formato x509 DER.

Esse processo pode precisar ser repetido tanto na mídia de instalação quanto no próprio dispositivo após a instalação. Para documentação técnica detalhada, solução de problemas e uso avançado, o arquivo USAGE.md dentro do zip é a referência principal.

Alternativamente, é possível baixar diretamente a Distribuição da Comunidade e seguir as instruções para uma instalação limpa com o developer bootloader já incorporado.

Conclusão

Com o novo bootloader, os dispositivos AWS DeepRacer ganham uma segunda vida como ambiente de educação e desenvolvimento em aprendizado de máquina. Agora é possível rodar sistemas operacionais modernos, ferramentas atualizadas e stacks de software contemporâneos — ou até criar sua própria distribuição customizada. Para começar, basta baixar o deepracer-developer-shim.zip, seguir as instruções no arquivo USAGE.md e continuar a jornada de ML com a Solução DeepRacer on AWS.

Fonte

Custom OS installation now available on AWS DeepRacer devices (https://aws.amazon.com/blogs/machine-learning/custom-os-installation-now-available-on-aws-deepracer-devices/)

AWS renova certificações ISO e CSA STAR com dois novos serviços no escopo

A Amazon Web Services (AWS) concluiu com êxito uma auditoria de integração — sem nenhuma não conformidade registrada — para renovar suas certificações ISO e CSA STAR referentes ao ciclo de 2026. Os certificados foram reemitidos em 31 de maio de 2026 pela auditora independente EY CertifyPoint.

Quais normas estão cobertas?

A auditoria contemplou um conjunto robusto de normas internacionais. Veja o que cada uma abrange:

• ISO 9001:2015 — Gestão da qualidade
• ISO 27001:2022 — Segurança da informação
• ISO 27017:2015 — Segurança em nuvem
• ISO 27018:2019 — Proteção de dados pessoais na nuvem
• ISO 27701:2019 — Gestão de privacidade da informação
• ISO 20000-1:2018 — Gestão de serviços de TI
• ISO 22301:2019 — Continuidade de negócios
• Aliança de Segurança em Nuvem (CSA) STAR Matriz de Controles de Nuvem (CCM) v4.0 — Framework de controles de segurança específico para ambientes de nuvem

Juntas, essas certificações demonstram o comprometimento da AWS em manter controles de segurança sólidos e proteger os dados dos clientes em seus serviços.

Os dois novos serviços adicionados ao escopo

Em relação à certificação anterior, emitida em 25 de fevereiro de 2026, dois novos serviços da AWS passaram a integrar o escopo das certificações ISO e CSA STAR:

• AWS Skill Builder — plataforma de treinamento e capacitação digital da AWS
• Amazon Nova Act — serviço de inteligência artificial da família Amazon Nova

A inclusão desses dois serviços significa que eles agora passam a ser auditados e monitorados sob os mesmos critérios rigorosos que já se aplicam aos demais serviços certificados da AWS.

Como verificar os serviços certificados e acessar os documentos

Para quem precisa validar quais serviços da AWS estão cobertos pelas certificações ISO e CSA STAR — seja para fins de conformidade, due diligence ou relatórios internos — a AWS disponibiliza duas formas de consulta:

• A página ISO e CSA STAR Certificados traz a lista completa e atualizada de serviços certificados.
• Os próprios certificados também podem ser acessados diretamente pelo AWS Artifact, dentro do Console de Gerenciamento da AWS — o que facilita o download e o compartilhamento com times de auditoria e conformidade.

Por que isso importa para você?

Para equipes de segurança, conformidade e arquitetura que utilizam serviços da AWS, cada expansão no escopo de certificação é um dado relevante. Significa que mais serviços passam a ter sua postura de segurança validada por auditores externos independentes, facilitando a vida de quem precisa demonstrar conformidade com normas internacionais para clientes, parceiros ou reguladores.

Fonte

2026 ISO and CSA STAR certificates are now available with two additional services (https://aws.amazon.com/blogs/security/2026-iso-and-csa-star-certificates-are-now-available-with-two-additional-services/)

Novo filtro de identidade para eventos de rede no CloudTrail

A AWS anunciou um aprimoramento importante no AWS CloudTrail: agora é possível filtrar eventos de atividade de rede com base na identidade do usuário Controle de Acesso e Identidade (IAM) que realizou a chamada de API. Essa novidade se aplica especificamente aos eventos de atividade de rede em endpoints de Nuvem Privada Virtual (VPC), um tipo de evento do CloudTrail que registra ações transmitidas por meio de um endpoint de VPC.

O que muda na prática

Antes dessa atualização, as equipes tinham controle limitado sobre quais eventos de atividade de rede eram registrados. Agora, com a filtragem por UserIdentity, é possível configurar seletores avançados para capturar apenas os eventos que realmente importam para o contexto de segurança da organização.

Um exemplo prático: é possível configurar o CloudTrail para registrar somente eventos de acesso negado quando a identidade que fez a chamada não está em uma lista de identidades confiáveis. Isso permite capturar tentativas de acesso não autorizado enquanto exclui o tráfego rotineiro de identidades já conhecidas — reduzindo tanto o custo de armazenamento quanto o volume de ruído nos logs.

Casos de uso em estratégias de perímetro de dados

Para equipes que trabalham com estratégias de perímetro de dados (data perimeter), esse recurso é especialmente valioso. É possível configurar seletores para registrar apenas eventos do tipo VpceAccessDenied originados de identidades fora de um conjunto confiável de perfis IAM. Isso viabiliza a detecção de possíveis tentativas de exfiltração de dados por meio de endpoints de VPC, sem o custo de registrar cada chamada de API bem-sucedida feita por usuários e perfis já aprovados.

Combinação com outros filtros existentes

A filtragem por UserIdentity pode ser combinada com campos já disponíveis nos seletores avançados, como eventName e vpcEndpointId. Essa combinação oferece controle granular sobre o que é registrado, permitindo cenários de monitoramento muito mais precisos e direcionados.

Disponibilidade e como usar

O recurso está disponível por meio do Console de Gerenciamento da AWS, da Interface de Linha de Comando (AWS CLI) e dos kits de desenvolvimento de software (SDKs) da AWS. A funcionalidade está ativa em todas as regiões da AWS onde os eventos de atividade de rede do CloudTrail já são suportados.

Para saber mais sobre eventos de atividade de rede, consulte o guia do usuário do AWS CloudTrail ou leia o post no blog da AWS sobre como habilitar eventos de atividade de rede.

Fonte

Selectively log network activity events by identity in AWS CloudTrail (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-cloudtrail-filter-useridentity-advance-selectors/)

O que é o agente de investigação do GuardDuty

A AWS anunciou a prévia pública do agente de investigação do Amazon GuardDuty, uma nova capacidade que usa inteligência artificial para investigar achados de segurança no ambiente Amazon Web Services (AWS) de forma automática e sob demanda. O objetivo declarado é reduzir o tempo de investigação de horas para minutos.

O GuardDuty já é o serviço gerenciado de detecção de ameaças da AWS, monitorando continuamente contas e workloads em busca de atividades suspeitas. O agente de investigação chega como uma camada adicional: em vez de deixar o analista correlacionar dados manualmente em múltiplas ferramentas, ele automatiza essa correlação e entrega inteligência acionável diretamente no serviço.

O acesso acontece via Console de Gerenciamento da AWS, Interface de Linha de Comando (AWS CLI), APIs ou SDKs da AWS.

Principais capacidades

Cada investigação concluída retorna um conjunto estruturado de informações:

• Nível de risco: Info, Baixo, Médio, Alto ou Crítico
• Confiança: Desconhecida, Baixa, Média ou Alta
• Resumo: narrativa das observações e achados principais
• Detalhes da investigação: contexto adicional sobre o incidente
• Ações recomendadas: passos priorizados de remediação, incluindo comandos AWS CLI
• Mapeamento MITRE ATT&CK®: técnicas de ataque e recursos AWS afetados

O escopo da investigação pode ser definido para um achado específico, uma conta individual ou todas as contas da organização. Via AWS CLI e API, é possível usar um campo de texto livre de até 2.048 caracteres para descrever em linguagem natural o que deve ser investigado — permitindo indicar áreas de preocupação, causas raiz suspeitas ou prioridades de análise.

As APIs do agente de investigação também estão disponíveis pelo servidor MCP da AWS, parte do Agent Toolkit for AWS, o que permite integrá-las em fluxos de trabalho com IA e nas cadeias de ferramentas de segurança já existentes.

Como o agente analisa os achados

Ao criar uma investigação, o agente usa inferência entre regiões (Cross-Region Inference) para processar os achados conforme o escopo definido. O serviço CRIS (Serviço de Inferência Entre Regiões) seleciona a região AWS mais adequada dentro da mesma geografia para processar a avaliação. Os dados permanecem armazenados apenas na região de origem da requisição, mas os dados e resultados da investigação podem ser processados fora dessa região. A transmissão ocorre de forma criptografada pela rede segura da Amazon. A tabela de roteamento de inferência pode ser consultada na seção de investigação do Guia do Usuário do Amazon GuardDuty.

Pré-requisitos e permissões de Gerenciamento de Identidade e Acesso (IAM)

Para usar o agente de investigação, é necessário ter o Amazon GuardDuty habilitado em uma conta em uma região suportada. Três novas permissões de IAM são exigidas:

• guardduty:CreateInvestigation — para iniciar novas investigações
• guardduty:GetInvestigation — para recuperar resultados
• guardduty:ListInvestigations — para listar investigações de um detector

Exemplo de política IAM:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "guardduty:CreateInvestigation",
        "guardduty:GetInvestigation",
        "guardduty:ListInvestigations"
      ],
      "Resource": "*"
    }
  ]
}

Modelo de autorização

Contas administradoras podem criar investigações, recuperar resultados e listar investigações para si mesmas e para suas contas membros. Contas membros só podem recuperar resultados e listar investigações da própria conta — não podem criar investigações nem acessar investigações de outras contas ou da conta administradora. A especificação do ID de conta só é necessária ao investigar uma conta membro específica.

Como habilitar e criar a primeira investigação

Com as permissões IAM configuradas, o processo pelo console segue os passos abaixo:

1. Acesse o Console de Gerenciamento da AWS na região suportada desejada e navegue até o Amazon GuardDuty.
2. No painel de navegação, selecione Investigations.
3. Se as investigações não estiverem habilitadas, acesse Go to Settings e ative a funcionalidade.
4. Após habilitar, volte à página de investigações e selecione Initiate Investigation.
5. Escolha o escopo: um Finding ID específico, um ID de conta AWS, ou todas as contas da organização.
6. Clique em Initiate investigation e aguarde a conclusão — tipicamente 2 a 5 minutos para nível de conta e 10 a 12 minutos para achados específicos durante a prévia.

Ao concluir, a investigação apresenta: informações gerais (ID, status, conta que disparou, timestamp), resumo narrativo, mapeamento de técnicas de ataque e recursos afetados, avaliação de ameaça com nível de risco e pontuação de confiança, e ações recomendadas priorizadas.

Executando investigações via AWS CLI

As investigações são assíncronas — o agente consulta múltiplas fontes de dados, correlaciona achados entre serviços e realiza análise com IA. Após criar uma investigação, é necessário verificar periodicamente o status até a conclusão.

Passo 1: Localizar o ID do detector

Cada implantação do GuardDuty tem um ID de detector único por conta e por região. Para encontrá-lo:

aws guardduty list-detectors --region=us-east-1

Resposta esperada:

{
  "DetectorIds": [
    "12abc34d567e8fa901bc2d34eexample"
  ]
}

Para evitar repetição ao trabalhar sempre na mesma região, é possível definir uma variável de ambiente (exemplo no Linux):

export AWS_DEFAULT_REGION=us-east-1

Passo 2: Criar uma investigação

Para investigar um achado específico:

aws guardduty create-investigation us-east-1 \
  --detector-id 12abc34d567e8fa901bc2d34eexample \
  --trigger-prompt "Investigate this finding ID 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6"

Para investigar todos os achados de uma conta:

aws guardduty create-investigation --region=us-east-1 \
  --detector-id 12abc34d567e8fa901bc2d34eexample \
  --trigger-prompt "Investigate findings in Account 123456789012"

Para investigar toda a organização:

aws guardduty create-investigation --region=us-east-1 \
  --detector-id 12abc34d567e8fa901bc2d34eexample \
  --trigger-prompt "Investigate findings across my AWS Organization"

A resposta retorna o ID da investigação:

{
  "InvestigationId":"a1b2c3d4-5678-90ab-cdef-ef1234567890"
}

Passo 3: Verificar o status da investigação

aws guardduty get-investigation --region=us-east-1 \
  --detector-id 12abc34d567e8fa901bc2d34eexample \
  --investigation-id a1b2c3d4-5678-90ab-cdef-ef1234567890 \
  --query 'Investigation.Status'

Repita o comando até o campo Status mostrar COMPLETED. Verificar a cada 30 segundos é suficiente. Os valores possíveis são: RUNNING, COMPLETED e FAILED. Em caso de falha, verifique a mensagem de erro e confirme se as permissões estão de acordo com o modelo de autorização.

Para listar todas as investigações de um detector:

aws guardduty list-investigations --region=us-east-1 \
  --detector-id 12abc34d567e8fa901bc2d34eexample \
  --max-results=10

Os endpoints de API disponíveis são: CreateInvestigation, GetInvestigation e ListInvestigations.

Integração em pipelines de segurança existentes

O design orientado a API do agente de investigação resolve um padrão comum: equipes que já encaminham achados do GuardDuty para ferramentas de terceiros via Amazon EventBridge podem adicionar uma função AWS Lambda no pipeline. Essa função chama CreateInvestigation com o ID do achado, aguarda a conclusão e repassa os resultados enriquecidos — nível de risco, pontuação de confiança, mapeamento MITRE ATT&CK e ações recomendadas — para o Sistema de Informação e Gerenciamento de Eventos de Segurança (SIEM) junto ao achado original.

Com isso, achados críticos vão diretamente para a fila de resposta a incidentes, enquanto achados de baixo risco com alta confiança podem ser fechados automaticamente ou agrupados para revisão semanal. O analista passa de correlação manual de logs para validação de avaliações e ação em ameaças confirmadas.

O agente de investigação é especializado em achados do GuardDuty e é distinto de outros agentes da AWS, como o AWS Security Agent e o AWS DevOps Agent.

Integração com o servidor MCP da AWS

O Protocolo de Contexto de Modelo (MCP) é um padrão aberto que permite que assistentes de IA se conectem de forma segura a fontes de dados e ferramentas externas. Como o servidor MCP da AWS implementa esse padrão para serviços AWS, é possível invocar investigações do GuardDuty por linguagem natural em ferramentas como Kiro, Claude da Anthropic ou outros clientes compatíveis com MCP.

Exemplos de prompts em linguagem natural que o agente suporta:

• “Investigate the latest high-severity finding in my production account”
• “Create an investigation for finding ID abc123 in account 987654321098 and summarize what happened”
• “List investigations from the last 24 hours and flag those that need human review”

Relação com o AWS Security Incident Response

O agente de investigação do GuardDuty e o AWS Security Incident Response (AWS SIR) atuam em estágios diferentes do fluxo de segurança. O agente de investigação oferece avaliação sob demanda: quando a equipe precisa de contexto mais profundo sobre um achado específico, uma postura de segurança de conta ou da organização inteira. O resultado é uma avaliação estruturada com níveis de risco, pontuações de confiança, mapeamentos MITRE ATT&CK e recomendações acionáveis.

Já o AWS SIR é voltado para eventos de segurança ativos, onde há necessidade de automação com IA e expertise humana para coordenar contenção e recuperação. Quando um caso com suporte da AWS é criado via SIR, um agente de investigação SIR é ativado em paralelo com os engenheiros de resposta a incidentes da AWS.

As equipes de segurança podem usar as duas capacidades de forma complementar: usar o agente do GuardDuty para avaliar e priorizar achados, escalar problemas confirmados com evidências de suporte e criar ou atualizar um caso no AWS SIR quando for necessário envolvimento adicional da AWS.

Disponibilidade e preços

A prévia pública do agente de investigação do GuardDuty está disponível em 10 regiões AWS: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm) e Asia Pacific (Tokyo).

Durante a prévia pública, o agente de investigação está disponível sem custo adicional. O uso é limitado a 10 investigações por conta por dia, com limite cumulativo de 100 investigações por conta durante o período de prévia. Investigações com falha não contam para essas cotas.

Para saber mais

• Documentação do Agente de Investigação do Amazon GuardDuty
• Referência de permissões IAM para o GuardDuty
• Guia do Usuário do Amazon EventBridge
• Framework MITRE ATT&CK®
• AWS Security Incident Response

Fonte

Introducing the Amazon GuardDuty investigation agent: on-demand AI-powered threat assessment (https://aws.amazon.com/blogs/security/introducing-the-amazon-guardduty-investigation-agent-on-demand-ai-powered-threat-assessment/)

O que mudou no Amazon GameLift Streams

A AWS anunciou uma atualização importante no Amazon GameLift Streams: o serviço agora suporta a atribuição de funções do IAM (Gerenciamento de Identidade e Acesso) diretamente a sessões de streaming. Com isso, aplicações em execução dentro de uma sessão de streaming passam a acessar recursos da conta AWS — como buckets do Amazon S3 e tabelas do DynamoDB — de forma segura e sem a necessidade de gerenciar credenciais manualmente.

Como funciona na prática

A partir dessa atualização, é possível passar um parâmetro RoleArn ao iniciar uma sessão de streaming. A partir daí, a aplicação recebe automaticamente credenciais AWS de curta duração e com renovação automática, por meio da cadeia padrão de resolução de credenciais do SDK da AWS — sem necessidade de alterar nenhuma linha de código da aplicação.

O mecanismo utilizado é o mesmo provedor de credenciais em contêineres já consolidado e confiável que está por trás das funções de tarefa do Amazon ECS e do Pod Identity do Amazon EKS. Ou seja, a AWS está trazendo para o GameLift Streams um padrão de segurança já bem estabelecido em outros serviços gerenciados da plataforma.

Por que isso importa: o problema que existia antes

Antes dessa funcionalidade, equipes que precisavam que suas aplicações em streaming acessassem serviços da AWS enfrentavam um dilema operacional e de segurança: ou embutiam chaves de acesso de longa duração diretamente nos pacotes da aplicação, ou as passavam como variáveis de ambiente. Ambas as abordagens são problemáticas — aumentam a superfície de ataque e dificultam a rotação e o gerenciamento dessas credenciais.

Com o suporte a funções IAM, esse risco é eliminado. As credenciais são temporárias, renovadas automaticamente e gerenciadas pelo próprio GameLift Streams, sem intervenção manual.

Validação e configuração simplificada

Outro ponto relevante do anúncio é a experiência de diagnóstico: erros de configuração na função IAM são detectados e sinalizados no momento do início da sessão, com mensagens de erro claras — em vez de falhar silenciosamente durante a execução da aplicação. Isso reduz o tempo de depuração e facilita a identificação de problemas de permissão.

Para facilitar ainda mais a adoção, a AWS também disponibilizou a configuração de funções IAM diretamente no console do Amazon GameLift Streams, com um modelo de política de confiança pré-preenchido para simplificar o processo de criação da função.

Disponibilidade

O suporte a funções IAM em sessões de streaming está disponível em todas as regiões da AWS onde o Amazon GameLift Streams já está disponível.

Para saber mais sobre como configurar credenciais de sessão, a AWS disponibiliza documentação detalhada: Configuração de Credenciais de Sessão no Guia do Desenvolvedor do Amazon GameLift Streams.

Fonte

Amazon GameLift Streams now supports IAM role credentials for stream sessions (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-gamelift-streams-iam/)