Category: Uncategorized

O contexto: IA acelerou o jogo, mas os fundamentos continuam sendo a base

Há poucas semanas, a Anthropic anunciou o modelo Claude Mythos Preview e lançou o Project Glasswing em parceria com a AWS e outras organizações de referência no setor. O movimento gerou bastante debate sobre o futuro da cibersegurança e o que o avanço contínuo dos modelos de fundação significa para as empresas na prática.

Nesse contexto, a AWS publicou um artigo destacando um ponto central: independentemente de onde a IA vai chegar, as organizações que não tiverem os fundamentos de segurança bem estabelecidos simplesmente não conseguirão reagir com agilidade às mudanças. E velocidade de resposta, na segurança, é tudo.

Para quem quiser se aprofundar na visão da AWS sobre como construir defesas de IA em escala, vale conferir o post Construindo defesas de IA em escala: antes das ameaças emergirem.

O problema real: a lacuna de higiene de segurança

É tentador achar que os elementos básicos de segurança já estão cobertos. Mas, na prática, casos de uso fundamentais — como gestão de identidade, detecção de ameaças, gestão de vulnerabilidades, proteção de dados e segurança de rede — costumam ser implementados de forma inconsistente em ambientes de nuvem.

A AWS reforça que, enquanto a IA redesenha o cenário de segurança, os fundamentos continuam sendo essenciais para qualquer organização, independentemente do tamanho ou setor. São eles:

• Aplicar patches de forma consistente
• Enforçar acesso com privilégio mínimo
• Habilitar logging e monitoramento
• Criptografar dados em repouso e em trânsito
• Revisar configurações de segurança regularmente

Com esses fundamentos estabelecidos, a organização fica muito melhor posicionada para aproveitar ferramentas orientadas por IA e responder rapidamente a vulnerabilidades recém-descobertas.

Para ajudar nessa jornada, a AWS disponibiliza gratuitamente materiais como o AWS Well-Architected Framework, que orienta as perguntas certas e ajuda a implementar melhorias no ambiente. Além disso, existe um programa específico para isso: o SHIP.

O que é o SHIP?

O Programa de Melhoria de Saúde em Segurança (SHIP) é um programa gratuito disponível para todos os clientes AWS, independentemente do nível de suporte contratado. Ele oferece uma metodologia comprovada e orientada por dados para:

• Avaliar a postura de segurança atual usando dados do próprio ambiente AWS do cliente
• Identificar oportunidades específicas de melhoria em 10 casos de uso principais de segurança
• Construir um plano de ação priorizado e adequado ao contexto da organização
• Estabelecer um mecanismo de melhoria contínua de segurança

O programa é conduzido por Arquitetos de Soluções e Gerentes Técnicos de Conta da AWS, que guiam o cliente por um relatório personalizado, contextualizam as descobertas para o ambiente específico e ajudam a montar um plano de ação com prioridades claras.

Por que o SHIP importa na era da IA?

O Project Glasswing evidencia uma mudança importante: ferramentas com IA estão acelerando o ritmo de descoberta de vulnerabilidades. Isso significa que as organizações precisam estar preparadas para avaliar e responder a novas descobertas muito mais rápido do que antes.

Além dos fatores externos, à medida que as empresas adotam IA — seja implantando modelos de fundação, construindo fluxos de trabalho agênticos ou usando serviços com IA embutida — a forma como implementam seus controles de segurança também precisa evoluir. Uma base sólida de segurança é o que torna a adoção confiante de IA possível.

Corrigir lacunas de segurança de forma proativa

O SHIP utiliza metodologia orientada por dados para identificar oportunidades de melhoria em 10 casos de uso principais de segurança: detecção de ameaças, gestão de postura de segurança em nuvem, testes de segurança de aplicações, gestão de configuração, governança de acesso, gestão de vulnerabilidades, proteção de aplicações, segurança de rede, criptografia e gestão de segredos.

O programa inclui uma avaliação SHIP para identificar descobertas críticas relacionadas à postura de segurança atual, permitindo que a equipe construa um roteiro de melhoria priorizado e adequado ao ambiente.

Estabelecer a linha de base de segurança que workloads de IA exigem

Antes de implantar o primeiro modelo no Amazon Bedrock ou construir fluxos de trabalho agênticos com o Amazon Bedrock AgentCore, é necessário ter confiança de que a infraestrutura subjacente segue as boas práticas de segurança. O SHIP usa dados reais do ambiente do cliente para fornecer orientações prescritivas e específicas, em vez de recomendações genéricas.

Isso é especialmente relevante à medida que ferramentas de descoberta de vulnerabilidades baseadas em IA se tornam mais amplamente disponíveis: organizações com bases sólidas conseguirão agir sobre novas descobertas de forma rápida e eficaz.

Construir um mecanismo de melhoria contínua de segurança

À medida que as capacidades de IA evoluem, as organizações se beneficiam de ter um processo repetível para avaliar e fortalecer sua postura de segurança ao longo do tempo. O SHIP estabelece a metodologia e os mecanismos para que a equipe avalie, priorize e melhore continuamente. Ao construir essa capacidade operacional, a organização fortalece sua habilidade de se adaptar e contribui para a resiliência mais ampla do setor.

Como começar com o SHIP

O programa está disponível hoje, sem custo, para todos os clientes AWS. Há três caminhos para dar o primeiro passo:

• Fale com o time de conta AWS. Solicite o agendamento de um engajamento SHIP diretamente ou acesse a página do SHIP para fazer a solicitação.
• Participe de um SHIP Activation Day. A AWS realiza regularmente workshops práticos onde é possível executar a avaliação SHIP com Arquitetos de Soluções e começar a construir o plano de melhoria.
• Explore a documentação prescritiva. Consulte o AWS Well-Architected Framework – Security Lens para documentação, arquiteturas de referência e guias de implementação disponíveis para uso imediato.

Conclusão

O recado da AWS é claro: a IA está acelerando tanto as capacidades de ataque quanto as de defesa, e as organizações que já tiverem seus fundamentos de segurança bem estabelecidos sairão na frente. O SHIP é uma oportunidade concreta — e gratuita — de fazer essa avaliação com apoio especializado, construir um plano priorizado e criar um ciclo de melhoria contínua.

Para quem está pensando em adotar workloads de IA na AWS, esse é um passo que vale ser dado antes, não depois. Acesse a página de recursos do SHIP para saber mais.

Fonte

