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.
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.
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:
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.
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:
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:
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:
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:
À 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
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:
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
(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:
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 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.
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.
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
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
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.
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.
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
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.
O que as políticas IAM realmente conseguem controlar?
Quem trabalha com segurança na AWS já se deparou com perguntas do tipo: “Consigo usar uma SCP do AWS Organizations para bloquear a criação de security groups que permitem tráfego de 0.0.0.0/0?” ou “Dá para impedir o upload de objetos no S3 que não estejam criptografados?” ou ainda “Posso bloquear funções Lambda com mais de 512 MB de memória alocada?”
Algumas dessas situações são perfeitamente controláveis via políticas Gerenciamento de Identidade e Acesso (IAM). Outras, simplesmente não são. A diferença está em um princípio fundamental da autorização na AWS: as políticas tomam decisões com base nas informações disponíveis no contexto de autorização no momento da chamada de API. Se a informação não estiver nesse contexto, a política não tem como avaliá-la.
A AWS publicou um post detalhado no blog de segurança explicando exatamente como usar o AWS Service Authorization Reference para descobrir o que é ou não controlável por políticas — e o que fazer quando as políticas não são suficientes.
Como funciona o contexto de autorização na AWS
Toda vez que uma requisição é feita à AWS — seja pelo console, pela Interface de Linha de Comando (AWS CLI) ou por um SDK — o serviço que recebe a requisição monta um contexto de requisição com as informações sobre aquela operação. É esse contexto que será usado para avaliar as políticas.
Esse contexto segue o modelo PARC, com quatro componentes:
Principal: quem está fazendo a requisição, incluindo atributos como tags e contexto de sessão
Action (Ação): a operação de API solicitada (por exemplo, s3:PutObject ou ec2:RunInstances)
Resource (Recurso): o recurso AWS de destino, identificado pelo ARN (Nome de Recurso da Amazon)
Condition (Condição): contexto adicional disponível no momento da requisição, como endereço IP, horário, parâmetros de criptografia, status de MFA (Autenticação Multifator) e atributos específicos do serviço
Para ilustrar, veja como seria o contexto de uma requisição de upload de objeto no Amazon S3:
Repare que o contexto inclui o método de criptografia e a classe de armazenamento especificados — e isso significa que uma política pode avaliar esses atributos. Por outro lado, o conteúdo real do arquivo, o tamanho do objeto ou padrões de dados internos não fazem parte do contexto, portanto não podem ser avaliados por políticas IAM.
O Service Authorization Reference: a fonte definitiva
O Service Authorization Reference é a documentação oficial da AWS que lista, para cada serviço, quais ações podem ser controladas por políticas, quais tipos de recursos podem ser alvos dessas ações e — o mais importante — quais condition keys (chaves de condição) estão disponíveis para cada ação.
As chaves de condição se dividem em duas categorias:
Chaves de condição globais: aplicáveis a qualquer serviço AWS (como aws:SourceIp, aws:PrincipalTag, etc.)
Chaves de condição específicas de serviço: definidas para uso com um serviço específico (como s3:x-amz-server-side-encryption ou ec2:InstanceType)
A regra é simples: se a informação que você quer controlar não aparece como uma chave de condição nessa documentação, você não conseguirá controlá-la apenas com políticas IAM.
Como usar o Service Authorization Reference na prática
O processo para verificar se um requisito pode ser atendido por políticas IAM é direto:
Localize a ação que você quer controlar (seja preciso, pois diferentes ações têm diferentes chaves disponíveis)
Examine a coluna de chaves de condição para aquela ação
Se a informação que você precisa não estiver listada como chave de condição, uma política IAM não será suficiente
Como exemplo, ao examinar a ação RunInstances do Amazon Elastic Compute Cloud (Amazon EC2)na seção do EC2 no Service Authorization Reference, é possível ver que diferentes tipos de recursos têm chaves de condição diferentes. Para o tipo de recurso instance*, estão disponíveis chaves como ec2:InstanceType, ec2:EbsOptimized e aws:RequestTag/. Para network-interface*, há chaves como ec2:Subnet, ec2:Vpc e ec2:AssociatePublicIpAddress. O reference completo lista dezenas de chaves de condição para os vários tipos de recursos afetados pelo RunInstances.
Acesso programático ao Service Authorization Reference
Além da documentação em formato legível, a AWS disponibiliza o Service Authorization Reference em formato JSON para automação de fluxos de trabalho de gerenciamento de políticas. Para detalhes sobre a estrutura JSON e definições dos campos, consulte a documentação sobre acesso programático às informações simplificadas de serviços AWS. Desenvolvedores também podem usar o IAM MCP Server para operações IAM com assistentes de IA, gerenciando usuários, funções, políticas e permissões seguindo boas práticas de segurança.
Exemplos práticos: o que é possível controlar com políticas IAM
Exemplo 1: Exigir criptografia AES-256 em uploads no S3
No Service Authorization Reference do Amazon S3, a chave de condição s3:x-amz-server-side-encryption está disponível para a ação s3:PutObject. Isso significa que é possível criar uma política que bloqueie uploads sem criptografia AES-256:
Essa é uma política baseada em recurso que pode ser aplicada diretamente no bucket S3. Ela nega qualquer requisição PutObject que não especifique criptografia AES-256.
Exemplo 2: Restringir tipos de instância EC2 por centro de custo
Com essa política, usuários com a tag CostCenter=Development só podem lançar instâncias T3 (mais econômicas), enquanto usuários de produção têm acesso às famílias M5, C5 e R5. Essa abordagem permite controle de custos dinâmico com base na identidade do solicitante. Atenção: recursos adicionais são necessários na política IAM para lançar instâncias EC2 com sucesso — consulte a documentação de lançamento de instâncias para a lista completa.
Exemplo 3: Controle de acesso granular no DynamoDB por nome de usuário
O Service Authorization Reference do Amazon DynamoDB expõe valores de chave de partição no contexto de autorização para as ações GetItem, PutItem e UpdateItem. Isso permite criar uma política em que cada usuário só acessa os itens onde a chave de partição corresponde ao seu próprio nome de usuário:
Com essa política, se a usuária alice tentar acessar um item com chave de partição bob, a requisição será negada automaticamente.
Cenários que exigem mais do que políticas IAM
Alguns requisitos de segurança simplesmente não podem ser atendidos apenas com políticas IAM — e o Service Authorization Reference é a ferramenta certa para descobrir isso antes de perder tempo tentando.
Cenário 1: Bloquear criação de regras de security group com 0.0.0.0/0 na porta 22
Não há nenhuma chave de condição para blocos CIDR, números de porta ou protocolos. O contexto de autorização simplesmente não inclui essas informações — portanto, políticas IAM não conseguem controlar esses atributos.
Cenário 2: Impedir criação de funções Lambda com mais de 512 MB de memória
Seguindo a mesma metodologia, ao consultar o Service Authorization Reference do AWS Lambda e examinar as chaves de condição disponíveis para a ação CreateFunction com o tipo de recurso function*, encontramos apenas chaves como lambda:CodeSigningConfigArn, lambda:Layer e lambda:VpcIds. Não existe nenhuma chave de condição para alocação de memória, timeout, armazenamento efêmero ou seleção de runtime.
O ponto central é que as políticas IAM são ferramentas poderosas de prevenção, mas a segurança eficaz na AWS não depende de um único controle perfeito — ela vem da combinação inteligente de medidas preventivas, detectivas e responsivas.
O que é o AWS Security Hub e por que fazer um POC?
O AWS Security Hub chegou à disponibilidade geral trazendo uma proposta bastante ambiciosa: centralizar e priorizar os problemas críticos de segurança de toda a sua infraestrutura AWS em um único lugar. O serviço agrega, correlaciona e enriquece sinais nativos de segurança da AWS, transformando-os em insights acionáveis que permitem respostas mais rápidas e eficientes.
Para times que ainda não conhecem o serviço na prática, a AWS oferece um período de teste gratuito que permite montar uma Prova de Conceito (POC) completa — sem grande investimento de tempo ou recursos logo de cara. Este guia percorre as etapas recomendadas para planejar e executar esse POC de forma estruturada.
Entendendo o valor do Security Hub
O Security Hub funciona como uma Plataforma de Proteção de Aplicações Nativas em Nuvem (CNAPP — Cloud-Native Application Protection Platform). Ele ingere sinais de múltiplos serviços AWS e soluções parceiras, consolidando tudo em uma visão única. As fontes de sinal incluem:
Na prática, o serviço entrega quatro capacidades principais em uma solução unificada:
Operações de segurança unificadas: todos os sinais de segurança em uma única visão consolidada, eliminando a necessidade de alternar entre múltiplas ferramentas. Isso inclui visibilidade sobre ambientes AWS, multi-cloud e on-premises.
Priorização inteligente: o Security Hub correlaciona findings analisando relações entre recursos e sinais de diferentes serviços, ajudando a identificar riscos críticos que seriam difíceis de perceber isoladamente.
Insights acionáveis: por meio de análise avançada, o serviço transforma findings correlacionados em insights claros e priorizados, permitindo entender rapidamente o impacto potencial e quais problemas representam maior risco.
Resposta e automação simplificadas: integração com sistemas de gestão de incidentes como Jira Cloud e ServiceNow, permitindo investigar riscos críticos a partir de um único painel, monitorar tendências e automatizar respostas.
Ao planejar seu POC, é importante se familiarizar com as especificações OCSF que o Security Hub utiliza e confirmar que as ferramentas de análise ou sistemas de Informação de Segurança e Gerenciamento de Eventos (SIEM — Security Information and Event Management) que você pretende integrar suportam esse formato.
Definindo critérios de sucesso
Antes de habilitar qualquer serviço, é fundamental estabelecer critérios de sucesso que conectem os resultados do POC aos objetivos do negócio. Alguns exemplos de indicadores-chave de desempenho (KPI — Key Performance Indicator) recomendados:
Consolidação de alertas: medir a redução do esforço de correlação de eventos de segurança, especialmente os processos realizados fora da AWS ou via SIEM.
Melhoria no tempo de resposta: redução do Tempo Médio de Detecção (MTTD — Mean Time to Detect) e do Tempo Médio de Resposta (MTTR — Mean Time to Respond) para findings críticos, além de maior precisão na análise de caminhos de ataque.
Capacidades de automação: avaliar quais partes dos playbooks de resposta a incidentes podem ser automatizadas, incluindo roteamento automático de findings para as equipes corretas via Jira Cloud, ServiceNow ou ferramentas de terceiros.
Classificação de severidade e risco: reduzir o tempo para identificar recursos críticos e lacunas de cobertura afetados por novas vulnerabilidades, ameaças e configurações incorretas.
Após definir os critérios, avalie a maturidade atual do ambiente: quais serviços de segurança já estão habilitados, quais são as cargas de trabalho críticas, e se há restrições organizacionais que possam impactar a implementação.
Maximizando o valor do POC com os períodos de teste gratuito
Para aproveitar ao máximo a avaliação, a AWS recomenda ativar os serviços subjacentes de forma coordenada, sobrepondo os períodos de teste gratuito disponíveis:
Security Hub: 30 dias de teste (capacidades do plano essencial)
GuardDuty: 30 dias de teste (cobre a maioria dos planos de proteção, exceto o GuardDuty Malware Protection)
Security Hub CSPM: 30 dias de teste
Macie: 30 dias de teste
Amazon Inspector: 15 dias de teste
A recomendação é habilitar todos esses serviços simultaneamente para garantir pelo menos duas semanas de cobertura sobreposta, permitindo avaliar as capacidades completas de correlação e priorização de riscos. Se houver limitações, é possível iniciar o POC habilitando apenas o Security Hub CSPM e o Amazon Inspector.
Dica importante: documente as datas de ativação e expiração dos testes. Crie lembretes no calendário e agende os marcos de avaliação do POC enquanto os serviços ainda estiverem ativos.
Configurando o Security Hub
Com os critérios de sucesso definidos, é hora de planejar a configuração. As principais decisões envolvem:
Administrador delegado: a partir da conta de gerenciamento do AWS Organizations, é possível definir um administrador delegado para o Security Hub. A recomendação da Arquitetura de Referência de Segurança AWS (AWS SRA) é usar o mesmo administrador delegado em todos os serviços de segurança para uma governança consistente.
Contas e regiões em escopo: definir quais contas e regiões AWS terão o Security Hub habilitado.
Integrações com serviços AWS: além das capacidades principais de CSPM e gerenciamento de vulnerabilidades, o Security Hub integra sinais de GuardDuty e Macie.
Integrações com terceiros: para gestão de tickets, o serviço integra com Jira Service Management Cloud e ServiceNow. Parceiros que já suportam ou pretendem suportar o esquema OCSF incluem Dynatrace, Netskope, Orca Security, SentinelOne, Sumo Logic, Tines, Wiz, entre outros como Arctic Wolf, CrowdStrike, DataBee, Datadog, Fortinet, IBM, Palo Alto Networks, Rapid7, Securonix, Sophos, Splunk, Trellix e Zscaler. Parceiros de serviços como Accenture, Caylent, Deloitte, IBM e Optiv também podem ajudar na adoção.
Estimativa de custos: utilize a Ferramenta de Estimativa de Custos do Security Hub para obter uma estimativa pré-habilitação com base no gasto atual em Amazon Inspector, Security Hub CSPM e GuardDuty.
Preparando o deployment
Com a configuração definida, o próximo passo é preparar o projeto com um plano estruturado. A linha do tempo sugerida é:
Antes da habilitação: validar a configuração dos serviços de segurança base (GuardDuty, Amazon Inspector, Security Hub CSPM e Macie) e obter as aprovações necessárias para o teste gratuito.
Dia 0: habilitar o serviço, familiarizar-se com o layout do Security Hub e iniciar o treinamento da equipe de segurança.
Semana 1: validar a cobertura desejada de detecção de ameaças, gerenciamento de vulnerabilidades e gerenciamento de postura em todas as contas e regiões.
Semana 2: conectar às ferramentas de Gerenciamento de Serviços de TI (ITSM — IT Service Management) e iniciar a criação de automações para cargas de trabalho e recursos críticos.
Semana 3: executar um exercício de simulação (tabletop exercise) em resposta a um finding de exposição selecionado.
Semana 4: analisar tendências de ameaças e exposições desde o dia 1 até a semana 4.
O Security Hub se integra ao AWS Organizations para facilitar o gerenciamento centralizado. O mínimo necessário para aproveitar as capacidades de correlação é habilitar o Security Hub CSPM e o Amazon Inspector. A combinação desses dois serviços fornece a telemetria necessária para o mecanismo de correlação do Security Hub e para os findings de exposição.
O Security Hub oferece os planos Essentials, Threat Analytics e Extended. Após a habilitação, os findings de exposição são criados e analisados imediatamente — porém, pode levar até 6 horas para que um finding de exposição para um recurso específico seja gerado.
Validando o deployment
A etapa final é confirmar que o Security Hub está configurado corretamente e avaliar os resultados em relação aos critérios de sucesso definidos no início:
Validar políticas: verificar se as permissões para gerenciar contas membro e as restrições regionais estão configuradas corretamente.
Validar integrações: confirmar que os tickets no ServiceNow ou Jira Cloud estão sendo criados corretamente, verificando se há um ID de ticket associado aos findings no console do Security Hub.
Avaliar critérios de sucesso: determinar se os objetivos definidos no início do projeto foram alcançados.
Conclusão
O AWS Security Hub oferece uma abordagem estruturada para unificar e priorizar operações de segurança em nuvem. Seguindo as fases descritas — definição de critérios de sucesso, configuração, preparação e validação — é possível realizar uma avaliação completa aproveitando os períodos de teste gratuito sem incorrer em custos significativos.
Durante o POC, vale manter o foco nos critérios predefinidos, mas também estar aberto a benefícios ou desafios inesperados que possam surgir. Para dúvidas técnicas, o time de conta AWS pode apoiar durante todo o processo.
A AWS anunciou uma melhoria importante no Serviço de Gerenciamento de Chaves (KMS): a partir de agora, o serviço registra automaticamente o último uso criptográfico de cada chave KMS. Isso elimina a necessidade de consultar e analisar logs manualmente para descobrir quando uma chave foi utilizada pela última vez.
Para equipes de segurança e conformidade, essa visibilidade é um ganho real no dia a dia. Antes, identificar se uma chave estava ativa ou abandonada exigia cruzar dados do AWS CloudTrail de forma manual — um processo trabalhoso e sujeito a erros.
O que é possível visualizar
Com o novo recurso, é possível consultar, diretamente pelo console de gerenciamento do AWS KMS ou via API, as seguintes informações sobre cada chave:
O timestamp da última operação criptográfica realizada;
O tipo de operação que foi executada;
O ID do evento no AWS CloudTrail associado àquela operação.
Casos de uso práticos
A AWS destaca três aplicações diretas para esse novo recurso:
Identificar chaves sem uso para limpeza e organização do ambiente;
Confirmar que chaves críticas estão sendo usadas ativamente, o que é essencial para auditorias de conformidade;
Rastrear como as chaves são utilizadas em conjunto com o AWS CloudTrail, facilitando investigações e revisões de segurança.
Proteção contra exclusão acidental
Além da visibilidade, a atualização traz uma nova condition key chamada kms:TrailingDaysWithoutKeyUsage. Ela permite criar políticas que protegem chaves usadas recentemente contra exclusão acidental — ou seja, é possível configurar uma regra que impeça a remoção de qualquer chave que tenha sido utilizada nos últimos N dias.
Esse tipo de proteção baseada em política reduz o risco operacional em ambientes onde múltiplas equipes gerenciam chaves, tornando o controle mais robusto sem depender apenas de processos manuais.
Disponibilidade
O recurso já está disponível em todas as regiões AWS onde o KMS opera, incluindo as regiões comerciais globais, as regiões AWS GovCloud (US) e as regiões AWS China. Para mais detalhes técnicos, a documentação oficial traz um guia completo sobre como determinar o uso passado de uma chave KMS no AWS KMS Developer Guide.
