Category: Uncategorized

  • Identifique chaves AWS KMS não utilizadas e evite exclusões acidentais

    Gerenciar chaves KMS em escala é um desafio real

    Conforme o uso da Amazon Web Services (AWS) cresce dentro de uma organização, o gerenciamento de chaves criptográficas se torna cada vez mais complexo. Seja com um punhado de chaves ou com milhares distribuídas por múltiplas contas e regiões, existe sempre a necessidade de auditar o uso dessas chaves — seja para atender requisitos de conformidade, avaliar riscos ou reduzir custos operacionais.

    O problema é que descobrir quais chaves estão ativas e quais ficaram paradas sem uso costumava ser um processo trabalhoso. Para resolver isso, o Serviço de Gerenciamento de Chaves da AWS (AWS KMS) lançou a API GetKeyLastUsage, uma nova funcionalidade que permite identificar rapidamente quando cada chave foi usada pela última vez em uma operação criptográfica. Para saber mais, consulte a documentação Determine past usage of a KMS key.

    Como era feita a auditoria antes

    Antes desse lançamento, a principal forma de auditar o uso de chaves era por meio dos logs do AWS CloudTrail. O CloudTrail registra todas as operações criptográficas por padrão, então os dados estavam disponíveis — o problema era transformar esse volume de dados em informação acionável.

    Para os últimos 90 dias, o histórico de eventos do CloudTrail tornava o processo viável. Para períodos mais longos, era necessário criar uma trilha dedicada, entregar os logs para o Amazon Simple Storage Service (Amazon S3) para retenção de longo prazo e, em seguida, consultar esses logs com ferramentas como o Amazon Athena. Um fluxo complexo para uma pergunta relativamente simples: “quando essa chave foi usada pela última vez?”

    O que a API GetKeyLastUsage oferece

    O AWS KMS agora disponibiliza uma forma direta de consultar quando uma chave foi utilizada pela última vez em operações criptográficas. Essa informação também pode ser visualizada pelo console de gerenciamento da AWS e pela Interface de Linha de Comando da AWS (AWS CLI).

    A API GetKeyLastUsage retorna a data e hora da operação criptográfica mais recente realizada com uma chave KMS — sem precisar vasculhar logs do CloudTrail. Os dados retornados incluem:

    • Data e hora da última operação com a chave
    • Tipo de operação realizada
    • ID do evento no CloudTrail
    • ID da requisição no KMS

    Essa informação está disponível para todas as chaves gerenciadas pelo cliente e chaves gerenciadas pela AWS, independentemente do tipo de chave, origem, armazenamento ou tipo de uso.

    Além disso, é possível restringir a desativação ou o agendamento de exclusão de uma chave que foi usada recentemente, incorporando essas informações de uso como condição na política da chave KMS.

    Entendendo o período de rastreamento

    Antes de depender das informações de último uso de uma chave, é fundamental compreender o conceito de período de rastreamento. Esse é o ponto de partida a partir do qual o AWS KMS passou a registrar a atividade criptográfica de cada chave. Para a maioria das regiões da AWS, o rastreamento teve início em 23 de abril de 2026.

    Isso é crítico: a ausência de informações de uso pode significar que a chave nunca foi usada ou que ela simplesmente não foi usada desde o início do rastreamento. Por exemplo, uma chave criada em 1º de janeiro de 2026 pode ter sido amplamente utilizada entre janeiro e 22 de abril — mas essas operações não estarão refletidas nos dados da API. Portanto, não é possível concluir que uma chave está em desuso apenas porque não há registros de uso após o início do rastreamento.

    Como visualizar as informações de uso

    Não é necessário habilitar nada nem fazer configurações adicionais para acessar as informações de último uso das chaves KMS. Basta acessar o console do KMS, selecionar uma chave em Customer-managed keys e verificar o campo Last used nas configurações gerais. Ao clicar no link exibido nesse campo, é possível ver detalhes adicionais como o timestamp, o tipo de operação e o ID do evento no CloudTrail.

    A coluna Last used também é exibida ao tentar agendar a exclusão de uma chave, permitindo tomar decisões mais informadas antes de confirmar a ação.

    Casos de uso práticos

    Caso de uso 1: Otimização de custos com limpeza de chaves não utilizadas

    Organizações que gerenciam milhares de chaves KMS distribuídas por múltiplas contas frequentemente acumulam chaves que nunca foram usadas ou que caíram em desuso. A limpeza dessas chaves reduz custos operacionais e diminui a superfície de segurança exposta. A API GetKeyLastUsage facilita esse processo ao indicar quais chaves não realizaram operações criptográficas recentemente.

    No entanto, é importante ter cautela: o fato de uma chave não ter sido usada recentemente não significa que ela pode ser excluída com segurança. Uma chave pode ficar meses sem atividade e ainda ser necessária para descriptografar arquivos em cenários de conformidade ou recuperação de desastres.

    Um exemplo claro disso são os volumes do Amazon Elastic Block Store (Amazon EBS). Esses volumes interagem com chaves KMS apenas em eventos específicos do ciclo de vida, como criação, anexação e desanexação. Após um volume ser anexado a uma instância do Amazon Elastic Compute Cloud (Amazon EC2), a chave de criptografia de dados em texto simples fica armazenada em cache no hardware do Nitro Card — e todas as operações subsequentes de leitura e gravação usam essa chave em cache, sem nenhuma chamada adicional à API do KMS.

    Isso significa que um volume de produção rodando continuamente por meses ou anos pode não mostrar nenhuma atividade KMS durante todo esse período — mas ainda depende completamente da chave para qualquer operação futura, como reinicializações de instância, reanexação de volume ou recuperação de desastres. Se a chave for excluída, a chave de criptografia de dados armazenada com o volume nunca poderá ser descriptografada novamente, tornando os dados do volume permanentemente inacessíveis.

    A recomendação é: ao identificar uma chave potencialmente não utilizada, primeiro desative-a usando o comando DisableKey e monitore suas aplicações e serviços em busca de falhas de criptografia ou descriptografia. Antes de excluir qualquer chave KMS, verifique se não há volumes EBS ou snapshots associados a ela, independentemente de quando ocorreu a última chamada à API do KMS.

    A AWS também disponibiliza um mecanismo para criar um alarme no CloudWatch que notifica quando uma chave com exclusão pendente está sendo acessada, dando a oportunidade de cancelar a exclusão antes que os dados se tornem inacessíveis.

    Script para identificar chaves não utilizadas

    A seguir, um exemplo de script que percorre todas as chaves gerenciadas pelo cliente em uma conta e recupera a data de último uso de cada uma via API GetKeyLastUsage. O script aceita dois parâmetros opcionais: um limite em dias e uma região da AWS. Ele filtra e exibe apenas as chaves que não foram usadas dentro do período especificado, apresentando os resultados em uma tabela com o nome da chave, ID da conta, região e data de último uso.

    Exemplo para verificar todas as chaves não usadas nos últimos 180 dias na região us-east-1:

    ./script.sh 180 us-east-1
    #!/bin/bash
    DAYS=${1:-90}
    REGION=${2:-$(aws configure get region)}
    CUTOFF=$(date -v-${DAYS}d +%s 2>/dev/null || date -d "-${DAYS} days" +%s)
    ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
    
    printf "Showing keys not used in the last %s days (Region: %s)\n\n" "$DAYS" "$REGION"
    printf "%-50s %-15s %-20s %-15s\n" "Key Name" "Account ID" "Region" "Last Usage Date"
    printf "%.0s-" {1..100}
    printf "\n"
    
    for key_id in $(aws kms list-keys --region $REGION --query 'Keys[*].KeyId' --output text); do
        key_manager=$(aws kms describe-key --region $REGION --key-id $key_id --query 'KeyMetadata.KeyManager' --output text)
        if [ "$key_manager" = "CUSTOMER" ]; then
            last_usage=$(aws kms get-key-last-usage --region $REGION --key-id $key_id)
            timestamp=$(echo $last_usage | jq -r '.KeyLastUsage.TimeStamp // empty')
            if [ -z "$timestamp" ]; then
                last_epoch=0
            else
                last_epoch=$(date -jf "%Y-%m-%dT%H:%M:%S" "$(echo $timestamp | cut -d. -f1)" +%s 2>/dev/null || date -d "$timestamp" +%s)
            fi
            if [ "$last_epoch" -lt "$CUTOFF" ]; then
                key_alias=$(aws kms list-aliases --region $REGION --key-id $key_id --query 'Aliases[0].AliasName' --output text)
                key_name=${key_alias:-$key_id}
                [ "$key_name" = "None" ] && key_name=$key_id
                if [ -z "$timestamp" ]; then
                    tracking_date=$(echo $last_usage | jq -r '.TrackingStartDate' | cut -d'T' -f1)
                    last_used="${tracking_date}*"
                else
                    last_used=$(echo $timestamp | cut -d'T' -f1)
                fi
                printf "%-50s %-15s %-20s %-15s\n" "$key_name" "$ACCOUNT_ID" "$REGION" "$last_used"
            fi
        fi
    done
    
    printf "\n* = No operations performed since tracking started\n"

    Caso de uso 2: Prevenção de exclusões acidentais com controles de política

    Exclusões acidentais de chaves KMS são um risco real nas organizações. Uma chave pode ser excluída porque alguém acredita que ela não está mais em uso — e só depois se descobre que aplicações ou workloads críticos dependiam dela. O resultado são falhas de acesso a dados, indisponibilidade de aplicações e procedimentos de recuperação de emergência.

    Para evitar esse cenário, é possível usar a chave de condição kms:TrailingDaysWithoutKeyUsage nas políticas de chave KMS, bloqueando automaticamente a exclusão ou desativação de chaves usadas recentemente. Veja como configurar isso no console do AWS KMS:

    1. Acesse o console do AWS KMS e selecione Customer managed keys no painel de navegação.
    2. Selecione a chave que deseja proteger.
    3. Na aba Key policy, clique em Edit.
    4. No editor de política, adicione o seguinte bloco:
    {
      "Sid": "PreventDeletionOfRecentlyUsedKeys",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "kms:ScheduleKeyDeletion",
        "kms:DisableKey"
      ],
      "Resource": "*",
      "Condition": {
        "NumericLessThanEquals": {
          "kms:TrailingDaysWithoutKeyUsage": "365"
        }
      }
    }

    Essa política bloqueia a exclusão ou desativação de qualquer chave que tenha sido usada nos últimos 365 dias. O limite pode ser ajustado conforme as necessidades da organização. Para mais informações sobre essa chave de condição, consulte a documentação de kms:TrailingDaysWithoutKeyUsage.

    Considerações importantes antes de excluir uma chave

    Ao revisar chaves para possível exclusão, é essencial ter em mente os seguintes pontos:

    • A exclusão de uma chave é irreversível e torna os dados criptografados com ela irrecuperáveis.
    • A AWS impõe um período de espera de 7 a 30 dias antes da exclusão ser efetivada. Durante esse tempo, monitore tentativas de uso e cancele a exclusão se necessário.
    • Exclua uma chave somente se tiver certeza de que nenhum dado foi ou será criptografado com ela.
    • Considere desativar a chave primeiro para testar o impacto da sua indisponibilidade antes de partir para a exclusão definitiva.
    • O CloudTrail continua sendo a fonte autoritativa de auditoria, pois fornece o histórico completo de quem fez cada requisição e com quais parâmetros. A GetKeyLastUsage informa rapidamente quando e qual operação ocorreu, mas o CloudTrail mostra o contexto completo. Saiba mais sobre registro de chamadas à API do KMS com o CloudTrail.

    Conclusão

    A API GetKeyLastUsage representa um avanço significativo nas capacidades de gerenciamento do ciclo de vida de chaves KMS. Ela oferece acesso imediato a dados de uso que antes só estavam disponíveis mediante consultas complexas ao CloudTrail. Para equipes que gerenciam grandes volumes de chaves, isso simplifica auditorias, reduz riscos de exclusões acidentais e facilita a otimização de custos.

    O ponto de partida é simples: acesse o console do AWS KMS e verifique o campo Last used nas chaves gerenciadas pelo cliente e nas chaves gerenciadas pela AWS. Para auditorias mais amplas, integre a API aos scripts de automação existentes usando os exemplos de AWS CLI apresentados aqui.

    Fonte

    Identify unused AWS KMS keys and prevent accidental key deletions (https://aws.amazon.com/blogs/security/identify-unused-aws-kms-keys-and-prevent-accidental-key-deletions/)

  • Novas capacidades do Amazon Bedrock AgentCore Gateway para MCP em produção

    Um único ponto de entrada para servidores MCP corporativos

    Quando uma organização começa a escalar o uso de servidores Protocolo de Contexto de Modelo (MCP) em produção, surgem desafios sérios: controle de acesso granular, visibilidade sobre quais equipes usam quais ferramentas, proteção contra vazamento de dados e gerenciamento centralizado de credenciais. Sem uma solução centralizada, cada servidor MCP precisa resolver esses problemas por conta própria.

    O Amazon Bedrock AgentCore Gateway foi criado exatamente para resolver esse cenário. Ele atua como intermediário entre os servidores MCP e os clientes que os consomem, centralizando credenciais, observabilidade e conectividade segura em um único ponto confiável. A AWS anunciou recentemente uma expansão significativa desse serviço com novas capacidades voltadas para implantações MCP em ambientes corporativos.

    As novidades cobrem: suporte estendido ao esquema de ferramentas MCP, prompts MCP e recursos MCP como primitivos de primeira classe, listagem dinâmica para descoberta em tempo de execução, streaming e gerenciamento de sessões para interações em tempo real, elicitação para solicitações de entrada durante a execução, e troca de tokens OAuth 2.0 on-behalf-of para autenticação delegada. Exemplos práticos estão disponíveis no repositório de amostras no GitHub.

    Como o AgentCore Gateway centraliza a governança

    Sem um gateway centralizado, cada servidor MCP construído pela organização precisa lidar individualmente com credenciais, aplicação de políticas, conectividade privada e logs. O servidor MCP de revisão de contratos do time jurídico, o de recuperação de dados do time financeiro e o de resposta a incidentes do time de operações — todos carregam o mesmo peso de infraestrutura. O time de segurança precisa revisar cada servidor separadamente, os desenvolvedores aguardam aprovações e ninguém tem uma visão unificada do uso da infraestrutura MCP.

    O AgentCore Gateway elimina essa duplicação ao estabelecer um ponto de entrada único para todo o tráfego MCP. Cada equipe cuida apenas da lógica de negócio do seu servidor; o gateway trata do restante. Ele agrega capacidades de diferentes tipos de destino, incluindo servidores MCP, APIs REST, funções AWS Lambda e outros.

    Entre os recursos de governança já disponíveis no AgentCore Gateway, destacam-se:

    Primitivos MCP como cidadãos de primeira classe

    O AgentCore Gateway passa a funcionar como um único endpoint MCP que agrega capacidades de todos os servidores MCP da organização. Os clientes enxergam um catálogo unificado de ferramentas, uma biblioteca de prompts e um namespace de recursos — sem precisar gerenciar 20 conexões separadas.

    O gateway suporta os três primitivos MCP: ferramentas, prompts e recursos. As definições de ferramentas incluem um outputSchema opcional para definir a estrutura de saída esperada e anotações que descrevem propriedades comportamentais, como se a ferramenta é somente leitura ou destrutiva. O gateway também suporta os métodos MCP completos: tools/list, tools/call, prompts/list, prompts/get, resources/list, resources/read e resources/templates/list.

    No modo de listagem padrão, o AgentCore Gateway descobre e armazena em cache as ferramentas, prompts e recursos dos servidores MCP conectados. Esse cache é atualizado implicitamente sempre que se chama CreateGatewayTarget ou UpdateGatewayTarget, e pode ser atualizado explicitamente com a API SynchronizeGatewayTargets. Quando os clientes fazem chamadas de listagem, o gateway responde diretamente do cache. A interação real com o servidor MCP só ocorre durante operações de invocação: tools/call, prompts/get e resources/read.

    Ferramentas e prompts retornados pelo gateway recebem o prefixo do nome do destino no formato targetName___. URIs de recursos são retornados sem prefixo — o URI original do servidor MCP é repassado diretamente. Um ponto de atenção importante: como os URIs de recursos não são validados pelo gateway, é preciso ter cuidado com destinos não confiáveis, pois um servidor MCP comprometido poderia retornar URIs apontando para endpoints internos ou caminhos do sistema de arquivos local.

    Listagem dinâmica para controle de acesso por usuário

    Alguns servidores MCP personalizam suas capacidades por usuário. Um servidor com controle de permissões pode expor a ferramenta approve_expense apenas para gerentes, ou um servidor multi-tenant pode disponibilizar ferramentas compatíveis com HIPAA somente para clientes de saúde. A listagem dinâmica permite preservar esse controle de acesso no lado do servidor, mesmo roteando pelo AgentCore Gateway.

    Ao criar um destino, é possível escolher entre dois modos de listagem: padrão e dinâmico.

    • Modo padrão: o gateway invoca o servidor MCP durante CreateGatewayTarget ou UpdateGatewayTarget para descobrir e armazenar em cache ferramentas, prompts e recursos. Chamadas de listagem são respondidas diretamente do cache.
    • Modo dinâmico: o gateway não invoca o servidor durante a criação ou atualização do destino. As chamadas de listagem são encaminhadas em tempo real ao servidor MCP, usando a identidade do usuário que está fazendo a chamada.

    Em ambos os modos, operações de invocação como tools/call, prompts/get e resources/read são roteadas diretamente ao servidor MCP de destino.

    Imagem original — fonte: Aws

    Essa arquitetura dual também oferece flexibilidade para multi-tenancy e controle de acesso granular (FGAC). Para o modo dinâmico, o controle de acesso pode ser gerenciado diretamente no servidor MCP, já que as operações de listagem são executadas sob a identidade do usuário final. Vale observar que, no modo dinâmico, os primitivos não são indexados no gateway, o que significa que a capacidade de busca semântica de ferramentas não pode ser utilizada.

    Streaming, gerenciamento de sessões e elicitação

    Muitos fluxos de trabalho MCP corporativos vão além de simples chamadas de requisição-resposta. Um servidor MCP pode precisar transmitir atualizações de progresso enquanto gera um relatório, pausar no meio da execução para pedir aprovação do usuário antes de uma ação sensível, ou manter contexto ao longo de uma conversa com múltiplos passos. O AgentCore Gateway agora suporta transporte HTTP com streaming, gerenciamento de sessões MCP e elicitação.

    HTTP com Streaming

    Sem streaming, uma chamada de ferramenta que leva 45 segundos não retorna nada até o final. Com streaming, o usuário vê eventos de progresso em tempo real. Quando um cliente envia uma requisição tools/call com Accept: application/json, text/event-stream, o AgentCore Gateway abre um stream SSE (Eventos Enviados pelo Servidor) e encaminha eventos do servidor MCP em tempo real, incluindo notificações de progresso, mensagens de log e o resultado final da ferramenta. Clientes que enviam apenas Accept: application/json continuam recebendo uma única resposta JSON, preservando compatibilidade retroativa.

    Para habilitar o streaming, basta configurar o bloco enableResponseStreaming na chamada de API CreateGateway ou UpdateGateway:

    "protocolConfiguration": {
      "mcp": {
        "streamingConfiguration": {
          "enableResponseStreaming": true
        }
      }
    }

    Um ponto de atenção: o AgentCore Gateway determina o código de status HTTP a partir do primeiro evento do stream. Se ocorrer um erro no meio do stream, ele é entregue como um objeto de erro JSON-RPC dentro de um frame SSE, e não como um código de status HTTP.

    Gerenciamento de Sessões

    O gerenciamento de sessões introduz fluxos de trabalho com múltiplos turnos ao AgentCore Gateway. Quando as sessões são habilitadas, o gateway gera um Mcp-Session-Id na primeira requisição de inicialização e o retorna como cabeçalho de resposta. O cliente inclui esse cabeçalho nas requisições subsequentes, permitindo que o gateway rastreie interações, mantenha mapeamentos para sessões de servidores MCP downstream e correlacione requisições de elicitação entre chamadas de ferramentas.

    Para habilitar sessões, adiciona-se um bloco sessionConfiguration na chamada de API CreateGateway ou UpdateGateway. O tempo limite de sessão pode ser configurado de 15 minutos a 8 horas, com padrão de 1 hora:

    "protocolConfiguration": {
      "mcp": {
        "sessionConfiguration": {
          "sessionTimeoutInSeconds": 3600
        }
      }
    }

    As sessões são escopadas ao usuário autenticado. O gateway deriva a identidade do usuário a partir do contexto de autorização — token JWT bearer para ingresso OAuth ou credenciais IAM para ingresso AWS_IAM — e valida que cada requisição dentro de uma sessão se origina do mesmo usuário, ajudando a prevenir sequestro de sessão. O gateway retorna HTTP 400 se receber uma requisição sem o cabeçalho Mcp-Session-Id, e HTTP 404 para sessões expiradas ou inexistentes.

    Elicitação

    A elicitação permite que servidores MCP por trás do AgentCore Gateway pausem a execução e solicitem entrada do usuário final. Isso é especialmente valioso para operações de alto risco que exigem confirmação explícita do usuário, coleta de dados estruturados ou autenticação fora de banda antes de prosseguir.

    O AgentCore Gateway suporta três modos de elicitação:

    • Modo formulário: o servidor MCP envia um JSON Schema descrevendo os campos necessários, e o cliente renderiza um formulário para o usuário preencher.
    • Modo URL: o servidor envia uma URL que o cliente abre para o usuário — tipicamente uma tela de consentimento OAuth ou um fluxo de aprovação externo.
    • Modo exceção URL: o servidor retorna um URLElicitationRequiredError contendo uma URL, solicitando que o cliente redirecione o usuário e tente novamente após a conclusão do fluxo externo.

    A elicitação requer que tanto o streaming quanto as sessões estejam habilitados no gateway. O AgentCore Gateway respeita a negociação de capacidades — ele só declara suporte à elicitação para um servidor MCP downstream quando o cliente conectado também declarou suporte durante a inicialização. O gateway também suporta múltiplas elicitações ativas por sessão, permitindo que chamadas de ferramentas concorrentes tenham cada uma sua própria elicitação pendente.

    Troca de tokens OAuth 2.0 on-behalf-of

    Quando agentes precisam acessar recursos downstream em nome de usuários autenticados, o AgentCore Gateway suporta troca de tokens OAuth 2.0 on-behalf-of (OBO) por meio do AgentCore Identity. Isso habilita um modelo de autenticação zero-trust onde a identidade original do usuário é preservada e propagada em cada salto da cadeia de requisições, enquanto cada camada recebe um token escopado precisamente para sua audiência pretendida.

    O fluxo funciona assim: o cliente MCP se autentica no AgentCore Gateway com JWT A, escopado para a audiência do gateway (aud: gw). Quando o gateway precisa chamar um servidor MCP downstream, ele chama o AgentCore Identity para trocar JWT A por JWT B, agora escopado para a audiência do servidor MCP (aud: mcp). Se o servidor MCP precisar chamar uma API ainda mais downstream, pode usar GetResourceOAuth2Token para obter JWT C escopado para essa API (aud: api). Em cada salto, a identidade original do usuário (sub: X) é mantida, permitindo que serviços downstream apliquem autorização granular por usuário sem disparar fluxos de consentimento adicionais.

    O AgentCore Identity atua como o broker central de tokens para todo esse fluxo. Ele fornece um cofre seguro de tokens para armazenar credenciais OAuth e segredos de cliente, além de suportar identidade de carga de trabalho para autenticação serviço a serviço usando identidade de carga de trabalho AWS em vez de segredos de longa duração. Suporta troca de tokens padrão (RFC 8693) ou concessão de autorização JWT (RFC 7523), dependendo do provedor de identidade.

    Adoção incremental sem quebrar o que já funciona

    Com essas novidades, é possível construir fluxos de trabalho agênticos com múltiplos turnos com streaming de progresso em tempo real, gates de aprovação humana que pausam e retomam a execução, e propagação de identidade zero-trust — tudo por meio de um único endpoint gerenciado. Sem stores de sessão customizados, sem infraestrutura de streaming manual, sem credenciais de conta de serviço compartilhadas.

    Para começar, a AWS recomenda consultar a documentação do Amazon Bedrock AgentCore Gateway para detalhes de configuração de cada recurso. Para exemplos práticos, o repositório de amostras no GitHub é o ponto de partida. Quem já executa servidores MCP por trás do AgentCore Gateway pode adotar essas capacidades de forma incremental, sem alterações nas configurações existentes do gateway ou dos destinos.

    Fonte

    Extending MCP support for Amazon Bedrock AgentCore Gateway (https://aws.amazon.com/blogs/machine-learning/extending-mcp-support-for-amazon-bedrock-agentcore-gateway-2/)

  • Amazon SageMaker agora suporta limites de permissões para conformidade com SCP

    O que mudou no SageMaker Unified Studio

    A AWS anunciou uma novidade importante para equipes que operam em ambientes corporativos com políticas de segurança rígidas: o Amazon SageMaker Unified Studio passou a suportar limites de permissões (permissions boundaries) personalizados do Controle de Acesso e Identidade (IAM). Com isso, organizações que utilizam Políticas de Controle de Serviço (SCP) e exigem que todas as funções IAM sejam criadas com um limite de permissões definido podem adotar o SageMaker Unified Studio sem precisar flexibilizar sua postura de segurança.

    Antes dessa atualização, esse tipo de requisito era um obstáculo real: a criação de projetos no SageMaker Unified Studio provisionava funções IAM sem respeitar automaticamente as SCPs corporativas, o que forçava administradores a intervir manualmente ou a abrir exceções nas políticas — algo que muitas equipes de segurança simplesmente não aceitam.

    Como funciona na prática

    Quando um usuário cria um projeto no SageMaker Unified Studio, a plataforma provisiona automaticamente três funções IAM:

    • Uma função de usuário do projeto (project user role)
    • Uma função de serviço do Amazon Bedrock (Amazon Bedrock service role)
    • Uma função de execução do Bedrock Lambda (Bedrock Lambda execution role)

    Com a nova funcionalidade, os administradores podem definir um limite de permissões diretamente na configuração do Tooling blueprint. A partir daí, todas as três funções são criadas já com esse limite de permissões aplicado — satisfazendo os requisitos das SCPs no momento da criação, sem que nenhuma intervenção adicional do administrador seja necessária.

    Controle centralizado e automático

    Outro ponto relevante dessa atualização é que o limite de permissões também restringe o que as funções provisionadas podem fazer. Isso significa que os administradores mantêm controle sobre as permissões em nível de projeto mesmo à medida que novos projetos são criados — sem precisar revisar cada um individualmente.

    E como a configuração é feita no nível do blueprint, ela se aplica automaticamente a todos os novos projetos criados a partir dali. Ou seja, o controle é centralizado e consistente por padrão.

    Disponibilidade

    O recurso já está disponível em todas as regiões da AWS onde o Amazon SageMaker Unified Studio está disponível. Para entender como configurar os parâmetros do blueprint, a AWS disponibiliza a documentação Gerenciar parâmetros do Tooling blueprint.

    Fonte

    Amazon SageMaker adds permissions boundaries for SCP compliance (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-sagemaker-scp/)

  • Amazon Quick Research passa a suportar chaves gerenciadas pelo cliente

    O que mudou no Amazon Quick Research

    A AWS anunciou uma atualização relevante para o Amazon Quick Research: o serviço agora oferece suporte a Chaves Gerenciadas pelo Cliente (CMK — Customer-Managed Keys) por meio do Serviço de Gerenciamento de Chaves da AWS (KMS — Key Management Service). Trata-se de uma evolução importante para equipes que precisam atender a requisitos rigorosos de segurança e conformidade.

    Por que isso importa para segurança e conformidade

    Antes dessa atualização, a criptografia dos dados no Amazon Quick Research era gerenciada pela própria AWS. Agora, as organizações podem assumir o controle direto sobre as chaves de criptografia, o que representa um nível a mais de autonomia e responsabilidade sobre os dados armazenados no serviço.

    Esse tipo de controle é frequentemente exigido por regulamentações de privacidade e segurança — especialmente em setores como financeiro, saúde e governo — onde a rastreabilidade e a capacidade de revogar acessos rapidamente são requisitos não negociáveis.

    O que é possível fazer com as CMKs no Quick Research

    Com a habilitação das chaves gerenciadas pelo cliente, as equipes ganham três capacidades principais:

    • Criptografar dados com chaves próprias do KMS, mantendo controle total sobre quem pode descriptografar as informações;
    • Rastrear todos os acessos aos dados para fins de auditoria de segurança, por meio da integração com o AWS CloudTrail;
    • Revogar o acesso a chaves comprometidas em até 15 minutos durante incidentes de segurança — um tempo de resposta bastante relevante em cenários críticos.

    Detalhes técnicos importantes

    O recurso suporta múltiplas CMKs, com uma chave padrão por conta AWS por região. Isso dá flexibilidade para gerenciar a criptografia em diferentes conjuntos de dados, mantendo controle granular sobre as informações sensíveis de inteligência de negócios.

    Há algumas restrições que vale destacar:

    • As chaves gerenciadas pelo cliente precisam ser criadas na mesma conta AWS e na mesma região dos recursos do Quick Research;
    • Apenas chaves simétricas do AWS KMS são suportadas — chaves assimétricas não são compatíveis com esse recurso.

    Disponibilidade

    O suporte a CMKs no Amazon Quick Research já está disponível de forma geral em todas as regiões AWS onde o Amazon Quick está disponível. Para saber mais sobre o serviço, a AWS disponibiliza a página de detalhes do Amazon Quick Research.

    Fonte

    Quick Research now supports customer managed keys (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-quick-research-cm-keys)

  • Relatórios SOC 1, 2 e 3 da Primavera de 2026 já estão disponíveis com 188 serviços no escopo

    AWS divulga relatórios SOC 1, 2 e 3 com 188 serviços no escopo

    A Amazon Web Services (AWS) anunciou a disponibilidade dos relatórios de Controles de Sistema e Organização (SOC) 1, 2 e 3 referentes ao ciclo da primavera de 2026. Esta é uma atualização relevante para equipes de conformidade, auditoria e segurança que utilizam serviços AWS e precisam comprovar aderência a padrões regulatórios.

    O que está coberto nos relatórios

    Os relatórios abrangem 188 serviços AWS ao longo de um período de 12 meses, de 1º de abril de 2025 a 31 de março de 2026. Isso significa que clientes têm à disposição um ano completo de evidências de conformidade, o que facilita muito processos de auditoria e due diligence.

    Esse tipo de cobertura contínua é especialmente valioso para empresas que precisam demonstrar controles robustos a reguladores, parceiros de negócio ou clientes corporativos — cenário cada vez mais comum no mercado brasileiro.

    Como acessar os relatórios

    Os relatórios SOC 1 e SOC 2 podem ser baixados diretamente pelo AWS Artifact no Console de Gerenciamento da AWS, que funciona como um portal de autoatendimento para acesso sob demanda a documentos de conformidade da AWS. Caso ainda não conheça a ferramenta, a AWS disponibiliza um guia de introdução em Primeiros Passos com o AWS Artifact.

    Já o relatório SOC 3 — a versão de uso geral, voltada para divulgação pública — pode ser encontrado tanto na Página de Conformidade SOC da AWS quanto no próprio AWS Artifact.

    Expansão contínua do escopo de conformidade

    A AWS mantém uma política de ampliar progressivamente o número de serviços cobertos por seus programas de conformidade. O objetivo é garantir que clientes consigam atender às suas necessidades arquiteturais e regulatórias sem precisar abrir mão de serviços mais recentes da plataforma. A lista atualizada de serviços no escopo pode ser consultada na página de Serviços no Escopo.

    Dúvidas e próximos passos

    Clientes AWS que tiverem dúvidas sobre conformidade SOC podem entrar em contato com o time de conta da AWS. Para uma visão geral de todos os programas de conformidade disponíveis, a AWS mantém uma página dedicada em Programas de Conformidade da AWS.

    Para equipes brasileiras que trabalham com setores regulados — como financeiro, saúde ou governo — manter esses relatórios atualizados é parte essencial da estratégia de governança em nuvem. Vale garantir que os documentos mais recentes já estejam em mãos antes da próxima rodada de auditorias.

    Fonte

    Spring 2026 SOC 1, 2, and 3 reports are now available with 188 services in scope (https://aws.amazon.com/blogs/security/spring-2026-soc-1-2-and-3-reports-are-now-available-with-188-services-in-scope/)

  • Amazon Quick passa a suportar conectividade VPC para conexões MCP

    O que mudou no Amazon Quick

    A AWS anunciou uma expansão importante para o Amazon Quick: o assistente de inteligência artificial agora suporta conectividade via Nuvem Privada Virtual (VPC) para conexões com servidores do Protocolo de Contexto de Modelo (MCP). A novidade é voltada especialmente para clientes corporativos que hospedam seus próprios servidores MCP em redes privadas.

    Para quem ainda não conhece, o Amazon Quick é um assistente de IA que transforma perguntas em respostas, respostas em ações e ações em resultados concretos — tanto para uso individual quanto para equipes inteiras.

    Qual era a limitação anterior

    Até então, o suporte a MCP no Amazon Quick estava restrito a servidores hospedados por terceiros e acessíveis pela internet pública. Isso deixava de fora um cenário muito comum em empresas: servidores MCP rodando em redes privadas, conectados a aplicações proprietárias, fontes de dados customizadas e ferramentas internas.

    O que a conectividade VPC resolve

    Com o suporte a VPC, organizações que hospedam servidores MCP em redes privadas agora conseguem estender essas capacidades com segurança para os fluxos de trabalho de IA dentro do Quick — sem precisar expor nada à internet pública.

    Na prática, é possível conectar o Quick a servidores MCP rodando em:

    • Amazon EC2
    • AWS Fargate
    • AWS Agentcore
    • Outros recursos de computação dentro da rede privada

    Todo o tráfego é roteado com segurança pela VPC, sem nenhuma exposição externa.

    Como configurar a conexão

    O processo é direto: durante a criação de um conector MCP no Quick, basta selecionar a conexão VPC desejada e informar a URL do servidor MCP. Após a configuração, toda a equipe pode interagir com os servidores MCP privados por meio de linguagem natural dentro do Quick.

    Disponibilidade

    O suporte a VPC para servidores MCP está disponível em todas as Regiões da AWS onde o Amazon Quick já está presente.

    Para saber mais sobre como conectar servidores MCP privados, a AWS disponibiliza a documentação sobre MCP e o guia de conectividade VPC.

    Fonte

    Amazon Quick now supports VPC connectivity for MCP connections (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-quick-vpc-mcp/)

  • Referencie seus próprios segredos do AWS Secrets Manager no Amazon Bedrock AgentCore Identity

    O desafio de credenciais em agentes de IA em produção

    Agentes de IA são tão poderosos quanto as ferramentas que conseguem acessar. Para buscar dados em um CRM, publicar atualizações no Slack ou consultar um repositório no GitHub, esses agentes precisam chamar APIs externas — e isso significa passar credenciais com segurança em tempo de execução. Fazer isso corretamente, sem hardcodar segredos no código ou expô-los nos prompts do agente, é um dos grandes desafios de quem constrói sistemas agênticos prontos para produção.

    O Amazon Bedrock AgentCore Identity já endereçava esse problema por meio de provedores de credenciais e um cofre de tokens que criavam e gerenciavam automaticamente um segredo no AWS Secrets Manager para cada recurso de provedor de credencial de saída (Outbound credential provider). Esse segredo armazenava a chave de API ou o client secret junto com outros metadados do provedor de identidade externo.

    No entanto, havia uma limitação importante: os clientes não podiam configurar tags personalizadas, políticas de rotação ou criptografia com chaves gerenciadas pelo cliente via Serviço de Gerenciamento de Chaves da AWS (AWS KMS) no momento da criação desses segredos.

    O que a AWS anunciou

    A AWS anunciou a possibilidade de referenciar um segredo já existente no AWS Secrets Manager dentro do AgentCore Identity. Com isso, as equipes podem apontar para um segredo pré-configurado e manter controle total sobre como ele é gerenciado — sem precisar criar um novo segredo do zero gerenciado pelo serviço.

    Na prática, isso significa que é possível fornecer um segredo existente no Secrets Manager para uso com seus recursos de provedor de credenciais. A equipe retém controle completo sobre a configuração de criptografia, rotação, replicação, tags e políticas de recurso — exatamente como gerencia qualquer outro segredo no Secrets Manager.

    Outro ponto relevante: é possível referenciar um segredo de outra conta AWS dentro da mesma Região AWS, embora o compartilhamento entre Regiões diferentes não seja suportado. A funcionalidade também é compatível com segredos trazidos por meio de conectores externos do AWS Secrets Manager, permitindo integração com gerenciadores de segredos de terceiros.

    Casos de uso práticos

    A AWS apresentou alguns cenários concretos onde essa capacidade faz diferença:

    • Reutilização de segredos existentes: Se o agente acessa uma API externa para a qual a equipe já tem um segredo configurado, basta fornecer o Nome de Recurso da Amazon (ARN) desse segredo ao recurso de provedor de credenciais, em vez de criar um novo. Segredos de outras contas AWS na mesma Região e segredos trazidos via conectores externos também são suportados.
    • Rotação sem interrupção: Quando o valor do segredo é rotacionado seguindo boas práticas de segurança, o AgentCore Identity recupera automaticamente o valor atualizado na próxima leitura. Não é necessário atualizar ou recriar os recursos de provedor de credenciais.
    • Controle granular de acesso: É possível configurar a política de recurso diretamente no AWS Secrets Manager, controlando quais entidades principais do Gerenciamento de Identidade e Acesso da AWS (IAM) podem acessar o segredo e definindo condições de acesso específicas.
    • Ambientes regulados com criptografia própria: Para agentes que operam em ambientes regulados onde toda credencial precisa ser criptografada com chave gerenciada pelo cliente, basta criar o segredo com essa chave antes de fornecê-lo ao AgentCore Identity. Isso é especialmente útil para organizações que aplicam Políticas de Controle de Serviço (SCPs) e Políticas de Controle de Recursos (RCPs) para garantir que todos os dados sejam criptografados com chaves gerenciadas pelo cliente. Ao referenciar um segredo existente, a configuração de criptografia é preservada integralmente.
    • Governança e rastreabilidade por tags: Organizações que exigem tags de recurso em segredos para alocação de custos, rastreamento de conformidade ou auditoria de governança podem criar e tagear o segredo conforme seus padrões antes de fornecê-lo ao AgentCore Identity.

    Para saber mais sobre as opções de configuração de segredos disponíveis, a AWS disponibiliza o Guia do Usuário do AWS Secrets Manager.

    Pré-requisitos

    Para utilizar essa funcionalidade, são necessários:

    • Um segredo existente no AWS Secrets Manager contendo a chave de API ou o client secret OAuth.
    • Permissões de IAM para conceder ao service principal do AgentCore Identity acesso de secretsmanager:GetSecretValue ao segredo.
    • Se estiver usando uma chave AWS KMS gerenciada pelo cliente, permissão de kms:Decrypt nessa chave para o service principal.
    • Acesso ao console do Amazon Bedrock AgentCore Identity ou à Interface de Linha de Comando da AWS (AWS CLI).

    Como configurar na prática

    Para referenciar um segredo no AWS Secrets Manager, basta fornecer o ARN do segredo e a chave JSON ao criar os recursos de provedor de credenciais pela API do AgentCore Identity. O serviço recupera o valor da credencial a partir da chave JSON especificada no segredo em tempo de execução.

    Pelo console

    É possível configurar um segredo referenciado ao criar novos recursos de provedor de credenciais diretamente pelo console do Amazon Bedrock AgentCore. A funcionalidade suporta tanto chaves de API quanto credenciais de cliente OAuth.

    Para adicionar uma chave de API com segredo referenciado:

    • Abra o console do Amazon Bedrock AgentCore.
    • No painel de navegação esquerdo, escolha Identity.
    • Na seção Outbound Auth, escolha Add Outbound Auth.
    • Escolha Add API key.
    • Insira um nome para o recurso Outbound Auth.
    • Em API key selection method, escolha Provide API key via Secrets Manager.
    • No campo Secrets Manager ARN, insira ou selecione o ARN do segredo existente. A lista exibe os segredos disponíveis na conta. Por exemplo: arn:aws:secretsmanager:us-east-1:123456789012:secret:myApiKeySecret-AbCdEf.
    • No campo JSON key, especifique a chave dentro do segredo que contém o valor da chave de API.
    • Escolha Add e verifique se o provedor de credenciais aparece na lista de Outbound Auth.

    Para adicionar um client secret OAuth com segredo referenciado:

    • Na página Identity, escolha Add Outbound Auth.
    • Escolha Add OAuth client.
    • Insira um nome para o cliente OAuth (por exemplo, google-oauth-client-v5fz5).
    • Em Provider, escolha o provedor desejado (incluído ou personalizado).
    • Insira o Client ID fornecido pelo provedor de identidade.
    • Em Client secret, escolha Provide Client secret via Secrets Manager.
    • No campo Secrets Manager ARN, insira o ARN do segredo que contém o client secret OAuth.
    • No campo JSON key, especifique a chave dentro do segredo que contém o valor do client secret.
    • Escolha Add OAuth Client e verifique se o provedor aparece na lista.

    Pela AWS CLI

    Também é possível configurar um segredo referenciado ao criar um novo recurso Outbound Auth para um client secret OAuth diretamente pela AWS CLI:

    aws bedrock-agentcore-control create-oauth2-credential-provider \
    --name "google-oauth-client-v5fz5" \
    --credential-provider-vendor "GoogleOauth2" \
    --oauth2-provider-config-input '{
      "googleOauth2ProviderConfig": {
        "clientId": "",
        "clientSecretSource": "EXTERNAL",
        "clientSecretConfig": {
          "secretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:myGoogleKeySecret-AbCdEf",
          "jsonKey": "key"
        }
      }
    }'

    Por meio de um agente de IA

    Se a equipe utiliza um agente de codificação por IA (como o Kiro ou similar), é possível instruí-lo a configurar um segredo referenciado diretamente com um prompt como:

    “I have an existing secret in AWS Secrets Manager at ARN arn:aws:secretsmanager:us-east-1:123456789012:secret:my-api-key. Create an OAuth2 credential provider in Amazon Bedrock AgentCore Identity named <client-name>, using GoogleOauth2 as the vendor. The client ID is <clientId>, the client secret source is EXTERNAL, and the secret JSON key is key.”

    Substitua <client-name> e <clientId> pelos valores correspondentes.

    Atenção: É necessário conceder ao AgentCore Identity permissão para ler o segredo, adicionando uma política de recurso ao segredo que permita ao service principal chamar secretsmanager:GetSecretValue. Se o segredo estiver criptografado com uma chave KMS gerenciada pelo cliente, também é necessário conceder ao service principal a permissão kms:Decrypt nessa chave.

    Conclusão

    Com a capacidade de referenciar segredos existentes no AWS Secrets Manager, o AgentCore Identity passa a oferecer maior flexibilidade para equipes que já possuem processos de gestão de segredos consolidados. É possível manter controle total sobre como as credenciais são criptografadas, rotacionadas e acessadas, enquanto o AgentCore Identity cuida de recuperá-las em tempo de execução.

    Para começar, a AWS disponibiliza a documentação do Amazon Bedrock AgentCore Identity. Para mais informações sobre gestão de segredos, consulte o Guia do Usuário do AWS Secrets Manager.

    Fonte

    Reference your own AWS Secrets Manager secrets in Amazon Bedrock AgentCore Identity (https://aws.amazon.com/blogs/machine-learning/reference-your-own-aws-secrets-manager-secrets-in-amazon-bedrock-agentcore-identity/)

  • Autenticação segura com OAuth no AgentCore Gateway para clientes MCP

    O problema: assistentes de IA precisam de acesso seguro a ferramentas corporativas

    No dia a dia de desenvolvimento moderno, assistentes de codificação baseados em IA — como o Kiro IDE — precisam se comunicar com ferramentas e serviços remotos para serem úteis. Mas essa comunicação levanta uma questão crítica de segurança: como garantir que apenas usuários e agentes autorizados consigam acessar essas ferramentas?

    O Protocolo de Contexto de Modelo (MCP) é o padrão que define como esses assistentes se conectam a servidores de ferramentas. E para que essa conexão seja segura em ambientes corporativos, é preciso um mecanismo robusto de autenticação — de preferência integrado ao provedor de identidade (IdP) já utilizado pela organização, como Okta, Microsoft Entra ID ou Amazon Cognito.

    A AWS publicou um guia técnico detalhando como implementar exatamente isso: o fluxo de código de autorização OAuth (Authorization Code Flow) como mecanismo de autenticação de entrada para servidores MCP hospedados no Amazon Bedrock AgentCore Gateway.

    O que é o AgentCore Gateway e qual é o seu papel aqui

    O Amazon Bedrock AgentCore é um serviço totalmente gerenciado para implantação, gerenciamento e escalonamento de agentes de IA em produção. Um de seus componentes principais, o AgentCore Gateway, funciona como ponto central de entrada para rotear e proteger as comunicações entre agentes e ferramentas.

    Nessa arquitetura, o Gateway atua como um servidor de recurso OAuth: ele intercepta cada requisição do assistente de IA, valida o token de identidade apresentado e só então encaminha a requisição ao servidor MCP de destino. Esse processo é chamado de autenticação de entrada (inbound authentication).

    Como o fluxo de autorização funciona na prática

    O fluxo envolve cinco componentes principais trabalhando em conjunto:

    • Provedor de Identidade (IdP): gerencia a autenticação dos usuários e emite tokens. Pode ser Amazon Cognito, Okta, Auth0 ou qualquer IdP corporativo compatível com OpenID Connect (OIDC).
    • Usuário: a pessoa real que se autentica no IdP e cuja identidade é verificada em cada requisição.
    • Amazon Bedrock AgentCore Gateway: valida os tokens e encaminha as requisições autenticadas ao servidor MCP.
    • Assistente de codificação (Kiro IDE): atua como cliente OAuth, gerenciando todo o fluxo de autenticação automaticamente.
    • Servidor MCP: as ferramentas e serviços de back-end que o assistente precisa acessar.

    Opcionalmente, um proxy OAuth para MCP pode ser utilizado para padronizar a interface entre o cliente, o IdP e o servidor MCP — especialmente útil quando há diferenças de implementação entre esses componentes.

    O fluxo completo segue estas etapas:

    • O Kiro IDE tenta se conectar ao endpoint MCP do Gateway.
    • O Gateway detecta a ausência de token válido e responde com HTTP 401, apontando para o endpoint de metadados de recurso protegido (.well-known/oauth-protected-resource). Isso segue o padrão de Metadados de Recurso Protegido (PRM) da especificação MCP.
    • O cliente busca os metadados e obtém a URL de descoberta do IdP.
    • O Kiro IDE abre o navegador do sistema e redireciona o usuário para a página de login do IdP, com um desafio PKCE (Prova de Chave para Troca de Código).
    • O usuário se autentica e concede autorização.
    • O IdP redireciona o navegador para o callback local do cliente com um código de autorização.
    • O cliente troca esse código (junto com o verificador PKCE) por um token de acesso junto ao IdP.
    • A partir daí, o Kiro IDE inclui o token em todas as requisições ao Gateway, que valida assinatura, expiração, emissor e claims antes de encaminhar ao servidor MCP.

    Implementação técnica passo a passo

    Pré-requisitos

    • Conta AWS com o AgentCore Gateway implantado.
    • Um IdP com permissão para configurar um aplicativo (Amazon Cognito, Okta, Auth0 ou similar).
    • Proxy OAuth para MCP (mcp-remote).
    • Kiro IDE instalado localmente.
    • Conhecimento básico de fluxos OAuth 2.0.

    Passo 1: Configurar o provedor de identidade

    O primeiro passo é registrar um aplicativo OIDC no IdP da organização, configurando-o para suportar o fluxo de código de autorização com PKCE.

    1.1 Criar o aplicativo OIDC — No console do IdP, crie uma nova integração de aplicativo OIDC/OAuth 2.0 com método de login OIDC e tipo de aplicação Web.

    1.2 Habilitar os tipos de concessão — Ative Authorization Code e Refresh Token.

    1.3 Definir as URIs de redirecionamento — Adicione o callback que o cliente utilizará:

    http://localhost:PORT/callback

    Substitua PORT pela porta que o cliente utiliza.

    1.4 Configurar tempos de vida dos tokens — Recomendações do guia original:

    • Token de acesso: 1 hora
    • Token de atualização: 90 dias (ajustar conforme requisitos de segurança)
    • Token de ID: 1 hora

    1.5 Salvar as configurações — Guarde o Client ID e a URL de descoberta do IdP (por exemplo: https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration). Importante: nenhum client secret é necessário, pois o PKCE foi projetado justamente para clientes públicos como aplicações desktop.

    Passo 2: Configurar o AgentCore Gateway

    2.1 Definir o modo de autenticação de entrada — Configure o Gateway para usar autenticação baseada em JWT (Token Web JSON) apontando para o endpoint de descoberta do IdP:

    aws agentcore update-gateway \
      --gateway-id <your-gateway-id> \
      --inbound-auth-type JWT \
      --jwt-discovery-url "https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration" \
      --region <your-region>

    2.2 Validação de claims personalizados — O Gateway valida tokens com base em claims padrão do OAuth 2.0 (iss, aud, exp, iat, client_id, scopes), mas também suporta validação de claims personalizados para acomodar diferentes implementações de IdP. Por exemplo, IdPs como o Okta podem usar cid em vez de client_id. Nesse caso, a configuração seria:

    Custom claim: <claim-name> EQUALS <expected-value>

    Consulte a documentação AgentCore Gateway: configuração de JWT para detalhes completos.

    2.3 Como o Gateway valida tokens — Um ponto importante destacado no guia: o Gateway é agnóstico em relação à forma como o token foi obtido. Não importa se o token veio de um fluxo de credenciais de cliente ou de um fluxo de código de autorização — o que conta é que o token passe nas validações configuradas: assinatura, expiração, emissor e claims de audiência ou personalizados.

    2.4 Verificar a configuração — Para confirmar que a autenticação está ativa, faça uma requisição sem token:

    curl -i -X POST https://<your-gateway-url>/mcp \
      -H "Content-Type: application/json" \
      -d '{"jsonrpc":"2.0","method":"initialize","params":{},"id":1}'

    A resposta esperada é um HTTP 401 com o cabeçalho www-authenticate apontando para o endpoint de metadados:

    HTTP/2 401
    www-authenticate: Bearer resource_metadata="https://<your-gateway-url>/.well-known/oauth-protected-resource"
    {"jsonrpc":"2.0","id":0,"error":{"code":-32001,"message":"Missing Bearer token"}}

    Passo 3: Instalar o proxy OAuth para MCP

    Para padronizar a interface entre o Kiro IDE e o endpoint protegido do Gateway, o guia recomenda o uso do mcp-remote. Vale notar que essa ferramenta é descrita como uma prova de conceito funcional e deve ser tratada como experimental:

    npm install -g mcp-remote

    Passo 4: Configurar o Kiro IDE

    Com o Gateway e o proxy configurados, o último passo é conectar o cliente ao endpoint do Gateway. O Kiro IDE gerencia o fluxo OAuth automaticamente ao receber um desafio 401.

    Adicione a configuração no arquivo ~/.kiro/settings/mcp.json:

    {
      "mcpServers": {
        "gateway-tools": {
          "command": "mcp-remote",
          "args": [
            "https://<your-gateway-url>/mcp",
            "<PORT>",
            "--static-oauth-client-info",
            "{\"client_id\": \"<your-idp-client-id>\", \"redirect_uris\": [\"http://localhost:<PORT>/oauth/callback\"], \"scope\": \"openid profile email offline_access\"}"
          ]
        }
      }
    }

    Parâmetros da configuração:

    • command: usa o mcp-remote para se conectar a servidores MCP remotos.
    • Primeiro argumento: URL do Gateway com o caminho /mcp.
    • Segundo argumento: porta local para o callback OAuth (ex: 3334).
    • --static-oauth-client-info: JSON com client_id do IdP, redirect_uris (deve bater com a porta do segundo argumento) e scope com os escopos necessários.

    Passo 5: Verificar o fluxo completo

    Após reiniciar o cliente e tentar usar uma ferramenta do Gateway, o usuário é redirecionado ao navegador para login no IdP. Após autenticação bem-sucedida, a ferramenta é executada normalmente. Nos logs do Gateway, uma validação bem-sucedida aparece como:

    [INFO] Token validated successfully for user: user@example.com
    [INFO] Executing tool: list_files

    Para um passo a passo completo usando o Okta como IdP, a AWS disponibilizou um repositório no GitHub com exemplos práticos.

    Limpeza dos recursos

    Para desfazer o ambiente criado durante os testes, o guia recomenda seguir a ordem inversa de criação:

    1. Revogar tokens OAuth ativos — Consulte o endpoint de revogação do seu IdP. Em geral, a chamada segue este padrão:
      curl -X POST "<your-idp-revocation-endpoint>" \
        -H "Content-Type: application/x-www-form-urlencoded" \
        -d "token=<your-refresh-token>&client_id=<your-client-id>"

      Para limpar o cache local de tokens do mcp-remote (macOS/Linux):

      rm -rf ~/.mcp-auth
    2. Remover a configuração do Kiro IDE — Apague o bloco gateway-tools do arquivo ~/.kiro/settings/mcp.json.
    3. Desinstalar o mcp-remote:
      npm uninstall -g mcp-remote
    4. Remover a configuração do Gateway — Duas opções:
      # Opção A: remover apenas a autenticação de entrada
      aws agentcore update-gateway \
        --gateway-id <your-gateway-id> \
        --inbound-auth-type NONE \
        --region <your-region>
      
      # Opção B: deletar o Gateway completamente
      aws agentcore delete-gateway \
        --gateway-id <your-gateway-id> \
        --region <your-region>
    5. Remover o aplicativo OIDC do IdP — Acesse o console do IdP, navegue até o aplicativo criado (ex: “AgentCore Gateway client”), desative-o e exclua.

    Principais conclusões

    O guia publicado pela AWS demonstra uma arquitetura sólida para garantir acesso seguro e verificado por identidade a servidores MCP em ambientes corporativos. Os pontos mais relevantes:

    • O fluxo de código de autorização garante autenticação forte, com consentimento explícito do usuário e verificação de identidade.
    • O AgentCore Gateway atua como servidor de recurso OAuth, validando tokens antes de permitir qualquer execução de ferramentas.
    • O fluxo é transparente para o usuário final: a autenticação ocorre uma vez, e os tokens são renovados automaticamente.
    • A arquitetura escala para múltiplos clientes de IA e diferentes provedores de identidade.

    Recursos adicionais

    Fonte

    Building a secure auth code flow setup using AgentCore Gateway with MCP clients (https://aws.amazon.com/blogs/machine-learning/building-a-secure-auth-code-flow-setup-using-agentcore-gateway-with-mcp-clients/)

  • AWS Shield Advanced agora oferece logs de fluxo de ataques DDoS

    Visibilidade em nível de pacote durante ataques DDoS

    A AWS anunciou uma novidade importante para quem utiliza o Shield Advanced: a chegada dos logs de fluxo de ataques de Negação de Serviço Distribuído (DDoS). Com esse recurso, equipes de segurança passam a ter visibilidade em nível de pacote sobre o tráfego que atinge os recursos protegidos pelo Shield Advanced durante um ataque ativo — algo que antes não estava disponível de forma nativa na plataforma.

    O que é capturado nos logs

    Os logs de fluxo de ataques DDoS registram detalhes críticos em nível de pacote. Entre as informações capturadas estão:

    • Endereços IP de origem e destino
    • Portas de origem e destino
    • Protocolos utilizados
    • Contagem de pacotes e bytes
    • País de origem do tráfego
    • Outros dados relevantes para análise

    Esses dados são publicados automaticamente no destino escolhido pela equipe em intervalos de 5 minutos enquanto o ataque estiver ativo.

    Onde os logs são armazenados

    A AWS permite que os dados sejam entregues em três destinos diferentes, conforme a preferência e a arquitetura de cada organização:

    • Amazon S3 — para armazenamento de longo prazo e análise posterior
    • Amazon CloudWatch Logs — para monitoramento e alertas em tempo real
    • Amazon Data Firehose — para ingestão e encaminhamento a outros sistemas de análise

    Após a publicação, os dados podem ser consultados com as ferramentas de análise que a equipe já utiliza, o que facilita bastante a integração com fluxos de trabalho existentes.

    Para que serve na prática

    A funcionalidade foi pensada para atender três grandes necessidades de segurança:

    • Investigação pós-incidente: entender exatamente o que aconteceu durante um ataque, com dados precisos em nível de pacote
    • Inteligência de ameaças: identificar padrões, origens e comportamentos recorrentes em ataques DDoS
    • Conformidade e auditoria: manter registros detalhados para fins regulatórios e de compliance

    Como habilitar

    Para utilizar os logs de fluxo de ataques DDoS, é necessário que os recursos estejam protegidos pelo Shield Advanced e que a entrega de logs esteja configurada para um dos destinos suportados. O recurso está disponível em todas as regiões onde o AWS Shield Advanced opera.

    Para mais detalhes sobre como configurar e utilizar os logs de fluxo de ataques DDoS, a AWS disponibiliza a documentação oficial do AWS Shield Advanced.

    Fonte

    AWS Shield Advanced introduces DDoS attack flow logs (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-shield-ddos/)

  • Filtragem por Categoria de URL e Domínio no AWS Network Firewall: simplifique o gerenciamento de políticas

    O problema que esse recurso resolve

    Manter listas de domínios bloqueados e permitidos é um trabalho sem fim. Novos sites e serviços surgem todos os dias, e qualquer lacuna na atualização manual dessas listas representa uma brecha de segurança. O desafio se intensifica quando o assunto é controlar o acesso a categorias em rápida evolução — como serviços de Inteligência Artificial (IA), onde novas ferramentas aparecem com frequência.

    Para endereçar esse problema, a AWS expandiu as capacidades do AWS Network Firewall com suporte a filtragem por categoria de URL e domínio. Em vez de gerenciar domínios individualmente, as equipes de segurança passam a trabalhar com categorias predefinidas e mantidas automaticamente pela própria AWS. Quando um novo domínio é registrado e se enquadra em uma categoria, ele já entra automaticamente no escopo das regras — sem nenhuma intervenção manual.

    Como funciona a filtragem por categoria

    O AWS Network Firewall é um serviço gerenciado de firewall de rede com estado (stateful) e detecção e prevenção de intrusões para controle granular do tráfego da sua Nuvem Privada Virtual (VPC). Com a filtragem por categoria, você escolhe de uma lista de categorias gerenciadas pela AWS — como Redes Sociais, Jogos de Azar ou Inteligência Artificial e Aprendizado de Máquina — e aplica políticas de acesso a elas de forma centralizada.

    O serviço oferece dois modos de filtragem por categoria:

    • Domain category (categoria de domínio): filtra pelo nome do domínio usando o campo Indicação de Nome do Servidor (SNI) do TLS, sem necessidade de descriptografia.
    • URL category (categoria de URL): filtra pelo caminho completo da URL, o que exige inspeção TLS para tráfego HTTPS. Para configurar esse modo, consulte a documentação sobre criação de configuração de inspeção TLS no Network Firewall.

    O foco deste guia é a filtragem por categoria de domínio, por ser mais direta de configurar.

    Pré-requisitos

    Antes de começar, é necessário ter um deployment do Network Firewall já em funcionamento para filtrar o tráfego de saída da sua Amazon VPC. Caso ainda não use o serviço, a AWS disponibiliza um guia de introdução ao AWS Network Firewall.

    Outro ponto importante é configurar corretamente a variável $HOME_NET no nível da política do firewall. As regras usam essa variável para delimitar o escopo do tráfego à sua rede interna. A recomendação da AWS é definir $HOME_NET com os intervalos de endereços IP privados RFC 1918: 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. O Network Firewall mapeia automaticamente a variável $EXTERNAL_NET como o inverso de $HOME_NET, então configurar uma resolve as duas.

    Criando uma regra de categoria pelo console

    Para começar rapidamente, é possível usar o construtor de regras do Console de Gerenciamento da AWS. O exemplo abaixo cria uma regra de alerta para a categoria de Inteligência Artificial e Aprendizado de Máquina:

    1. Acesse o console do Amazon VPC, navegue até Network Firewall > Rule groups e clique em Create rule group.
    2. Selecione Stateful rule group, formato Standard stateful rules e ordem de avaliação Strict order.
    3. Defina o nome como Domain-Category-Rules, a descrição como Domain Category Rules e a capacidade como 50.
    4. No editor de regras, selecione o botão Category Matching e escolha Match all selected categories.
    5. Em AWS category type, selecione Domain Category. Em Categories, escolha Artificial Intelligence and Machine Learning.
    6. Defina o protocolo como TLS, a origem como Custom com o valor $HOME_NET, o destino como Any e a ação como Alert.
    7. Clique em Add rule e, em seguida, em Create rule group.

    Essa regra gera uma entrada de log de alerta sempre que uma conexão corresponder a um domínio da categoria de IA e ML. Ela não bloqueia o tráfego — para isso, basta alterar a ação para Drop ou Reject.

    Criando a mesma regra com strings Suricata

    O construtor de regras do console é prático para começar, mas a AWS recomenda o uso de strings de regras compatíveis com Suricata em ambientes de produção. As regras Suricata oferecem controle total sobre as opções de regra, são fáceis de copiar, editar, compartilhar e fazer backup, e suportam a maioria das capacidades do motor Suricata. Para mais detalhes, consulte as limitações e ressalvas para regras stateful no AWS Network Firewall.

    Para criar o mesmo grupo de regras usando Suricata:

    1. Acesse Network Firewall > Network Firewall rule groups e clique em Create rule group.
    2. Selecione Stateful rule group, formato Suricata compatible rule string e ordem Strict order.
    3. Defina o nome como Suricata-Domain-Category-Rules, a descrição como Suricata Domain Category Rules e a capacidade como 50.
    4. Deixe as seções de variáveis de regra e referências de conjunto de IPs vazias — a variável $HOME_NET é herdada da política do firewall.
    5. Cole a seguinte regra no editor:
    alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"Artificial Intelligence and Machine Learning Category"; aws_domain_category:Artificial Intelligence and Machine Learning; sid:1000001;)

    A tabela abaixo explica cada componente dessa regra:

    • alert: ação — gera uma entrada de alerta no log quando a regra corresponder. Outras ações possíveis: pass, drop e reject.
    • tls: protocolo — inspeciona tráfego TLS, correspondendo ao campo SNI no TLS Client Hello.
    • $HOME_NET any -> $EXTERNAL_NET any: origem e destino — corresponde ao tráfego de qualquer IP interno para qualquer IP externo, em qualquer porta.
    • msg:"...": mensagem gravada no log de alerta quando a regra é acionada.
    • aws_domain_category:...: categoria de domínio gerenciada pela AWS a ser verificada. O firewall consulta o banco de dados de categorias e corresponde se o domínio de destino pertencer à categoria.
    • sid:1000001: identificador único da assinatura. Cada regra em um grupo deve ter um SID único.

    Após criar o grupo de regras, retorne à política do firewall e associe-o em Stateful rule groups. A recomendação é sempre associar novos grupos de regras primeiro em um ambiente de desenvolvimento ou teste antes de levar para produção.

    Gerenciando exceções para serviços aprovados

    É possível criar exceções para manter sites críticos para o negócio acessíveis. Por exemplo, para permitir o acesso ao OpenAI enquanto bloqueia todo o restante do tráfego de IA e ML, basta substituir a regra básica pelo seguinte conjunto de regras no grupo Suricata-Domain-Category-Rules:

    # Allow OpenAI (TLS)
    pass tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; dotprefix; content:".openai.com"; nocase; endswith; flow:to_server; alert; msg:"Allow OpenAI over TLS"; sid:1000001;)
    
    # Allow OpenAI (HTTP)
    pass http $HOME_NET any -> $EXTERNAL_NET any (http.host; dotprefix; content:".openai.com"; nocase; endswith; flow:to_server; alert; msg:"Allow OpenAI over HTTP"; sid:1000002;)
    
    # Block all other AI/ML category traffic (TLS)
    reject tls $HOME_NET any -> $EXTERNAL_NET any (msg:"Block non-approved AI/ML sites over TLS"; aws_domain_category:Artificial Intelligence and Machine Learning; flow:to_server; alert; sid:1000003;)
    
    # Block all other AI/ML category traffic (HTTP)
    reject http $HOME_NET any -> $EXTERNAL_NET any (msg:"Block non-approved AI/ML sites over HTTP"; aws_url_category:Artificial Intelligence and Machine Learning; flow:to_server; alert; sid:1000004;)

    Com a avaliação em ordem estrita (strict order), o firewall processa as regras na sequência em que foram definidas. As regras de pass para o OpenAI aparecem primeiro, então o tráfego correspondente é permitido antes que as regras de bloqueio da categoria mais ampla sejam avaliadas.

    Para verificar se as regras estão funcionando como esperado, é possível testar a partir de um host que roteia o tráfego pelo firewall. Os comandos abaixo suprimem o corpo da resposta e verificam o código de saída da requisição curl. Se o curl completar uma conexão TCP, exibe CONNECTION ALLOWED; se o firewall resetar a conexão, exibe CONNECTION BLOCKED:

    curl -s -o /dev/null https://openai.com && echo "CONNECTION ALLOWED" || echo "CONNECTION BLOCKED"

    Resultado esperado: CONNECTION ALLOWED

    curl -s -o /dev/null https://chat.mistral.ai && echo "CONNECTION ALLOWED" || echo "CONNECTION BLOCKED"

    Resultado esperado: CONNECTION BLOCKED

    Monitorando o uso por categoria

    Quando uma regra de categoria de domínio é adicionada à política do firewall, o Network Firewall realiza uma consulta de categoria para cada conexão que corresponde ao protocolo e às especificações de IP da regra. As regras deste guia correspondem a $HOME_NET any -> $EXTERNAL_NET any, o que significa que o firewall consulta a categoria de todo o tráfego de saída originado da rede interna.

    Cada entrada de log inclui um campo aws_category com um array JSON contendo todas as categorias às quais o domínio de destino pertence. Um único domínio pode pertencer a múltiplas categorias. Por exemplo, uma requisição para chat.mistral.ai gera uma entrada com "aws_category": "[\"Social Networking\",\"Artificial Intelligence and Machine Learning\"]".

    Os logs do firewall podem ser acessados pelo Amazon CloudWatch, pelo Amazon S3 e pelo Amazon Data Firehose.

    Abaixo está um exemplo de entrada de log para uma requisição bloqueada ao chat.mistral.ai:

    {
      "firewall_name": "egress-and-east-west-firewall",
      "availability_zone": "us-east-1a",
      "event_timestamp": "1775599146",
      "event": {
        "aws_category": "[\"Social Networking\",\"Artificial Intelligence and Machine Learning\"]",
        "tx_id": 0,
        "app_proto": "tls",
        "src_ip": "10.1.1.100",
        "src_port": 58664,
        "event_type": "alert",
        "alert": {
          "severity": 3,
          "signature_id": 1000003,
          "rev": 1,
          "signature": "Block non-approved AI/ML sites over TLS",
          "action": "blocked",
          "category": ""
        },
        "flow_id": 763153567844057,
        "dest_ip": "172.66.2.203",
        "proto": "TCP",
        "verdict": {
          "action": "drop",
          "reject-target": "to_client",
          "reject": [
            "tcp-reset"
          ]
        },
        "tls": {
          "sni": "chat.mistral.ai",
          "version": "UNDETERMINED"
        },
        "dest_port": 443,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-04-07T21:59:06.906761+0000",
        "direction": "to_server"
      }
    }

    O campo aws_category mostra que o domínio pertence às categorias “Social Networking” e “Artificial Intelligence and Machine Learning”. O campo verdict confirma que a conexão foi descartada com um reset TCP enviado ao cliente.

    Consultando logs com o CloudWatch Logs Insights

    Se os logs do firewall forem enviados para o Amazon CloudWatch Logs, é possível usar o CloudWatch Logs Insights para analisar padrões de tráfego por categoria. Como uma única conexão pode gerar múltiplas entradas de log, as queries abaixo deduplicam por flow_id para contar cada conexão apenas uma vez. Atenção: as consultas no CloudWatch Logs Insights geram cobranças com base na quantidade de dados varridos — consulte a página de preços do Amazon CloudWatch para detalhes.

    Categorias mais acessadas

    fields @timestamp, event.aws_category, event.flow_id
    | filter ispresent(event.aws_category) and event.aws_category != "[]"
    | stats latest(event.aws_category) as categories by event.flow_id
    | stats count(*) as connections by categories
    | sort connections desc
    | limit 20

    Categorias menos acessadas

    fields @timestamp, event.aws_category, event.flow_id
    | filter ispresent(event.aws_category) and event.aws_category != "[]"
    | stats latest(event.aws_category) as categories by event.flow_id
    | stats count(*) as connections by categories
    | sort connections asc
    | limit 20

    Categorias mais acessadas — apenas tráfego permitido

    fields @timestamp, event.aws_category, event.flow_id, event.verdict.action
    | filter ispresent(event.aws_category) and event.aws_category != "[]"
    | stats latest(event.aws_category) as categories, latest(event.verdict.action) as verdict by event.flow_id
    | filter verdict = "alert"
    | stats count(*) as connections by categories
    | sort connections desc
    | limit 20

    Categorias mais acessadas — apenas tráfego bloqueado

    fields @timestamp, event.aws_category, event.flow_id, event.verdict.action
    | filter ispresent(event.aws_category) and event.aws_category != "[]"
    | stats latest(event.aws_category) as categories, latest(event.verdict.action) as verdict by event.flow_id
    | filter verdict = "drop"
    | stats count(*) as connections by categories
    | sort connections desc
    | limit 20

    Detalhamento por categoria específica

    Esta query usa um filtro like para encontrar todo o tráfego onde o campo aws_category contém uma categoria específica, independentemente de quais outras categorias o domínio também pertença. Substitua o nome da categoria no filtro like para investigar qualquer outra categoria:

    fields @timestamp, event.tls.sni, event.aws_category, event.verdict.action, event.flow_id
    | filter ispresent(event.aws_category) and event.aws_category like /Artificial Intelligence and Machine Learning/
    | stats latest(event.tls.sni) as sni, latest(event.verdict.action) as verdict by event.flow_id
    | stats count(*) as connections by sni, verdict
    | sort connections desc
    | limit 20

    Consumo de banda por categoria

    Esta query mostra quais combinações de categorias consomem mais banda de saída. Ela correlaciona os logs de fluxo (que contêm contagens de bytes) com os logs de alerta (que contêm dados de categoria) usando o campo flow_id compartilhado. Para executar esta query, selecione tanto o grupo de logs de alerta quanto o de logs de fluxo no CloudWatch Logs Insights:

    fields @timestamp
    | filter ispresent(event.netflow.bytes) or ispresent(event.aws_category)
    | stats sum(event.netflow.bytes) as flowBytes, latest(event.aws_category) as categories by event.flow_id
    | filter ispresent(categories) and categories != "[]"
    | stats sum(flowBytes) as totalBytes by categories
    | sort totalBytes desc
    | limit 20

    Disponibilidade

    O recurso de filtragem por categoria de URL e domínio está disponível em todas as regiões comerciais da AWS onde o AWS Network Firewall é suportado. Para saber mais, consulte a documentação do recurso.

    Fonte

    Simplifying policy management with URL and Domain Category filtering on AWS Network Firewall (https://aws.amazon.com/blogs/security/simplifying-policy-management-with-url-and-domain-category-filtering-on-aws-network-firewall/)