A AWS anunciou que o Amazon Managed Grafana alcançou a autorização FedRAMP High nas regiões AWS GovCloud (US-East) e AWS GovCloud (US-West). Essa é uma conquista relevante para organizações que operam em ambientes com exigências rigorosas de conformidade e segurança, especialmente no contexto do setor público norte-americano.
O que é o FedRAMP e por que ele importa
O Programa Federal de Gerenciamento de Risco e Autorização (FedRAMP — Federal Risk and Authorization Management Program) é um programa do governo dos Estados Unidos que estabelece uma abordagem padronizada para avaliação de segurança, autorização e monitoramento contínuo de produtos e serviços em nuvem. Em termos práticos, ele funciona como um “selo de aprovação” que garante que determinado serviço de nuvem atende aos requisitos de segurança exigidos por agências federais americanas.
A classificação High é o nível mais elevado dentro do FedRAMP, destinado a sistemas que lidam com informações altamente sensíveis. Conquistar essa autorização significa que o Amazon Managed Grafana passou por um processo rigoroso de auditoria e pode ser utilizado por organizações com as exigências de conformidade mais criteriosas.
Quem se beneficia dessa novidade
Com a autorização FedRAMP High em vigor, os seguintes perfis de organização passam a poder utilizar o Amazon Managed Grafana dentro dos requisitos de conformidade exigidos:
Agências federais dos Estados Unidos
Organizações do setor público com obrigações regulatórias específicas
Empresas privadas que precisam atender a requisitos FedRAMP High em seus contratos ou operações
Todas essas organizações agora podem usar o serviço para visualizar, consultar e configurar alertas sobre métricas operacionais em seus ambientes AWS e híbridos, sem abrir mão das exigências de segurança e conformidade.
O que é o Amazon Managed Grafana
Para quem não conhece o serviço: o Amazon Managed Grafana é uma solução totalmente gerenciada baseada no popular projeto open-source Grafana. Ele foi desenvolvido para facilitar a visualização e análise de dados operacionais em escala, eliminando a necessidade de instalar, configurar e manter a infraestrutura do Grafana manualmente. A AWS cuida de toda a gestão do serviço, enquanto os times de engenharia e operações focam no que realmente importa: os dados e os dashboards.
Como saber mais
Para quem deseja aprofundar o entendimento sobre o Amazon Managed Grafana no contexto do GovCloud, a AWS disponibiliza a documentação oficial do Amazon Managed Grafana para GovCloud. Também é possível acessar a página do produto para informações gerais sobre o serviço, ou entrar em contato diretamente com o time de conta AWS para orientações específicas.
A AWS anunciou uma atualização relevante para quem trabalha com migrações de sistemas de autenticação: o Amazon Cognito agora suporta a importação de usuários com hashes de senha diretamente em arquivos CSV. Essa novidade resolve um ponto de atrito bastante comum em projetos de migração de identidade.
Como era antes
Até então, quando uma equipe precisava importar uma base de usuários para o Amazon Cognito via arquivo CSV, os usuários chegavam sem senha válida no novo sistema. Isso significava que cada pessoa precisava redefinir sua senha no primeiro acesso — uma experiência ruim para o usuário final e um obstáculo operacional para as equipes responsáveis pela migração.
O que muda na prática
Com a nova funcionalidade, é possível incluir o hash da senha de cada usuário diretamente no arquivo CSV de importação. No momento de criação do processo de importação, a equipe especifica qual algoritmo de hash foi utilizado pelo sistema de origem. O Amazon Cognito então importa esses usuários e, no primeiro login, verifica a senha informada contra o hash importado — tudo de forma transparente para o usuário final.
O resultado prático é direto: os usuários migrados conseguem acessar o sistema imediatamente com as mesmas credenciais que já utilizavam, sem nenhuma interrupção no fluxo de autenticação.
Algoritmos de hash suportados
A AWS incluiu suporte aos principais algoritmos modernos de hash de senha utilizados pelo mercado:
bcrypt
scrypt
Argon2id
PBKDF2 com SHA-256
Vale destacar que todos os hashes importados recebem uma camada adicional de proteção criptográfica antes de serem armazenados no Cognito. Ou seja, a AWS não apenas aceita o hash existente — ela reforça a segurança desses dados na camada de armazenamento.
Disponibilidade e como começar
A funcionalidade de importação com hash de senha está disponível em todas as regiões da AWS onde o Amazon Cognito já está presente. Para utilizá-la, basta criar um processo de importação de usuários pelo Console de Gerenciamento da AWS, pela Interface de Linha de Comando (CLI) da AWS ou pelos Kits de Desenvolvimento de Software (SDKs) da AWS. Para instruções detalhadas, a AWS disponibiliza o guia do desenvolvedor com o passo a passo completo.
Por que isso importa
Migrações de base de usuários são momentos críticos em qualquer projeto. Forçar uma redefinição de senha em massa gera atrito, aumenta chamados de suporte e pode comprometer a adoção do novo sistema. Com essa atualização, o Amazon Cognito passa a oferecer uma rota de migração muito mais fluida — especialmente para equipes que estão consolidando sistemas legados ou migrando de provedores de identidade terceiros para a AWS.
O AWS Security Hub sempre foi posicionado como a base de operações de segurança para quem roda na AWS — um ponto central onde os sinais de risco são coletados, priorizados e transformados em ação. Agora, a AWS anunciou duas expansões significativas que ampliam esse papel de forma concreta: proteção dedicada a cargas de trabalho de Inteligência Artificial (IA) e monitoramento de segurança para ambientes Microsoft Azure.
Ambas as direções vieram de demandas reais dos clientes, e juntas representam um movimento claro da AWS em direção a uma plataforma de segurança full-stack — ou seja, que cobre toda a pilha de tecnologia de uma empresa, independentemente de onde ela roda.
Gerenciamento de segurança multicloud para o Microsoft Azure
Muitas organizações já operam em mais de uma nuvem há anos. O problema é que, até agora, o Security Hub era focado exclusivamente no ambiente AWS. Essa lacuna começa a ser fechada: o Security Hub passa a descobrir e monitorar recursos do Microsoft Azure, incluindo Máquinas Virtuais (VMs), imagens de contêiner, Function Apps e identidades.
A avaliação cobre problemas de configuração incorreta, exposição à internet e vulnerabilidades de software, com verificações de postura baseadas no CIS Microsoft Azure Foundations Benchmark™ — um padrão amplamente reconhecido do setor para boas práticas de segurança no Azure.
O que torna isso relevante do ponto de vista operacional é a integração: as descobertas do Azure são priorizadas lado a lado com as descobertas da AWS, usando o mesmo formato de alerta, as mesmas automações e os mesmos fluxos de resposta. O time de segurança passa a trabalhar com uma visão unificada de risco, sem precisar alternar entre ferramentas diferentes para cada ambiente.
Em termos de preço, os recursos do Azure são cobrados nas mesmas tarifas dos recursos equivalentes na AWS, sem taxas adicionais, e há um período de teste gratuito independente de 30 dias. Para mais detalhes, a AWS publicou um post no What’s New.
Vale destacar que essa não é a primeira iniciativa multicloud do Security Hub. Anteriormente, a AWS já havia lançado o Security Hub Extended, que integra soluções de parceiros especializados em nove categorias de segurança — cobrindo endpoints, identidades, e-mail, navegadores e dados em qualquer nuvem ou ambiente on-premises. O suporte nativo ao Azure complementa essa estratégia, ampliando o que as próprias capacidades da AWS conseguem cobrir.
Proteção para cargas de trabalho de IA
O outro grande movimento anunciado é a proteção dedicada a workloads de IA. Equipes de desenvolvimento estão colocando modelos em produção em ritmo acelerado — usando Amazon Bedrock, SageMaker e AgentCore — mas os times de segurança frequentemente não têm visibilidade sobre o que está rodando, quem está invocando modelos e quais agentes estão orquestrando fluxos de trabalho.
Um exemplo citado pela própria AWS ilustra bem o problema: um líder de segurança só descobriu que uma conta de serviço comprometida estava invocando um modelo de fundação milhares de vezes porque o time financeiro questionou a fatura. O incidente de segurança foi identificado por uma revisão contábil — não por uma ferramenta de segurança. Essa lacuna de visibilidade é real e já está gerando custos.
Para endereçar isso, a AWS anunciou três lançamentos relacionados à segurança de IA.
GuardDuty AI Protection (disponível para todos)
O Amazon GuardDuty AI Protection é uma capacidade de detecção de ameaças construída especificamente para Bedrock e SageMaker. Ele detecta invocações anômalas de modelos, ataques de “colheita de custos” — onde credenciais comprometidas são usadas para rodar inferências às custas da vítima — e tentativas de injeção de prompt, por meio da integração com o Bedrock Guardrails.
O mecanismo de detecção analisa dados de eventos do CloudTrail, aprende o padrão normal de invocação em escala e sinaliza desvios que indicam comprometimento ou abuso. A AWS destaca que esse tipo de detecção só é possível na escala da AWS, onde é possível observar o comportamento de milhões de workloads para definir o que é “normal”. O GuardDuty AI Protection está disponível para todos os clientes do GuardDuty com um período de teste gratuito de 30 dias.
Investigações com IA no GuardDuty (em prévia)
As investigações com IA do GuardDuty automatizam boa parte do trabalho manual de investigação que consome o tempo dos times de segurança e contribui para a fadiga de alertas. A capacidade analisa automaticamente as descobertas do GuardDuty e o contexto das contas envolvidas, separando ameaças reais de atividades benignas.
O processo examina o contexto de cada descoberta, atividades relacionadas dos últimos 90 dias, recursos afetados e indicadores de ameaça — usando grafos de conhecimento e inteligência de ameaças para concluir em minutos o que antes levava horas. Cada investigação retorna uma avaliação de disposição com pontuação de confiança, classificação pelo framework MITRE ATT&CK®, evidências de suporte e recomendações claras para suprimir, conter ou remediar o problema. A funcionalidade está disponível em prévia em 10 regiões da AWS.
Inventário de IA no Security Hub (disponível para todos)
O terceiro lançamento é o inventário de IA do Security Hub — uma visão continuamente atualizada de todos os ativos de IA da organização e sua postura de segurança.
O inventário descobre e cataloga cargas de trabalho de IA de duas formas: para serviços gerenciados, ele mapeia recursos do AWS Config no Bedrock, SageMaker e AgentCore; para workloads auto-hospedados e externos, ele identifica modelos rodando em EC2, ECS e EKS por meio de análise em tempo de execução, além de identificar endpoints de modelos externos que suas aplicações consomem.
Cada ativo é mapeado à infraestrutura subjacente — incluindo computação, rede, funções do IAM (Gerenciamento de Identidade e Acesso) e armazenamentos de dados — e correlacionado com sinais de segurança, como descobertas do GuardDuty. Quando o GuardDuty AI Protection sinaliza uma invocação anômala, o inventário de IA mostra imediatamente qual infraestrutura está envolvida, o que está conectado a ela e onde ela se encaixa na ordem de prioridades.
Esse recurso está disponível no plano Security Hub Essentials sem custo adicional.
Uma abordagem diferente para segurança full-stack
O que une todos esses lançamentos é uma filosofia de integração: não é necessário adquirir proteção de IA como um produto separado, nem montar operações isoladas para o Azure. Tudo é adicionado ao Security Hub que a equipe já opera, aparecendo na mesma visão priorizada de risco.
Nenhum desses parceiros está presente por padrão — cada um foi selecionado com base em critérios de qualidade e comprometimento com uma visão compartilhada de segurança empresarial. O benefício comercial do Extended já é tangível hoje: precificação pay-as-you-go, fatura única na AWS, elegibilidade para o EDP (Programa de Desconto Empresarial) e sem compromissos de longo prazo.
Mas o que a AWS descreve como o trabalho mais importante vai além da parte comercial. As descobertas de cada solução parceira são emitidas no formato OCSF (Framework Aberto de Esquema de Cibersegurança) e agregadas no Security Hub. A direção é construir uma correlação única entre todos eles, para que um sinal de uma solução de endpoint, uma de identidade e uma de nuvem se combinem em uma única exposição e um único caminho de ataque — em vez de três alertas desconectados. Para saber mais, a AWS publicou um post no What’s New sobre o Extended.
O que esperar a seguir
O panorama geral está ficando mais claro: o Security Hub está se expandindo em três direções simultaneamente. Primeiro, em cobertura de provedores de nuvem — começando pelo Azure, com outros clouds previstos. Segundo, em tipos de workload — com proteção e inventário específicos para IA. Terceiro, em categorias de segurança — por meio do Extended e seus parceiros curados.
O que começou como uma ferramenta para organizar descobertas de segurança na AWS está se tornando a forma como empresas cada vez maiores operam segurança em toda a sua infraestrutura. A base é detecção e visibilidade. O que a AWS está construindo em cima disso é uma experiência que conecta sinais de todas as fontes confiáveis e ajuda os times a responder mais rápido.
O problema de identificar bots legítimos em escala
À medida que agentes de Inteligência Artificial (IA) e ferramentas automatizadas passam a acessar aplicações web com mais frequência, distinguir tráfego legítimo de tentativas maliciosas tornou-se um dos desafios centrais de segurança na nuvem. As abordagens tradicionais — como filtros baseados em Protocolo de Internet (IP) e consultas reversas de Sistema de Nomes de Domínio (DNS) — simplesmente não funcionam bem em ambientes multi-tenant, como o Amazon Bedrock AgentCore, onde milhares de cargas de trabalho distintas compartilham o mesmo espaço de IPs.
Nesse cenário, atacantes conseguem facilmente falsificar cabeçalhos de agente de usuário, e listas de permissão manuais não acompanham o crescimento da demanda. Para endereçar esse problema, a AWS introduziu a Autenticação Web de Bots (WBA — Web Bot Authentication) no AWS WAF Bot Control em novembro de 2025.
Como funciona a Autenticação Web de Bots (WBA)
A WBA utiliza criptografia assimétrica para verificar identidades de bots por meio de assinaturas de mensagens HTTP. O mecanismo se apoia em dois rascunhos ativos da Força-Tarefa de Engenharia da Internet (IETF — Internet Engineering Task Force): um rascunho de diretório para compartilhamento de chaves públicas e um rascunho de protocolo que define como as chaves associam a identidade do crawler às requisições HTTP.
O fluxo de funcionamento é o seguinte:
Registro do bot: os operadores de bots publicam suas chaves públicas em um diretório de assinaturas. O AWS WAF consulta esses diretórios periodicamente e mantém um registro atualizado de chaves válidas.
Assinatura das requisições: cada requisição do operador de bot é assinada com sua chave privada, seguindo o padrão IETF de Assinaturas de Mensagens HTTP (RFC 9421).
Verificação: o AWS WAF valida as assinaturas contra as chaves públicas conhecidas associadas ao operador do bot e adiciona rótulos relacionados ao status de verificação.
Uma requisição típica assinada com WBA inclui cabeçalhos como os seguintes:
O fluxo representado no diagrama segue estas etapas: um bot envia uma requisição assinada ao Amazon CloudFront, que é inspecionada pelo AWS WAF Bot Control; o serviço recupera a chave pública do operador no diretório de assinaturas; verifica a assinatura ed25519; adiciona um rótulo de verificação (verified, invalid, expired ou unknown_bot); e, por fim, avalia as regras configuradas para permitir ou bloquear a requisição.
Novas capacidades adicionadas ao AWS WAF
Verificação criptográfica de bots
Quando um bot envia uma requisição, ela inclui assinaturas de mensagens HTTP que o AWS WAF valida na borda usando o grupo de regras do AWS WAF Bot Control (versão 4.0 ou superior). Essa validação adiciona latência mínima às requisições e oferece certeza criptográfica sobre a identidade do bot. O padrão RFC 9421 é aberto e definido pela IETF — na prática, significa que o bot assina criptograficamente cabeçalhos e metadados específicos de cada requisição, e o receptor pode verificar essa assinatura usando a chave pública publicada pelo bot.
Novos rótulos para controle granular
O AWS WAF valida automaticamente as assinaturas e marca o tráfego verificado com sucesso. Esses rótulos podem ser usados em regras do WAF e políticas de gerenciamento de bots. Veja o significado de cada rótulo e a ação sugerida:
awswaf:managed:aws:bot-control:bot:web_bot_auth:invalid — Tentativa de verificação falhou → Bloquear ou limitar taxa
awswaf:managed:aws:bot-control:bot:web_bot_auth:expired — Chave expirada utilizada → Bloquear e alertar
awswaf:managed:aws:bot-control:bot:web_bot_auth:unknown_bot — Chave não reconhecida → Monitorar ou bloquear
awswaf:managed:aws:bot-control:bot:vendor:<vendor_name> — Fornecedor ou operador do bot → Usar em regras por fornecedor
awswaf:managed:aws:bot-control:bot:name:<rfc_name> — Nome do bot (token RFC da WBA) → Usar em regras por bot específico
awswaf:managed:aws:bot-control:bot:account:<hash> — Identificador de conta AWS (somente agentes Amazon Bedrock AgentCore) → Usar para controles por conta
Permissão automática para tráfego verificado de agentes de IA
O AWS WAF Bot Control passou a respeitar o status de verificação da WBA por padrão, permitindo automaticamente o tráfego de agentes de IA verificados. Isso trouxe duas mudanças de comportamento específicas:
Atualização da regra Category:AI: anteriormente, essa regra bloqueava bots não verificados. Agora, o Bot Control verifica o status WBA antes de aplicá-la.
Atualização da regra TGT_TokenAbsent: essa regra, que detecta requisições sem token do WAF, não mais corresponde a requisições que carreguem o rótulo web_bot_auth:verified.
Benefícios para quem usa o AWS WAF
A WBA integrada ao AWS WAF traz vantagens concretas para organizações que gerenciam tráfego automatizado em escala:
Maior visibilidade de bots: identificação clara de bots distintos operando em plataformas multi-tenant como o Amazon Bedrock AgentCore. O console do AWS WAF inclui um novo painel de atividade de IA com uma visão centralizada do tráfego de bots e agentes de IA em todos os recursos protegidos.
Segurança aprimorada: verificação criptográfica de identidades de bots usando mecanismos de assinatura baseados em padrões da indústria.
Redução de falsos positivos: distinção precisa entre tráfego automatizado legítimo e malicioso, especialmente em ambientes de IP compartilhado.
Alinhamento com a indústria: compatibilidade com padrões amplamente adotados e com os principais provedores de Rede de Distribuição de Conteúdo (CDN — Content Delivery Network) para autenticação consistente de bots entre plataformas.
Casos de uso da WBA com AWS WAF
A WBA se aplica a diferentes cenários onde agentes automatizados precisam de acesso seguro e controlado a aplicações web:
Agentes de suporte ao cliente verificados: autenticação de bots de chat e suporte com IA, permitindo que os sites os reconheçam como agentes aprovados e registrados, com trilhas de auditoria completas.
Crawling e indexação automatizados: crawlers de mecanismos de busca e indexadores de conteúdo podem acessar páginas com identidade clara e permissões definidas, reduzindo bloqueios por falsos positivos.
Integrações com parceiros: agentes de terceiros acessam portais de clientes e Interfaces de Programação de Aplicações (APIs) com consentimento explícito e controles de acesso granulares, facilitando integrações seguras entre empresas (B2B — Business-to-Business).
Automações e agentes corporativos: ferramentas de automação internas — incluindo sistemas de monitoramento, bots de Garantia de Qualidade (QA), pipelines de Integração e Entrega Contínua (CI/CD) e soluções de Automação Robótica de Processos (RPA) — obtêm acesso autenticado a aplicações web com princípios de menor privilégio e auditabilidade completa.
Como começar: guia rápido para desenvolvedores
Passo 1: Implantar o Bot Control com suporte a WBA
Adicione o grupo de regras do AWS WAF Bot Control ao seu Web Controle de Acesso (ACL — Access Control List) associado ao CloudFront usando a versão estática Version_4.0 ou Version_5.0 — ambas incluem suporte à WBA para verificação criptográfica de bots. A versão 5.0 (lançada em fevereiro de 2026) cobre mais de 650 bots e agentes únicos em categorias como crawlers de mecanismos de busca com IA, coletores de dados com IA, assistentes de IA e crawlers de treinamento de Modelos de Linguagem de Grande Escala (LLM — Large Language Model).
Importante: você deve selecionar explicitamente uma dessas versões estáticas. O trecho de Linguagem de Marcação YAML do CloudFormation abaixo exemplifica a configuração:
# Bot Control rule group with WBA support
ManagedRuleGroupStatement:
VendorName: AWS
Name: AWSManagedRulesBotControlRuleSet
# Use Version_4.0 or higher for WBA support
Version: Version_5.0
ManagedRuleGroupConfigs:
- AWSManagedRulesBotControlRuleSet:
# COMMON level provides WBA verification
# TARGETED level adds additional bot-specific protections
InspectionLevel: COMMON
Passo 2: Assinar requisições do seu bot
Se o seu agente roda no Amazon Bedrock AgentCore Browser, a assinatura das requisições é feita automaticamente — nenhuma configuração adicional é necessária. Para agentes que rodam fora do AgentCore, há APIs de registro no roadmap que permitirão assinar requisições de forma independente:
Gerar um par de chaves ed25519
Hospedar sua chave pública em um diretório de assinaturas
Assinar as requisições HTTP de saída usando os cabeçalhos Signature-Input e Signature com a tag web-bot-auth
Analise os logs do AWS WAF para identificar padrões nas tentativas de autenticação de bots, filtrando pelos rótulos web_bot_auth.
Use o Painel de Atividade de IA no console do AWS WAF para uma visão centralizada do tráfego de bots de IA, identificar os bots mais ativos e os caminhos mais visados, e filtrar por status de verificação para decidir quais bots permitir, limitar ou bloquear.
Disponibilidade
A WBA foi introduzida na versão Version_4.0 do grupo de regras do Bot Control (novembro de 2025) para distribuições do Amazon CloudFront. A partir da Version_6.0, a WBA está disponível para todos os tipos de recursos suportados pelo AWS WAF nas regiões comerciais padrão da AWS.
Conclusão
A WBA integrada ao AWS WAF representa uma mudança significativa na forma como o tráfego automatizado é gerenciado: saindo de listas de permissão baseadas em IP para verificação baseada em assinaturas criptográficas. Isso garante identificação precisa de bots mesmo em ambientes multi-tenant. No roadmap da AWS estão APIs de registro que permitirão aos proprietários de agentes verificar criptograficamente a identidade e a intenção dos seus bots, ajudando os donos de sites a distinguir rapidamente automação confiável de tráfego desconhecido.
A AWS anunciou o Amazon GuardDuty AI Protection, uma expansão do serviço Amazon GuardDuty que estende a detecção de ameaças para cargas de trabalho de inteligência artificial — com suporte inicial ao Amazon Bedrock e ao Amazon SageMaker.
O movimento faz sentido: à medida que as organizações adotam IA em ritmo acelerado, as equipes de segurança frequentemente não têm visibilidade adequada sobre ameaças específicas a esses ambientes. O GuardDuty AI Protection chega para preencher exatamente essa lacuna.
Quais ameaças ele detecta
O serviço monitora continuamente as cargas de trabalho de IA e é capaz de identificar três categorias principais de atividade suspeita:
Padrões anômalos de invocação de modelos: comportamentos fora do normal no uso dos modelos de IA, que podem indicar acesso não autorizado ou uso indevido.
Ataques de consumo de recursos (cost harvesting): quando agentes maliciosos forçam os recursos de IA a consumir tempo excessivo de GPU e tokens, gerando custos elevados para a conta da vítima.
Tentativas de prompt injection: ataques que tentam manipular o comportamento dos modelos por meio de entradas maliciosas, detectados por meio da integração com o Amazon Bedrock Guardrails.
Para isso, o GuardDuty AI Protection analisa eventos de gerenciamento e de dados do CloudTrail provenientes dos serviços de IA da AWS, sem exigir configuração manual ou ferramentas personalizadas por parte da equipe de segurança.
Integração com o AWS Security Hub
Os alertas gerados pelo GuardDuty AI Protection fluem diretamente para o AWS Security Hub, centralizando a visão dos ativos e ameaças de IA em um único painel. Isso facilita a priorização e a resposta a incidentes, sem que as equipes precisem alternar entre consoles diferentes.
Como habilitar
A ativação do recurso pode ser feita em poucos passos diretamente no console do GuardDuty ou do Security Hub. Para organizações que utilizam o AWS Organizations, é possível habilitar o GuardDuty AI Protection de forma centralizada para todas as contas da organização de uma só vez.
Disponibilidade e preços
O GuardDuty AI Protection está disponível para clientes do Amazon GuardDuty com um período de teste gratuito de 30 dias. Para consultar os detalhes de precificação após o período de teste, acesse a página de preços do Amazon GuardDuty.
A cada mês, a AWS consolida as principais publicações de segurança num post de resumo — ideal para quem não consegue acompanhar tudo em tempo real. O digest de junho de 2026 cobre identidade e gerenciamento de acesso, inteligência de ameaças, segurança de rede, ferramentas de segurança com IA e governança multi-conta. A seguir, a CloudTroop traz os destaques organizados por tema.
Identidade e Controle de Acesso
Segurança de agentes de IA multi-tenant com Amazon Bedrock AgentCore
A AWS anunciou melhorias significativas no Cognito: alta performance de throughput, chaves gerenciadas pelo cliente para criptografia de dados em repouso e replicação multi-região para continuidade de negócios — tudo construído sobre uma nova infraestrutura de armazenamento migrada com zero downtime. O post Amazon Cognito libera capacidades avançadas com infraestrutura de nova geração detalha essas mudanças.
Visibilidade sobre ataques DDoS com flow logs no AWS Shield Advanced
O artigo Ganhando visibilidade sobre ataques DDoS com flow logs no AWS Shield Advanced explica como configurar os logs de fluxo de ataque do AWS Shield Advanced para capturar metadados de tráfego durante eventos de Ataque Distribuído de Negação de Serviço (DDoS), identificar origens, verificar mitigações e alimentar pipelines de análise existentes.
Subdomain takeover: como detectar e prevenir
O post Destaque de tática de ameaça: Subdomain takeover aborda uma das táticas mais subestimadas: a tomada de subdomínios abandonados. A publicação mostra como usar regras personalizadas do AWS Config para identificar registros CNAME de DNS “pendurados” que apontam para recursos deletados em namespaces globais compartilhados.
Prevenção de exfiltração de dados com controles de egresso
AWS Continuum: segurança na velocidade das máquinas
A AWS apresentou o AWS Continuum, uma plataforma nativa de IA para vulnerabilidades de código que cobre o ciclo completo — da descoberta e priorização até a validação e remediação — tudo em velocidade de máquina. O artigo Apresentando o AWS Continuum: segurança na velocidade das máquinas detalha como a plataforma funciona.
Investigações de segurança com Kiro CLI
O post Acelerando investigações de segurança com Kiro CLI mostra como usar o Kiro CLI para conduzir investigações seguindo o framework do Guia de Resposta a Incidentes de Segurança da AWS — desde a triagem de achados do Amazon GuardDuty até contenção e preservação de evidências.
Atualização do Catálogo de Técnicas de Ameaça de junho de 2026
A AWS publicou investigações sobre vulnerabilidades de segurança reportadas que afetam serviços, softwares e produtos Amazon e AWS. Abaixo, a lista dos boletins divulgados em junho:
Junho trouxe 10 novos repositórios de amostras cobrindo segurança de IA, identidade, segurança de infraestrutura, governança e observabilidade. Todos disponíveis para que você implante e valide no seu próprio ambiente antes de adotar em produção.
Gerenciamento de Postura de Segurança de IA (AI SPM) na AWS: descubra, avalie e proteja agentes de IA no seu ambiente usando serviços nativos AWS em três pilares: observar, governar e defender — com regras mapeadas para OWASP LLM Top 10, NIST AI RMF e MITRE ATLAS.
Bedrock Ops Lens: implante um dashboard de observabilidade do Amazon Bedrock na sua própria conta para atribuição de custos por conta, por modelo e por tag, rastreamento de cotas, monitoramento de latência e gerenciamento do ciclo de vida de modelos — com servidor MCP para acesso via IDE.
Aplicação de demonstração do AWS Agent Registry: use o AWS Agent Registry para publicar, revisar, aprovar e descobrir agentes de IA, servidores MCP e habilidades de agentes por meio de um catálogo centralizado com fluxos de trabalho de governança.
OpenAI Codex via Amazon Bedrock — Governança de uso com LiteLLM: governe, administre e monitore centralmente o acesso ao OpenAI Codex para equipes de engenharia usando o Amazon Bedrock como backend de inferência, com orçamentos por usuário, limites de taxa e trilhas de auditoria via LiteLLM.
Governança de Dados Agêntica — a escada de contexto: meça como camadas de contexto de governança — dicionários de dados, métricas semânticas e habilidades de execução — melhoram a precisão de agentes de dados por meio de uma escada de ablação de quatro níveis no benchmark BIRD.
Conclusão
Junho de 2026 foi um mês denso em conteúdo prático para segurança AWS em escala organizacional. Os destaques vão desde roteiros de maturidade e restrições de acesso ao console até registros de agentes de IA e plataformas de gerenciamento de postura. Os posts e amostras apresentam padrões para visibilidade sobre DDoS com flow logs, isolamento de agentes multi-tenant com políticas baseadas em recursos, controles de egresso para prevenção de exfiltração de dados e frameworks de governança para assistentes de codificação com IA. Cada recurso inclui passos de implantação ou código executável para que você possa validar no seu próprio ambiente antes de adotar.
Para receber as publicações assim que saírem, assine o feed RSS do AWS Security Blog e volte mensalmente para o digest consolidado.
A AWS anunciou que o AWS IAM Identity Center agora está dentro do escopo da certificação FedRAMP Classe C. O serviço passou a atender a esse requisito nas seguintes regiões dos Estados Unidos: US East (Ohio), US East (N. Virginia), US West (N. California) e US West (Oregon).
O que muda na prática
Com essa certificação, organizações que precisam estar em conformidade com o FedRAMP Classe C podem utilizar o IAM Identity Center para gerenciar o acesso da força de trabalho a contas AWS e aplicações sujeitas a esse nível de compliance. Ou seja, o serviço agora é uma opção válida também para ambientes com exigências regulatórias mais rigorosas dentro do contexto do governo americano.
Vale lembrar que o IAM Identity Center já é o serviço recomendado pela AWS para gerenciar o acesso de colaboradores a contas e aplicações AWS — e essa certificação reforça ainda mais seu uso em cenários regulados.
O que é o FedRAMP
O Programa Federal de Gerenciamento de Riscos e Autorizações (FedRAMP) é um programa do governo dos Estados Unidos que estabelece uma abordagem padronizada para avaliação de segurança, certificação e monitoramento contínuo de produtos e serviços em nuvem. Em outras palavras, é o mecanismo que o governo americano usa para garantir que soluções de nuvem atendam a critérios rigorosos de segurança antes de serem adotadas por agências federais.
O HITRUST i1 é a certificação mais amplamente exigida no setor de saúde. A avaliação cobre 182 controles selecionados no nível de implementação (Implemented) e aparece com frequência em contratos com fornecedores, Acordos de Parceiro de Negócios (BAAs) e exigências de planos de saúde, sistemas hospitalares e associados de negócios como condição para estabelecer parcerias.
Em outras palavras: para quem atua no ecossistema de saúde nos Estados Unidos — ou para empresas brasileiras que prestam serviços a clientes norte-americanos nesse setor — essa certificação pode ser um requisito contratual real.
O que o guia cobre
O material foi desenhado para preencher a lacuna entre entender o que o HITRUST i1 exige e saber como implementar esses requisitos na AWS. Ele conduz arquitetos de nuvem, engenheiros de segurança, responsáveis por conformidade e equipes de preparação para avaliação por todo o ciclo de um engajamento i1 — desde a definição do escopo da avaliação até a implementação de controles em cada domínio técnico.
Os 11 domínios de controle técnico abordados no guia são:
Controle de acesso
Proteção de endpoints
Gerenciamento de configuração
Gerenciamento de vulnerabilidades
Proteção de rede
Proteção de transmissão
Gerenciamento de incidentes
Proteção de dados e privacidade
Registro de auditoria e monitoramento
Gerenciamento de senhas
Continuidade de negócios e recuperação de desastres
Cenário ilustrativo com AWS Landing Zone Accelerator
Para tornar os conceitos mais concretos, o guia utiliza um cenário fictício — mas realista — de uma plataforma de saúde conectada implantada no AWS Landing Zone Accelerator. Vale reforçar: o cenário existe para fins didáticos e não sugere que a mesma arquitetura ou as mesmas escolhas de controle se aplicam universalmente. O escopo do HITRUST i1 é, por natureza, específico para cada organização.
O limite da avaliação, os controles aplicáveis e os requisitos de evidência são definidos pelo escopo de sistema de cada organização e gerenciados pelo portal HITRUST MyCSF. A recomendação é tratar o guia como ponto de partida e trabalhar com um Avaliador Externo Autorizado HITRUST para validar o que se aplica ao ambiente específico de cada empresa. O documento não constitui uma consultoria de certificação de conformidade.
A documentação de garantia HITRUST da AWS e a Matriz de Responsabilidade do Cliente estão disponíveis pelo AWS Artifact. Para suporte na preparação para avaliações, a AWS indica o AWS Security Assurance Services.
Quando um agente de IA generativa é colocado em produção em arquiteturas multi-tenant, surge um problema de identidade bastante específico: ao fazer uma chamada para uma API downstream em nome de um usuário, qual identidade viaja com essa chamada?
Existem três abordagens possíveis, mas apenas uma delas é segura. Executar a chamada com a identidade de serviço do próprio agente destrói a trilha de auditoria, pois cada sistema downstream precisa confiar incondicionalmente no agente. Encaminhar o token do usuário sem modificação só funciona quando a audiência do token já corresponde à API downstream — condição raramente verdadeira em sistemas multi-tenant. A terceira opção, a troca On-Behalf-Of (OBO), é a única que preserva a identidade do usuário de ponta a ponta, aplica o princípio do menor privilégio na fronteira de audiência e produz um token que a API downstream pode validar de forma independente.
O que é o padrão On-Behalf-Of e por que ele importa
Em uma troca OBO, o claim sub do token de entrada é preservado enquanto o claim aud é reescrito para o serviço downstream. O ator da troca fica registrado em um claim separado (act conforme a RFC 8693, ou cid no Okta), permitindo que a API downstream responda duas perguntas a partir de um único token: em nome de quem a ação está sendo executada? (claim sub) e quem está executando a ação? (claim do ator).
O AgentCore Gateway suporta esse padrão de forma transparente: ele intercepta a chamada de ferramenta, identifica o tenant de destino e instrui o AgentCore Identity a realizar a troca contra o servidor de autorização do tenant antes de emitir a chamada downstream. O código do agente não precisa implementar nenhuma lógica de troca — ele obtém um único token de entrada e invoca ferramentas normalmente.
A implementação de referência: TravelBot
O TravelBot é um assistente de reservas multi-tenant que atende dois tenants de exemplo, Acme e Globex. A implementação de referência estará disponível no repositório aws-samples/sample-obo-flow-poc após a publicação.
A arquitetura tem seis componentes principais:
Servidor de autorização provedor — Emite o Token Web JSON (JWT) de entrada que o agente apresenta ao Gateway. No TravelBot, é o servidor Okta chamado TravelBot Provider.
AgentCore Gateway — Valida o JWT de entrada, roteia a invocação de ferramenta para o tenant correto e orquestra a troca OBO.
AgentCore Identity — Armazena as credenciais do cliente delegado e executa a troca de token RFC 8693 contra o servidor de autorização do tenant.
Servidores de autorização por tenant — Emitem tokens OBO com escopo para a audiência de cada tenant. No TravelBot, ACME Travel API e Globex Travel API são dois servidores Okta distintos, cada um com sua própria audiência e política de acesso.
Superfície de API por tenant — Um Amazon API Gateway HTTP API com um autorizador JWT por tenant. Cada autorizador valida emissor, audiência e escopos obrigatórios.
Lógica de negócio do tenant — Uma função AWS Lambda que recebe o token OBO validado, lê os claims e armazena reservas no Amazon DynamoDB particionado pelo claim sub.
Fluxo de troca de tokens: três fases
O fluxo completo passa por três transformações de token. A tabela a seguir resume como cada claim JWT é transformado entre o token de entrada e o token OBO:
iss: reescrito do servidor provedor para o servidor do tenant
aud: reescrito de travelbot-provider para https://api.acme-travel.example
sub: preservado de ponta a ponta (alice@acme-travel.example)
cid: reescrito do cliente provedor para o cliente delegado (AgentCore Delegate)
scp: reescrito de [openid email gateway/invoke] para [booking/read booking/write]
authorized_scopes: novo claim calculado a partir da associação de grupo do usuário
Três claims carregam a história de segurança: o sub é preservado para que logs de auditoria e decisões de autorização resolvam para o chamador original; o aud é reescrito para a API do tenant, vinculando o token criptograficamente a um único serviço downstream; e o cid registra o delegado que realizou a troca, separando o ator do chamador.
Fase 1 — Token de entrada, emitido pelo servidor de autorização provedor
Um objetivo natural em sistemas multi-tenant é conceder escopos diferentes a cada usuário por papel. Por exemplo, um grupo acme-readonly recebe booking/read, e um grupo acme-fullaccess recebe ambos booking/read e booking/write. O problema é que a troca OBO é processada como uma concessão máquina-a-máquina (M2M): o Okta não mapeia o usuário sujeito de volta para seus grupos para fins de filtragem de escopos. O claim scp do token OBO retorna contendo todos os escopos que o cliente solicitou, independentemente do grupo do usuário.
A solução utiliza um claim em vez de um escopo. Embora o Okta não filtre scp por usuário durante a troca, ele avalia um claim do tipo Expression contra o usuário sujeito no momento da emissão. Adiciona-se um claim personalizado em cada servidor de autorização do tenant:
Nome: authorized_scopes
Tipo de token: Access Token
Tipo de valor: Expression
Valor (Acme): isMemberOfGroupName("acme-fullaccess") ? "booking/read booking/write" : (isMemberOfGroupName("acme-readonly") ? "booking/read" : "")
Incluir em: Qualquer escopo
O token OBO passa a carregar tanto um scp permissivo (informativo) quanto um claim authorized_scopes que reflete a permissão real do usuário. O servidor de recursos toma sua decisão com base em authorized_scopes.
A função Lambda trata authorized_scopes como fonte da verdade para operações de escrita:
# Requisições GET consultam o DynamoDB particionado por tenant + sub.
# Requisições POST exigem adicionalmente booking/write em authorized_scopes:
if method == "POST":
authorized = obo_claims.get("authorized_scopes") or []
if isinstance(authorized, str):
authorized = authorized.split()
if "booking/write" not in authorized:
return {
"statusCode": 403,
"headers": {"Content-Type": "application/json"},
"body": json.dumps({
"error": "forbidden",
"message": f"User {username} is not permitted to create bookings.",
}),
}
# ... proceed to write the booking
Isolamento de dados por tenant com o claim sub
A propagação de identidade só tem valor se os sistemas downstream agirem sobre ela. O TravelBot armazena reservas no DynamoDB particionado pela identidade do usuário: a chave de partição (pk) é "{tenant}#{sub}" — por exemplo, acme#alice@acme-travel.example — e a chave de ordenação é o ID da reserva. Em uma leitura, a Lambda emite uma Query com escopo para o pk do chamador. Em uma escrita, coloca um item sob o mesmo pk. O efeito é que um usuário não consegue recuperar as reservas de outro usuário — não por um filtro na camada de aplicação, mas porque a consulta é construída a partir do próprio claim sub do chamador, assinado pelo Okta e verificado pelo autorizador do API Gateway antes de a Lambda ser invocada.
Um token OBO emitido para um tenant não pode ser usado para acessar os recursos de outro tenant. No TravelBot, esse princípio é aplicado em três locais independentes: no target do Gateway (o valor customParameters.audience é definido por target); no servidor de autorização do tenant (o Okta valida se o parâmetro audience da requisição de troca está registrado no servidor antes de assinar o token OBO); e no autorizador JWT do API Gateway (cada rota está vinculada a um autorizador cuja JwtConfiguration.Audience é a audiência do tenant). Um token cujo claim aud não corresponde é rejeitado com HTTP 401 antes de a função Lambda ser invocada.
Após essas três operações, o código do agente não contém nenhuma lógica de troca de tokens. Ele adquire um token do provedor, abre uma sessão MCP contra o Gateway e invoca ferramentas. O Gateway e o Identity realizam a troca de forma transparente em cada chamada de ferramenta. A integração de um novo tenant requer apenas a criação de um provedor de credenciais e um target de Gateway — sem alterações no código do agente.
Armadilhas comuns na integração com Okta
A implementação do TravelBot revelou um conjunto de problemas que aparecem consistentemente em integrações OBO contra o Okta:
Filtragem de escopos por grupo é ignorada durante a troca de tokens. Como o Okta processa a concessão OBO como M2M, não mapeia o usuário do subject_token para seus grupos para filtragem de scp. Use um claim Expression (authorized_scopes) aplicado no servidor de recursos.
O DPoP (Demonstração de Prova de Posse) deve ser desabilitado. O DPoP vincula um token a uma chave privada que o cliente original possui. O AgentCore Identity é um relay de tokens e não possui essa chave, portanto deixar o DPoP obrigatório produz erros invalid_dpop_proof no momento da troca. Compense com tokens OBO de curta duração e TLS em todos os saltos.
O Okta usa o claim cid, não client_id. O mecanismo allowedClients do Gateway corresponde a client_id, que os tokens de acesso do Okta não carregam. Use allowedAudience.
O parâmetro subject_token_type deve ser access_token. Vários SDKs padronizam para jwt em trocas RFC 8693, e o Okta rejeita isso com invalid_request. Substitua o valor via customParameters no target do Gateway.
O servidor de autorização provedor deve ser registrado como emissor confiável em cada servidor de autorização do tenant. Isso é configurado em “Trusted Servers” no console de administração do Okta. Sem essa relação de confiança, mesmo uma requisição de troca corretamente construída falha.
O aplicativo delegado deve listar o grant type de troca de token em seus grant types permitidos. Tanto o controle no nível do aplicativo quanto a política de acesso do servidor de autorização são obrigatórios. A ausência de qualquer um produz um erro unauthorized_client.
Boas práticas para produção
Um provedor de credenciais e um cliente delegado por tenant — evite compartilhar provedores entre tenants.
Vincule audiências explicitamente — defina customParameters.audience em cada target do Gateway e JwtConfiguration.Audience em cada autorizador do API Gateway.
Emita tokens OBO de curta duração — configure os servidores de autorização dos tenants para emitir tokens OBO com o menor tempo de vida (TTL) que a aplicação tolere.
Trate o client secret do AgentCore Delegate como a credencial mais sensível do sistema — um secret vazado permite que um usuário não autorizado emita tokens OBO para qualquer valor de sub em todos os servidores de autorização de tenant aos quais o delegado está atribuído. Armazene o secret no AWS Secrets Manager com rotação habilitada.
Tome decisões de autorização com base em sub e claims por usuário, não no claim do ator — o chamador original é o principal; o delegado que realizou a troca é o ator.
Nunca emita claims de nomes ou tokens brutos nos logs de aplicação — registre sub, o ator (cid no Okta), aud e o jti do token. Nunca registre o valor bruto do cabeçalho Authorization.
O AgentCore Identity suporta conectividade pública e privada (VPC) para servidores de autorização de tenants. Consulte Conectar a provedores de identidade privados no guia do desenvolvedor do AgentCore para padrões de configuração.
Conclusão
A troca de tokens On-Behalf-Of é o padrão de identidade correto para agentes de IA multi-tenant, e o Amazon Bedrock AgentCore Gateway o operacionaliza sem exigir que o agente implemente a RFC 8693. Ao combinar os provedores de credenciais com audiência vinculada do Gateway com os autorizadores JWT por tenant do API Gateway, preserva-se a identidade do usuário de ponta a ponta, aplica-se o menor privilégio na fronteira de audiência e produz-se uma trilha de auditoria que distingue o delegado do usuário. O claim sub torna-se um principal confiável que os serviços downstream podem passar para uma camada de autorização refinada, como o Amazon Verified Permissions.
AWS reconhecida como fornecedor estratégico para o sistema financeiro britânico
A Amazon Web Services EMEA Sarl foi oficialmente designada como um Terceiro Crítico (CTP — Critical Third Party) para o setor financeiro do Reino Unido pelo HM Treasury, o Tesouro britânico. A designação marca um passo relevante na regulação de provedores de nuvem que sustentam infraestruturas financeiras de grande porte.
O que é o regime CTP?
O regime de Terceiros Críticos (CTP) entrou em vigor em 1º de janeiro de 2025. Ele cria um framework por meio do qual o Banco da Inglaterra, a PRA (Autoridade de Regulação Prudencial) e a FCA (Autoridade de Conduta Financeira) — coletivamente chamados de reguladores do Reino Unido — podem estabelecer requisitos e exercer supervisão direta sobre os fornecedores designados.
Trata-se de um regime orientado a resultados, ou seja, o foco está nos desfechos práticos de resiliência, e não apenas no cumprimento formal de regras.
Obrigações da AWS sob o regime
Com a designação, a AWS passa a estar sujeita a requisitos relacionados aos seus Serviços Sistêmicos de Terceiros (STPS — Systemic Third-Party Services). O primeiro passo previsto é uma autoavaliação desses serviços frente aos critérios do regime CTP, que a AWS deverá conduzir dentro dos prazos estabelecidos pelos reguladores.
A AWS já vinha participando ativamente das discussões com as autoridades britânicas durante o desenvolvimento do regime e sinalizou que manterá essa postura colaborativa ao longo do cumprimento de suas obrigações.
O que muda para os clientes?
Os reguladores do Reino Unido deixaram claro que o regime CTP não elimina, reduz nem substitui a responsabilidade das empresas, seus conselhos e gestores seniores pela resiliência operacional — inclusive quando dependem de serviços de terceiros. Em outras palavras, as obrigações dos clientes de serviços financeiros que utilizam a AWS permanecem as mesmas.
À medida que a AWS avança no cumprimento de suas obrigações, está prevista a publicação de materiais que os clientes poderão usar para embasar seus próprios planos de resiliência operacional e gestão de riscos de terceiros.
Compromisso com a resiliência operacional
A AWS reforça seu comprometimento em apoiar clientes do setor financeiro no fortalecimento da resiliência operacional, disponibilizando serviços e orientações — incluindo o AWS Well-Architected Framework e recursos voltados ao gerenciamento de incidentes em nuvem — para ajudar organizações a alcançarem resultados efetivos de resiliência.
A empresa conta com uma equipe de especialistas em regulação e tecnologia com foco em serviços financeiros, disponível para apoiar clientes com dúvidas sobre o regime CTP ou sobre resiliência operacional de forma mais ampla. Clientes interessados podem entrar em contato com o time de conta da AWS para obter mais informações.
