Category: Uncategorized

Desafios na análise de risco em seguros

A análise de risco em seguros enfrenta um cenário complexo: os analistas precisam examinar múltiplas fontes de dados, avaliar riscos e tomar decisões que atendam a requisitos regulatórios cada vez mais rigorosos. Esse processo se torna ainda mais desafiador quando a organização enfrenta três problemas críticos.

Primeiro, os dados estão fragmentados. Informações de clientes residem em sistemas de Gestão de Relacionamento com Clientes (Sistemas de CRM), repositórios de documentos e bases de dados transacionais, criando silos que dificultam uma análise integrada e confiável.

Segundo, há pressão regulatória. As autoridades exigem decisões que sejam explicáveis e auditáveis — propriedades que abordagens tradicionais baseadas em modelos de “caixa preta” não conseguem fornecer adequadamente.

Terceiro, há necessidade de escala. As organizações precisam manter regras de análise consistentes e automatizadas em todo o portfólio, com capacidade de identificar proativamente sinais de fraude e comportamentos suspeitos.

Uma solução integrada com inteligência artificial

A AWS apresenta uma arquitetura que combina diferentes componentes para resolver esses desafios. O pilar técnico dessa solução é o Amazon Nova 2 Lite, um modelo de linguagem que fornece raciocínio transparente e explicável para cada decisão tomada.

Como funciona a arquitetura

A solução utiliza o Protocolo de Contexto de Modelo (MCP) para criar ferramentas especializadas em três tarefas: detecção de fraude em seguros, avaliação de risco de um solicitante e tomada de decisão sobre cobertura. Quando uma ferramenta é acionada a partir de uma consulta, ela acessa dados de fontes específicas — repositórios de documentos como Amazon Simple Storage Service (S3) e bases de dados como Amazon DynamoDB — e invoca o Amazon Nova 2 Lite para análise e geração de recomendações.

Depois de recuperar as instruções de sistema e o contexto necessário, o modelo retorna uma resposta estruturada conforme esperado pela ferramenta. O servidor MCP é hospedado no Amazon Bedrock AgentCore Runtime com autorização de entrada via OAuth 2.0. Já o cliente MCP do Amazon Quick Suite é configurado com autenticação de serviço para permitir conexões de entrada ao servidor MCP.

A interação do usuário ocorre de forma natural: o agente de conversa processa consultas em linguagem natural, invoca as ferramentas MCP necessárias e mantém diálogos interativos com múltiplas trocas de mensagens.

Fluxo de operação

O fluxo começa quando um usuário autenticado do Quick Suite acessa o agente de conversa do Quick Suite e submete uma pergunta através da interface do assistente. Um exemplo seria: “Avalie o risco para o solicitante APP-0900”.

O agente de conversa está integrado com as Integrações de Ações MCP do Amazon Quick Suite para invocar ações em um servidor MCP implantado no AgentCore Runtime. O agente analisa a pergunta para entender a intenção, identifica entidades-chave como identificadores de solicitantes e números de sinistros, e decide quais ferramentas MCP devem ser acionadas.

O cliente MCP do Quick Suite solicita um token de acesso do Amazon Cognito usando credenciais de cliente OAuth. O Cognito valida as credenciais e emite um token de curta duração. O Quick Suite inclui esse token na requisição ao AgentCore Runtime, que valida o token contra o Cognito.

O AgentCore Runtime possui uma tradução integrada que transforma a requisição de entrada no formato JSON-RPC 2.0 do MCP e invoca as ferramentas apropriadas. O registro de eventos pode ser habilitado para registrar tudo no Amazon CloudWatch.

O servidor MCP executa a lógica das ferramentas, recupera dados do DynamoDB e S3, e invoca o Amazon Nova 2 Lite através da API Converse do Amazon Bedrock para gerar uma resposta com um processo detalhado de raciocínio. A resposta é transformada novamente para corresponder ao protocolo do Quick Suite e retornada ao usuário através da interface do assistente.

O Amazon Nova 2 Lite oferece capacidades importantes nesse cenário: consegue solicitar ferramentas e compreender seus esquemas, realiza raciocínio para determinar quais ferramentas são necessárias baseado nas perguntas do usuário, e então gera requisições de ferramentas com parâmetros validados que o servidor MCP executa.

Implementação prática da solução

Pré-requisitos

Para colocar em prática essa solução, você precisará de:

• Uma conta AWS
• Amazon Quick Suite configurado com assinatura Author Pro
• Permissão para criar funções e políticas de AWS Identity and Access Management (IAM) e recursos AWS, incluindo tabela DynamoDB, bucket S3, pool de usuários Cognito e AgentCore Runtime
• Acesso a um ambiente de linha de comando com AWS SDK e Python instalados

Hospedagem do servidor MCP

A implementação começa clonando o repositório de código correspondente. Em seguida, você edita o arquivo de configuração config/enterprise_config.yaml para fornecer o nome do servidor MCP, o pool de usuários Cognito, as tabelas DynamoDB contendo solicitantes e sinistros, e o bucket S3 para registros médicos.

Depois, configura um ambiente virtual Python com as dependências necessárias:

python -m venv smart_insurance_agent_venv
source smart_insurance_agent_venv/bin/activate
pip install -r deployment/requirements.txt

Opcionalmente, você pode gerar dados sintéticos de solicitantes, registros médicos e sinistros. A geração de dados sintéticos utiliza a biblioteca faker para criar registros de solicitantes e sinistros que são persistidos no DynamoDB e registros médicos que são persistidos no S3 em formato JSON. Você pode modificar o esquema ou formatos de registro personalizando o script de carregamento conforme suas necessidades.

Com tudo preparado, você implanta o servidor MCP no Amazon Bedrock AgentCore executando o script de implantação. Este passo cria um pool de usuários Cognito, constrói uma imagem Docker, a implanta no AgentCore, configura permissões IAM, e gera a documentação com a URL do endpoint do servidor MCP e configuração OAuth necessária para integração com o Quick Suite.

Para validar que tudo funcionou corretamente, executa o teste de funcionalidade das ferramentas MCP. A execução bem-sucedida fornecerá uma saída confirmando que o servidor foi implantado e operacional.

Integração com Quick Suite

Depois, você estabelece uma conexão OAuth de serviço a serviço do Quick Suite para o endpoint hospedado no Amazon Bedrock AgentCore. Essa conexão permite que seu agente de conversa do Quick Suite invoque ações do servidor MCP para cumprir solicitações dos usuários.

No console do Quick Suite, você navega até Integrações e cria uma nova integração MCP. Na página de configuração de conexão, fornece os detalhes do servidor MCP: um nome (por exemplo, “Especialista em Análise de Seguros”), uma descrição opcional e a URL do endpoint do servidor MCP.

Na página de autenticação, você seleciona autenticação de serviço, escolhe OAuth de serviço a serviço como tipo de autenticação, e fornece o ID de cliente, segredo do cliente e URL do token. Depois de revisar e confirmar, a integração está pronta.

Para testar, você acessa a seção de Integrações no console, verifica que o status está “Disponível”, seleciona a integração criada e testa as APIs de ação para confirmar que estão funcionando corretamente.

Criando o agente de conversa personalizado

Agora você cria um agente de conversa customizado no Quick Suite. Você fornece um nome para identificar o agente e uma descrição opcional que ajude os usuários a entender seu propósito.

