Category: Uncategorized

Nova capacidade de rastreamento de custos no Bedrock

A AWS expandiu as funcionalidades de gerenciamento de custos do Amazon Bedrock, adicionando suporte para alocação de despesas por principal IAM (Identificação e Acesso aos Recursos – IAM). Este recurso está disponível tanto no AWS Cost and Usage Report 2.0 (CUR 2.0) quanto no Cost Explorer, ferramentas nativas da plataforma para análise de gastos em nuvem.

A novidade permite que clientes entendam com precisão e atribuam os custos de inferência de modelos do Bedrock de forma granular, separando despesas por usuários específicos, equipes, projetos ou até aplicações individuais.

Como funciona a alocação por IAM

Etiquetagem de identidades

O fluxo é simples: primeiro, as organizações devem adicionar etiquetas (tags) aos seus usuários e funções IAM com informações contextuais como time, projeto ou centro de custos. Depois, é necessário ativar essas tags como marcadores de alocação de custos no console de Faturamento e Gerenciamento de Custos.

Análise e visualização

Após essa configuração, os usuários podem criar uma exportação de dados CUR 2.0 e selecionar a opção “Include caller identity (IAM principal) allocation data” para obter detalhes granulares. Alternativamente, é possível filtrar por etiquetas diretamente no Cost Explorer para visualizar graficamente os gastos segmentados por diferentes dimensões.

Escopo de disponibilidade

Este recurso está disponível em todas as regiões comerciais da AWS onde o Amazon Bedrock já funciona, facilitando a adoção para empresas que já utilizam o serviço de modelos de fundação da plataforma.

Próximos passos

Para começar, a AWS recomenda consultar a documentação técnica sobre alocação de custos por principal IAM e explorar a documentação do Amazon Bedrock para implementar essa funcionalidade em seu ambiente.

Fonte