Security posture improvement in the AI era (https://aws.amazon.com/blogs/security/security-posture-improvement-in-the-ai-era/)

O que foi anunciado

O AWS Security Assurance Services acaba de publicar um novo guia de conformidade: o ISO 31000:2018 Risk Management on AWS Compliance Guide. O material foi desenvolvido para ajudar organizações que desejam estruturar ou aprimorar seus programas de gestão de riscos em ambientes AWS, seguindo os princípios da norma ISO 31000:2018.

Trata-se de um recurso prático — não apenas teórico — que mostra como integrar os serviços AWS aos processos de gestão de riscos já existentes nas empresas.

O que o guia cobre

O documento está estruturado em torno dos componentes centrais da ISO 31000:2018 e explica como os recursos da AWS podem dar suporte a cada um deles:

• Estabelecimento de contexto e critérios: como definir o escopo e os parâmetros do programa de riscos dentro do ambiente AWS.
• Avaliação de riscos: como usar os serviços da AWS para identificar, analisar e priorizar riscos.
• Tratamento de riscos: estratégias práticas de mitigação, transferência, aceitação e eliminação de riscos, com apoio das ferramentas disponíveis na plataforma.
• Monitoramento e revisão contínuos: como as capacidades de automação e monitoramento da AWS ajudam a manter a visibilidade operacional e a prontidão para conformidade ao longo do tempo.

Governança e o Modelo de Responsabilidade Compartilhada

Um ponto de destaque do guia é a conexão com o Modelo de Responsabilidade Compartilhada da AWS. O documento apresenta considerações de governança e tratamento de riscos alinhadas a esse modelo, deixando claro o que é responsabilidade da AWS e o que cabe ao cliente gerenciar — algo fundamental para qualquer programa de conformidade bem estruturado.

Por que isso importa para equipes brasileiras

A ISO 31000 é uma norma internacional amplamente adotada por organizações que precisam demonstrar maturidade em gestão de riscos — seja para auditorias internas, exigências regulatórias ou certificações. Ter um guia específico para ambientes AWS simplifica bastante o trabalho de times de segurança, compliance e arquitetura que precisam mapear como os controles da nuvem se encaixam no framework de riscos da empresa.

Ao combinar os princípios da ISO 31000 com os serviços de segurança da AWS, as organizações conseguem construir ambientes escaláveis e automatizados que suportam a identificação contínua de riscos, o tratamento proativo de ameaças e a visibilidade operacional necessária para manter a conformidade.

Como acessar

O guia está disponível gratuitamente para download. Acesse o ISO 31000:2018 Risk Management on AWS Compliance Guide diretamente pelo site da AWS. Para suporte adicional ou dúvidas sobre implementação, o AWS Security Assurance Services pode ser acionado diretamente.

Fonte

Announcing the ISO 31000:2018 Risk Management on AWS Compliance Guide (https://aws.amazon.com/blogs/security/announcing-the-iso-310002018-risk-management-on-aws-compliance-guide/)

O que mudou

A AWS anunciou que o Amazon CloudFront agora suporta tráfego WebSocket através de origens em Nuvem Privada Virtual (VPC — Virtual Private Cloud). Isso significa que aplicações em tempo real hospedadas inteiramente em sub-redes privadas podem usar o CloudFront como único ponto de entrada, sem precisar expor nada à internet diretamente.

Por que isso importa

Antes dessa mudança, quem precisava usar WebSockets tinha um problema claro: as origens precisavam estar em sub-redes públicas. Para proteger esses servidores, as equipes precisavam configurar e manter Listas de Controle de Acesso (ACLs — Access Control Lists) e outros mecanismos de restrição — o que gerava esforço contínuo e complexidade operacional.

Agora, a AWS permite que os clientes coloquem seus recursos — como Balanceadores de Carga de Aplicação (ALB — Application Load Balancer), Balanceadores de Carga de Rede (NLB — Network Load Balancer) e instâncias EC2 — em sub-redes totalmente privadas, acessíveis apenas através das distribuições do CloudFront.

Casos de uso beneficiados

A extensão do suporte a WebSockets para origens VPC é especialmente relevante para aplicações que dependem de conexões persistentes e bidirecionais entre clientes e servidores. Alguns exemplos práticos mencionados pela AWS:

• Plataformas de chat
• Ferramentas de edição colaborativa
• Dashboards ao vivo
• Sistemas de gerenciamento de dispositivos de IoT (Internet das Coisas)

Benefícios de segurança

Com essa novidade, o CloudFront passa a funcionar como a porta de entrada única tanto para tráfego HTTP tradicional quanto para conexões WebSocket em tempo real. Segundo a AWS, isso traz benefícios concretos:

• Redução da superfície de ataque, já que os servidores de origem ficam em sub-redes privadas
• Simplificação do gerenciamento de segurança, centralizando o controle de acesso no CloudFront
• Proteção integrada contra DDoS (Negação de Serviço Distribuída — Distributed Denial of Service), nativa do CloudFront

Disponibilidade e custo

O suporte a WebSockets para origens VPC já está disponível em todas as Regiões Comerciais da AWS onde o recurso de origens VPC é suportado. A AWS informa que não há custo adicional para o tráfego WebSocket através de origens VPC.

Para saber mais sobre como configurar esse recurso, a documentação oficial está disponível em Origens VPC no CloudFront.

Fonte

Amazon CloudFront Announces WebSocket Support for VPC Origins (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-cloudfront-websockets-vpc-origins/)

O que mudou no IAM Roles Anywhere

A AWS anunciou uma atualização importante no Gerenciamento de Identidade e Acesso (IAM) Roles Anywhere: a partir de agora, as políticas de endpoint de Nuvem Privada Virtual (VPC) passam a ser aplicadas também à API CreateSession. Antes dessa mudança, essa operação específica ficava de fora do escopo das políticas de endpoint — uma lacuna que a AWS agora fecha.

Entendendo o contexto: o que é o IAM Roles Anywhere e a API CreateSession

O IAM Roles Anywhere foi criado para resolver um desafio comum em ambientes híbridos: como conceder credenciais temporárias da AWS para cargas de trabalho que rodam fora da nuvem AWS. O mecanismo funciona com certificados X.509 — a carga de trabalho externa apresenta um certificado válido e, em troca, recebe credenciais temporárias para acessar recursos AWS.

A API CreateSession é exatamente o ponto de entrada desse fluxo: é ela que processa o certificado e devolve as credenciais temporárias. Por ser tão central no processo, controlar quem pode chamá-la via endpoint privado de VPC é uma necessidade crítica de segurança.

Como funcionam as políticas de endpoint VPC agora

Com a atualização, as regras de permissão e negação definidas nas políticas de endpoint de VPC passam a valer para o CreateSession da mesma forma que já valiam para as demais operações do IAM Roles Anywhere. Na prática, isso significa:

• Se a política de endpoint VPC não incluir explicitamente o CreateSession no bloco Allow, a operação será bloqueada.
• Da mesma forma, se a política não permitir todas as operações — por exemplo, usando rolesanywhere:* como ação — o IAM Roles Anywhere não retornará credenciais temporárias para requisições feitas por aquele endpoint.
• Para manter o comportamento atual sem interrupções, basta garantir que a política de endpoint permita explicitamente o CreateSession ou use o curinga rolesanywhere:*.

Por que essa atualização importa para a segurança

Antes dessa mudança, havia uma inconsistência: as políticas de endpoint VPC controlavam todas as operações do IAM Roles Anywhere — exceto justamente a CreateSession, que é a mais sensível delas, pois é quem emite as credenciais temporárias. Isso criava um ponto cego no controle de acesso.

Agora, com a aplicação uniforme das políticas, as equipes de segurança conseguem definir controles granulares e consistentes em todas as operações do IAM Roles Anywhere realizadas via endpoint privado. É o tipo de ajuste que parece pequeno, mas que faz diferença real na postura de segurança de ambientes híbridos.

Disponibilidade

A funcionalidade já está disponível em todas as regiões AWS onde o IAM Roles Anywhere opera, incluindo as regiões AWS GovCloud (EUA), AWS European Sovereign Cloud (Alemanha) e as regiões da China.

Para entender como configurar as políticas de endpoint de VPC para o IAM Roles Anywhere, a AWS disponibiliza o Guia do Usuário do IAM Roles Anywhere com orientações detalhadas.

Fonte

IAM Roles Anywhere now enforces VPC endpoint policies for the CreateSession API (https://aws.amazon.com/about-aws/whats-new/2026/05/iam-roles-anywhere-vpc/)

O desafio: agentes de IA que precisam de recursos privados

Agentes de IA em ambientes de produção frequentemente precisam acessar APIs internas, bancos de dados e outros serviços que ficam dentro dos limites de uma Nuvem Privada Virtual da Amazon (Amazon VPC). Gerenciar a conectividade privada para cada par agente-ferramenta gera sobrecarga operacional e atrasa implantações.

Para resolver isso, a AWS disponibilizou a conectividade VPC do Amazon Bedrock AgentCore, projetada para implantar agentes de IA e servidores do Protocolo de Contexto de Modelo (MCP) sem que o tráfego precise ser exposto à internet pública. Essa capacidade inclui o egresso gerenciado de VPC para o Amazon Bedrock AgentCore Gateway, permitindo conexões a endpoints dentro de redes privadas em todo o ambiente AWS.

Neste guia, a AWS explica como configurar o AgentCore Gateway para acessar endpoints privados usando o Resource Gateway — um construto gerenciado que provisiona Interfaces de Rede Elásticas (ENIs) diretamente dentro da sua Amazon VPC, uma por sub-rede. São abordados dois modos de implementação (gerenciado e autogerenciado) e três cenários práticos: conexão a um Amazon API Gateway privado, integração com um servidor MCP no Amazon Elastic Kubernetes Service (Amazon EKS) e acesso a uma API REST privada.

Conceitos fundamentais da arquitetura

Antes de entrar nos modos de implementação, vale entender os termos centrais da arquitetura de egresso VPC do AgentCore Gateway:

• VPC de Recurso: a Amazon VPC onde o seu recurso privado reside — por exemplo, a VPC que hospeda seu servidor MCP ou endpoint de API. Pode estar na mesma conta AWS do AgentCore Gateway ou em uma conta diferente.
• Conta do AgentCore Gateway: a conta AWS onde você cria e gerencia os recursos do AgentCore Gateway.
• Resource Gateway: atua como ponto de entrada privado na VPC de Recurso. Ao ser criado, provisiona uma ENI por sub-rede especificada, cada uma dentro da sua VPC. O tráfego do AgentCore Gateway chega ao seu recurso privado por meio dessas ENIs.
• Resource Configuration: define o recurso específico que o AgentCore Gateway tem permissão de acessar através do Resource Gateway, identificado por nome de domínio ou endereço IP. Em vez de liberar acesso a toda a VPC, a Resource Configuration delimita a conectividade a um único endpoint.
• Service Network Resource Association: conecta uma Resource Configuration à rede de serviço do AgentCore, permitindo que o serviço AgentCore Gateway invoque o endpoint privado. O AgentCore cria e gerencia essa associação automaticamente, independentemente do modo escolhido.

Dois modos de implementação

O egresso VPC do AgentCore Gateway suporta dois modos, dependendo do nível de controle desejado sobre a infraestrutura de rede subjacente.

Modo gerenciado (Managed VPC Resource)

Neste modo, o AgentCore Gateway cuida de tudo automaticamente. Basta fornecer o ID da VPC, os IDs das sub-redes e os grupos de segurança como parte da configuração do target — o AgentCore cria e gerencia o VPC Resource Gateway na sua conta. Esse modo se integra com arquiteturas de rede existentes, seja com VPC peering para conectividade na mesma região ou entre regiões, seja com um modelo hub-and-spoke usando o AWS Transit Gateway para ambientes multi-VPC e híbridos.

O diagrama abaixo ilustra como o AgentCore Gateway se conecta a um Amazon API Gateway privado usando o modo gerenciado:

Nesse fluxo, o AgentCore Gateway inicia a requisição e a roteia para o Resource Gateway provisionado dentro da VPC de Recurso. O tráfego passa pela ENI na sub-rede privada, governado pelos grupos de segurança configurados, e então chega ao endpoint de VPC execute-api, que fornece conectividade privada ao endpoint interno do Amazon API Gateway. No modo gerenciado, você tem apenas visibilidade de leitura sobre o Resource Gateway criado pelo AgentCore.

Modo autogerenciado (Self-Managed Lattice Resource)

Neste modo, você mesmo cria e gerencia o VPC Lattice Resource Gateway e a Resource Configuration antes de referenciá-los na criação do target no AgentCore Gateway. Isso oferece visibilidade e controle completos sobre a Resource Configuration — incluindo o número de endereços IPv4 por ENI, posicionamento de sub-redes e regras de grupos de segurança. Mais importante, permite compartilhar a configuração usando o AWS Resource Access Manager (AWS RAM) (necessário para conectividade entre contas), visualizar associações e revogar acessos quando necessário.

O diagrama a seguir mostra como o AgentCore Gateway se conecta a endpoints de API REST privados usando o modo autogerenciado:

Nesse fluxo, você pré-cria o Resource Gateway e a Resource Configuration antes de configurar o AgentCore Gateway Target. Ao chamar CreateGatewayTarget, você passa o ID da Resource Configuration para associar o target do AgentCore Gateway ao seu endpoint privado. Diferente do modo gerenciado, você é o responsável pelo ciclo de vida completo do Resource Gateway e da Resource Configuration.

Comparativo entre os modos

A tabela a seguir resume as principais diferenças para ajudar a escolher o modo mais adequado para cada arquitetura:

• Complexidade de configuração: o modo gerenciado é mais simples — basta fornecer VPC ID, sub-redes e security groups. O autogerenciado exige criação prévia do Resource Gateway e das Resource Configurations.
• Conectividade entre contas: o modo gerenciado não suporta nativamente — use VPC peering ou AWS Transit Gateway. O autogerenciado suporta com AWS RAM, sem necessidade de peering ou Transit Gateway.
• Visibilidade e governança: no modo gerenciado, as Resource Configurations ficam na conta de serviço do AgentCore e não aparecem no console da VPC. No autogerenciado, há visibilidade total no console do Amazon VPC Lattice, com capacidade de auditar e revogar acessos de forma granular.
• Precificação: o modo gerenciado cobra apenas pelo processamento de dados (por GB). O autogerenciado adiciona uma cobrança por hora pela associação à rede de serviço, mais o processamento de dados.

Pré-requisitos

O tutorial foca no modo gerenciado. Para explorar o modo autogerenciado, a AWS disponibiliza exemplos de código no GitHub. Antes de começar, é necessário ter:

• Interface de Linha de Comando da AWS (AWS CLI)
• Credenciais AWS configuradas
• Certificado de Autoridade Certificadora (CA) pública — atualmente o AgentCore Gateway confia apenas em certificados TLS assinados publicamente. Se o endpoint usar certificado privado ou autoassinado, consulte a solução de contorno disponível no GitHub.
• Permissões de Gerenciamento de Identidade e Acesso da AWS (IAM): o principal IAM precisa da permissão iam:CreateServiceLinkedRole para bedrock-agentcore.amazonaws.com, para que o AgentCore possa criar a role vinculada ao serviço se ela ainda não existir.

O grupo de segurança do Resource Gateway controla o tráfego de saída que as ENIs podem enviar aos recursos dentro da Amazon VPC. Se nenhum grupo de segurança for fornecido ao chamar a API CreateGatewayTarget, o grupo de segurança padrão é utilizado.

Caso ainda não tenha um AgentCore Gateway criado, execute:

aws bedrock-agentcore create-gateway \
  --name my-gateway \
  --role-arn arn:aws:iam::<account-id>:role/AgentCoreGatewayRole

Guarde o gatewayId retornado na resposta — ele será necessário nas etapas seguintes. Para exemplos mais detalhados, consulte o repositório no GitHub.

Cenário 1: Amazon API Gateway privado

Para criar um AgentCore Gateway target que roteia para um Amazon API Gateway privado, chame a API CreateGatewayTarget com os seguintes parâmetros. No campo openApiSchema, forneça a URL do endpoint privado do Amazon API Gateway (https://{api-id}-{vpce-id}.execute-api.{region}.amazonaws.com/{stage}). No bloco managedVpcResource, forneça o ID da VPC, os IDs das sub-redes e o ID do grupo de segurança:

aws bedrock-agentcore-control create-gateway-target \
  --region us-west-2 \
  --cli-input-json '{
    "gatewayIdentifier": "<GATEWAY_ID>",
    "name": "private-apigw",
    "description": "Private API Gateway",
    "targetConfiguration": {
      "mcp": {
        "openApiSchema": {
          "inlinePayload": "..."
        }
      }
    },
    "credentialProviderConfigurations": [...],
    "privateEndpoint": {
      "managedVpcResource": {
        "vpcIdentifier": "<VPC_ID>",
        "subnetIds": ["<SUBNET_ID_1>", "<SUBNET_ID_2>"],
        "endpointIpAddressType": "IPV4",
        "securityGroupIds": ["<VPCE_SG_ID>"]
      }
    }
  }'

Após executar o comando, o AgentCore Gateway usa sua role vinculada ao serviço para provisionar um Resource Gateway na VPC, criando uma ENI por sub-rede especificada. O diagrama abaixo mostra o fluxo de rede resultante:

O AgentCore Gateway inicia a requisição e a roteia para o Resource Gateway provisionado dentro da VPC de Recurso. O tráfego passa pela ENI na sub-rede privada, onde as regras do grupo de segurança governam o próximo salto. A partir daí, a requisição alcança o endpoint de VPC execute-api, que fornece conectividade privada ao endpoint interno do Amazon API Gateway.

Cenário 2: Servidor MCP privado no Amazon EKS

Para rotear para um servidor MCP privado rodando no Amazon EKS, chame a API CreateGatewayTarget com os seguintes parâmetros. No bloco mcpServer, forneça a URL interna do servidor MCP. No bloco managedVpcResource, forneça o ID da VPC, os IDs das sub-redes e o ID do grupo de segurança:

aws bedrock-agentcore-control create-gateway-target \
  --region us-west-2 \
  --cli-input-json '{
    "gatewayIdentifier": "<GATEWAY_ID>",
    "name": "private-apigw",
    "description": "Private API Gateway",
    "targetConfiguration": {
      "mcp": {
        "mcpServer": {
          "endpoint": "https://internal.example.com/csm/mcp"
        }
      }
    },
    "credentialProviderConfigurations": [...],
    "privateEndpoint": {
      "managedVpcResource": {
        "vpcIdentifier": "<VPC_ID>",
        "subnetIds": ["<SUBNET_ID_1>", "<SUBNET_ID_2>"],
        "endpointIpAddressType": "IPV4",
        "securityGroupIds": ["<VPCE_SG_ID>"]
      }
    }
  }'

O diagrama a seguir mostra o caminho completo do tráfego nesse cenário:

O AgentCore Gateway envia uma requisição HTTPS ao endpoint interno. A zona hospedada privada do Amazon Route 53 resolve o domínio para o Balanceador de Carga de Rede (NLB) interno. A requisição entra na VPC de Recurso pelo Resource Gateway, passa pela ENI governada pelos grupos de segurança e chega ao NLB. O NLB encerra o TLS na porta 443 usando um certificado público do AWS Certificate Manager (ACM) e encaminha a requisição via HTTP na porta 80 para o NGINX Ingress Controller rodando no Amazon EKS, que a roteia para o pod apropriado.

Cenário 3: API REST privada

Para rotear para qualquer API REST rodando dentro da Amazon VPC — como um microsserviço em contêiner — a chamada à API CreateGatewayTarget segue o mesmo padrão dos cenários anteriores. No campo openApiSchema, forneça o schema OpenAPI descrevendo a API REST. No bloco managedVpcResource, forneça o ID da VPC, os IDs das sub-redes e o ID do grupo de segurança.

Após o AgentCore Gateway provisionar o Resource Gateway na VPC, o fluxo de tráfego é o seguinte:

O AgentCore Gateway envia uma requisição HTTPS ao endpoint interno. A zona hospedada privada do Amazon Route 53 resolve o domínio para o Balanceador de Carga de Aplicação (ALB) interno. A requisição entra na VPC de Recurso pelo Resource Gateway, passa pela ENI governada pelos grupos de segurança e chega ao ALB interno. O ALB encerra o TLS na porta 443 usando um certificado público do ACM e encaminha a requisição via HTTP na porta 8000 para o grupo de destino contendo os servidores de backend.

Limpeza de recursos

Para evitar cobranças contínuas, exclua todos os recursos criados durante o processo. Consulte a página de preços do egresso VPC do AgentCore Gateway para referência. Clusters do Amazon EKS, load balancers e endpoints do API Gateway geram cobranças enquanto estão ativos.

Se você seguiu o exemplo no GitHub, execute a seção de limpeza ao final de cada Jupyter Notebook. Se usou o modo gerenciado, excluir o Gateway Target remove automaticamente o Amazon VPC Resource Gateway associado:

aws bedrock-agentcore delete-gateway-target \
  --gateway-identifier <gateway-id> \
  --target-id <target-id>

Conclusão e próximos passos

À medida que os agentes de IA assumem tarefas mais complexas, eles precisam de acesso seguro às ferramentas e serviços que sustentam o negócio — muitos dos quais vivem dentro de redes privadas. O egresso VPC do AgentCore Gateway permite que os agentes alcancem servidores MCP privados, APIs internas, bancos de dados e sistemas on-premises sem expô-los à internet pública.

O modo gerenciado se integra diretamente à VPC existente com configuração mínima. O modo autogerenciado oferece controle granular, mas exige configuração adicional. Ambos roteiam o tráfego por um Resource Gateway que nunca sai da rede AWS.

Como próximos passos, a AWS sugere:

• Identificar uma API interna ou servidor MCP no seu ambiente que se beneficiaria de acesso por agentes de IA
• Revisar a arquitetura Amazon VPC existente para determinar qual modo (gerenciado ou autogerenciado) se encaixa melhor
• Consultar a documentação do Amazon Bedrock AgentCore Gateway para opções adicionais de configuração
• Explorar a documentação do Amazon VPC Lattice Resource Gateway para cenários entre contas
• Explorar padrões de integração avançados nos exemplos no GitHub

Fonte

Configuring Amazon Bedrock AgentCore Gateway for secure access to private resources (https://aws.amazon.com/blogs/machine-learning/configuring-amazon-bedrock-agentcore-gateway-for-secure-access-to-private-resources/)

O que mudou no Bedrock AgentCore Identity

A AWS anunciou uma atualização relevante para quem desenvolve agentes de inteligência artificial com o Amazon Bedrock AgentCore Identity: o serviço agora suporta a troca de token On-Behalf-Of (OBO), um mecanismo que permite a agentes acessarem recursos protegidos em nome de usuários autenticados — tudo isso sem exigir que o usuário passe por múltiplos fluxos de consentimento.

Qual era o problema anterior

Antes dessa atualização, desenvolvedores que precisavam construir agentes capazes de agir em nome de um usuário enfrentavam uma dificuldade prática: era necessário gerenciar fluxos de consentimento separados para cada recurso protegido que o agente precisasse acessar. Isso gerava atrito desnecessário para o usuário final e aumentava a complexidade do lado do desenvolvedor.

Como funciona a troca de token OBO

Com a troca de token OBO, o desenvolvedor pode trocar um token de acesso existente por um novo token com escopo reduzido. Esse novo token carrega tanto a identidade do usuário original quanto a identidade do agente, e é direcionado especificamente ao recurso protegido de destino.

O resultado prático é um acesso just-in-time e com menor privilégio possível — sem solicitar consentimento adicional ao usuário. Ou seja: o agente faz o que precisa fazer, com as permissões certas, sem incomodar o usuário com novas telas de autorização.

Disponibilidade por região

O recurso de troca de token OBO do Amazon Bedrock AgentCore Identity já está em disponibilidade geral (GA) em 14 regiões da AWS:

• US East (Norte da Virgínia)
• US East (Ohio)
• US West (Oregon)
• Canada (Central)
• Asia Pacific (Mumbai)
• Asia Pacific (Seul)
• Asia Pacific (Singapura)
• Asia Pacific (Sydney)
• Asia Pacific (Tóquio)
• Europe (Frankfurt)
• Europe (Irlanda)
• Europe (Londres)
• Europe (Paris)
• Europe (Estocolmo)

Saiba mais

Para explorar os detalhes técnicos e começar a implementar o recurso, a AWS disponibilizou a documentação oficial do Amazon Bedrock AgentCore Identity.

Fonte

Amazon Bedrock AgentCore Identity now supports On-Behalf-Of (OBO) token exchange (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-bedrock-agentcore/)

Por que um proxy MCP serverless importa em produção

Quando agentes de IA se conectam a ferramentas por meio do Protocolo de Contexto de Modelo (MCP), eles ganham acesso a capacidades que vão de consultas a bancos de dados e chamadas de API até operações em arquivos e integrações com serviços de terceiros. Em produção, essas interações precisam de governança adequada, controles e observabilidade alinhados às políticas de segurança da organização.

Isso inclui sanitizar entradas de ferramentas antes que cheguem aos sistemas de backend, gerar trilhas de auditoria em formatos específicos ou redigir dados sensíveis na camada de protocolo. Esses requisitos são moldados por padrões internos de governança, regulamentações do setor e as especificidades de cada ambiente de produção.

A AWS publicou um guia mostrando como implantar um proxy MCP serverless no Amazon Bedrock AgentCore Runtime que fornece exatamente essa camada programável.

O contexto: Gateway, interceptores Lambda e quando o proxy faz mais sentido

O Amazon Bedrock AgentCore Gateway já oferece governança centralizada para integração entre agentes e ferramentas, incluindo descoberta semântica de ferramentas, credenciais gerenciadas e aplicação de políticas. Para organizações que precisam embutir lógica personalizada no caminho de requisição do Gateway, o serviço suporta interceptores Lambda — que permitem executar código de validação, transformação ou filtragem como funções AWS Lambda em cada invocação de ferramenta.

Porém, algumas organizações já investiram em lógica de filtragem MCP personalizada fortemente acoplada a bibliotecas internas ou sistemas de conformidade on-premises. Elas querem reutilizar essa lógica no AgentCore Runtime sem refatorá-la em funções Lambda. Outras operam em ambientes híbridos onde executar controles como um servidor MCP independente oferece mais portabilidade. Nesses casos, um proxy MCP serverless rodando no AgentCore Runtime é um padrão complementar e mais adequado.

O que é o AgentCore Runtime e por que ele serve de base para o proxy

O AgentCore Runtime é um ambiente de computação totalmente gerenciado para implantar agentes de IA e servidores MCP. Ele oferece infraestrutura serverless com escalonamento automático, observabilidade integrada via Amazon CloudWatch e OpenTelemetry, além do AgentCore Identity para autenticação e autorização.

Como o Runtime suporta nativamente o protocolo MCP, ele permite hospedar servidores MCP — incluindo proxies MCP que adicionam controles personalizados ao tráfego. O proxy apresentado no guia é stateless, roda como uma carga de trabalho serverless no Runtime, descobre ferramentas de um servidor MCP upstream na inicialização, re-expõe essas ferramentas com sua lógica personalizada aplicada e encaminha requisições de forma transparente.

Visão geral da arquitetura

A solução envolve três camadas lógicas que trabalham juntas via MCP: o cliente MCP, o proxy MCP no AgentCore Runtime e o servidor MCP upstream. O fluxo de requisições percorre essas camadas em sequência: o cliente envia requisições MCP ao proxy, o proxy aplica a lógica personalizada e encaminha a requisição ao servidor MCP upstream, e o servidor upstream processa a requisição e retorna a resposta pelo mesmo caminho.

O servidor MCP upstream pode ser hospedado em qualquer lugar — no próprio AgentCore Runtime, na infraestrutura da organização ou como serviço de terceiros. No guia publicado pela AWS, o AgentCore Gateway é usado como servidor upstream porque já fornece um endpoint compatível com MCP com alvos registrados, permitindo seguir o passo a passo sem precisar configurar um servidor MCP separado.

Como o proxy MCP funciona internamente

A implementação usa o FastMCP para descobrir ferramentas do servidor MCP upstream na inicialização e encaminhar cada requisição do cliente em tempo de execução. O proxy não define ferramentas próprias e não tem conhecimento prévio do que o servidor upstream expõe.

Quando o processo do proxy inicia, ele envia uma requisição padrão tools/list ao servidor upstream. O servidor retorna o catálogo completo de ferramentas disponíveis. Para cada ferramenta, o proxy registra dinamicamente uma ferramenta FastMCP local com o mesmo nome e descrição. Cada ferramenta é suportada por uma função handler que encaminha requisições tools/call ao servidor upstream e retorna a resposta.

Clientes MCP que se conectam ao proxy veem o mesmo catálogo de ferramentas e obtêm os mesmos resultados como se estivessem se conectando diretamente ao servidor upstream. Como o proxy é um servidor MCP Python padrão que você possui e implanta, é possível inserir lógica personalizada antes de encaminhar uma chamada de ferramenta ou após receber a resposta.

Autorização entre os componentes

A autorização é aplicada de forma independente em cada camada da arquitetura, criando fronteiras de confiança distintas ao longo do fluxo.

Do agente ao proxy MCP

Quando um agente se conecta ao proxy MCP, ele usa o AgentCore Identity para autenticação e autorização. O proxy utiliza as capacidades que o AgentCore Identity oferece, incluindo gerenciamento centralizado de identidades de agentes e armazenamento seguro de credenciais.

Do proxy ao servidor MCP upstream

O proxy precisa se autenticar no servidor MCP upstream ao qual se conecta. O método de autenticação depende dos requisitos do servidor upstream. O AgentCore Identity oferece autorização de entrada para cargas de trabalho hospedadas no AgentCore Runtime por meio de Gerenciamento de Identidade e Acesso da AWS (IAM) usando AWS Signature Version 4 (SigV4) e autorização baseada em Token Web JSON (JWT) usando credenciais de cliente OAuth 2.0.

Para autorização baseada em IAM, o proxy assina requisições usando SigV4 com a função de execução IAM que herda do AgentCore Runtime. O script de implantação concede a essa função permissões bedrock-agentcore:InvokeGateway, com o campo Resource com escopo para o Gateway. O proxy usa a sessão boto3 do runtime para assinar requisições automaticamente.

Para autorização OAuth, o proxy substitui a assinatura SigV4 por um token bearer obtido via concessão de credenciais de cliente OAuth 2.0. O token é armazenado em cache na memória e atualizado automaticamente quando se aproxima da expiração. Cada requisição de saída ao servidor MCP upstream inclui o token como cabeçalho Authorization: Bearer. O projeto no GitHub usa autorização baseada em IAM como método padrão, mas o script de implantação também suporta autorização baseada em JWT.

Do servidor upstream para as ferramentas

O servidor MCP upstream se autentica nas ferramentas downstream usando provedores de credenciais do AgentCore Identity, que gerenciam tokens OAuth 2.0, chaves de API e rotação de credenciais de forma transparente. A autorização de saída opera da mesma forma independentemente de as requisições se originarem do proxy ou de um cliente direto.

Pré-requisitos para a implantação

• Ambiente de desenvolvimento Linux ou macOS com Python 3.12 ou posterior instalado
• Interface de Linha de Comando da AWS (AWS CLI) instalada e configurada com credenciais para um principal AWS IAM com permissões para criar funções IAM, interagir com o Amazon Elastic Container Registry (Amazon ECR) e invocar APIs do Amazon Bedrock AgentCore
• O AgentCore starter toolkit instalado — consulte como começar com o Amazon Bedrock AgentCore starter toolkit em Python
• Docker instalado — a CLI do AgentCore usa Docker para construir a imagem de contêiner
• Um endpoint de servidor MCP upstream — o guia usa um Amazon Bedrock AgentCore Gateway com pelo menos um alvo registrado
• (Opcional, para OAuth) Um pool de usuários do Amazon Cognito com domínio configurado e um cliente de aplicativo que usa concessão de credenciais de cliente com segredo de cliente

Implantando a solução

O processo começa clonando o repositório do GitHub e revisando a estrutura do projeto. Em seguida, o arquivo deploy_config.json deve ser configurado com os valores do ambiente: o endpoint do servidor MCP upstream em gateway_endpoint, a região AWS em region, e opcionalmente o Nome de Recurso Amazon (ARN) do Gateway em gateway_api_id para restringir as permissões IAM a esse recurso específico.

O campo auth_mode determina como o proxy se autentica no servidor upstream — o padrão é "iam" para autenticação baseada em IAM. Para autenticação OAuth, define-se auth_mode como "jwt" e configuram-se os campos do Cognito.

O script automatizado setup_and_deploy.py executa o fluxo completo de implantação em sequência:

• Valida pré-requisitos — verifica se AWS CLI, Python e Docker estão disponíveis e se as credenciais AWS estão configuradas
• Cria uma função de execução IAM com política de confiança que permite ao bedrock-agentcore.amazonaws.com assumir a função, incluindo permissões para invocar o Gateway, gravar no Amazon CloudWatch Logs e extrair imagens do Amazon ECR
• Configura o agente com a CLI do AgentCore executando agentcore configure com o protocolo MCP, apontando para o entrypoint do proxy em mcp_proxy/main.py
• Lança o agente no AgentCore Runtime via agentcore launch, passando o endpoint do servidor upstream como variável de ambiente (GATEWAY_ENDPOINT)

Após a implantação, o status do agente proxy MCP pode ser verificado com agentcore status --agent mcp_proxy. O ARN do agente exibido na saída é usado no cliente de teste para invocar o proxy.

Oportunidades de personalização

Tokenização de dados sensíveis

Argumentos de chamadas de ferramentas podem conter Informações de Identificação Pessoal (PII) que não devem chegar aos sistemas de backend em texto claro. O fluxo de encaminhamento do proxy oferece um ponto de interceptação natural para adicionar tokenização. O código relevante fica na função _make_tool_handler em main.py:

def _make_tool_handler(tool_name: str):
    """Create a tool handler function that forwards calls to the gateway."""
    def handler(**kwargs) -> str:
        # --- Tokenize: scan kwargs for PII and replace with tokens ---
        result = _send_gateway_request(
            "tools/call",
            {"name": tool_name, "arguments": kwargs}
        )
        content = result.get("content", [])
        # --- Detokenize: reverse tokens in content before returning ---
        if content and isinstance(content, list):
            texts = [c.get("text", str(c)) for c in content if isinstance(c, dict)]
            return "\n".join(texts) if texts else json.dumps(result)
        return json.dumps(result)
    return handler

A tokenização pode ser adicionada em dois pontos dentro do closure do handler: antes da chamada a _send_gateway_request, para escanear os valores de kwargs em busca de padrões de PII e substituí-los por tokens reversíveis (consulte o Guia de Tokenização para Melhorar a Segurança de Dados e Reduzir o Escopo de Auditoria na AWS); e após o retorno de _send_gateway_request, para reverter os tokens no conteúdo da resposta antes de devolvê-la ao cliente.

Controle de acesso por ferramenta

É possível restringir quais ferramentas um determinado chamador pode invocar, mesmo que o servidor upstream exponha o catálogo completo. Isso é implementado adicionando uma verificação de política no início da função handler criada por _make_tool_handler. Antes de encaminhar a requisição tools/call ao servidor upstream, o handler avalia a identidade do chamador em relação a uma política de acesso. Se o chamador não estiver autorizado para aquela ferramenta, o handler retorna uma resposta de erro sem contatar o servidor upstream. Também é possível filtrar a resposta de tools/list na função register_gateway_tools para expor apenas as ferramentas que correspondem a uma determinada política.

Limpeza dos recursos

Para evitar cobranças recorrentes, os recursos criados devem ser removidos após os testes. A CLI do AgentCore fornece um comando destroy que remove o agente e seus recursos associados:

agentcore destroy --agent <agent-name> --delete-ecr-repo --force

Em seguida, a política IAM inline e a função de execução devem ser removidas:

aws iam delete-role-policy --role-name <your-MCPProxy-Server-Role> --policy-name <your-Gateway-Access-Policy>
aws iam delete-role --role-name <your-MCPProxy-Server-Role>

Se um AgentCore Gateway foi criado especificamente para este exercício e não é mais necessário, ele também deve ser removido:

agentcore gateway delete-mcp-gateway --name <your-Gateway> --force

Conclusão

O padrão de proxy MCP serverless no AgentCore Runtime oferece uma camada programável onde é possível aplicar lógica personalizada como validação de entrada, logging, limitação de taxa ou enriquecimento de resposta. O proxy é stateless, roda como um contêiner padrão no Runtime e pode ser conectado a qualquer servidor MCP upstream compatível, encadeando múltiplos endpoints ou adicionando lógica de middleware específica para a carga de trabalho.

O código-fonte completo, scripts de implantação e agente de teste estão disponíveis no GitHub. Para saber mais sobre como construir e implantar agentes no AgentCore e usar o framework Strands Agents, a AWS disponibiliza a documentação do Amazon Bedrock AgentCore e o SDK do Strands Agents.

Fonte

Run custom MCP proxies serverless on Amazon Bedrock AgentCore Runtime (https://aws.amazon.com/blogs/machine-learning/run-custom-mcp-proxies-serverless-on-amazon-bedrock-agentcore-runtime/)

O problema de escala no gerenciamento de acesso AWS

À medida que as organizações expandem sua presença na Amazon Web Services (AWS), gerenciar o acesso de forma segura, escalável e eficiente em múltiplas contas se torna um desafio crescente. A abordagem tradicional — criar usuários IAM individuais e atribuir permissões manualmente — não sustenta ambientes corporativos complexos.

Para endereçar esse problema, a AWS oferece o AWS IAM Identity Center, uma solução centralizada para gerenciar o acesso de colaboradores a contas AWS. Ele simplifica a autenticação, reforça a segurança e proporciona uma experiência de login consistente em diferentes ambientes.

O ponto mais poderoso dessa solução, no entanto, está na combinação entre permission sets e session tags — uma dupla que abre caminho para controle de acesso granular e otimização de custos sem aumentar a complexidade operacional.

O que são session tags e por que elas importam

Session tags são atributos dinâmicos que podem ser passados de um provedor de identidade externo para a AWS durante o processo de autenticação. Em vez de definir permissões estáticas por usuário, é possível usar informações contextuais — como departamento, projeto ou perfil de custo — para determinar o que cada sessão pode fazer.

Essa abordagem viabiliza o que a AWS chama de controle de acesso baseado em atributos (ABAC): as permissões são determinadas pelos atributos do usuário, não por regras fixas atribuídas individualmente. O resultado é um modelo mais flexível, onde adicionar um novo colaborador ao grupo correto no provedor de identidade já é suficiente para garantir o acesso adequado — sem necessidade de reconfigurar políticas IAM.

Essa integração também habilita recursos avançados da AWS, como os perfis de uso do AWS Glue e o AWS Systems Manager Session Manager com Run As, permitindo que administradores mapeiem permissões e configurações de runtime dinamicamente com base nos atributos do usuário.

A arquitetura: Microsoft Entra ID + IAM Identity Center

O artigo publicado pela AWS demonstra como session tags derivadas de atributos de grupos no Microsoft Entra ID podem entregar uma funcionalidade equivalente às tags de roles do AWS Identity and Access Management (IAM). A integração usa dois protocolos complementares:

• SAML 2.0 — para autenticação federada entre o Entra ID e o IAM Identity Center
• SCIM — para sincronização automática de usuários e grupos do Entra ID para a AWS

O fluxo de autenticação funciona da seguinte forma: o usuário acessa a aplicação corporativa configurada no Azure, o Microsoft Entra ID realiza o login, e durante a autenticação SAML, atributos do usuário (como departamento, função, centro de custo ou ID de projeto) são enviados como session tags para o IAM Identity Center. A partir daí, esses atributos são usados para aplicar permissões granulares dentro da AWS.

Os usuários podem acessar a AWS pelo console ou pela Interface de Linha de Comando da AWS (AWS CLI), e o acesso é concedido a contas específicas dentro do AWS Organizations.

Pré-requisitos para implementar a solução

Antes de colocar a solução em prática, a AWS lista os seguintes requisitos:

• Uma instância organizacional do IAM Identity Center habilitada
• Um tenant do Microsoft Entra ID (veja o Quickstart para criar um novo tenant)
• Integração SAML e SCIM configurada entre o Entra ID e o IAM Identity Center, conforme descrito na documentação Configure SAML e SCIM com Microsoft Entra ID e IAM Identity Center

Implementando a solução passo a passo

1. Criar um perfil de uso no AWS Glue

O caso de uso demonstrado utiliza os perfis de uso do AWS Glue para controle flexível de custos. Para o exemplo, deve-se criar um perfil chamado developer com as seguintes configurações:

• Número de workers padrão: 20
• Tipo de worker padrão: G.1X
• Tipos de worker permitidos: G.1X, G.2X, G.4X e G.8X

Essas configurações se aplicam tanto a jobs quanto a sessões interativas.

2. Criar um permission set personalizado

Em vez de usar permission sets predefinidos, a AWS recomenda criar um permission set personalizado e anexar as seguintes políticas gerenciadas da AWS:

• AWSGlueConsoleFullAccess
• IAMReadOnlyAccess

Vale destacar que o exemplo usa políticas com permissões amplas por simplicidade didática. Em ambientes de produção, a AWS orienta seguir o princípio do menor privilégio e escopar as permissões adequadamente.

Após criar o permission set, é necessário provisioná-lo em uma conta AWS atribuindo acesso a usuários ou grupos no IAM Identity Center. Mais detalhes estão disponíveis em Atribuir acesso de usuário ou grupo a contas AWS.

3. Configurar atributos de usuário no Microsoft Entra ID

Esta etapa é o coração da solução. A configuração segue o passo 5 da documentação Configure SAML e SCIM com Microsoft Entra ID e IAM Identity Center para habilitar o ABAC.

No portal do Azure, dentro da aplicação corporativa criada, acesse a seção Single sign-on e depois Attributes & Claims. Em seguida, adicione uma nova claim com as seguintes configurações:

• Name: AccessControl:<NomeDoAtributo> — para o exemplo, use AccessControl:glue:UsageProfile
• Claim conditions:
  • User type: Members
  • Source: Attribute
  • Value: developer

O ponto central aqui é que as tags são atribuídas com base na associação de grupo no Entra ID. Isso significa que qualquer usuário que faça login no IAM Identity Center e pertença ao grupo configurado receberá automaticamente o valor da tag aplicado à sua sessão — sem necessidade de configurar tags individualmente por usuário.

Quando o AWS Glue recebe chamadas de API para criação de recursos, o sistema verifica se o usuário ou role está marcado com a chave glue:UsageProfile e o nome do perfil como valor.

Testando e validando a configuração

Com tudo configurado, o teste consiste em fazer login como usuário pelo Microsoft Entra ID acessando https://myapps.microsoft.com/ e verificar a criação de jobs no AWS Glue usando o perfil developer. Um job criado com sucesso dentro das configurações do perfil confirma que as session tags estão sendo aplicadas corretamente.

Validação via AWS CloudTrail

Para confirmar que as tags de sessão estão sendo transmitidas corretamente durante a autenticação, a AWS recomenda verificar o evento AssumeRoleWithSAML no AWS CloudTrail. O caminho é:

• Acessar o console do CloudTrail
• Selecionar Event history
• Filtrar pelo nome de evento AssumeRoleWithSAML
• Abrir um evento relevante e inspecionar a seção requestParameters
• Confirmar que as session tags esperadas aparecem em PrincipalTags

Outros casos de uso: AWS Systems Manager Session Manager

A mesma lógica pode ser estendida para o AWS Systems Manager Session Manager com suporte a Run As para usuários federados.

Por padrão, o Session Manager inicia sessões usando uma conta de sistema gerada automaticamente chamada ssm-user. Para instâncias Linux, é possível configurar sessões para serem executadas como um usuário específico do sistema operacional. Nesse cenário, basta configurar o provedor de identidade para passar o atributo AccessControl:SSMSessionRunAs com o nome de um usuário do SO como valor durante a federação — e a sessão será iniciada com esse usuário automaticamente.

Limpeza dos recursos

Para evitar cobranças desnecessárias após os testes, a AWS orienta remover os recursos criados:

• Remover a instância do IAM Identity Center e limpar a aplicação corporativa no Microsoft Entra
• Excluir o perfil de uso do AWS Glue
• Remover quaisquer outros recursos AWS provisionados durante os testes

Por que essa abordagem importa

A combinação de IAM Identity Center, SAML 2.0 e session tags representa uma evolução significativa na forma como organizações gerenciam acesso em ambientes AWS multi-conta. Ao usar ABAC com atributos vindos de um provedor de identidade externo, as equipes de segurança conseguem manter controle granular sem a complexidade de gerenciar usuários IAM individuais ou roles estáticas.

À medida que os ambientes de nuvem crescem em complexidade, adotar federação de identidade moderna e ABAC via IAM Identity Center é uma das formas mais eficazes de equilibrar segurança rigorosa com agilidade operacional.

Recursos adicionais

• Como usar a permissão PassRole com roles IAM
• Políticas gerenciadas pelo cliente
• Configurando o Run As do AWS Systems Manager Session Manager para usuários federados usando session tags
• Personalizar claims de tokens SAML

Fonte

Access control with IAM Identity Center session tags (https://aws.amazon.com/blogs/security/access-control-with-iam-identity-center-session-tags/)

O que foi anunciado

A AWS anunciou a disponibilidade geral do AWS Glue 5.1 em todas as regiões comerciais e nas regiões AWS GovCloud (US). Com essa expansão, as regiões Ásia-Pacífico (Nova Zelândia), AWS GovCloud (US-West) e AWS GovCloud (US-East) passam a contar com a versão mais recente do serviço.

Para quem não conhece, o AWS Glue é um serviço serverless e escalável de integração de dados. Ele simplifica as tarefas de descoberta, preparação, movimentação e integração de dados provenientes de múltiplas fontes — sem a necessidade de gerenciar infraestrutura.

O que muda na versão 5.1

Atualização dos motores principais

O AWS Glue 5.1 atualiza os principais componentes de execução do serviço. Os destaques são:

• Apache Spark 3.5.6 — motor de processamento distribuído de dados
• Python 3.11 — linguagem de programação amplamente usada em pipelines de dados
• Scala 2.12.18 — linguagem alternativa para desenvolvimento de jobs no Glue

Essas atualizações trazem melhorias de desempenho e segurança para os jobs existentes.

Suporte atualizado a formatos de tabela abertos

A versão 5.1 também atualiza as bibliotecas de formatos de tabela abertos (open table formats), que são fundamentais para arquiteturas de Data Lakehouse modernas:

• Apache Hudi 1.0.2
• Apache Iceberg 1.10.0
• Delta Lake 3.3.2

Novidades do Apache Iceberg formato versão 3.0

O Glue 5.1 introduz suporte ao Apache Iceberg no formato versão 3.0, que adiciona capacidades relevantes para quem trabalha com grandes volumes de dados:

• Valores padrão para colunas (default column values)
• Vetores de exclusão para tabelas merge-on-read (deletion vectors)
• Transformações com múltiplos argumentos (multi-argument transforms)
• Rastreamento de linhagem de linhas (row lineage tracking)

Controle de acesso mais granular com o Lake Formation

Uma das mudanças mais significativas desta versão está na integração com o AWS Lake Formation. O controle de acesso refinado (fine-grained access control) do Lake Formation foi estendido para operações de escrita — tanto Linguagem de Manipulação de Dados (DML) quanto Linguagem de Definição de Dados (DDL) — para Spark DataFrames e Spark SQL.

Anteriormente, esse controle estava disponível apenas para operações de leitura. Com essa expansão, as equipes ganham um nível muito maior de governança sobre quem pode modificar dados e estruturas dentro do lake.

Além disso, o Glue 5.1 adiciona controle de acesso em nível de tabela completa (full-table access control) no Apache Spark para tabelas Apache Hudi e Delta Lake, ampliando ainda mais as opções de segurança disponíveis.

Como começar a usar

O AWS Glue 5.1 já está disponível em todas as regiões comerciais e GovCloud (US) da AWS. É possível começar a utilizá-lo por meio das APIs da AWS, AWS CLI, AWS SDK ou pelo AWS Glue Studio. Para mais detalhes, a AWS disponibiliza a página do produto e a documentação oficial.

Fonte

AWS Glue 5.1 is now available in all AWS Commercial and AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2026/04/aws-glue-5-1-all-govcloud-commercial-regions/)

O Catálogo de Técnicas de Ameaças da AWS ganhou três novas entradas

A equipe de Resposta a Incidentes de Clientes da AWS (AWS CIRT — Customer Incident Response Team) mantém um repositório público chamado Catálogo de Técnicas de Ameaças para AWS (TTC) — um documento vivo que documenta padrões reais de ataque observados em engajamentos de resposta a incidentes. A ideia é simples e valiosa: em vez de guardar esse conhecimento internamente, a AWS o disponibiliza para que qualquer equipe de segurança possa se preparar antes de precisar lidar com um incidente.

A atualização de março de 2026 traz três novas entradas, todas com algo em comum: exploram comportamentos normais e esperados da plataforma para manter acesso não autorizado ou dificultar a recuperação. Veja o que mudou e por que isso importa para o seu ambiente.

O que está sendo observado na prática

Abuso de refresh tokens do Cognito: a persistência silenciosa

O Amazon Cognito usa refresh tokens para que aplicações possam obter novos tokens de acesso sem exigir que o usuário faça login novamente. Por padrão, esses tokens têm validade de 30 dias — e podem ser configurados com validade de até 10 anos.

O problema documentado na entrada T1098.A006 é o seguinte: quando um agente malicioso obtém um refresh token válido — seja por roubo de credenciais, comprometimento de armazenamento no lado do cliente ou abuso de permissões elevadas — ele pode chamar a API cognito-idp:GetTokensFromRefreshToken para gerar novos tokens silenciosamente, mantendo acesso ativo por toda a janela de validade do token.

O detalhe mais perigoso: o usuário legítimo continua usando a aplicação normalmente, porque sua sessão também renova tokens de forma independente. As chamadas do invasor não invalidam a sessão original. Isso cria um acesso paralelo e persistente, completamente invisível para o usuário.

Em ambientes onde a rotação de refresh tokens não está habilitada, o mesmo token pode ser reutilizado indefinidamente dentro do período de validade. Equipes de resposta que acreditaram ter contido o comprometimento inicial já descobriram, semanas depois, que o acesso não autorizado continuava ativo por meio de um refresh token que nem sabiam que existia.

Mitigação recomendada: habilitar a rotação de refresh tokens e reduzir o tempo de vida desses tokens são as ações mais diretas para reduzir esse risco.

Exclusão de imagens AMI: atacando a capacidade de recuperação

As Imagens de Máquina da Amazon (AMI — Amazon Machine Images) são peças centrais em estratégias de recuperação de desastres. Elas contêm o sistema operacional, configurações de aplicação e tudo o que é necessário para reconstruir a infraestrutura. Exatamente por isso, elas se tornaram alvo.

A técnica documentada em T1485.A002 envolve o uso da API ec2:DeregisterImage para remover AMIs e dificultar — ou inviabilizar — a recuperação após um incidente. Por padrão, quando uma AMI é desregistrada, ela simplesmente some. Regras de retenção no Recycle Bin permitem recuperar a imagem, mas apenas se essa funcionalidade tiver sido explicitamente habilitada antes do incidente.

Em casos reais acompanhados pela AWS CIRT, o impacto foi além da perda imediata: os agentes maliciosos também removeram as imagens “golden” — aquelas versões base e validadas que as equipes planejavam usar para restaurar os sistemas. Sem elas, a recuperação se torna muito mais lenta e complexa.

Mitigação recomendada: habilitar regras de retenção no Recycle Bin para AMIs críticas. O TTC fornece orientações detalhadas sobre como detectar e mitigar essa técnica.

Roles adicionais na nuvem: o ponto cego nas políticas de confiança

A entrada T1098.003: Roles Adicionais na Nuvem foi atualizada para incluir o rastreamento da chamada de API UpdateAssumeRolePolicy.

O contexto é relevante: muitas equipes configuram alertas para detectar a criação de novas roles via iam:CreateRole. Para contornar esse monitoramento, agentes maliciosos com permissões suficientes passaram a modificar a política de confiança de uma role já existente usando UpdateAssumeRolePolicy. Com isso, eles adicionam uma conta externa ou uma identidade que controlam como principal confiável — sem criar nenhuma role nova, sem criar nenhuma política nova.

A role existente simplesmente passa a confiar em um novo principal, que o invasor pode assumir quando quiser. Nenhum alarme dispara. Nenhuma anomalia óbvia aparece. A modificação se mistura ao volume normal de operações do AWS Identity and Access Management (IAM), especialmente em ambientes com grande número de roles onde mudanças em políticas de confiança não são monitoradas ativamente.

Mitigação recomendada: incluir UpdateAssumeRolePolicy no monitoramento e configurar alertas para modificações em políticas de confiança de roles existentes.

A tendência que conecta os três casos

Há um fio condutor claro nas três atualizações: agentes maliciosos estão usando comportamentos sutis, padrões ou inesperados para escapar da detecção. Refresh tokens funcionando exatamente como foram projetados. Desregistro de AMIs concluindo sem nenhum bloqueio. Políticas de confiança sendo modificadas por chamadas de API completamente legítimas.

Essas ações provavelmente não dispararão alarmes na maioria dos ambientes — porque parecem operações normais. Essa é uma mudança de postura que merece atenção. Em vez de exploits inéditos ou zero-days, as técnicas catalogadas refletem agentes que entendem como os serviços de nuvem funcionam e usam esse conhecimento para se esconder à vista de todos.

A implicação para equipes de segurança é direta: as estratégias de prevenção e detecção precisam evoluir além do monitoramento de ações obviamente maliciosas. É preciso observar ações legítimas acontecendo em contexto ilegítimo — a chamada de API certa, feita pelo principal errado, no momento errado.

Checklist: o que revisar agora no seu ambiente

A AWS recomenda que as equipes revisem as entradas relevantes do TTC e avaliem se o monitoramento atual conseguiria detectar esses padrões:

• T1098.A006: Abuso de Refresh Token do Cognito — Você está monitorando chamadas de cognito-idp:GetTokensFromRefreshToken vindas de fontes inesperadas? A rotação de refresh tokens está habilitada?
• T1485.A002: Exclusão de Imagem AMI — Você tem regras de retenção no Recycle Bin protegendo suas AMIs críticas? Você saberia se uma AMI de produção fosse desregistrada fora de uma janela de manutenção?
• T1098.003: Roles Adicionais na Nuvem — Modificações em políticas de confiança são rastreadas e geram alertas? Uma conta externa poderia ser adicionada a uma role existente sem que ninguém percebesse?

Todas essas técnicas deixam rastros no AWS CloudTrail, e o TTC fornece orientações específicas sobre o que monitorar e como responder.

Por que o TTC existe e como usá-lo

O Catálogo de Técnicas de Ameaças para AWS parte de uma premissa simples: os padrões observados em engajamentos de resposta a incidentes não deveriam ficar guardados a sete chaves. Quando uma técnica se repete em múltiplos clientes, documentá-la e torná-la pública é a forma mais eficaz de permitir que outras equipes se preparem antes de se encontrarem no meio de um incidente.

A recomendação da AWS é que equipes de segurança revisem o catálogo regularmente, incorporem suas técnicas em exercícios de modelagem de ameaças e o utilizem como vocabulário compartilhado para discutir ameaças específicas de ambientes de nuvem. O catálogo continuará evoluindo conforme novos padrões forem observados em campo.

Recursos adicionais

• Reduza custos com proteção contra exclusão personalizada para snapshots Amazon EBS e AMIs baseadas em EBS
• Proteja seus recursos contra exclusões com o Rule Lock para Recycle Bin
• Como monitorar, otimizar e proteger a autorização máquina a máquina do Amazon Cognito
• AWS CIRT anuncia o lançamento do Catálogo de Técnicas de Ameaças para AWS
• Documentação oficial de refresh tokens do Amazon Cognito
• Amazon GuardDuty

Fonte

What the March 2026 Threat Technique Catalog update means for your AWS environment (https://aws.amazon.com/blogs/security/what-the-march-2026-threat-technique-catalog-update-means-for-your-aws-environment/)