Na configuração do agente, você define sua identidade. Um exemplo seria: “Você é Nova, um Analista de Seguros baseado em IA com expertise profunda em avaliação de risco explicável e detecção de fraude. Você tem acesso a dados empresariais de seguros incluindo mais de 1000 perfis de solicitantes, registros médicos e histórico de sinistros através de capacidades avançadas de raciocínio”.

Você também fornece instruções de persona que definem como o agente interage com usuários durante a conversa. Por exemplo, instruções que enfatizam transparência, explicam o nível de confiança nas recomendações, decompõem decisões complexas em passos lógicos claros, referenciam perfis específicos de solicitantes quando disponível, fornecem pontuações de risco com explicações detalhadas dos fatores contribuintes, incluem considerações de conformidade regulatória, e oferecem perguntas de acompanhamento para aprofundar a análise quando apropriado.

Na seção de Ações, você vincula o conector de ação que criou, lançando o agente. Após alguns minutos, o agente estará operacional e pronto para conversar.

Você pode começar pedindo ao agente uma avaliação de risco específica — por exemplo, “Avalie o risco para o solicitante APP-0900”. O agente processará a requisição, invocará as ações necessárias, e retornará uma análise detalhada. A interface da conversa pode solicitar informações adicionais para algumas ações antes de proceder, garantindo precisão na análise.

Benefícios da abordagem

Essa arquitetura soluciona os três desafios centrais mencionados no início. Primeiro, unifica dados de DynamoDB e S3, permitindo que o sistema acesse informações completas sobre solicitantes, registros e histórico de sinistros em uma única consulta. Segundo, entrega raciocínio passo a passo transparente para cada decisão, atendendo requisitos regulatórios de explicabilidade e auditoria. Terceiro, mantém trilhas de auditoria completas no CloudWatch para conformidade regulatória, e permite que investigadores façam perguntas como “Mostre-me todos os sinistros registrados dentro de 30 dias do início da apólice” para identificar padrões suspeitos.

Com essa solução em operação, você consegue escalar análises de risco — líderes de negócios ganham inteligência de portfólio em tempo real através de interações em linguagem natural, e todo o processo de análise é rastreável e auditável do início ao fim.

Limpeza de recursos

Após experimentar a solução, você pode remover todos os recursos AWS criados para evitar cobranças contínuas usando o script fornecido na documentação de implantação.

Fonte