Amazon Bedrock now supports cost allocation by IAM user and role (https://aws.amazon.com/about-aws/whats-new/2026/04/bedrock-iam-cost-allocation/)

Por Que a Coleta Forense Segura Importa

Quando organizações enfrentam um incidente de segurança, precisam coletar rapidamente artefatos forenses para identificar a causa raiz, extrair indicadores de comprometimento e validar os esforços de remediação. Esse processo é crítico, mas delicado — envolve comunicação com recursos potencialmente comprometidos e exige rigor absoluto nas práticas de segurança.

O guia NIST 800-86 define a perícia digital como um processo composto por quatro fases: coleta, exame, análise e relatório. A AWS apresentou recentemente um framework focado especificamente na primeira fase — coleta — demonstrando como implementar melhor privilégio durante todo o processo de coleta de evidências.

Arquitetura da Solução

O framework proposto pela AWS incorpora várias práticas recomendadas simultaneamente:

Menor Privilégio e Acesso Temporário

A arquitetura combina AWS Identity and Access Management (IAM) com AWS Security Token Service (AWS STS) para gerar credenciais de curta duração, altamente restritas. Cada tarefa de coleta forense recebe credenciais únicas que expiram automaticamente, reduzindo significativamente o risco de abuso enquanto as credenciais estão expostas no sistema sob investigação.

Compatibilidade com Ferramentas Existentes

Um diferencial importante é que o framework não exige alteração das ferramentas forenses de terceiros. Muitos softwares especializados já suportam upload para Amazon Simple Storage Service (Amazon S3) usando credenciais AWS, e essa solução aproveita essa compatibilidade nativa.

Distribuição Automática de Credenciais

Em vez de investigadores forenses utilizarem o console da AWS ou entenderem políticas IAM, credenciais com escopo apropriado são fornecidas automaticamente sob demanda, através de um processo orquestrado. Isso simplifica o fluxo de trabalho durante incidentes ativos.

Protegendo o Bucket de Artefatos

O S3 fornece a base sólida para armazenar artefatos forenses — com 11 noves de durabilidade e capacidade de armazenar objetos de um byte até 5 TB. Porém, é necessário configuração personalizada para proteger esses dados sensíveis.

A AWS recomenda habilitar:

• Criptografia em trânsito: Exigir TLS e versões mínimas aceitáveis através de políticas de bucket
• Criptografia em repouso: Usar chaves gerenciadas pelo cliente, não apenas chaves gerenciadas pela AWS, permitindo controle total sobre quem acessa as evidências
• Auditoria completa: Ativar eventos de dados do CloudTrail para rastrear toda atividade no nível de objeto, criando uma cadeia de custódia digital
• Controle de acesso fino: Definir exatamente quem (humanos ou máquinas) pode acessar artefatos, inclusive para descriptografia
• Proteção contra modificação: Usar versionamento de objeto, bloqueio de objeto ou exclusão com autenticação multifator

Organização Estruturada de Evidências

O framework sugere estruturar o bucket usando prefixos de objeto S3 para segregar cada tarefa de coleta. Por exemplo, um caso identificado como CASO-0001 teria seu próprio prefixo, e as políticas IAM poderiam restringir uploads apenas para esse prefixo específico. Isso impede acidentalmente — ou maliciosamente — sobrescrever evidências de outros casos.

Implementando Credenciais Temporárias com Menor Privilégio

O desafio técnico está em criar credenciais que expiram automaticamente e acessam apenas o necessário. A solução envolve três componentes IAM:

Papéis IAM Base

Um papel (ForensicsUploadRole) define o conjunto máximo de permissões — capacidade de fazer upload para o bucket e usar a chave AWS Key Management Service (AWS KMS) para criptografar. Esse papel não é usado diretamente, mas como referência máxima.

Relação de Confiança

Uma política de confiança permite que outros papéis de investigador forense assumam esse papel base, tornando possível a delegação segura.

Políticas de Sessão Dinâmicas

Ao chamar o AssumeRole da AWS STS, uma política de sessão é fornecida junto, restringindo ainda mais as permissões — por exemplo, permitindo upload apenas para o prefixo CASO-0001. As permissões efetivas são a interseção de todas as três políticas (papel base, política de recurso e política de sessão).

O resultado final é que as ferramentas forenses recebem credenciais que:

• Expiram após um tempo pré-definido (por padrão, 1 hora)
• Podem fazer upload apenas para um prefixo específico
• Não permitem leitura, listagem ou qualquer operação além de upload e gestão de uploads multi-parte
• Funcionam com ferramentas de terceiros sem modificação

Automatizando o Fluxo Completo

Para operações em escala, a AWS propõe uma arquitetura automatizada baseada em eventos:

Fluxo de Orquestração

Um alerta dispara o fluxo (manual ou automatizado). A solicitação é inserida em uma fila Amazon Simple Queue Service (Amazon SQS), que invoca uma função AWS Lambda, que por sua vez orquestra uma máquina de estado usando Step Functions.

Etapas de Execução

A máquina de estado determina:

• Se o sistema é gerenciado por AWS Systems Manager
• Qual sistema operacional (Windows ou Linux)
• Gera credenciais temporárias para baixar ferramentas forenses específicas do SO
• Executa as ferramentas no sistema via Systems Manager
• Gera novas credenciais temporárias para fazer upload dos resultados
• Remove artefatos temporários da máquina alvo

Monitoramento e Auditoria

Amazon EventBridge monitora o bucket de evidências e alerta via Amazon Simple Notification Service (Amazon SNS) se alguém não autorizado tentar acessar. Metadados de cada execução são registrados em Amazon DynamoDB para rastreabilidade completa.

Implementação Prática com AWS CDK

O exemplo fornecido usa AWS Cloud Development Kit (AWS CDK) para definir toda a infraestrutura como código, dividida em três stacks:

• SecurityStack: Orquestração base, Step Functions, Lambda, filas e papéis IAM
• AlertStack: Regras EventBridge para anomalias no bucket
• CustomerStack: Documentos Systems Manager implantados nas contas dos clientes

Variáveis de Configuração

Antes de implantar, é necessário personalizar:

• ID da conta de segurança
• IDs das contas-alvo
• Endereços de email para alertas
• Nomes de papéis autorizados a acessar o bucket

Processo de Implantação

O fluxo completo envolve:

• Configurar credenciais AWS via CLI
• Instalar dependências Node.js
• Bootstrap da infraestrutura CDK em cada conta
• Deploy dos stacks de segurança na conta de ferramentas
• Deploy do stack de cliente em contas de carga de trabalho
• Confirmação de inscrição SNS para alertas

Validação e Testes

A AWS propõe um teste end-to-end:

• Verificar que uma instância EC2 Linux está acessível ao Systems Manager
• Enviar uma mensagem manualmente para a fila SQS com ID de conta, ticket, região e instância
• Acompanhar a execução via console Step Functions
• Verificar metadados no DynamoDB
• Confirmar upload dos artefatos no bucket S3

Um teste crítico adicional: tentar usar as credenciais temporárias para fazer upload em outro prefixo ou aguardar a expiração do token — ambos os cenários devem retornar erro de acesso negado.

Benefícios Práticos para Organizações

Essa abordagem traz vários benefícios concretos:

• Reduz risco: Credenciais não circulam, expiram automaticamente
• Simplifica operações: Investigadores focam em análise, não em autenticação
• Mantém conformidade: Auditoria completa, criptografia, controle de acesso
• Escala: Automação reduz erros manuais durante incidentes ativos
• Integra ferramentas existentes: Sem necessidade de reescrever softwares especializados

Próximos Passos

A AWS fornece um repositório com código pronto para implementar essa arquitetura. Além disso, oferece recursos complementares como Automated Forensics Orchestrator para EC2 e guias sobre construção de módulos kernel forenses para instâncias Linux.

Para organizações que lidam com investigações forenses regulares, essa framework elimina guesswork e reduz significativamente o tempo de resposta em incidentes — dois fatores críticos para minimizar danos.

Fonte

A framework for securely collecting forensic artifacts into S3 buckets (https://aws.amazon.com/blogs/security/a-framework-for-securely-collecting-forensic-artifacts-into-s3-buckets/)

A Escala da Proteção: IA na Vanguarda da Segurança

Ao longo de décadas, a AWS desenvolveu processos e ferramentas sofisticadas para defender milhões de clientes simultaneamente, independentemente de onde operem no planeta. Por trás das cortinas, seus times de segurança e inteligência de ameaças realizam diariamente trabalhos com IA e automação que a maioria das pessoas nunca vê.

Os números revelam o alcance dessa operação: o sistema de análise de logs alimentado por IA da empresa conseguiu reduzir de seis horas para sete minutos o tempo que engenheiros de SecOps (Segurança de Operações) gastam analisando registros de segurança — um aumento de produtividade de 50 vezes que permite detectar e responder a ameaças com velocidade sem precedentes.

A plataforma analisa mais de 400 trilhões de fluxos de rede por dia para identificar padrões que sinalizam ameaças emergentes. Apenas em 2025, bloqueou mais de 300 milhões de tentativas de criptografar maliciosamente arquivos de clientes hospedados no Amazon S3. Nesse ecossistema, cada ameaça detectada para um cliente fortalece as defesas para todos os outros — e a IA já é central nesse funcionamento.

Uma Nova Classe de IA para Cibersegurança

A Anthropic anunciou recentemente o Project Glasswing, uma iniciativa de cibersegurança concebida para proteger a infraestrutura de software mais crítica do mundo e avançar nas práticas que o setor precisará à medida que a IA se torna mais capaz. Organizações que desenvolvem ou mantêm infraestrutura digital crítica estão recebendo acesso antecipado ao Claude Mythos Preview, uma nova classe de modelo de IA criada para identificar e corrigir vulnerabilidades nos sistemas dos quais o mundo depende.

Como instituição responsável por proteger algumas das infraestruturas mais essenciais do planeta, a AWS desempenha papel integral em avançar esse trabalho. A força propulsora por trás do projeto é o Claude Mythos Preview, o modelo de IA mais avançado da Anthropic até o momento — um salto qualitativo em capacidades de raciocínio e IA aplicadas à cibersegurança. Ele representa uma classe de modelo fundamentalmente nova: mais inteligente e capaz que os modelos anteriores da empresa, com desempenho superior em tarefas de cibersegurança, codificação de software e raciocínio complexo.

A AWS já aplicou o Claude Mythos Preview a bases de código críticas próprias que sofrem revisões de segurança contínuas alimentadas por IA. Mesmo em ambientes bem testados, o modelo identificou oportunidades adicionais para fortalecer o código. Em testes internos, o Claude Mythos Preview provou ser mais produtivo que modelos anteriores ao descobrir achados de segurança, requerendo menos orientação manual dos engenheiros para entregar resultados acionáveis.

A empresa também concedeu acesso antecipado a um grupo selecionado de clientes, que estão implantando o Claude Mythos Preview em seus próprios fluxos de trabalho de segurança e ajudando a moldar a evolução do modelo. Para a AWS, trata-se de uma extensão natural das ferramentas de IA que já utiliza — e conforme a tecnologia se torna mais poderosa, as defesas também devem evoluir.

A Parceria AWS e Anthropic

A AWS é o provedor de nuvem principal da Anthropic para cargas de trabalho críticas, pesquisa de segurança e desenvolvimento de modelos de fundação. Mais amplamente, a plataforma fornece a infraestrutura que as empresas de IA líderes mundiais usam para construir, treinar e implantar seus modelos mais avançados. A AWS traz duas décadas de experiência em segurança para essa parceria, ajudando a garantir que o Claude Mythos Preview esteja pronto para ainda mais organizações construírem e operarem com segurança em grande escala.

O Claude Mythos Preview sinaliza uma onda próxima de modelos capazes de encontrar vulnerabilidades e construir exploits funcionais numa escala e velocidade nunca vista antes. A Anthropic e a AWS adotam uma abordagem deliberadamente cautelosa no lançamento. O acesso começa com um pequeno número de organizações, priorizando empresas críticas para a internet e mantenedores de código aberto cujo software e serviços digitais impactam centenas de milhões de usuários. O objetivo: encontrar e corrigir vulnerabilidades no software mais crítico do mundo.

O Claude Mythos Preview está disponível em preview de pesquisa com portão através do Amazon Bedrock com controles de segurança de nível empresarial, incluindo criptografia gerenciada pelo cliente, isolamento de VPC (Nuvem Privada Virtual) e logging detalhado — permitindo que os times explorem as capacidades do Claude Mythos Preview sem expor ativos de produção a riscos desnecessários.

Arquitetura de Segurança: Princípios que Escalam

O trabalho com Project Glasswing está fundamentado em uma filosofia que a AWS desenvolveu ao longo de duas décadas protegendo cargas de trabalho críticas: não se pode esperar as ameaças se materializarem antes de construir defesas. É preciso antecipar, adotar novas tecnologias, construir proteções primeiro, implantá-las em operações próprias em grande escala e refiná-las com base no aprendizado obtido. É exatamente isso que a AWS fez com IA e segurança.

Sua abordagem abrange o espectro completo: defesa proativa por meio de busca de ameaças e pesquisa de vulnerabilidades, resposta dinâmica a campanhas ativas e certificações de terceiros que verificam se as práticas de segurança atendem aos padrões mais altos do setor. Essa experiência operacional ensinou onde a IA acelera o trabalho de segurança e onde o julgamento humano permanece essencial — reforçando que inovação em segurança deve ser pragmática: comprovada em produção antes de pedir que clientes dependam dela.

Padrões e Certificações

É por isso que a AWS também ajuda a definir como deve ser a IA segura. Tornou-se o primeiro grande provedor de nuvem a conquistar certificação ISO 42001 (Padrão Internacional de Gestão de IA) para serviços de IA. Participa ativamente da OWASP (Projeto Aberto de Segurança de Aplicações Web), da Coalition for Secure AI (Coligação pela IA Segura) e do Frontier Model Safety Framework (Marco de Segurança de Modelos de Fronteira). E co-fundou o Open Cybersecurity Schema Framework (OCSF — Marco de Schema Aberto de Cibersegurança) para possibilitar melhor compartilhamento de inteligência de ameaças em todo o ecossistema.

O AWS Nitro System oferece isolamento matemático para cargas de trabalho. Sua arquitetura de acesso zero de operadores significa que pessoal da AWS não pode acessar dados dos clientes. Estas não são aspirações — é como a empresa opera hoje, em escala, todos os dias. O Amazon Bedrock é onde esses princípios ganham vida prática para IA. Fornece controles de acesso aplicados por política, ferramentas de avaliação integradas para medir a eficácia com que modelos identificam e validam vulnerabilidades, além da capacidade de executar cargas de trabalho dentro da nuvem privada virtual do cliente.

A AWS também é o primeiro provedor de nuvem a conquistar autorizações FedRAMP (Programa Federal de Gestão de Risco e Autorização) High e Department of Defense Security Requirements Guide (Guia de Requisitos de Segurança do Departamento de Defesa) Impact Levels 4 e 5 para modelos de fundação Claude geralmente disponíveis — reforçando que o Amazon Bedrock é onde organizações mais sensíveis em segurança já confiam na tecnologia da Anthropic.

Ferramentas Práticas para Fortalecer a Postura de Segurança

Os mesmos princípios que orientam o trabalho em escala na AWS aplicam-se independentemente de quais ferramentas de IA se está utilizando: observabilidade abrangente, defesa em profundidade, automação onde agrega valor e julgamento humano onde é essencial.

Preparação para a Próxima Geração de Segurança de IA

O Claude Mythos Preview sinaliza uma onda próxima de modelos de IA que transformarão a cibersegurança. Organizações devem começar a fortalecer sua postura de segurança agora, preparando-se para quando essas capacidades se tornarem mais amplamente disponíveis. O Claude Mythos Preview está disponível em preview com portão através do Amazon Bedrock, e o acesso é limitado a um allow-list inicial de organizações. Se a organização foi colocada na allow-list, o time de conta da AWS entrará em contato diretamente.

Testes de Penetração sob Demanda com AWS Security Agent

O AWS Security Agent, agora geralmente disponível, oferece testes de penetração autônomos que operam 24/7 a uma fração do custo dos testes de penetração manuais. Transforma testes de penetração de um gargalo periódico em uma capacidade sob demanda que cresce com a velocidade de desenvolvimento em AWS, Azure, GCP (Google Cloud Platform), outros provedores de nuvem e ambiente local.

O AWS Security Agent representa uma nova classe de agentes de fronteira: sistemas autônomos que trabalham independentemente para atingir objetivos, escalam para lidar com tarefas simultâneas e rodam persistentemente sem supervisão humana constante. Implanta agentes de IA especializados para descobrir, validar e relatar vulnerabilidades de segurança através de cenários de ataque sofisticados e multi-etapas.

Diferentemente de scanners tradicionais que geram achados sem validação, o AWS Security Agent identifica vulnerabilidades potenciais e depois tenta explorá-las com payloads direcionados e cadeias de ataque para confirmar que são riscos de segurança legítimos. Cada achado inclui pontuações de risco CVSS (Sistema Comum de Avaliação de Vulnerabilidade), classificações de severidade específicas da aplicação, etapas de reprodução detalhadas e sugestões de remediação. O resultado: testes de penetração que antes levavam semanas agora se completam em horas, e cobertura de segurança que cresce por toda carteira de aplicações, não apenas sistemas mais críticos.

Clientes novos podem explorar o AWS Security Agent com um teste gratuito de dois meses.

Construir Aplicações de IA Confiáveis com Amazon Bedrock

Para times construindo com IA generativa, o desafio não é apenas fazer IA funcionar — é fazer IA funcionar com segurança. O Amazon Bedrock fornece os controles de segurança e proteção que se precisa para implantar IA responsavelmente. Sua capacidade de Raciocínio Automatizado é a primeira e única salvaguarda de IA a usar lógica formal para ajudar a prevenir erros factuais decorrentes de alucinações de IA, fornecendo explicações verificáveis com acurácia de 99% — capacidade refinada ao longo de mais de uma década aplicando métodos formais em armazenamento, identidade e rede da AWS.

O Amazon Bedrock também oferece guardrails personalizáveis que bloqueiam conteúdo prejudicial e aplicam políticas de conteúdo próprias, junto com observabilidade abrangente para rastrear comportamento de IA e detectar anomalias em cargas de trabalho.

A Urgência do Momento

O cenário de ameaças não está aguardando que a indústria se atualize. Atores de nível de estado-nação, operadores de ransomware (sequestro de dados) e atacantes de cadeia de suprimentos já estão usando IA para escalar suas operações. A tarefa de seguradores é manter a frente construindo defesas primeiro, implantando-as em escala e compartilhando o que se aprende para que toda comunidade se beneficie.

É o que a AWS faz todos os dias: prova que tecnologia funciona em suas próprias operações antes de pedir que clientes dependam dela, estabelece padrões em vez de segui-los, e antecipa os desafios de amanhã para abordá-los hoje. Conforme capacidades de IA continuam evoluindo, essa abordagem não mudará. A empresa seguirá construindo defesas primeiro, refinando-as em escala, e trabalhando com parceiros como a Anthropic para garantir que a próxima geração de ferramentas de segurança de IA atenda às necessidades reais de empresas defendendo nesta escala.

Recursos para Aprofundamento

• Comece com AWS Security Agent
• Explore Amazon Bedrock
• Conheça Guardrails de Segurança para IA
• Veja como a AWS está Securizando IA
• Saiba mais sobre IA Responsável da AWS
• Consulte Conformidade de IA da AWS
• Revise Boletins de Segurança da AWS sobre ameaças emergentes

Fonte

Building AI defenses at scale: Before the threats emerge (https://aws.amazon.com/blogs/security/building-ai-defenses-at-scale-before-the-threats-emerge/)

Novo modelo de IA para segurança em larga escala

A AWS expandiu o portfólio do Amazon Bedrock, sua plataforma para construir aplicações e agentes de IA generativa em escala de produção, com a inclusão do Claude Mythos Preview em acesso restrito. Anunciado em abril de 2026, este modelo representa uma colaboração estratégica entre Anthropic e AWS no contexto do Project Glasswing.

Capacidades técnicas avançadas

O Claude Mythos Preview é apresentado como o modelo de IA mais avançado da Anthropic até o momento, definido como uma classe fundamentalmente nova de modelo com capacidades de ponta em três áreas críticas: cibersegurança, desenvolvimento de software e tarefas de raciocínio complexo.

A proposta diferencial está na capacidade de identificar vulnerabilidades sofisticadas em software e demonstrar sua exploração. O modelo consegue compreender grandes bases de código e entregar descobertas viáveis com menos orientação manual em comparação com modelos anteriores de IA, representando um avanço significativo em automação de análise de segurança.

Implicações para equipes de segurança

Para equipes de defesa cibernética, o Claude Mythos Preview promete acelerar trabalhos defensivos, permitindo identificação e correção mais rápida de vulnerabilidades em software crítico. A capacidade de encontrar e remediação de problemas antes que ameaças materializem oferece uma abordagem proativa ao invés de reativa.

Estratégia cautelosa de lançamento

Anthropic e AWS adotaram uma abordagem deliberadamente conservadora para o lançamento. O acesso inicial foi priorizado para empresas críticas à internet e mantenedores de código aberto cujo software e serviços digitais impactam centenas de milhões de usuários. Esta estratégia oferece aos defensores oportunidade de fortalecer seus códigos e compartilhar aprendizados, permitindo que toda a indústria se beneficie.

Disponibilidade e acesso

O Claude Mythos Preview está disponível em acesso restrito na região US East (N. Virginia) através do Amazon Bedrock. O acesso é limitado a uma lista inicial permitida de organizações. Organizações selecionadas receberão contato direto da equipe de conta AWS para ativação.

Para compreender melhor as implicações desta anúncio para o futuro da cibersegurança, a AWS disponibiliza perspectivas adicionais em Building AI Defenses at Scale: Before the Threats Emerge.

Fonte

Amazon Bedrock now offers Claude Mythos Preview (Gated Research Preview) (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-bedrock-claude-mythos/)

Gerenciamento centralizado de acesso a servidores MCP

À medida que as organizações expandem suas implementações de agentes de IA, o número de servidores MCP (Model Context Protocol) que cada equipe utiliza cresce rapidamente. O Amazon Bedrock AgentCore Gateway oferece uma camada centralizada para gerenciar como os agentes de IA conectam-se a ferramentas e servidores MCP em toda a organização. Essa solução consolida autenticação, observabilidade e imposição de políticas em um único endpoint, eliminando a necessidade de configurar e proteger cada conexão de servidor MCP individualmente.

Em vez de configurar cada servidor MCP separadamente por IDE (ambiente de desenvolvimento), os times passam a apontar para uma única URL do Gateway, proporcionando acesso consistente ao conjunto completo de ferramentas MCP disponíveis. Esse padrão está acelerando conforme as organizações adotam servidores MCP de produção de terceiros, como os fornecidos pela AWS, GitHub, Salesforce e Databricks.

Desafios na autenticação em escala

Muitos servidores MCP empresariais exigem autenticação OAuth 2.0 (Protocolo de Autorização 2.0), onde o agente precisa autenticar-se em nome de um usuário antes de invocar ferramentas. Alguns desses servidores são protegidos pelo provedor de identidade principal através de federação, enquanto outros são protegidos por seus próprios servidores de autorização.

À medida que o número de servidores MCP por organização aumenta, gerenciar conexões, autenticação e roteamento no nível do IDE torna-se insustentável. O AgentCore Gateway centraliza essa complexidade, oferecendo um único plano de controle para acesso MCP enquanto proporciona aos desenvolvedores uma experiência sem atritos.

Suporte a fluxo de código de autorização

A AWS agora oferece suporte ao fluxo de código de autorização OAuth 2.0 através do Amazon Bedrock AgentCore Identity. Com isso, seus agentes podem acessar com segurança servidores MCP protegidos sem incorporar credenciais no código da aplicação ou gerenciar manualmente o ciclo de vida dos tokens.

A plataforma disponibiliza dois métodos para criar e gerenciar acesso a servidores MCP protegidos por OAuth:

Sincronização implícita durante a criação do alvo MCP

Neste método, o usuário administrador completa o fluxo de código de autorização durante operações CreateGatewayTarget, UpdateGatewayTarget ou SynchronizeGatewayTargets. Isso permite que o AgentCore Gateway descubra e cache as ferramentas do servidor MCP antecipadamente.

Fornecimento de esquema antecipado

Nesta abordagem, os usuários administradores fornecem o esquema das ferramentas diretamente durante operações CreateGatewayTarget ou UpdateGatewayTarget, em vez de o AgentCore Gateway buscá-los dinamicamente do servidor MCP. O gateway analisa o esquema fornecido e faz cache das definições de ferramentas.

Esta é a abordagem recomendada quando a intervenção humana não é possível durante operações de criação ou atualização. Além disso, oferece controle granular sobre quais ferramentas do servidor MCP serão expostas. É importante notar que, com este método, a operação SynchronizeGatewayTargets não é suportada.

Você pode alternar um alvo entre os dois métodos simplesmente atualizando a configuração do alvo, proporcionando flexibilidade conforme suas necessidades evoluem.

Vinculação de sessão por URL

Um componente crítico de segurança é a vinculação de sessão por URL, que verifica se o usuário que iniciou a solicitação de autorização OAuth é o mesmo que concedeu consentimento. Quando o AgentCore Identity gera uma URL de autorização, também retorna uma session-URI. Após o usuário concluir o consentimento, o navegador redireciona para uma URL de callback com a session-URI.

A aplicação é então responsável por chamar a API CompleteResourceTokenAuth, apresentando tanto a identidade do usuário quanto a session-URI. O AgentCore Identity valida que o usuário que iniciou o fluxo é o mesmo que o completou antes de trocar o código de autorização por um token de acesso. Isso ajuda a evitar cenários onde um usuário compartilha acidentalmente a URL de autorização e outra pessoa completa o consentimento, concedendo tokens de acesso para a parte errada.

Para segurança adicional, a URL de autorização e a session URI são válidas apenas por 10 minutos, limitando ainda mais a janela para uso indevido.

Conceitos principais

Usuário do AgentCore Gateway: O usuário final que consome as ferramentas no Amazon Bedrock AgentCore Gateway com clientes MCP. Esses usuários não gerenciam o próprio AgentCore Gateway — simplesmente usam a URL única do gateway para acessar as ferramentas disponíveis para eles.

Usuário administrador: O usuário que gerencia e mantém o Amazon Bedrock AgentCore Gateway. É responsável por conectar servidores MCP, ferramentas ou APIs ao gateway, permitindo que usuários do gateway as consumam.

Servidor MCP: Neste contexto, assume-se que o servidor MCP é protegido por um fluxo de código de autorização OAuth 2.0, que requer interação do usuário para completar a autenticação. Isso é diferente de métodos de autenticação máquina-para-máquina, como Client Credentials ou Token Exchange, que não requerem intervenção do usuário.

Implementação prática com GitHub

Para demonstrar a integração, a AWS fornece exemplos de código mostrando como conectar um servidor GitHub MCP ao Amazon Bedrock AgentCore Gateway. O processo envolve ambos os métodos — sincronização implícita durante a criação do alvo e fornecimento de esquema antecipado.

Configuração inicial com GitHub

Antes de começar, é necessário configurar uma aplicação OAuth no GitHub. Acesse https://github.com/settings/apps para criar uma nova aplicação GitHub, fornecendo detalhes como nome da aplicação, URL da homepage e URL de callback de autorização.

Nas configurações avançadas, recomenda-se desativar a expiração automática de tokens, desativar a autorização de usuário durante a instalação e desativar o Device Flow, seguindo as melhores práticas de segurança da sua organização.

Preparação do ambiente

Você precisará de permissões IAM (Gestão de Identidade e Acesso) apropriadas para executar o código. O repositório contém exemplos práticos — comece clonando o repositório GitHub e abrindo o arquivo github-mcp-server.ipynb.

Configuração do provedor de credenciais

Configure o provedor de credenciais do Agentcore Identity no console do Amazon Bedrock AgentCore. Crie um cliente OAuth, fornecendo um nome e selecionando o provedor GitHub pré-incluído. Insira o ID do cliente e o segredo da aplicação GitHub.

Copie a URL de callback do cliente OAuth do AgentCore Identity e retorne à aplicação OAuth do GitHub que criou para atualizar a URL de callback de autorização com o valor gerado.

Fluxo de sincronização implícita

No método de sincronização implícita, o usuário administrador completa o fluxo de autorização durante a criação do alvo. Certifique-se de que a função de execução do AgentCore Gateway possui permissões para GetWorkloadAccessTokenForUserId e CompleteResourceTokenAuth.

O processo segue esta sequência: o administrador chama CreateGatewayTarget, fornecendo o endpoint do servidor MCP, o provedor de credenciais do AgentCore Identity e a URL de retorno. O AgentCore Gateway solicita um token de acesso de workload ao provedor de credenciais, passando a identidade do gateway e um ID de usuário. Com esse token, o gateway solicita um token de acesso OAuth 2.0, que retorna uma URL de autorização e uma session-URI.

Neste ponto, o alvo entra em status “Requer autorização”. O administrador abre a URL de autorização em seu navegador, faz login e concede as permissões solicitadas. Após o consentimento, o servidor OAuth 2.0 envia um código de autorização ao callback registrado do provedor de credenciais.

O provedor redireciona o navegador do administrador para a URL de retorno, com a session-URI. A aplicação então chama CompleteResourceTokenAuth, apresentando o ID do usuário e a session-URI. O provedor de credenciais valida que o mesmo usuário que iniciou o fluxo completou o consentimento, prevenindo roubo de token.

Após validação bem-sucedida, o provedor troca o código de autorização pelo token de acesso OAuth 2.0. Esse token é usado para listar as ferramentas no alvo do servidor MCP; as definições de ferramentas retornadas são armazenadas em cache no AgentCore Gateway.

Método de esquema antecipado

Esta é a abordagem recomendada quando a intervenção humana não é possível durante operações de criação ou atualização. Durante a seleção de criação de alvo, você seleciona a opção de usar uma lista de ferramentas pré-definidas e fornece as definições de ferramentas do GitHub.

O alvo entra imediatamente em status “Pronto”, com status de autorização “Nenhuma autorização necessária”. Isso oferece flexibilidade total sobre quais ferramentas expor e elimina a necessidade de interação do administrador durante a configuração.

Experiência do usuário do gateway

Após a criação bem-sucedida do alvo, seja através de sincronização implícita ou esquema antecipado, os usuários do AgentCore Gateway podem descobrir e invocar ferramentas usando o protocolo MCP.

Quando um usuário do gateway envia uma solicitação de lista de ferramentas com seu token de autorização de entrada, o AgentCore Gateway retorna as definições de ferramentas em cache imediatamente, sem necessidade de nova autenticação no servidor MCP.

Quando o usuário envia uma solicitação para invocar uma ferramenta, o AgentCore Gateway desencadeia o fluxo de autorização OAuth para aquele alvo específico de servidor MCP. O gateway solicita um token de acesso de workload, e então usa esse token para solicitar um token de acesso OAuth 2.0 ao provedor de credenciais.

Se nenhum token válido existir ainda para este usuário, o provedor retorna uma URL de autorização e uma session-URI. O gateway passa esses valores para o usuário, que abre a URL em seu navegador, faz login e concede permissões. Após consentimento, o servidor OAuth 2.0 envia um código de autorização ao callback do provedor de credenciais.

O provedor redireciona o navegador do usuário para a URL de retorno com a session-URI. A aplicação do usuário chama CompleteResourceTokenAuth com o JWT do usuário e a session-URI. O provedor valida que o mesmo usuário completou o consentimento, então troca o código de autorização por um token de acesso OAuth 2.0.

Este token é armazenado em cache no Token Vault sob a identidade do workload e a identidade do usuário. Na próxima invocação de ferramenta, o AgentCore Gateway recupera o token em cache e o usa para chamar o servidor MCP, proporcionando uma experiência fluida após a autenticação inicial.

Explorando exemplos e casos de uso

Embora este exemplo concentre-se no servidor GitHub MCP, o repositório de código inclui exemplos de integração para outros servidores MCP populares de terceiros e um guia para hospedar seu próprio servidor MCP com suporte a fluxo de código de autorização no AgentCore Runtime.

A AWS incentiva explorar esses exemplos e adaptá-los à paisagem de servidor MCP de sua organização, facilitando a adoção de múltiplas ferramentas MCP de forma segura e centralizada.

Recursos adicionais

Para aprofundar seu conhecimento, consulte a documentação oficial: Apresentando o Amazon Bedrock AgentCore Gateway: transformando o desenvolvimento de ferramentas para agentes de IA empresariais, Apresentando o Amazon Bedrock AgentCore Identity: protegendo IA agentic em escala e Exemplos do Amazon Bedrock AgentCore.

Fonte

Connecting MCP servers to Amazon Bedrock AgentCore Gateway using Authorization Code flow (https://aws.amazon.com/blogs/machine-learning/connecting-mcp-servers-to-amazon-bedrock-agentcore-gateway-using-authorization-code-flow/)

Nomes DNS únicos para ambientes multi-conta

A AWS anunciou uma evolução importante no Amazon WorkSpaces Personal: agora é possível utilizar nomes de Domínio (DNS — Sistema de Nomes de Domínio) únicos e publicamente resolvíveis para cada ponto de extremidade de PrivateLink (Conexão Privada) dentro de uma Nuvem Privada Virtual (VPC — Rede Privada Virtual).

Essa funcionalidade resolve um desafio recorrente em ambientes empresariais complexos: permite que organizações implementem WorkSpaces Personal em múltiplas VPCs e contas da AWS sem enfrentar conflitos de resolução de nomes. Anteriormente, todos os pontos de extremidade compartilhavam um nome DNS genérico, o que criava colisões quando tentava-se usar múltiplos endpoints separados em diferentes contas.

Como funciona a solução

Cada ponto de extremidade de interface VPC recebe agora um nome DNS exclusivo gerenciado globalmente pela AWS, além do nome DNS genérico anterior. Essa abordagem mantém a compatibilidade com configurações existentes enquanto oferece maior flexibilidade para arquiteturas de múltiplas contas.

Os nomes DNS publicamente resolvíveis simplificam a configuração sem sacrificar a segurança — eles resolvem apenas para endereços IP privados, acessíveis somente dentro de suas respectivas VPCs. A solução elimina a necessidade de gerenciamento manual de DNS customizado ou configurações adicionais no Route 53 (serviço de DNS da AWS), já que o sistema mantém automaticamente esses nomes durante todo o seu ciclo de vida.

Benefícios para ambientes empresariais

Com essa melhoria, clientes empresariais podem agora:

• Implementar diretórios de WorkSpaces Personal em diferentes VPCs e contas da AWS mantendo isolamento de segurança adequado
• Rotear tráfego de forma apropriada em ambientes multi-conta com infraestrutura DNS centralizada
• Eliminar conflitos de colisão de nomes que previamente impediam o uso de múltiplos endpoints em diferentes contas

Disponibilidade e compatibilidade

O recurso está disponível em todas as regiões AWS (áreas geográficas onde a AWS opera) onde o PrivateLink está disponível no Amazon WorkSpaces Personal. Clientes existentes recebem automaticamente essa melhoria, pois o sistema mantém compatibilidade retroativa com configurações DNS anteriores — nenhuma ação manual é necessária.

Para aprofundar-se na implementação, consulte a documentação de PrivateLink do Amazon WorkSpaces e o Guia de Administração do WorkSpaces para detalhes técnicos de configuração.

Fonte

Amazon WorkSpaces Personal now supports unique DNS names for PrivateLink (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-workspaces-personal-privatelink/)

O que mudou no Amazon Verified Permissions

A AWS anunciou, em abril de 2026, novas funcionalidades para o Amazon Verified Permissions, seu serviço de autorização de granularidade fina. As novidades incluem suporte para aliases de policy stores, políticas nomeadas e templates de políticas nomeados. Essas melhorias foram projetadas para simplificar significativamente as implementações multi-tenant e a gestão diária de políticas.

O Amazon Verified Permissions é um serviço que ajuda você a gerenciar e fazer cumprir permissões em suas aplicações usando políticas Cedar. Com as novas capacidades, a plataforma reduz a complexidade operacional, eliminando necessidades que costumavam ser contornadas manualmente.

Entendendo os Aliases de Policy Stores

Uma das maiores dores de cabeça em ambientes multi-tenant é manter tabelas de mapeamento separadas. Essas tabelas associam identificadores de inquilino (tenant IDs) com IDs de policy stores — um trabalho tedioso e propenso a erros.

Com os aliases de policy stores, desenvolvedores podem agora atribuir um alias legível associado ao identificador do tenant e utilizá-lo em qualquer chamada de API. Isso elimina completamente a necessidade de tabelas de consulta (lookup tables). Em vez de trabalhar com IDs gerados pelo sistema, você trabalha com nomes significativos e contextualizados.

Políticas e Templates Nomeados

Da mesma forma, as políticas nomeadas e os templates de políticas nomeados permitem que você faça referência a políticas por nomes significativos, em vez de depender de IDs gerados automaticamente pelo sistema.

Essa mudança traz benefícios práticos importantes: conforme sua aplicação cresce e a lógica de autorização se torna mais complexa, trabalhar com nomes descritivos torna a gestão muito mais intuitiva e menos suscetível a erros de configuração. Você consegue identificar rapidamente qual política faz o quê, sem precisar consultar documentações ou mapeamentos internos.

Disponibilidade e Próximos Passos

As novas funcionalidades de aliases de policy stores, políticas nomeadas e templates de políticas nomeadas estão disponíveis em todas as regiões AWS onde o Amazon Verified Permissions já é oferecido.

Para explorar essas novidades, você pode consultar:

• A lista de endpoints e quotas do Amazon Verified Permissions para confirmar disponibilidade em sua região;
• A documentação sobre aliases de policy stores e como criar políticas estáticas no Guia do Usuário;
• A referência completa da API do Amazon Verified Permissions para detalhes técnicos de implementação.

O que isso significa para arquitetos e desenvolvedores

Essas mudanças refletem a evolução contínua da AWS em torno de segurança e autorização. Para times que trabalham com aplicações multi-tenant complexas, as novas funcionalidades representam uma redução real de fricção operacional e uma camada adicional de clareza no código de autorização. Menos mapeamentos manuais significam menos bugs, menos confusão e deployments mais confiáveis.

Fonte

Amazon Verified Permissions now supports policy store aliases and named policies and policy templates (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-verified-permissions-policy-store/)

Controle de segurança centralizado para modelos de IA

A AWS anunciou a disponibilidade geral de uma capacidade significativa no Amazon Bedrock Guardrails: as proteções entre contas (cross-account safeguards). Essa funcionalidade permite que as equipes de segurança central de uma organização implementem automaticamente controles de segurança em todas as contas AWS, eliminando a necessidade de configurações repetitivas em cada conta individual.

O Amazon Bedrock Guardrails já oferecia salvaguardas configuráveis capazes de bloquear até 88% do conteúdo prejudicial em múltiplas modalidades (texto, imagem e outros formatos), tanto em prompts de entrada quanto em respostas dos modelos de fundação. Agora, com as proteções entre contas, essa capacidade ganhou uma camada de automação e centralização organizacional.

Como funcionam as proteções entre contas

O mecanismo é direto: administradores podem especificar um identificador de guardrail da conta de gerenciamento em uma nova política do Amazon Bedrock que se propaga automaticamente para todas as entidades membro, incluindo unidades organizacionais (OUs) e contas individuais. Dessa forma, toda e qualquer invocação de modelo no Amazon Bedrock passa automaticamente pelos mesmos controles de segurança definidos centralmente.

Esse modelo de enforçamento oferece três níveis de implementação:

• Proteção de baseline organizacional: Define um padrão de segurança uniforme para toda a organização
• Controles por conta: Permite ajustes específicos conforme necessidade de departamentos ou unidades de negócio
• Salvaguardas específicas de aplicação: Completa as políticas organizacionais com proteções direcionadas para casos de uso particulares

Durante as invocações do modelo, múltiplos guardrails são aplicados de forma conjunta, garantindo que o conteúdo prejudicial seja bloqueado mesmo com regras em diferentes níveis de hierarquia.

Disponibilidade e acesso

A funcionalidade já está disponível em todas as regiões comerciais da AWS e em regiões GovCloud onde o Bedrock Guardrails é suportado. Ela pode ser acessada tanto pelo console de gerenciamento da AWS quanto através das APIs suportadas.

Para quem deseja aprofundar a implementação dessa capacidade, a AWS disponibiliza recursos complementares. Recomendamos consultar o artigo de blog sobre guardrails centralizados, explorar a documentação completa do Amazon Bedrock Guardrails e conferir a página de serviço do Amazon Bedrock Guardrails para informações adicionais. Também existe documentação específica sobre políticas do Amazon Bedrock no guia de organizações da AWS.

Impacto para equipes de segurança

Essa mudança reduz significativamente o overhead operacional de grandes organizações que precisam manter padrões de segurança consistentes em dezenas ou centenas de contas AWS. Em vez de replicar manualmente cada guardrail em cada ambiente, as equipes de segurança central podem agora estabelecer políticas uma única vez e deixar que elas se propaguem automaticamente para toda a infraestrutura de IA da organização.

Fonte

Amazon Bedrock Guardrails announces general availability of cross-account safeguards (https://aws.amazon.com/about-aws/whats-new/2026/04/bedrock-guardrails-cross-account-safeguards/)

Entendendo o Desafio da Criptografia em Escala

Aplicações que operam em larga escala e lidam com volumes significativos de dados criptografados enfrentam um desafio técnico importante: acompanhar os limites de criptografia e gerenciar a rotação de chaves de forma eficiente. Este artigo explora como a AWS Key Management Service (AWS KMS) e o AWS Encryption SDK resolvem automaticamente os limites de criptografia do padrão AES-GCM (Advanced Encryption Standard em Galois Counter Mode), utilizando métodos de derivação de chaves. Isso elimina a necessidade de os desenvolvedores rastrearem manualmente esses limites.

A abordagem utiliza chaves derivadas que são geradas a partir de uma chave principal por meio de um valor aleatório chamado nonce. Dessa forma, cada operação de criptografia usa uma chave única, permitindo que a chave principal seja reutilizada por muito mais tempo. Métodos similares de derivação de chaves têm sido propostos em esquemas recentes como o (KC-)XAES, DNDK v2, e outros trabalhos acadêmicos da comunidade criptográfica.

Os Limites da Criptografia Simétrica

Criptografia AEAD e AES-GCM

Algoritmos de criptografia simétrica protegem grandes volumes de dados, tanto em trânsito quanto em repouso. Os cifras modernos também autenticam os dados usando uma tag de autenticação — essas são chamadas de cifras AEAD (Authenticated Encryption with Additional Data). Exemplos incluem o AES-GCM e o ChaCha20/Poly1305.

O AES-GCM é o algoritmo de criptografia mais amplamente utilizado e foi padronizado pelo NIST na especificação SP 800-38D. Este algoritmo utiliza uma chave de 128 ou 256 bits (K), um vetor de inicialização (IV) de 96 bits e criptografa um texto simples (P), autenticando também dados adicionais (AAD). O resultado é um texto cifrado (C) e uma tag de autenticação (T).

Na descriptografia, o receptor recupera o texto simples original utilizando a chave, o IV e os dados autenticados, depois valida a tag para garantir a integridade da mensagem.

Limite de Invocações de Criptografia

Um requisito crítico para a segurança do AES-GCM é que o par (chave K, IV) nunca se repita durante toda a vida útil da chave. Se isso acontecer, as propriedades de segurança do algoritmo são comprometidas. A especificação SP 800-38D exige que a implementação mantenha uma probabilidade de reutilização inferior a 1 em 4,29 bilhões (menor que 2⁻³²).

Isso pode ser alcançado utilizando um IV determinístico que não se repete ou um IV aleatório. Se um IV aleatório é usado, torna-se necessário trocar a chave após 2³² criptografias. Protocolos comuns como TLS ou IKEv2/IPsec evitam colisões do par (K, IV) usando IVs determinísticos que começam com um valor aleatório e são incrementados para cada conexão.

Limite de Volume de Dados

Além do limite de invocações, existe também um limite relacionado ao volume total de dados que pode ser criptografado com a mesma chave. O contador de blocos no AES-GCM é de 32 bits, o que resulta em um limite de 2³²-2 bytes (aproximadamente 68,72 GB) por operação de criptografia, ou seja, por cada par único (K, IV).

Quando não se restringe o volume total de dados criptografados, reduz-se a garantia de segurança de indistinguibilidade — a capacidade de um adversário de não conseguir distinguir entre dois textos cifrados diferentes. Quanto maior a proteção de indistinguibilidade, menor é o total de bytes que podem ser criptografados sob uma única chave.

A especificação do NIST sugere um limite de 2⁶⁸ bytes protegidos sob uma chave única, o que fornece uma probabilidade de indistinguibilidade de 50%. Porém, margens de segurança mais conservadoras baseadas em diferentes análises criptográficas são frequentemente utilizadas. A AWS adota uma abordagem ainda mais conservadora, impondo por padrão uma probabilidade de indistinguibilidade negligenciável (menor que 2⁻³²).

Quando se atinge os limites de dados do AES-GCM para uma determinada margem de segurança, é necessário fazer a rotação da chave simétrica. Em aplicações modernas de criptografia em larga escala, esses limites (por exemplo, 2³² criptografias com IVs aleatórios ou o volume máximo de dados por chave) podem ser atingidos. Rastrear esses limites em sistemas distribuídos com muitas sessões concorrentes adiciona complexidade operacional significativa. A AWS compartilhou essas dificuldades em um documento detalhado e uma apresentação no terceiro Workshop do NIST sobre Modos de Cifra em Blocos de 2023.

Como AWS KMS Utiliza Chaves Derivadas

A AWS KMS é um serviço gerenciado que permite criar e controlar as chaves utilizadas para criptografar e assinar dados. A API Encrypt do KMS suporta criptografia simétrica e assimétrica. Para criptografia com chaves simétricas, o AWS KMS utiliza AES-GCM com chaves de 256 bits para criptografar um texto simples de até 4 KB.

Quando uma solicitação ao KMS Encrypt é feita, ela inclui o texto simples e o identificador da chave simétrica gerenciada pelo cliente armazenada no KMS. A chamada da API de Encrypt usa a chave para derivar uma chave de criptografia simétrica antes de criptografar o texto simples.

O processo funciona da seguinte forma: a AWS KMS gera um nonce aleatório de 128 bits e produz uma chave simétrica de 256 bits a partir da chave principal especificada, utilizando uma função de derivação de chaves (KDF). Essa função recebe a chave, um rótulo e contexto, um nonce específico da invocação, e um comprimento de saída desejado, produzindo material de chave do tamanho especificado.

Para o AWS KMS, a função KDF é o Counter Mode KDF conforme a especificação SP 800-108r1 do NIST, que produz 256 bits de material de chave utilizando HMAC-SHA256 como função pseudoaleatória. A chave derivada é produzida com uma chamada ao HMAC-SHA256 com a chave principal:

Subsequentemente, o AWS KMS gera um IV aleatório de 96 bits e criptografa o texto simples de entrada com AES-GCM. O resultado inclui o IV, o nonce, o texto cifrado e a tag de autenticação. Estes componentes são retornados em um blob de texto cifrado (CiphertextBlob) que pode ser descriptografado em chamadas posteriores à API Decrypt.

Intuitivamente, o nonce aleatório de 128 bits usado para derivar uma chave única de criptografia sob uma chave gerenciada permite que o chamador ultrapasse significativamente o limite de 2³² invocações de criptografia sob essa chave. Além disso, o limite de 4 KB no tamanho da carga útil para uma chamada AWS Encrypt garante que o volume total de dados criptografados sob uma chave de criptografia permaneça bem abaixo dos limites totais de criptografia do NIST ou de outras margens mais conservadoras. Para mais detalhes sobre os fundamentos matemáticos e criptográficos desse esquema, consulte o artigo Key Management Systems at the Cloud Scale.

Como AWS Encryption SDK Aplica Modos de Chave Derivada

O AWS Encryption SDK é uma biblioteca de criptografia do lado do cliente usada para criptografar e descriptografar dados. Pode ser configurado para usar cache de chaves de dados, reduzindo chamadas de API ao criptografar múltiplas cargas úteis.

Usar uma chave derivada baseada em nonce para cada invocação de AES-GCM elimina a necessidade de os clientes acompanharem o volume total de dados que criptografam sob uma única chave de dados. Embora o AWS Encryption SDK ofereça muita flexibilidade para acomodar diversos cenários de criptografia, a configuração padrão lida com derivação de chaves e dimensionamento de frames automaticamente, elimando a necessidade de ajustar essas configurações para a maioria dos casos de uso.

Para derivar uma chave diferente para cada invocação, assim como o AWS KMS, o SDK utiliza um valor aleatório gerado, a chave principal e contexto específico da invocação na KDF. O valor aleatório tem 256 bits na configuração padrão. A KDF subjacente é a Função de Derivação de Chaves baseada em HMAC (HKDF — HMAC-based Extract-and-Expand Key Derivation Function) com SHA512 como o hash padrão.

A chave derivada é produzida com uma chamada ao HKDF com a chave principal, usando um rótulo constante e um contexto que consiste em constantes concatenadas com um valor aleatório de 256 bits. Subsequentemente, o AWS Encryption SDK usa a chave derivada para criptografar o conteúdo do usuário, dividido em frames de 4 KB por padrão.

Cada frame de texto simples é criptografado com AES-GCM usando um IV determinístico que consiste em um contador de frames, onde o ID do frame é menor que 2³². O dado autenticado adicional (AAD) é específico do frame de dados do Encryption SDK. Na descriptografia, o receptor deriva a chave da mesma forma e descriptografa o texto cifrado para produzir o texto simples do frame, validando a tag de autenticação.

O tamanho padrão de 4 KB por frame garante que por padrão não mais que 2⁴⁴ bytes (2³² frames de 4 KB cada) possam ser criptografados sob uma única chave de criptografia. Isso está bem abaixo do limite sugerido pelo NIST (2⁶⁸ bytes), mesmo com cache de chaves de dados. Também está bem abaixo do requisito conservador da AWS de probabilidade de indistinguibilidade menor que 2⁻³².

O limite de invocações por chave, mesmo com cache de chaves de dados, excede as contagens de criptografia na maioria das aplicações em larga escala.

Considerações sobre Versões Anteriores

Enquanto a configuração padrão do AWS Encryption SDK faz escolhas conservadoras, se você estiver usando a versão legada 1.0 ou fizer alterações de configuração, poderá ter garantias de segurança menores. Por exemplo, um tamanho máximo customizado de frame de 2³²-1 bytes levaria a um tamanho total de texto simples maior, que ainda está abaixo do limite sugerido pelo NIST de 2⁶⁸ bytes, mas não necessariamente abaixo de outras margens conservadoras.

Vale notar que a configuração padrão do AWS Encryption SDK também fornece propriedades de segurança menos conhecidas, como compromisso de chave. A string de comprometimento é produzida de forma similar à chave derivada, utilizando a chave principal e HKDF.

Conclusão

Ao derivar uma chave única para cada chamada de criptografia, a AWS KMS e o AWS Encryption SDK eliminam a necessidade de rastrear manualmente os limites do AES-GCM. Para compreender os fundamentos acadêmicos dos limites do AES-GCM, consulte a especificação SP 800-38D e o rascunho draft-irtf-cfrg-aead-limits.

Para leitura adicional sobre a análise criptográfica do esquema de derivação de chaves utilizado no KMS, consulte Key Management Systems at the Cloud Scale. Para mais detalhes sobre a derivação de chaves AES-GCM do Encryption SDK, veja a referência de algoritmos do AWS Encryption SDK.

Fonte

How AWS KMS and AWS Encryption SDK overcome symmetric encryption bounds (https://aws.amazon.com/blogs/security/how-aws-kms-and-aws-encryption-sdk-overcome-symmetric-encryption-bounds/)

Autoativação expandida no CloudWatch

A AWS anunciou uma expansão significativa da funcionalidade de autoativação do CloudWatch. O serviço agora oferece suporte automático para ativação de logs de acesso padrão do Amazon CloudFront, relatórios de descoberta de postura de segurança (CSPM) do AWS Security Hub, além de logs e rastreamentos de memória e gateway do Amazon Bedrock AgentCore que são enviados automaticamente para o CloudWatch Logs.

Essa evolução marca um passo importante na simplificação do gerenciamento de telemetria em ambientes de nuvem. Clientes podem agora estabelecer regras de autoativação que configuram automaticamente a coleta de telemetria tanto para recursos já existentes quanto para novos recursos criados no futuro, garantindo uma cobertura de monitoramento consistente sem necessidade de configurações manuais repetitivas.

Flexibilidade no escopo das regras

As regras de autoativação oferem um alto grau de flexibilidade em termos de escopo. É possível configurá-las em três níveis diferentes:

• No nível da organização como um todo
• Para contas específicas dentro da organização
• Para recursos específicos identificados por tags

Essa estrutura permite que equipes padronizem a coleta de telemetria de forma consistente, adaptando-se às necessidades específicas de cada ambiente. Um exemplo prático dessa flexibilidade: uma equipe central de segurança pode criar uma única regra que automaticamente envia logs de acesso do CloudFront e descobertas do Security Hub para todos os recursos em toda a organização para o CloudWatch Logs.

Disponibilidade e cobertura

A capacidade de autoativação do CloudWatch está disponível em todas as regiões comerciais da AWS. É importante observar que a ingestão de logs será cobrada conforme os preços estabelecidos no modelo de preços do CloudWatch.

Quanto ao escopo das regras por tipo de recurso: logs de acesso do Amazon CloudFront e descobertas do Security Hub CSPM suportam regras de autoativação em nível de organização, enquanto os dados de memória e gateway do Bedrock AgentCore funcionam com regras no nível de conta.

Próximos passos

Para aprofundar o conhecimento sobre como configurar e usar as regras de autoativação no CloudWatch, a documentação do Amazon CloudWatch oferece detalhes completos sobre a implementação dessa funcionalidade.

Fonte

Amazon CloudWatch expands auto-enablement to Amazon CloudFront logs and 3 additional resource types (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-cloudwatch-cloudfront-enablement/)