Create an intelligent insurance underwriter agent powered by Amazon Nova 2 Lite and Amazon Quick Suite (https://aws.amazon.com/blogs/machine-learning/create-an-intelligent-insurance-underwriter-agent-powered-by-amazon-nova-2-lite-and-amazon-quick-suite/)

Expansão global do SES Mail Manager

A AWS anunciou a disponibilidade do SES Mail Manager em 10 regiões comerciais adicionais. Esta expansão leva o serviço de um total de 17 regiões para 27 regiões, consolidando uma cobertura significativa. A novidade marca um passo importante: o Mail Manager agora está disponível em todas as regiões comerciais onde o SES oferece seu serviço principal de envio de emails (Outbound).

O que é o SES Mail Manager

O SES Mail Manager é um serviço da AWS que permite aos clientes configurar mecanismos de roteamento e entrega de emails para seus domínios. Mais que isso, oferece uma visualização única de governança de emails, gerenciamento de riscos e soluções de conformidade para todos os trabalhos relacionados a emails na organização.

Na prática, as empresas implantam o Mail Manager para substituir soluções legadas de retransmissão de emails hospedados ou para simplificar a integração com provedores de caixas de correio terceirizados e soluções de segurança de email. O serviço também oferece funcionalidades complementares:

• Integração com caixas de correio WorkMail
• Arquivamento integrado com capacidades de busca e exportação
• Integração com complementos de segurança terceirizados diretamente no console

As 10 novas regiões

As regiões recém-adicionadas incluem:

• Oriente Médio (Bahrein)
• Ásia Pacífico (Jacarta)
• África (Cidade do Cabo)
• Oriente Médio (Emirados Árabes Unidos)
• Ásia Pacífico (Hyderabad)
• Ásia Pacífico (Malásia)
• Europa (Milão)
• Israel (Tel Aviv)
• Canadá Oeste (Calgary)
• Europa (Zurique)

Como começar

Para ter acesso à lista completa de regiões onde o Mail Manager está disponível, consulte a documentação de disponibilidade de regiões. Para aprender mais detalhes sobre o serviço, visite a página do produto Amazon SES Mail Manager e a documentação completa. Você pode começar a usar o Mail Manager nessas novas regiões imediatamente através do console da Amazon SES.

Fonte

SES Mail Manager is now available in 10 additional AWS Regions, 27 total (https://aws.amazon.com/about-aws/whats-new/2025/12/ses-mail-manager-10-regions/)

Expansão Global do Pegasus 1.2 no Amazon Bedrock

A AWS anunciou uma expansão significativa na disponibilidade do modelo Pegasus 1.2, desenvolvido pela TwelveLabs, através do Amazon Bedrock. Com a introdução de inferência global entre regiões, o modelo agora está acessível em 23 novas regiões, complementando as sete regiões onde já estava disponível anteriormente. Além disso, o Bedrock passou a oferecer acesso ao modelo em todas as regiões da União Europeia utilizando inferência geográfica entre regiões.

Diferenças nas Estratégias de Inferência

A AWS disponibiliza duas estratégias distintas de processamento para esse modelo. A inferência geográfica entre regiões é ideal para cargas de trabalho que apresentam requisitos específicos de residência de dados ou conformidade regulatória dentro de limites geográficos definidos. Por outro lado, a inferência global entre regiões é recomendada para aplicações que priorizam disponibilidade e performance em múltiplas geografias, permitindo que o processamento aconteça onde houver melhor desempenho.

Capacidades do Modelo Pegasus 1.2

O Pegasus 1.2 é um modelo de linguagem orientado para processamento de vídeos que consegue gerar texto baseado no conteúdo visual, áudio e textual dentro de vídeos. Desenvolvido especificamente para vídeos de longa duração, o modelo se destaca na geração de texto a partir de vídeos e na compreensão temporal, permitindo análises sofisticadas de conteúdo videográfico.

Benefícios da Maior Disponibilidade Regional

Com a expansão do Pegasus 1.2 para essas regiões adicionais, desenvolvedores podem construir aplicações de inteligência em vídeo mais próximas aos seus dados e usuários finais. Essa proximidade reduz a latência das requisições e simplifica a arquitetura geral das soluções, permitindo processamento mais rápido e eficiente.

Próximos Passos

Para obter a lista completa de perfis de inferência suportados e regiões disponíveis para o Pegasus 1.2, consulte a documentação de inferência entre regiões. Para começar a trabalhar com o Pegasus 1.2, acesse o console do Amazon Bedrock. Mais detalhes técnicos e informações adicionais estão disponíveis na página do produto e na documentação do Amazon Bedrock.

Fonte

TwelveLabs’ Pegasus 1.2 model now in 23 new AWS regions via Global cross-region inference (https://aws.amazon.com/about-aws/whats-new/2025/12/twelvelabs-pegasus-available-with-global-cross-region-inference/)

Proteção aprimorada contra ataques DDoS na camada de aplicação

Nos primeiros meses deste ano, a AWS implementou novas camadas de proteção para aplicações, respondendo ao crescimento de ataques de negação de serviço distribuído (DDoS) de curta duração e alto volume na camada 7 (L7). Essas proteções são oferecidas através do grupo de regras gerenciadas Anti-DDoS AMR (Regras Gerenciadas Anti-DDoS da AWS). Embora a configuração padrão seja eficaz para a maioria dos cenários, você pode personalizar a resposta para se adequar à tolerância ao risco da sua aplicação.

Neste artigo, exploraremos como o Anti-DDoS AMR funciona internamente e como você pode ajustar seu comportamento utilizando rótulos e regras adicionais do AWS WAF. Você acompanhará três cenários práticos, cada um demonstrando uma técnica diferente de personalização.

Como o Anti-DDoS AMR funciona

Detecção de anomalias e aplicação de rótulos

O Anti-DDoS AMR estabelece uma linha de base do seu tráfego e a utiliza para detectar anomalias em questão de segundos. Quando um ataque DDoS é identificado, o serviço adiciona metadados às requisições — aquilo que o AWS WAF chama de rótulos. Especificamente, todas as requisições recebem o rótulo event-detected, enquanto as requisições suspeitas de contribuir para o ataque recebem o rótulo ddos-request.

Além disso, rótulos adicionais baseados em confiança são aplicados, como high-suspicion-ddos-request, quando existe alta suspeita de que a requisição faz parte do ataque. Em termos técnicos, um rótulo é um metadado adicionado a uma requisição por uma regra quando ela é correspondida. Após ser adicionado, o rótulo fica disponível para as regras subsequentes, que podem utilizá-lo para enriquecer sua lógica de avaliação.

Estratégias de mitigação padrão

As mitigações padrão combinam dois tipos de ação: bloqueio direto e desafio JavaScript. O desafio funciona apenas com clientes que esperam conteúdo HTML. Por esse motivo, você precisa excluir requisições que não podem ser desafiadas — como chamadas de API — nas configurações do Anti-DDoS AMR. O serviço aplica o rótulo challengeable-request às requisições que não correspondem às exclusões configuradas.

As regras de mitigação padrão são avaliadas na seguinte sequência:

• ChallengeAllDuringEvent: Equivalente à lógica: SE event-detected E challengeable-request, ENTÃO desafiar. Esta regra ativa desafios para todas as requisições elegíveis durante um evento detectado.
• ChallengeDDoSRequests: Equivalente à lógica: SE (high-suspicion-ddos-request OU medium-suspicion-ddos-request OU low-suspicion-ddos-request) E challengeable-request, ENTÃO desafiar. A sensibilidade pode ser ajustada para desafiar apenas requisições de média e alta suspeita.
• DDoSRequests: Equivalente à lógica: SE high-suspicion-ddos-request, ENTÃO bloquear. A sensibilidade pode ser aumentada para bloquear também requisições de média suspeita, por exemplo.

Personalizando sua resposta aos ataques DDoS

Duas abordagens de personalização

Existem dois caminhos principais para personalizar como você responde a ataques DDoS na camada 7. Na primeira abordagem, você configura o Anti-DDoS AMR para a ação desejada e, em seguida, adiciona regras subsequentes para enrijecer ainda mais sua resposta sob condições específicas. Na segunda abordagem, você converte algumas ou todas as regras do Anti-DDoS AMR para modo de contagem e cria regras adicionais que definem sua resposta personalizada.

Em ambas as abordagens, as regras subsequentes são configuradas utilizando condições que você define, combinadas com condições baseadas em rótulos aplicados pelo Anti-DDoS AMR. Para configurar regras com lógica complexa, você precisará usar o editor JSON do AWS WAF ou ferramentas de infraestrutura como código, como AWS CloudFormation ou Terraform.

Exemplo 1: Mitigação mais sensível fora de países principais

Suponha que sua operação ocorra principalmente em dois países: Emirados Árabes Unidos e Arábia Saudita. Você está satisfeito com o comportamento padrão do Anti-DDoS AMR nesses países, mas deseja bloquear mais agressivamente fora deles. Você pode implementar isso com as seguintes regras:

• Anti-DDoS AMR com configurações padrão
• Uma regra customizada que bloqueia se: a requisição vier de fora dos Emirados Árabes Unidos ou Arábia Saudita E a requisição tiver os rótulos high-suspicion-ddos-request ou medium-suspicion-ddos-request

Após adicionar o Anti-DDoS AMR com configuração padrão, crie uma regra customizada subsequente com a seguinte definição JSON:

{
  "Action": {
    "Block": {}
  },
  "Name": "more-sensitive-ddos-mitigation-outside-of-core-countries",
  "Priority": 1,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "NotStatement": {
            "Statement": {
              "GeoMatchStatement": {
                "CountryCodes": [
                  "AE",
                  "SA"
                ]
              }
            }
          }
        },
        {
          "OrStatement": {
            "Statements": [
              {
                "LabelMatchStatement": {
                  "Key": "awswaf:managed:aws:anti-ddos:medium-suspicion-ddos-request",
                  "Scope": "LABEL"
                }
              },
              {
                "LabelMatchStatement": {
                  "Key": "awswaf:managed:aws:anti-ddos:high-suspicion-ddos-request",
                  "Scope": "LABEL"
                }
              }
            ]
          }
        }
      ]
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "more-sensitive-ddos-mitigation-outside-of-core-countries",
    "SampledRequestsEnabled": true
  }
}

De forma similar, durante um ataque, você pode mitigar de forma mais agressiva requisições de fontes incomuns, como aquelas identificadas pelo grupo de regras gerenciadas de reputação de IP como provenientes de provedores de hospedagem e nuvem.

Exemplo 2: Redução de limites de taxa durante ataques DDoS

Imaginemos que sua aplicação possui URLs sensíveis que são computacionalmente intensivas. Para proteger a disponibilidade, você aplicou uma regra de limitação de taxa configurada com um limite de 100 requisições a cada 2 minutos. Você pode enrijecer essa resposta durante um ataque DDoS aplicando um limite mais agressivo. Você pode implementar isso com:

• Anti-DDoS AMR com configurações padrão
• Uma regra de limitação de taxa, restrita às URLs sensíveis, configurada com limite de 100 requisições em janela de 2 minutos
• Uma segunda regra de limitação de taxa, restrita às URLs sensíveis E ao rótulo event-detected, configurada com limite de 10 requisições em janela de 10 minutos

Após adicionar o Anti-DDoS AMR com configuração padrão e sua regra de limitação de taxa para URLs sensíveis, crie uma nova regra de limitação com a seguinte definição JSON:

{
  "Action": {
    "Block": {}
  },
  "Name": "ip-rate-limit-10-10mins-under-ddos",
  "Priority": 2,
  "Statement": {
    "RateBasedStatement": {
      "AggregateKeyType": "IP",
      "EvaluationWindowSec": 600,
      "Limit": 10,
      "ScopeDownStatement": {
        "AndStatement": {
          "Statements": [
            {
              "ByteMatchStatement": {
                "FieldToMatch": {
                  "UriPath": {}
                },
                "PositionalConstraint": "EXACTLY",
                "SearchString": "/sensitive-url",
                "TextTransformations": [
                  {
                    "Priority": 0,
                    "Type": "LOWERCASE"
                  }
                ]
              }
            },
            {
              "LabelMatchStatement": {
                "Key": "awswaf:managed:aws:anti-ddos:event-detected",
                "Scope": "LABEL"
              }
            }
          ]
        }
      }
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "ip-rate-limit-10-10mins-under-ddos",
    "SampledRequestsEnabled": true
  }
}

Exemplo 3: Resposta adaptativa conforme escalabilidade da aplicação

Considere uma aplicação legada que pode escalar com segurança até um certo limite de volume de tráfego, além do qual degrada. Se o volume total de tráfego, incluindo ataque DDoS, estiver abaixo desse limite, você decide não desafiar todas as requisições durante um ataque para evitar impactar a experiência do usuário. Neste cenário, você depende apenas da ação de bloqueio padrão para requisições de alta suspeita. Porém, se o volume total exceder o limite seguro, você ativa a mitigação equivalente a ChallengeDDoSRequests.

Você pode implementar isso com:

• Anti-DDoS AMR com as regras ChallengeAllDuringEvent e ChallengeDDoSRequests configuradas em modo de contagem
• Uma regra de limitação de taxa que conta seu tráfego, configurada com um limite correspondente à capacidade da sua aplicação, que aplica um rótulo customizado — como CapacityExceeded — quando o limite é atingido
• Uma regra que replica ChallengeDDoSRequests, mas apenas quando o rótulo CapacityExceeded está presente: desafiar se os rótulos ddos-request, CapacityExceeded e challengeable-request estão todos presentes

Primeiro, atualize seu Anti-DDoS AMR alterando as ações Challenge para Count.

Em seguida, crie a regra de detecção de capacidade excedida em modo de contagem, usando a seguinte definição JSON:

{
  "Action": {
    "Count": {}
  },
  "Name": "capacity-exceeded-detection",
  "Priority": 7,
  "RuleLabels": [
    {
      "Name": "mycompany:capacityexceeded"
    }
  ],
  "Statement": {
    "RateBasedStatement": {
      "AggregateKeyType": "IP",
      "EvaluationWindowSec": 120,
      "Limit": 10000
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "capacity-exceeded-detection",
    "SampledRequestsEnabled": true
  }
}

Finalmente, crie a regra de desafio usando a seguinte definição JSON:

{
  "Action": {
    "Challenge": {}
  },
  "Name": "challenge-if-ddos-and-capacity-exceeded",
  "Priority": 2,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "LabelMatchStatement": {
            "Key": "mycompany:capacityexceeded",
            "Scope": "LABEL"
          }
        },
        {
          "LabelMatchStatement": {
            "Key": "awswaf:managed:aws:anti-ddos:ddos-request",
            "Scope": "LABEL"
          }
        },
        {
          "LabelMatchStatement": {
            "Key": "awswaf:managed:aws:anti-ddos:challengeable-request",
            "Scope": "LABEL"
          }
        }
      ]
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "challenge-if-ddos-and-capacity-exceeded",
    "SampledRequestsEnabled": true
  }
}

Conclusão

Ao combinar as proteções integradas do Anti-DDoS AMR com lógica customizada, você consegue adaptar suas defesas para corresponder ao seu perfil de risco único, padrões de tráfego e escalabilidade da aplicação. Os exemplos apresentados ilustram como você pode ajustar a sensibilidade, aplicar mitigações mais fortes sob condições específicas e até construir defesas adaptativas que respondem dinamicamente à capacidade do seu sistema.

O sistema dinâmico de rótulos no AWS WAF permite implementar essas personalizações de forma granular. Você pode também utilizar rótulos do AWS WAF para excluir o registro custoso de tráfego de ataque DDoS, otimizando sua observabilidade sem sacrificar a segurança.

Fonte

How to customize your response to layer 7 DDoS attacks using AWS WAF Anti-DDoS AMR (https://aws.amazon.com/blogs/security/how-to-customize-your-response-to-layer-7-ddos-attacks-using-aws-waf-anti-ddos-amr/)

Nova Camada de Armazenamento Aquecido para Kinesis Video Streams

A AWS ampliou as capacidades de armazenamento do Amazon Kinesis Video Streams com a introdução de uma nova camada de armazenamento econômica, designada como “warm tier”. Essa novidade oferece aos desenvolvedores uma opção mais eficiente em custos para manter vídeos e mídia por períodos prolongados, sem sacrificar a performance.

Entendendo as Duas Camadas de Armazenamento

Anteriormente, o Amazon Kinesis Video Streams operava com uma única camada de armazenamento, agora renomeada como “hot tier”. Essa camada permanece otimizada para acesso em tempo real e armazenamento de curta duração, mantendo todas as suas características de baixa latência.

A nova camada “warm” foi projetada especificamente para cenários que exigem retenção de longa duração de mídia. O diferencial está na manutenção de acesso em sub-segundo — mesmo com custos de armazenamento significativamente reduzidos — tornando-a ideal para aplicações que precisam preservar dados históricos sem manter infraestrutura de acesso instantâneo.

Casos de Uso Práticos

A solução beneficia especialmente dois segmentos:

• Segurança residencial: Desenvolvedoras de soluções de monitoramento residencial podem agora oferecer retenção estendida de vídeo, armazenando semanas ou meses de gravações com custos operacionais reduzidos.
• Monitoramento empresarial: Organizações com múltiplas câmeras de vigilância conseguem manter históricos longos para auditoria, conformidade regulatória e análise de incidentes, equilibrando retenção com custos.

Maior Flexibilidade na Configuração

Além das duas camadas de armazenamento, a AWS adicionou controle granular sobre o tamanho dos fragmentos de dados. Desenvolvedores podem agora escolher entre:

• Fragmentos menores: Para casos de uso que exigem latência ultra-baixa e responsividade imediata.
• Fragmentos maiores: Para reduzir custos de ingestão, ideal quando a prioridade é economia de processamento em vez de latência extrema.

Integração com Serviços de IA e Análise

Ambas as camadas (hot e warm) funcionam nativamente com os serviços de visão computacional da AWS. A integração com Amazon Rekognition Video e Amazon SageMaker permite que desenvolvedores construam pipelines contínuos de processamento de vídeo e análise, independente de qual camada de armazenamento estejam utilizando.

Disponibilidade Global

A nova camada warm do Amazon Kinesis Video Streams está disponível em todas as regiões onde o serviço já opera, com a exceção das AWS GovCloud (US) Regions.

Para aprofundar a implementação, consulte o guia de primeiros passos da documentação oficial.

Fonte

Amazon Kinesis Video Streams now supports a new cost effective warm storage tier (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-kinesis-video-streams-warm-storage-tier/)

Novas versões do PostgreSQL no Amazon Aurora

A AWS anunciou o suporte a cinco novas versões secundárias do PostgreSQL no Amazon Aurora PostgreSQL-Compatible Edition: versões 17.6, 16.10, 15.14, 14.19 e 13.22. Essas atualizações incorporam as correções de bugs e melhorias de produtos da comunidade PostgreSQL, além de incluir aprimoramentos específicos do Aurora.

Segurança elevada com Mascaramento Dinâmico de Dados

Um dos destaques desta liberação é o Mascaramento Dinâmico de Dados (DDM — Dynamic Data Masking), disponível nas versões 16.10 e 17.6. Esse recurso de segurança em nível de banco de dados oferece proteção para dados sensíveis, como informações de identificação pessoal, ao mascarar valores de coluna dinamicamente durante a execução de consultas. O aspecto mais importante: o mascaramento ocorre em tempo de consulta, com base em políticas de função de acesso, sem alterar os dados armazenados de fato.

Outras melhorias implementadas

Além da segurança, esta versão traz aprimoramentos significativos em desempenho e confiabilidade. A introdução de um compartilhamento de plano de cache melhora a eficiência das operações. Também houve melhoria no objetivo de tempo de recuperação (RTO — Recovery Time Objective), reduzindo o tempo necessário para retomar as operações após uma falha. Para ambientes multi-região, a troca de banco de dados global (Global Database switchovers) agora funciona de forma otimizada.

Como começar com as novas versões

Para utilizar as versões mais recentes, você pode criar um novo banco de dados Aurora PostgreSQL-compatible diretamente pelo Console de Gerenciamento do Amazon RDS em poucos cliques. Caso já possua um banco de dados existente, também é possível fazer uma atualização. A AWS recomenda consultar a documentação do Aurora para compreender melhor o processo de upgrade.

Planejamento de atualizações

Para decidir com qual frequência atualizar e como planejar seu processo de upgrade, consulte a política de versão do Aurora. Esse documento fornece orientações sobre ciclos de suporte e estratégias de migração.

Disponibilidade global

Essas novas versões estão disponíveis em todas as regiões comerciais da AWS, assim como nas regiões do AWS GovCloud (US).

Sobre o Amazon Aurora

O Amazon Aurora é projetado para oferecer desempenho e disponibilidade sem precedentes em escala global, com compatibilidade completa com MySQL e PostgreSQL. A plataforma oferece segurança integrada, backups contínuos, computação serverless, até 15 réplicas de leitura, replicação automatizada entre regiões e integração com outros serviços da AWS. Para dar seus primeiros passos, consulte a página de primeiros passos.

Fonte

Amazon Aurora now supports PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-aurora-minor-versions-17-6-16-10-15-14-14-19-13-22)

O desafio da infraestrutura de chaves públicas em escala

A Infraestrutura de Chaves Públicas (PKI) é fundamental para garantir a segurança e estabelecer confiança nas comunicações digitais. À medida que as organizações expandem suas operações digitais, precisam emitir e revogar certificados continuamente. A revogação de certificados é especialmente importante quando funcionários se desligam, durante migrações para novas hierarquias de autoridades certificadoras, para atender requisitos de conformidade ou em resposta a incidentes de segurança.

Para rastrear certificados revogados, as organizações podem usar a Lista de Revogação de Certificados (CRL) ou o Protocolo de Status de Certificado Online (OCSP). A Autoridade Certificadora Privada da AWS (AWS Private CA) permite criar uma autoridade certificadora que publica informações de revogação através desses métodos, possibilitando que sistemas verifiquem a validade dos certificados.

Porém, empresas que enfrentam crescimento significativo encontram limitações ao usar CRLs completas para emitir e revogar mais de 1 milhão de certificados. Simplesmente aumentar o tamanho do arquivo CRL não é uma solução viável, pois muitas aplicações não conseguem processar arquivos CRL grandes — algumas exigem um máximo de 1 MB. Além disso, soluções alternativas como OCSP podem ser rejeitadas por grandes repositórios de confiança e fornecedores de navegadores devido a preocupações com privacidade e requisitos de conformidade. Essas restrições impactam significativamente a capacidade das organizações de escalar sua infraestrutura de PKI de forma eficiente, mantendo segurança e conformidade.

A solução: CRLs particionadas

A AWS Private CA agora oferece CRLs particionadas como resposta a esses desafios. Essa funcionalidade permite a emissão e revogação de até 100 milhões de certificados por CA, distribuindo as informações de revogação em múltiplas partições de CRL menores e gerenciáveis, cada uma mantendo um tamanho máximo de 1 MB para melhor compatibilidade com aplicações.

No momento da emissão, os certificados são automaticamente vinculados a partições CRL específicas através de uma extensão crítica de Ponto de Distribuição do Emissor (IDP), que contém uma URI única identificando a partição. A validação funciona comparando a URI de CRL na extensão de Ponto de Distribuição de CRL (CDP) do certificado contra a extensão IDP da CRL, proporcionando validação precisa.

Capacidades principais da nova funcionalidade

As CRLs particionadas oferecem diversos benefícios operacionais:

• Escalabilidade automática do limite de emissão de certificados: de 1 milhão para 100 milhões de certificados por CA
• Suporte tanto para novas quanto para autoridades certificadoras existentes
• Opções de configuração flexível para nomes e caminhos de CRL
• Compatibilidade reversa, preservando a funcionalidade completa de CRL existente enquanto oferece CRL particionada como recurso opcional
• Conformidade com padrões da indústria, como o RFC5280, mantendo eficiência operacional e segurança

Configurando CRLs particionadas na AWS Private CA

A configuração de CRLs particionadas em autoridades certificadoras existentes segue um processo estruturado através do console da AWS:

Passos de configuração

Para ativar CRLs particionadas, acesse sua autoridade certificadora privada no console da AWS Private CA. Primeiro, selecione a CA desejada e navegue até a aba de configuração de revogação. Se a distribuição de CRL estiver desabilitada, você precisará ativá-la nos próximos passos.

Ao editar as configurações, marque a opção para ativar distribuição de CRL e selecione um bucket do Amazon S3 existente para armazenar os arquivos de CRL. É importante verificar que o recurso de Bloqueio de Acesso Público está desabilitado para sua conta e para o bucket. Se necessário, você pode consultar a documentação sobre criar uma CA privada na AWS Private CA para obter instruções detalhadas sobre políticas de acesso. Para configurações de segurança mais específicas, consulte o guia sobre políticas de acesso para CRLs no Amazon S3 e aprenda como adicionar uma política de bucket usando o console do Amazon S3.

Na seção de configurações de CRL, marque a caixa para ativar o particionamento. Isso habilitará o uso de CRL particionada. Se você não ativar o particionamento, uma CRL completa será criada e sua CA ficará sujeita ao limite de 1 milhão de certificados emitidos ou revogados. Para informações sobre limites de capacidade, consulte as cotas da AWS Private CA.

Após salvar as alterações, a distribuição de CRL aparecerá como habilitada com CRLs particionadas, e o limite de 1 milhão será automaticamente atualizado para 100 milhões por CA.

Benefícios para segurança, operações e conformidade

As CRLs particionadas da AWS Private CA oferecem benefícios substanciais em múltiplas dimensões organizacionais.

Perspectiva de segurança

A funcionalidade mantém a validação de certificados enquanto suporta capacidades abrangentes de revogação para até 100 milhões de certificados por CA. Isso permite que as organizações respondam efetivamente a incidentes de segurança ou comprometimento de chaves.

Perspectiva operacional

Operacionalmente, o recurso reduz a necessidade de rotação de autoridades certificadoras, diminuindo a sobrecarga administrativa e simplificando o gerenciamento de PKI. Manter os tamanhos de partição de CRL em 1 MB oferece compatibilidade ampla com aplicações, enquanto suporta gerenciamento automático de partições.

Perspectiva de conformidade

Para conformidade regulatória, a solução permite que as organizações atendam a múltiplos requisitos da indústria:

• Suporte aos princípios e critérios de WebTrust
• Conformidade com os padrões ETSI TSP
• Compatibilidade com o RFC5280
• Alinhamento com requisitos de repositórios de confiança de navegadores para suporte tanto a CRL quanto a OCSP
• Flexibilidade para padrões emergentes, como Matter

Custo e disponibilidade

Um ponto importante é que você pode maximizar o valor de suas autoridades certificadoras de propósito geral ou vida curta ativando CRL particionada sem custos adicionais, além da AWS Private CA e do Amazon Simple Storage Service (Amazon S3). Todos os certificados continuam sendo revogáveis, proporcionando uma solução completa e econômica para gestão de PKI em escala.

Próximos passos

Organizações interessadas em começar podem criar sua autoridade certificadora através do console de gerenciamento da AWS Private CA. A nova funcionalidade está disponível para configuração imediata em autoridades certificadoras existentes ou novas.

Fonte

AWS Private Certificate Authority now supports partitioned CRLs (https://aws.amazon.com/blogs/security/aws-private-certificate-authority-now-supports-partitioned-crls/)

Uma nova forma de gerenciar secrets no Kubernetes

A AWS anunciou um novo provedor para o Secrets Store CSI Driver destinado ao Amazon EKS (Elastic Kubernetes Service), que funciona como um add-on gerenciado para a plataforma. Esse novo componente permite que as equipes de desenvolvimento recuperem secrets do AWS Secrets Manager e parâmetros do AWS Systems Manager Parameter Store, montando-os como arquivos nos pods do Kubernetes. A solução é clara em sua proposta: oferecer uma forma segura, confiável e gerenciada de acessar credenciais dentro de ambientes containerizados.

O novo add-on simplifica significativamente o processo de instalação e configuração, funciona tanto em instâncias de Amazon Elastic Compute Cloud (EC2) quanto em nós híbridos, e é mantido com as correções de segurança e atualizações mais recentes. Para equipes brasileiras que trabalham com Kubernetes em ambientes AWS, isso representa uma redução considerável no tempo necessário para implementar práticas seguras de gestão de credenciais.

Por que isso importa para a segurança

Historicamente, um dos maiores desafios em ambientes Kubernetes é evitar o uso de credenciais hardcoded no código-fonte das aplicações. O Secrets Manager já resolve essa questão no contexto geral da AWS, mas integrá-lo nativamente com Kubernetes exigia passos complexos de instalação e manutenção.

O novo provedor funciona como um DaemonSet do Kubernetes de código aberto, trabalhando em conjunto com o Secrets Store CSI Driver mantido pela comunidade Kubernetes. Essa arquitetura permite que o driver de armazenamento de secrets funcione de forma nativa no cluster, sem necessidade de integração customizada.

Benefícios do add-on gerenciado

Os add-ons do EKS da AWS proporcionam instalação e gerenciamento de um conjunto curado de componentes para clusters EKS. Em vez de depender de métodos legados como Helm ou kubectl, o novo add-on reduz significativamente o tempo de setup e aumenta a estabilidade geral dos clusters. Além disso, o gerenciamento centralizado pela AWS garante que patches de segurança e correções de bugs sejam aplicados de forma automática e consistente.

Considerações de segurança

Como em qualquer solução que envolve gestão de credenciais, a segurança é uma preocupação central. A AWS recomenda armazenar secrets em cache na memória quando possível, reduzindo a frequência de acesso ao Secrets Manager. Para equipes que preferem uma experiência totalmente nativa do Kubernetes, o AWS Secrets Manager Agent oferece uma alternativa complementar.

Do ponto de vista de controle de acesso, qualquer entidade IAM (Identity and Access Management) que precise acessar os secrets deve ter permissões explícitas no Secrets Manager. Se usar Parameter Store, também precisa de permissões específicas para ler parâmetros. As políticas de recurso funcionam como mecanismo adicional de controle de acesso, e é especialmente importante quando se acessa secrets de contas AWS diferentes.

O add-on inclui suporte a endpoints FIPS, alinhando-se com exigências de conformidade em ambientes altamente regulados. A AWS fornece uma política IAM gerenciada chamada AWSSecretsManagerClientReadOnlyAccess, que é a recomendação padrão para uso com esse add-on. Para implementar o princípio do menor privilégio, é possível criar políticas customizadas direcionadas apenas aos secrets específicos que cada aplicação precisa acessar.

Guia prático de implementação

Para equipes que desejam começar, a AWS disponibiliza um fluxo de trabalho completo desde a criação do cluster até a recuperação efetiva de um secret. Abaixo, apresentamos um resumo dos passos principais.

Pré-requisitos

Antes de iniciar, certifique-se de ter:

• Credenciais AWS configuradas no seu ambiente para permitir chamadas à API
• AWS CLI v2 ou superior
• A região preferida configurada no seu ambiente via comando: aws configure set default.region <regiao-preferida>
• As ferramentas de linha de comando kubectl e eksctl instaladas
• Um arquivo de deployment Kubernetes disponível no repositório do provedor

Criando o cluster EKS

Comece criando uma variável de shell com o nome do seu cluster:

CLUSTER_NAME="my-test-cluster"

Depois, crie o cluster:

eksctl create cluster $CLUSTER_NAME

O eksctl usará automaticamente uma versão recente do Kubernetes e criará todos os recursos necessários para o funcionamento do cluster. Esse comando geralmente leva cerca de 15 minutos.

Criando um secret de teste

Crie um secret chamado addon_secret no Secrets Manager:

aws secretsmanager create-secret \
--name addon_secret \
--secret-string "super secret!"

Instalando o add-on do Secrets Store CSI Driver

Use o eksctl para instalar o add-on:

eksctl create addon \
--cluster $CLUSTER_NAME \
--name aws-secrets-store-csi-driver-provider

Configurando autenticação com IAM e Pod Identity

Crie uma role IAM que o serviço de Pod Identity do EKS possa assumir (substitua <regiao> pela sua região AWS):

ROLE_ARN=$(aws --region <regiao> --query Role.Arn --output text iam create-role --role-name nginx-deployment-role --assume-role-policy-document '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}')

Anexe a política gerenciada à role que você acabou de criar:

aws iam attach-role-policy \
--role-name nginx-deployment-role \
--policy-arn arn:aws:iam::aws:policy/AWSSecretsManagerClientReadOnlyAccess

Instalando o EKS Pod Identity Agent

O add-on oferece dois métodos de autenticação: IAM roles para service accounts (IRSA) e EKS Pod Identity. Neste exemplo, usaremos Pod Identity. Instale o agent:

eksctl create addon \
--cluster $CLUSTER_NAME \
--name eks-pod-identity-agent

Depois, crie a associação de Pod Identity para o cluster (substituindo <regiao> pela sua região):

eksctl create podidentityassociation \
--cluster $CLUSTER_NAME \
--namespace default \
--region <regiao> \
--service-account-name nginx-pod-identity-deployment-sa \
--role-arn $ROLE_ARN \
--create-service-account true

Configurando a SecretProviderClass

A SecretProviderClass é um arquivo YAML que define quais secrets e parâmetros devem ser montados como arquivos no seu cluster. Crie um arquivo chamado spc.yaml com o seguinte conteúdo:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: nginx-pod-identity-deployment-aws-secrets
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "addon_secret"
        objectType: "secretsmanager"
        usePodIdentity: "true"

Aplique a configuração:

kubectl apply -f spc.yaml

Para detalhes adicionais sobre a SecretProviderClass, consulte a documentação no GitHub do provedor.

Implantando o pod no cluster

Use o arquivo de deployment disponível no repositório para implantar o pod:

kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/examples/ExampleDeployment-PodIdentity.yaml

Isso montará o addon_secret no caminho /mnt/secrets-store dentro do seu cluster.

Recuperando e verificando o secret

Para confirmar que o secret foi montado com sucesso, execute:

kubectl exec -it $(kubectl get pods | awk '/nginx-pod-identity-deployment/{print $1}' | head -1) -- cat /mnt/secrets-store/addon_secret

Você deverá ver a saída:

super secret!

Parabéns! Você recuperou com sucesso um secret do Secrets Manager e o montou como arquivo no seu cluster Kubernetes usando o novo add-on da AWS.

Limpeza de recursos

Quando terminar a implementação de testes, limpe os recursos criados:

aws secretsmanager delete-secret \
--secret-id addon_secret \
--force-delete-without-recovery

aws iam delete-role --role-name nginx-deployment-role

eksctl delete cluster $CLUSTER_NAME

Alternativas de instalação

Embora o add-on gerenciado seja a forma recomendada, a AWS também oferece opções alternativas de instalação usando AWS CloudFormation, AWS Command Line Interface (AWS CLI), console de gerenciamento ou a própria API do EKS.

Conclusão

O novo add-on do Secrets Store CSI Driver para EKS representa um avanço significativo na forma como as equipes podem gerenciar credenciais em ambientes Kubernetes hospedados na AWS. Ao oferecer instalação simplificada, gerenciamento centralizado, atualizações de segurança automáticas e integração estreita com o EKS, a solução reduz tanto a complexidade operacional quanto o risco de segurança associado ao armazenamento inadequado de secrets.

Para organizações brasileiras que trabalham com Kubernetes em escala, esse add-on se posiciona como uma alternativa muito mais prática do que métodos legados de instalação, mantendo a flexibilidade e a conformidade com padrões de segurança internacionais. A documentação técnica completa está disponível para equipes que desejam explorar cenários mais avançados e configurações específicas.

Saiba mais

• Amazon EKS add-ons: configuração avançada
• Considerações adicionais de segurança no GitHub
• Documentação do AWS Secrets Manager
• AWS Security Blog

Fonte

How to use the Secrets Store CSI Driver provider Amazon EKS add-on with Secrets Manager (https://aws.amazon.com/blogs/security/how-to-use-the-secrets-store-csi-driver-provider-amazon-eks-add-on-with-secrets-manager/)

O Desafio de Escalar Agentes de IA com Segurança

As empresas estão adotando agentes de IA em ritmo acelerado para automatizar fluxos de trabalho e aumentar produtividade. No entanto, esse crescimento traz um problema crítico de segurança: como garantir que centenas de agentes autônomos acessem apenas as ferramentas que lhes são permitidas quando milhares de ferramentas estão distribuídas entre diferentes times e unidades de negócio?

Diferentemente de arquiteturas tradicionais com alguns agentes chamando poucas APIs, as plataformas de IA modernas envolvem cenários muito mais complexos. Uma organização pode ter centenas de agentes, aplicações de IA para consumidores e fluxos de trabalho automatizados precisando acessar milhares de ferramentas através do Protocolo de Contexto de Modelo (MCP). Cada acesso precisa ser validado não apenas pela identidade do agente, mas também pela identidade do usuário, contexto de execução, canal de acesso e permissões que podem mudar dinamicamente.

Apresentando os Interceptadores do Gateway AgentCore

Para resolver esses desafios de segurança e governança em escala, a AWS lançou um novo recurso: interceptadores de gateway para o Amazon Bedrock AgentCore Gateway. Trata-se de uma capacidade poderosa que fornece segurança refinada, controle de acesso dinâmico e gerenciamento flexível de esquemas.

Os interceptadores funcionam como pontos programáveis onde você pode injetar lógica de segurança personalizada, permitindo transformar requisições e respostas sem modificar as ferramentas subjacentes ou os servidores MCP.

Dois Pontos de Interceptação

O gateway oferece interceptação em dois momentos críticos do ciclo de requisição-resposta:

• Interceptador de requisição do gateway: Processa requisições recebidas antes de atingirem as ferramentas alvo, permitindo controle de acesso refinado, validação de credenciais, criação de trilhas de auditoria e tradução de esquemas.
• Interceptador de resposta do gateway: Processa respostas de saída antes de retornarem ao agente chamador, possibilitando filtragem de ferramentas, criação de trilhas de auditoria e tradução de esquemas com base em permissões do usuário.

Principais Capacidades dos Interceptadores

Controle de Acesso Refinado para Ferramentas

Organizações já implantam milhares de ferramentas MCP através de um gateway unificado. O desafio é garantir que cada principal chamador — seja um agente, usuário ou aplicação — acesse apenas as ferramentas autorizadas, baseando-se em múltiplos fatores dinâmicos como identidade do agente, identidade do usuário e contexto de execução.

Os interceptadores de requisição garantem que a chamada de uma ferramenta seja bloqueada se o usuário não tiver permissão específica. Isso é feito através da extração e validação do token JWT (Token Web JSON), verificação do escopo do usuário e bloqueio de invocações não autorizadas com um erro MCP estruturado — tudo antes que a ferramenta seja executada.

Filtragem Dinâmica de Ferramentas

Agentes descobrem ferramentas disponíveis através de buscas semânticas e operações padrão de listagem. Sem controles apropriados, os servidores MCP retornariam a lista completa de ferramentas independentemente do nível de autorização do agente ou usuário, criando vulnerabilidades de segurança.

Os interceptadores de resposta resolvem isso filtrando a lista de ferramentas antes que retorne ao agente. Para cada ferramenta na lista, o interceptador avalia se o usuário tem autorização com base nos escopos do JWT, removendo as ferramentas não autorizadas antes de enviar a resposta.

Tradução de Esquemas e Proteção de Dados

Empresas enfrentam desafios complexos ao gerenciar contratos entre agentes de IA e APIs downstream. É necessário mapear dinamicamente esquemas de requisição MCP para esquemas de API correspondentes, possibilitando proteção crítica de dados como redação ou remoção de informações pessoalmente identificáveis (PII) que usuários possam enviar em prompts.

O desacoplamento entre o esquema MCP e as implementações downstream permite que times de backend modifiquem suas APIs, alterem nomes de campos, reestruturem payloads ou atualizem requisitos de autenticação sem quebrar contratos de agentes ou forçando retreinamento de modelos.

Propagação de Headers Customizados e Gerenciamento de Contexto de Identidade

Quando agentes interagem com múltiplos serviços downstream, manter a identidade do usuário através de limites de serviços torna-se crítico para segurança, conformidade e trilhas de auditoria. Os interceptadores de requisição extraem informações de identidade dos headers de requisição recebida, transformam-nas no formato esperado pelos serviços downstream e enriquecem requisições antes que alcancem os serviços alvo.

Abordagens de Autorização: Representação versus Agindo em Nome de

Uma decisão fundamental em como a identidade flui através de fluxos de trabalho multi-hop é escolher entre representação (impersonation) ou agindo em nome de (act-on-behalf).

Abordagem de Representação (Não Recomendada)

Na representação, o token JWT original do usuário é passado inalterado por cada etapa da cadeia de chamadas. Embora mais simples de implementar, cria riscos de segurança significativos:

• Serviços downstream recebem tokens com privilégios mais amplos do que necessário
• Risco aumentado de escalação de privilégio se qualquer componente for comprometido
• Escopo do token não pode ser limitado a alvos downstream específicos
• Vulnerável a ataques de deputy confuso, onde serviços comprometidos abusam tokens excessivamente privilegiados

Abordagem Agindo em Nome de (Recomendada)

Na abordagem agindo em nome de, cada etapa do fluxo de trabalho recebe um token separado e limitado especificamente emitido para aquele alvo downstream, enquanto JWT é usado para propagar contexto de execução. Isso implementa o princípio do menor privilégio e oferece benefícios significativos:

• Cada serviço recebe apenas as permissões necessárias para acessar APIs específicas downstream
• Raio de explosão reduzido — tokens comprometidos têm escopo limitado e não podem ser reutilizados
• Auditoria melhorada — cadeia clara de custódia mostrando qual serviço agiu em nome do usuário
• Prevenção de deputy confuso — tokens de escopo limitado impedem serviços de serem enganados

Implementação de Controle de Acesso Refinado

Usando Escopos JWT

O controle de acesso refinado usa valores de escopo JWT emitidos pelo Amazon Cognito ou outro provedor OAuth 2. A convenção segue um padrão simples: usuários recebem acesso completo a um alvo MCP (por exemplo, mcp-target-123) ou acesso em nível de ferramenta (por exemplo, mcp-target-123:getOrder).

O interceptador de requisição valida permissões em tempo de execução através de etapas simples:

• Extrai e decodifica o JWT para recuperar a solicitação de escopo
• Identifica qual ferramenta está sendo invocada
• Bloqueia a requisição se o usuário não tiver acesso completo ao alvo ou permissão específica da ferramenta
• Retorna um erro MCP estruturado para invocações não autorizadas

Este modelo é facilmente extensível com claims adicionais (como tenantId e workspaceId) para arquiteturas multi-tenant.

Modelos de Autorização Flexível: Sem Autenticação e OAuth

Muitas empresas necessitam de modelos de autorização flexíveis que equilibrem descoberta com segurança. Um cenário comum é permitir que agentes e aplicações descubram e busquem ferramentas MCP disponíveis sem autenticação, facilitando exploração perfeita do catálogo de ferramentas. Porém, ao invocar ferramentas, é necessária autorização OAuth rigorosa.

O gateway agora suporta isso através de um tipo de autorização “Sem Autenticação” (No Auth) em nível de gateway para todas as chamadas recebidas. Quando configurado, torna todos os alvo e ferramentas acessíveis sem autenticação para fins de descoberta.

Para aplicar autorização OAuth em nível de método (ListTools versus CallTools) ou implementar políticas de autorização por ferramenta, você usa interceptadores de gateway para examinar o JWT recebido, validá-lo contra requisitos de RFC 6749 usando a URL de descoberta do servidor de autorização, e programaticamente permitir ou negar acesso a métodos ou chamadas de ferramentas específicas.

Observabilidade e Monitoramento

A observabilidade abrangente fornecida pelo AgentCore Observability é crítica para monitorar, depurar e auditar fluxos de trabalho de agentes de IA. Os interceptadores de gateway aplicam autorização, transformam requisições e filtram dados antes que serviços downstream executem, tornando a camada de observabilidade um limite crítico de segurança.

Os interceptadores integram-se automaticamente com AgentCore Observability, fornecendo:

• Monitoramento em tempo real de decisões de autorização
• Identificação de gargalos de desempenho através de métricas de duração e invocação
• Rastreabilidade ponta a ponta através de fluxos de trabalho de agentes multi-hop
• Atributos de identidade e contexto para validar comportamento de autorização em ambientes multi-tenant

Integração do AgentCore Gateway

O AgentCore Gateway transforma APIs e funções AWS Lambda existentes em ferramentas compatíveis com agentes, conecta-se a servidores MCP existentes e fornece integração perfeita com ferramentas e serviços de negócio essenciais de terceiros como Jira, Asana e Zendesk. Este ponto de acesso unificado habilita integração segura entre sistemas corporativos.

Com o lançamento dos interceptadores de gateway, as organizações podem implementar controle de acesso refinado e gerenciamento de credenciais através de funções Lambda customizadas nos dois pontos críticos do ciclo de requisição-resposta.

Conclusão

Os interceptadores de gateway do AgentCore resolvem os desafios fundamentais de segurança que organizações enfrentam ao implantar sistemas de IA em escala. Fornecendo pontos de interceptação programáveis para requisições e respostas, as organizações implementam controle de acesso refinado sem modificar implementações de ferramentas subjacentes ou arquiteturas de servidores MCP.

À medida que organizações escalam para centenas de agentes e milhares de ferramentas, os interceptadores de gateway oferecem a flexibilidade e controle necessários para manter segurança, conformidade e visibilidade operacional através de implantações complexas de IA, alinhando-se com padrões de integração empresarial e práticas recomendadas de segurança.

Para explorar como aplicar interceptadores de gateway a desafios empresariais comuns, consulte os exemplos de controle de acesso refinado e propagação de headers customizados. Para documentação completa sobre configuração e implementação de interceptadores de gateway, consulte Controle de acesso refinado para Amazon Bedrock AgentCore Gateway.

Fonte

Apply fine-grained access control with Bedrock AgentCore Gateway interceptors (https://aws.amazon.com/blogs/machine-learning/apply-fine-grained-access-control-with-bedrock-agentcore-gateway-interceptors/)

Controle centralizado de segurança no S3

A AWS anunciou uma importante expansão do Block Public Access (Bloqueio de Acesso Público) para o Amazon S3. O serviço agora permite gerenciamento centralizado através do AWS Organizations, possibilitando que organizações padronizem e enforcem configurações de acesso público em todos os accounts de sua estrutura por meio de uma única configuração de política.

Como funciona o Block Public Access em nível organizacional

Propagação automática de políticas

O Block Public Access em nível organizacional opera através de uma configuração única que controla todas as definições de acesso público em todos os accounts dentro da organização. Quando você anexa a política no root ou em uma Unidade Organizacional (OU, do inglês Organizational Unit) da sua organização, ela se propaga automaticamente para todos os sub-accounts dentro desse escopo. Contas-membro novas herdam a política de forma automática, eliminando a necessidade de configuração manual individual.

Flexibilidade de aplicação

Além da abordagem centralizada, você também tem a opção de aplicar a política a accounts específicos quando precisa de um controle mais granular. Essa flexibilidade permite que organizações balanceiem a uniformidade de segurança com necessidades específicas de diferentes times ou departamentos.

Como começar

Configuração através do console

Para iniciar, acesse o console do AWS Organizations e utilize o checkbox “Bloquear todo acesso público” ou use o editor JSON para configurações mais avançadas. A interface permite que você customize exatamente quais tipos de acesso público devem ser bloqueados em toda a sua organização.

Monitoramento e auditoria

A AWS CloudTrail pode ser utilizada para auditar e acompanhar a anexação de políticas, bem como monitorar o enforcement da política em todas as contas-membro. Isso oferece visibilidade completa sobre como as configurações de segurança estão sendo aplicadas e mantidas em toda a organização.

Disponibilidade e acesso

Esse recurso está disponível no console do AWS Organizations, bem como através da AWS CLI (Interface de Linha de Comando, do inglês Command Line Interface) e SDKs (Kits de Desenvolvimento de Software, do inglês Software Development Kits), em todas as regiões AWS onde AWS Organizations e Amazon S3 são suportados. Importante destacar que não há custos adicionais para usar esse recurso.

Para aprofundar seus conhecimentos, você pode consultar o guia do usuário do AWS Organizations e a documentação do Block Public Access do Amazon S3 para detalhes técnicos e melhores práticas de implementação.

Fonte

Amazon S3 Block Public Access now supports organization-level enforcement (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-s3-block-public-access-organization-level-enforcement)