Category: Uncategorized

  • Como verificar milhares de contratos de locação por conformidade usando Amazon Quick e o padrão Adjudicated Query

    O problema de conformidade em escala

    Imagine um operador de portfólio imobiliário com 50.000 contratos de locação distribuídos por vários estados americanos. Cada estado tem suas próprias leis de locação — limites de multa por atraso, prazos de notificação, tetos para depósito de segurança — e essas leis mudam conforme o calendário legislativo, não conforme a conveniência do operador. Quando uma regulação muda, a equipe de conformidade precisa identificar quais contratos estão fora do padrão.

    Em volumes pequenos, um paralegal lê os contratos manualmente. A resposta é confiável porque há um humano por trás dela. A partir de certo volume, isso deixa de ser viável. O trabalho passa para software, e surge um novo problema: o resultado vira um número numa tela que ninguém consegue verificar de forma independente.

    Dois requisitos emergem dessa realidade:

    • Completude comprovável: afirmar “verificamos todos os 22.910 contratos do Texas” precisa ser verdadeiro e demonstrável. Um registro não avaliado deve ser reportado como não avaliado, nunca omitido silenciosamente.
    • Defensibilidade: uma conclusão pode ser contestada meses depois em litígio, auditoria ou fiscalização regulatória. Defendê-la exige saber qual versão de qual regra foi aplicada, a qual trecho de texto, por qual método, em qual data.

    Essas duas propriedades são o que distingue esse problema de uma busca corporativa comum. Geração Aumentada por Recuperação (RAG) resolve o problema de acessibilidade, mas não consegue satisfazer nenhuma das duas propriedades: busca por similaridade não tem um limiar que signifique “todos eles”, e uma amostra ranqueada nunca sabe o que excluiu. Text-to-SQL reduz a lacuna, mas carrega um risco estrutural: um predicado alucinado pode silenciosamente reduzir a população avaliada, e o número resultante parece exato mesmo quando o escopo está errado.

    O padrão Adjudicated Query

    A AWS publicou uma arquitetura de referência que resolve esse dilema com o que chamou de padrão Adjudicated Query. A ideia central é criar uma camada conversacional delimitada sobre um motor de regras determinístico. O modelo de linguagem faz exatamente duas coisas: traduz a pergunta em linguagem natural para uma chamada em um conjunto fixo de operações tipadas, e narra o resultado que retorna. Ele nunca escreve uma consulta, nunca define a população e nunca realiza uma determinação.

    Por trás dessa fronteira fica o motor de regras. As regras são dados versionados, não código. O motor conhece operadores de comparação genéricos — maior ou igual, menor ou igual, igual, existe — e não contém nenhuma ramificação nomeando uma jurisdição ou tópico específico. Uma mudança na lei é uma edição em uma linha do livro de regras, não um deploy de código.

    Cada varredura de conformidade produz um recibo de completude: um invariante afirmado onde conforme + em violação + ambíguo + ilegível deve ser igual ao total varrido. Esse invariante é calculado antes de qualquer dado ser persistido. Uma execução que não consegue contabilizar sua população nunca é concluída. Não existe caminho pelo qual um registro seja silenciosamente ignorado.

    Por que não RAG ou Text-to-SQL?

    A comparação entre as abordagens deixa claro o posicionamento do padrão:

    • Recuperação semântica (RAG): trabalha com amostras ranqueadas; completude de população é estruturalmente impossível; defensibilidade apenas parcial.
    • Consultas geradas (Text-to-SQL): completude alegada, mas não comprovável; risco de redução silenciosa da população; defensibilidade possível se bem modelado.
    • Motor de regras + BI (sem chat): completude exata e comprovada; totalmente defensável; mas sem camada conversacional.
    • Adjudicated Query: completude exata e comprovada; totalmente defensável; com acesso em linguagem natural.

    O padrão Adjudicated Query adiciona acesso em linguagem natural à combinação de motor de regras e Inteligência de Negócios (BI) sem sacrificar a garantia. É a escolha certa quando usuários responsáveis precisam de acesso conversacional e um registro perdido é uma responsabilidade legal, não apenas um inconveniente.

    Arquitetura de referência

    A arquitetura proposta conecta os componentes da seguinte forma: um analista de conformidade interage com duas superfícies no Amazon Quick — um agente de chat para fazer perguntas e um painel do Amazon QuickSight para navegar pelo conjunto completo de resultados.

    O agente de chat primeiro obtém um token OAuth do Amazon Cognito. Em seguida, envia requisições via Protocolo de Contexto de Modelo (MCP) por um Amazon API Gateway HTTP API, que valida o token antes de encaminhar para uma função AWS Lambda. Essa função hospeda o servidor MCP e o motor de regras, lê e escreve no Amazon Aurora Serverless v2 via RDS Data API, e chama o Amazon Bedrock apenas para o caminho exploratório de busca em cláusulas. O painel do Amazon QuickSight lê o mesmo banco Aurora diretamente por uma conexão de Nuvem Virtual Privada (VPC).

    Como as duas superfícies leem do mesmo armazenamento, o recibo de completude é uma única fonte de verdade. O agente de chat carrega o recibo de completude e um link para o painel. O painel carrega o volume completo, porque milhares de linhas não cabem numa mensagem de chat.

    A superfície de operações delimitada

    O servidor MCP expõe exatamente seis ferramentas, cada uma com uma semântica distinta:

    • sweep_compliance: varredura exaustiva da população contra as regras vigentes em uma data declarada. Resultado oficial — cada contrato contabilizado em um recibo calculado. Grava os achados.
    • simulate_rule_change: uma regra testada com um valor proposto contra a linha de base aprovada. Resultado exploratório — apenas contagens direcionais. Não registra nada.
    • explore_clauses: Top K por similaridade semântica dentro de uma população filtrada. Resultado interpretativo — amostra ranqueada. Não responde “quantos”.
    • get_finding: cadeia completa de evidências de um único achado. Drill-down em uma determinação específica.
    • list_rules: o livro de regras vigente em uma data, com versões, citações e aprovadores. Consulta de referência.
    • check_connection: verificação de disponibilidade do transporte, sem tocar em dados.

    Essa superfície delimitada elimina o caminho para o risco de redução silenciosa de população presente em consultas geradas. Como o modelo só pode selecionar entre um conjunto fixo de operações cuja lógica de população foi escrita, revisada e testada por pessoas, ele não tem como compor uma população errada.

    Componentes principais da arquitetura

    • Amazon Quick: interface conversacional e camada de orquestração do agente. Autentica no servidor MCP usando OAuth de dois fatores (2LO) via Amazon Cognito e cuida da descoberta de ferramentas e narração das respostas.
    • Amazon Aurora Serverless v2 (Postgres + pgvector): armazena o livro de regras, registros de contratos, status de extração e determinações em um único banco relacional. Colocar tudo em um banco torna o recibo de completude uma contagem SQL — uma forma econômica de tornar a garantia central inspecionável.
    • AWS Lambda: hospeda o servidor MCP (JSON-RPC 2.0 sobre HTTP streamável, usando enquadramento Server-Sent Events para respostas) e o motor de regras. Operações delimitadas se traduzem em SQL baseado em conjuntos usando valores de regras vinculados como parâmetros. Nenhuma linguagem natural chega à camada de consulta.
    • Amazon API Gateway HTTP API: porta de entrada com autorizador de Token Web JSON (JWT) respaldado pelo Amazon Cognito. Nenhuma rota não autenticada existe.
    • Amazon Bedrock: alimenta apenas o caminho exploratório, usando Amazon Titan Text Embeddings V2 (amazon.titan-embed-text-v2:0) para ranqueamento por similaridade semântica e Anthropic Claude Sonnet 5 para avaliação qualitativa de cláusulas. Não é consultado para determinações oficiais de conformidade.
    • Amazon QuickSight: conecta-se ao Aurora por uma conexão VPC e renderiza a tabela completa de achados, filtrável por varredura e banda de severidade.

    Regras de design não negociáveis

    A AWS estabelece um conjunto de princípios que não podem ser violados na implementação desse padrão:

    • Regras são dados. Uma mudança na lei é uma edição em linha no livro de regras. O motor não contém ramificações específicas de jurisdição.
    • Nenhuma linguagem natural chega ao SQL. Operadores selecionam templates fixos de SQL. Valores de regras são vinculados como parâmetros.
    • Determinístico antes da IA. Uma comparação numérica responde à varredura. Nenhum modelo é consultado.
    • Filtragem exata para completude; vetores apenas para ranqueamento. Similaridade nunca decide pertencimento à população.
    • Recibos são calculados, não escritos à mão. O invariante é afirmado antes de uma varredura ser confirmada.
    • Documentos ilegíveis são nomeados, não descartados. Cada contrato cai em exatamente um balde.
    • Achados são somente de adição. Não existe UPDATE ou DELETE contra achados na base de código.

    Tratando o modelo de sumarização como um renderizador não confiável

    Um elemento de design merece atenção especial: as salvaguardas para sobreviver à paráfrase do modelo de chat. Excluir o modelo do caminho de decisão mas colocá-lo de volta no caminho de entrega reintroduz risco no final da cadeia.

    Na prática, a AWS observou comportamentos problemáticos: um modelo removeu um prefixo de ressalva; uma tag de citação marcada como ilustrativa foi removida durante a paráfrase, e o modelo apresentou uma citação inventada como estatuto; um modelo extrapolou a partir de uma amostra de 20 linhas e inferiu um intervalo que não existia nos dados.

    Três técnicas endereçam isso:

    • Formule ressalvas como sufixos entre colchetes que não podem ser removidos, repetidos em vários níveis do payload — não como rótulos iniciais que parecem metadados removíveis.
    • Forneça os dados que tornam a resposta honesta a mais fácil. Calcule agregados reais sobre todos os registros e entregue-os ao modelo. Um modelo que tem o número real não precisa adivinhar a partir de uma amostra.
    • Repita rótulos de modo em múltiplos níveis estruturais (campo, string, resumo) para que pelo menos um sobreviva à paráfrase.

    Como implantar e executar o exemplo

    A implementação de referência completa está disponível no repositório de exemplo no GitHub. Ela inclui dados sintéticos (sem dados reais de contratos), geração determinística de corpus e testes de aceitação contra o stack implantado.

    Pré-requisitos

    • Uma conta AWS com acesso ao Amazon Bedrock habilitado para Amazon Titan Text Embeddings V2 e Anthropic Claude Sonnet 5 na região US East (N. Virginia) — us-east-1.
    • AWS CLI v2 com credenciais configuradas (aws sts get-caller-identity deve funcionar).
    • Python 3.12.
    • Node.js 24 para o AWS Cloud Development Kit (AWS CDK) CLI.

    Passo 1: Clonar o repositório

    git clone https://github.com/aws-samples/sample-quick-adjudicated-query.git
    cd sample-quick-adjudicated-query
    python3 -m venv .venv && .venv/bin/pip install -q -r requirements.txt

    Passo 2: Implantar a infraestrutura

    eval "$(mise env -s zsh)"
    export CDK_DEFAULT_ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
    npx aws-cdk@2.261.0 bootstrap aws://$CDK_DEFAULT_ACCOUNT/us-east-1
    npx aws-cdk@2.261.0 deploy --outputs-file outputs.json

    A versão do CDK está fixada em 2.261.0 para corresponder ao requirements.txt. O provisionamento do Aurora leva aproximadamente 11 minutos. O stack implanta: Amazon Cognito (cliente 2LO), Amazon API Gateway com autorizador JWT, AWS Lambda (servidor MCP + motor de regras), Amazon Aurora Serverless v2 e rede do Amazon QuickSight.

    Passo 3: Popular dados e verificar

    PY=.venv/bin/python
    $PY db/migrate.py        # schema, livro de regras, views (7 verificações)
    $PY gen_corpus.py        # corpus determinístico + manifesto
    $PY ingest.py            # carregar + embeddings (tempo varia por ambiente)
    $PY setup_dashboard.py   # configuração do QuickSight
    $PY acceptance.py        # 28 verificações contra o stack ativo

    Passo 4: Registrar a integração MCP no Amazon Quick

    O Amazon Quick faz um snapshot da lista de ferramentas no momento do registro. Novas ferramentas ou ferramentas renomeadas não são detectadas até que a integração seja excluída e recriada. Implantar apenas a Lambda não é suficiente.

    python3 - <<'PY'
    import json
    o = json.load(open('outputs.json'))['QuickPocStack']
    for k in ('McpUrl', 'TokenEndpoint', 'ClientId', 'Scope'):
        print('%-14s %s' % (k, o[k]))
    PY

    Recupere o segredo do cliente do Amazon Cognito (lido a cada vez, nunca gravado em disco) e registre no Amazon Quick em Connectors > Create for your team > Model Context Protocol.

    Passo 5: Verificar a integração

    $PY show_payload.py check_connection   # transporte ativo
    $PY acceptance.py                       # 28/28 verificações

    Percorrendo a experiência

    Com o stack implantado, é possível executar uma varredura de conformidade diretamente pelo chat do Amazon Quick. Ao perguntar "Which Texas leases violate the late fee cap? Use rules effective 01/01/2026", o Amazon Quick identifica isso como uma varredura de conformidade e seleciona a ferramenta sweep_compliance. A ferramenta executa uma verificação exaustiva contra todos os contratos do Texas na população, aplicando as regras vigentes na data declarada. Nenhum modelo está envolvido na determinação.

    A resposta inclui uma amostra dos achados em não conformidade, o recibo de completude como contagens (por exemplo, 10.111 violações, 689 ambíguos e 20 ilegíveis), uma ressalva de dados sintéticos e um link para o painel do QuickSight. Deliberadamente, ela não tenta renderizar todos os registros na mensagem de chat.

    Para verificar o recibo de completude, basta checar o invariante: conforme + em violação + ambíguo + ilegível deve ser igual ao total da população varrida. No exemplo, as contagens somam o total de contratos do Texas, confirmando que cada registro caiu em exatamente um balde.

    O painel do QuickSight exibe cada achado da varredura — um por par contrato-regra — com a cadeia completa de evidências: ID do contrato, a regra que disparou, o valor extraído e o valor esperado. Cada determinação carrega sua citação de regra, versão e o texto verbatim da cláusula do contrato, então nada precisa ser reconstruído posteriormente.

    Considerações de segurança

    Como esse padrão é construído para trabalho de conformidade, a segurança faz parte do design, não é um complemento. A implementação de exemplo aplica as seguintes práticas:

    • Acesso apenas autenticado: todas as requisições chegam ao servidor MCP por uma HTTP API do Amazon API Gateway protegida por um autorizador JWT respaldado pelo Amazon Cognito. Nenhuma rota não autenticada existe.
    • Tratamento de segredos: o segredo do cliente do Amazon Cognito é lido no momento do registro e não é gravado em disco nem commitado no controle de versão.
    • Acesso mínimo ao modelo: a função de execução do AWS Lambda concede InvokeModel no Amazon Bedrock apenas para os ARNs específicos dos modelos usados no exemplo, não um wildcard sobre todos os modelos.
    • Isolamento de rede para o caminho de dados: o Amazon QuickSight acessa o Amazon Aurora Serverless v2 por uma conexão VPC, não por um endpoint público.
    • Sem linguagem natural no caminho de consulta: o motor de regras monta SQL apenas a partir de uma tabela fixa de operador-para-template com valores de regras vinculados como parâmetros — isso é uma propriedade de segurança tanto quanto de correção.
    • Achados auditáveis e somente de adição: não existe caminho de UPDATE ou DELETE na base de código, então o registro de conformidade não pode ser silenciosamente alterado após o fato.

    Um ponto importante sobre atribuição: o Amazon Quick autentica no servidor MCP máquina-a-máquina via fluxo de credenciais de cliente, então o token identifica a aplicação Amazon Quick, não o indivíduo que fez a pergunta no chat. Para o requisito de "por quem" na defensibilidade, a atribuição fica na camada de auditoria do Amazon Quick. Se você precisar que a atribuição seja registrada diretamente no armazenamento de conformidade, é necessário encaminhar um ID de usuário final do Amazon Quick para a chamada de ferramenta e persistí-lo na linha de varredura.

    Quando usar (e quando não usar) esse padrão

    O padrão Adjudicated Query se aplica quando: um registro perdido é uma responsabilidade legal em vez de um inconveniente; respostas podem ser contestadas meses depois; a lógica de governança é de propriedade externa e muda em seu próprio calendário; e o conjunto de registros é enumerável. Isso abrange conformidade de contratos, adjudicação de sinistros de seguros, triagem de sanções, controle de exportações, monitoramento de protocolos de ensaios clínicos, inspeção de código de construção, testes de controles de relatórios financeiros e verificação de credenciais.

    O padrão é pesado — um motor de regras, uma superfície de ferramentas delimitada e um recibo de completude. Essa maquinaria só vale a pena no problema certo. Evite o padrão em três casos:

    • As regras não são realmente determinísticas. O padrão funciona quando a conformidade é uma comparação limpa (taxa menor ou igual a um teto). Quando a decisão é um julgamento genuíno (se uma cláusula é abusiva), forçá-la nesse padrão esconde a subjetividade dentro da autoria de regras e faz o resultado parecer exato quando não é.
    • A completude não importa para a pergunta. Se o usuário quer apenas alguns exemplos representativos ou está explorando, o recibo de completude é sobrecarga para uma garantia que não é necessária. RAG é a resposta mais simples e correta para esse tipo de pergunta.
    • A própria população é imprecisa. O recibo prova que você cobriu cada registro na população, não que a população é a correta. Se a definição de "todos os contratos do Texas" é em si contestável, a garantia é precisa sobre o denominador errado.

    Conclusão

    O padrão Adjudicated Query resolve um problema real de conformidade em escala: como oferecer acesso conversacional a verificações de conformidade sem abrir mão das garantias de completude e defensibilidade que esse tipo de trabalho exige. A chave está em manter o modelo de linguagem fora do caminho de decisão — ele traduz perguntas e narra resultados, mas nunca toca nas determinações que produzem a garantia.

    Para começar, clone o repositório de exemplo, implante o stack, registre a integração MCP no Amazon Quick e experimente fazer sua primeira pergunta de conformidade.

    Fonte

    Sweep thousands of leases for compliance using Amazon Quick and the Adjudicated Query pattern (https://aws.amazon.com/blogs/machine-learning/sweep-thousands-of-leases-for-compliance-using-amazon-quick-and-the-adjudicated-query-pattern/)

  • AWS European Sovereign Cloud: demonstrando operação independente dentro da União Europeia

    A AWS vai provar na prática que sua nuvem europeia é soberana de verdade

    No sábado, 24 de outubro de 2026, a AWS realizará um exercício técnico para demonstrar que a AWS European Sovereign Cloud é capaz de operar de forma completamente autônoma, sem depender de nenhuma infraestrutura localizada fora da União Europeia (UE). O teste vai além de uma simples declaração: a proposta é gerar evidências concretas e verificáveis.

    Durante algumas horas, a nuvem soberana europeia da AWS funcionará desconectada do backbone da Rede Global AWS — a rede privada que normalmente transporta dados operacionais autorizados entre os datacenters da empresa, sem passar pela internet pública. No período do exercício, esse tráfego será redirecionado com segurança pela internet pública.

    O que vai (e o que não vai) ser afetado

    A AWS deixou claro que o exercício não afetará a disponibilidade dos serviços dentro da AWS European Sovereign Cloud, nem em outras Regiões AWS, nem nas conexões privadas via AWS Direct Connect.

    O único impacto esperado são breves interrupções de conectividade durante as transições de rota de rede — uma no início do exercício, quando o tráfego migra para os provedores de internet exclusivos da nuvem soberana, e outra no final, quando o tráfego retorna ao backbone global. Esse fenômeno é chamado de convergência: o tempo curto em que outras redes ajustam suas tabelas de roteamento para refletir a mudança.

    A equipe operacional responsável pela execução do exercício é composta inteiramente por residentes da UE, trabalhando dentro da UE, utilizando exclusivamente os recursos de hardware e software da própria AWS European Sovereign Cloud.

    O que é a AWS European Sovereign Cloud

    A AWS European Sovereign Cloud é uma nuvem independente, criada especificamente para a Europa. Seus datacenters estão localizados em Brandemburgo, na Alemanha, e são fisicamente e logicamente separados das demais Regiões AWS ao redor do mundo. Uma cópia local do código-fonte fica armazenada dentro da UE.

    Todo o conteúdo dos clientes e os metadados criados por eles permanecem dentro da UE. A infraestrutura não possui dependências críticas de recursos fora do bloco e é operada exclusivamente por residentes da UE.

    Em condições normais de operação, a AWS European Sovereign Cloud utiliza dois sistemas globais:

    • O backbone da Rede Global AWS, que oferece desempenho superior, capacidade, confiabilidade, segurança e economia de custos — incluindo criptografia permanente e defesas contra ataques de negação de serviço distribuído (DDoS). Vale destacar que o backbone não consegue descriptografar nem visualizar os dados trafegados pelos clientes da nuvem soberana.
    • Um sistema dedicado, controlado e supervisionado pela equipe local da UE, que gerencia transferências limitadas e controladas de dados operacionais da AWS.

    Nenhum dos dois sistemas é crítico para a operação, e nenhum deles afeta as garantias de soberania da plataforma. A AWS European Sovereign Cloud pode operar de forma independente a qualquer momento — e é exatamente isso que o exercício de outubro vai demonstrar.

    Alinhamento com frameworks regulatórios europeus

    O exercício foi desenhado para produzir evidências técnicas e operacionais verificáveis de que a nuvem pode funcionar de forma autônoma dentro da UE. A iniciativa está alinhada aos objetivos do EU Cloud Sovereignty Framework (CSF) da Comissão Europeia e aos critérios do framework C3A do BSI — o Escritório Federal Alemão para Segurança da Informação.

    Esses frameworks estabelecem os critérios para avaliar se serviços de nuvem podem ser fornecidos de forma independente e autônoma. A AWS projetou a nuvem soberana especialmente para clientes regulados e para o setor público em toda a UE.

    O AWS European Sovereign Cloud: Sovereign Reference Framework (ESC-SRF) oferece um conjunto abrangente de evidências, mapeamentos de controles, artefatos e outros elementos que reguladores e autoridades de conformidade precisam para acelerar a adoção da plataforma. Os resultados do exercício de outubro vão compor pacotes adicionais de conformidade e assurance para clientes e parceiros.

    O que acontece com os dados dos clientes durante o exercício

    A AWS reafirma o compromisso de não mover o conteúdo dos clientes nem os metadados criados por eles para fora da UE. Apenas determinados dados operacionais da AWS — que não se enquadram como conteúdo ou metadados de clientes — deixam o bloco, e isso ocorre por meio do sistema dedicado controlado pela equipe local.

    Durante o exercício, esse sistema será completamente desativado. Isso confirmará, na prática, que a AWS European Sovereign Cloud continua operando de forma independente mesmo sem ele.

    Para a conectividade com a internet mundial, a nuvem soberana utilizará exclusivamente sua conectividade dedicada com provedores europeus de serviços de internet — sem passar pelo backbone global da AWS.

    Próximos passos

    Após a realização do exercício, a AWS compartilhará uma atualização com reguladores e clientes. Para saber mais sobre o design e os controles de soberania digital da AWS European Sovereign Cloud, acesse aws.eu. Em caso de dúvidas sobre o exercício ou sobre possíveis impactos nas suas cargas de trabalho, a recomendação da AWS é entrar em contato com o Suporte AWS ou com o time de conta responsável.

    Fonte

    AWS European Sovereign Cloud: Demonstrating an independent operation (https://aws.amazon.com/blogs/security/aws-european-sovereign-cloud-demonstrating-an-independent-operation/)

  • Amazon RDS para MySQL anuncia novas versões menores do Suporte Estendido: 5.7.44 e 8.0.46

    O que foi anunciado

    A AWS anunciou duas novas versões menores dentro do programa Amazon RDS Extended Support para o Amazon Serviço de Banco de Dados Relacional (RDS) para MySQL: a 5.7.44-rds.20260902 e a 8.0.46-rds.20260908. As atualizações foram disponibilizadas em 24 de setembro de 2026.

    O que é o Suporte Estendido do RDS

    O Amazon RDS Extended Support (Suporte Estendido) é um programa que oferece até três anos adicionais de correções para Vulnerabilidades e Exposições Comuns (CVE) críticas e bugs, contados a partir do fim do suporte padrão de uma versão principal do MySQL. Na prática, isso significa que equipes que ainda operam em versões mais antigas ganham uma janela de tempo maior para planejar e executar a migração para uma versão principal mais recente, sem ficarem expostas a riscos de segurança não corrigidos.

    Como fazer o upgrade do banco de dados

    A AWS disponibiliza três caminhos para quem precisa atualizar a versão do banco de dados:

    • Amazon RDS Blue/Green Deployments: estratégia que mantém dois ambientes paralelos (produção e staging) para validar a atualização antes de promovê-la, reduzindo o risco de indisponibilidade.
    • Upgrade in-place: atualização direta na instância existente, sem necessidade de criar um novo ambiente.
    • Restauração a partir de snapshot: criação de uma nova instância a partir de um backup, já na versão desejada.

    Mais detalhes sobre como executar cada um desses processos estão disponíveis no Guia do Usuário do Amazon RDS para MySQL.

    Migrando de fontes externas para o MySQL 8.4

    Para quem mantém bancos MySQL fora da AWS e deseja migrar para o MySQL 8.4 diretamente no RDS, a AWS indica o uso do AWS Database Migration Service (Serviço de Migração de Banco de Dados). Essa ferramenta permite transferir dados de fontes externas para o RDS com controle sobre o processo de migração.

    Disponibilidade e preços

    Informações sobre preços e disponibilidade regional do programa de Suporte Estendido podem ser consultadas diretamente na página de preços do Amazon RDS para MySQL. Para criar ou atualizar uma instância gerenciada, é possível usar o Console de Gerenciamento do Amazon RDS ou a Interface de Linha de Comando da AWS (AWS CLI).

    Por que isso importa

    Manter bancos de dados em versões sem suporte ativo é um dos maiores riscos operacionais em ambientes de produção. O programa de Suporte Estendido da AWS permite que times com ciclos de migração mais longos continuem recebendo correções de segurança críticas, evitando exposições desnecessárias enquanto o trabalho de atualização está em andamento. As novas versões menores anunciadas são parte desse compromisso contínuo de manutenção.

    Fonte

    Amazon RDS for MySQL announces Extended Support minor versions 5.7.44-rds.20260902 and 8.0.46-rds.20260908 (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-rds-mysql-extended-support-minor-5744-8046-rds/)

  • MFA nunca foi tão importante: AWS alcança marco histórico na autenticação multifator

    A campanha que reforça uma verdade já conhecida

    O Australian Signals Directorate (ASD) — equivalente australiano de uma agência nacional de segurança cibernética — lançou recentemente a campanha MFA: Switch it on, convocando empresas, organizações e pessoas físicas a ativarem a Autenticação Multifator (MFA) em todas as suas contas digitais. A iniciativa não é apenas mais um alerta genérico de segurança: o MFA é considerado um dos pilares do modelo de maturidade Essential Eight do próprio ASD, além de ser reconhecido nos principais frameworks de cibersegurança ao redor do mundo.

    A AWS declarou apoio à campanha — e não é por acaso. O MFA é exatamente o tipo de controle simples, de alto impacto, que protege contra as ameaças mais comuns do dia a dia: phishing, credential stuffing (ataque que testa senhas vazadas em massa) e engenharia social. Senhas, por mais complexas que sejam, já não são suficientes para proteger contas críticas.

    O marco histórico da AWS com MFA

    Em junho de 2025, o AWS Identity and Access Management (IAM) — serviço de Gerenciamento de Identidade e Acesso da AWS — atingiu um ponto de inflexão importante: a exigência abrangente de MFA para usuários root em todos os tipos de conta. Segundo a própria AWS, este é um feito inédito entre os grandes provedores de nuvem.

    Imagem original — fonte: Aws

    Essa conquista foi resultado de uma jornada gradual e deliberada. Veja como a AWS construiu esse caminho:

    • Maio de 2024: exigência de MFA para usuários root de contas de gerenciamento no AWS Organizations — serviço de organização e governança de múltiplas contas AWS.
    • Junho de 2024: extensão da exigência para usuários root de contas standalone (independentes).
    • Novembro de 2024: introdução do gerenciamento centralizado de acesso root.
    • Junho de 2025: conclusão da exigência para todos os tipos de conta, incluindo contas-membro dentro de organizações.

    O resultado prático é significativo: o MFA bloqueia mais de 99% dos ataques baseados em senhas comprometidas. E o melhor: está disponível para todos os clientes AWS sem custo adicional, com suporte a passkeys FIDO2 e chaves de segurança certificadas FIDO — tecnologias resistentes a phishing.

    MFA vai além do ambiente AWS

    Um ponto frequentemente negligenciado: a segurança do ambiente AWS não depende apenas do que acontece dentro da console da AWS. Contas externas conectadas ao seu fluxo de trabalho representam vetores de ataque reais.

    Por exemplo: uma conta de e-mail comprometida pode ser usada para redefinir a senha de acesso AWS. Um sistema de controle de versão (como GitHub ou GitLab) violado pode expor segredos embutidos em código de infraestrutura como código. Por isso, a recomendação é clara: ative o MFA também em ferramentas de e-mail, colaboração, controle de código-fonte e qualquer outro serviço que suporte essa proteção.

    Para orientações mais amplas sobre como proteger contas além do ambiente AWS, a página da campanha MFA do ASD oferece um guia completo.

    Como habilitar MFA no ambiente AWS

    Para usuários root, a AWS já aplica o MFA automaticamente. A atenção agora deve se voltar para os usuários IAM — as identidades utilizadas pelos membros da equipe e pelas aplicações no dia a dia.

    A configuração pode ser feita individualmente pelo AWS Management Console (console de gerenciamento da AWS) para IAM. Para quem quer se aprofundar, a documentação de boas práticas de segurança no IAM é o ponto de partida recomendado.

    Para quem busca autenticação resistente a phishing com passkeys FIDO2, a documentação sobre passkeys e chaves de segurança no IAM detalha como configurar esse nível adicional de proteção.

    Dúvidas ou feedbacks sobre MFA na AWS podem ser enviados pelo AWS re:Post, a comunidade oficial de perguntas e respostas da AWS.

    Por que isso importa para o mercado brasileiro

    A campanha do ASD é australiana, mas a mensagem vale para qualquer organização no mundo — incluindo as brasileiras. Ataques de phishing e credential stuffing não têm fronteiras, e a realidade é que muitas empresas ainda operam com MFA desativado por “facilidade” ou falta de priorização.

    O MFA é uma das medidas de segurança com melhor custo-benefício disponível: simples de implementar, gratuito na AWS, e capaz de neutralizar a esmagadora maioria dos ataques baseados em credenciais. Não há justificativa técnica ou financeira para deixá-lo desativado.

    Se sua organização ainda não habilitou o MFA em todas as contas relevantes, este é o momento. Ative o MFA agora — em todas as contas que você gerencia.

    Fonte

    Supporting ASD’s multi-factor authentication campaign: Why MFA matters more than ever (https://aws.amazon.com/blogs/security/supporting-asds-multi-factor-authentication-campaign-why-mfa-matters-more-than-ever/)

  • Resumo de Segurança AWS: Agosto de 2026

    Visão geral do mês

    O blog de segurança da AWS encerrou agosto de 2026 com um volume expressivo de conteúdo: 20 posts organizados em sete categorias, 23 boletins de segurança e 17 exemplos de código prontos para uso. Quem acompanha o espaço de segurança em nuvem vai notar um fio condutor claro ao longo do mês — a superfície de ataque de agentes de IA cresceu e ganhou destaque tanto nas novidades quanto nos alertas de vulnerabilidade.

    Identidade e Gerenciamento de Acesso

    Cinco posts cobriram o tema de identidade em agosto, com destaques práticos para quem gerencia autenticação e acesso em ambientes corporativos.

    Amazon Cognito ganha limites provisionados de taxa

    O Amazon Cognito passou a oferecer limites provisionados para gerenciamento de taxa de autenticação em modo self-service. O que antes exigia um ticket de suporte com prazo de 10 a 14 dias agora pode ser ajustado em minutos. O post De 2 semanas para 2 minutos: Amazon Cognito lança limites provisionados para gerenciamento de taxa explica como usar o recurso para escalar capacidade sob demanda.

    Uma década do AWS Managed Microsoft AD

    O AWS Managed Microsoft AD completou 10 anos como serviço de Active Directory totalmente gerenciado na nuvem. O post Uma década de identidade corporativa na nuvem com AWS Managed Microsoft AD celebra a evolução do serviço, que hoje oferece edições Standard, Enterprise e Hybrid, com replicação multi-região e mais de 20 integrações com outros serviços da AWS.

    Nova experiência de login no console da AWS

    A AWS está implementando gradualmente uma página de login redesenhada, com ponto de entrada unificado por e-mail, opções de provedores de identidade social e uma experiência atualizada para gerenciar múltiplas sessões ativas. Mais detalhes no post Atualizações na experiência de login da AWS.

    Console Private Access para VPCs sem internet

    O AWS Management Console Private Access passou a suportar VPCs sem conectividade com a internet. Todo o tráfego do console — autenticação, assets estáticos e chamadas de API — é roteado por endpoints do AWS PrivateLink, reforçando o perímetro de dados em ambientes isolados. O post Estenda seu perímetro de dados ao Console de Gerenciamento da AWS com Private Access detalha a configuração.

    Governança automatizada do IAM Identity Center

    O post Automatize a governança do IAM Identity Center com descoberta e relatórios contínuos mostra como implantar descoberta automatizada e relatórios para aplicações e atribuições do AWS IAM Identity Center em toda a organização, com monitoramento orientado a eventos que valida convenções de nomenclatura e permite aplicação de políticas em tempo quase real.

    Proteção de Dados

    Cache de chaves KMS em ambientes multi-thread

    O post Cache de chaves de dados KMS em ambientes multi-thread: criptografia por tenant para sistemas orientados a eventos em escala aborda o problema de cache stampede em criptografia envelope multi-tenant, apresentando o padrão de keyring hierárquico recomendado pela AWS ou uma abordagem customizada baseada em Caffeine para reduzir custos com o AWS KMS.

    Suporte ao protocolo ACME no AWS Certificate Manager

    O AWS Certificate Manager passou a suportar o protocolo ACME, permitindo automatizar a emissão e renovação de certificados públicos com clientes padrão como Certbot e cert-manager. O post Automatize certificados com suporte a ACME no AWS Certificate Manager explica os controles corporativos disponíveis para escopo de domínios e visibilidade centralizada.

    Remediação de buckets S3 com permissões excessivas

    O post Protegendo seus buckets Amazon S3: identificando e remediando acessos com permissões excessivas ensina a detectar e corrigir buckets do Amazon S3 com permissões excessivas em ambientes multi-conta, usando AWS Lambda, AWS Config e AWS Security Hub para monitoramento contínuo.

    Fim da validação de domínio por e-mail no ACM

    Atenção para um prazo importante: o post AWS Certificate Manager encerrará a validação por e-mail para certificados informa que o ACM descontinuará certificados públicos validados por e-mail até 30 de setembro de 2027, alinhando-se aos padrões do Fórum CA/B. O post traz o cronograma e o passo a passo para migrar para validação por DNS.

    Segurança de IA

    Quatro posts cobriram segurança de IA em agosto, todos focados no ecossistema do Amazon Bedrock AgentCore.

    Autenticação customizada no AgentCore Gateway

    O post Implemente autenticação customizada para integração de ferramentas usando request Lambda interceptor no AgentCore Gateway mostra como usar um interceptor Lambda de requisição para integrar mecanismos legados de autenticação, como Basic Auth, isolando credenciais dos agentes de IA com o AWS Secrets Manager.

    Propagação de contexto de autorização em agentes de IA

    O post Propagação de contexto de autorização de usuário em agentes de IA com Amazon Bedrock AgentCore demonstra como aplicar acesso de menor privilégio em agentes de IA propagando a identidade do usuário até o Amazon DynamoDB, Knowledge Bases e Salesforce — sem embutir lógica de autorização no código do agente.

    Estendendo o Bedrock Guardrails para interações com ferramentas

    O post Estenda o Amazon Bedrock Guardrails para interações com ferramentas usando o Strands Agents SDK explica como levar os guardrails além do limite do modelo, aplicando-os a chamadas de ferramentas, dados externos e interações com servidores MCP por meio de três pontos de validação construídos com lifecycle hooks do Strands Agents SDK.

    Detecção de Ameaças e Resposta a Incidentes

    Security Hub Extended inclui segurança de cadeia de suprimentos

    O AWS Security Hub Extended adicionou segurança de cadeia de suprimentos como sua décima categoria, com Chainguard e Socket como parceiros curados. O post Security Hub Extended adiciona segurança de cadeia de suprimentos como décima categoria detalha como verificar dependências de código aberto e bloquear pacotes maliciosos por meio de uma única relação de cobrança na AWS.

    Correlação de sinais em ataques multi-estágio

    O post Detectando ataques multi-estágio na AWS: um guia para correlação de sinais entre serviços ensina a correlacionar sinais do AWS CloudTrail, VPC Flow Logs e logs do Route 53 Resolver para detectar ataques encadeados, combinando contexto de negócio, classificação de dados e janelas de mudança sobre o Amazon GuardDuty Extended Threat Detection.

    AWS Continuum integrado a ambientes de desenvolvimento

    O post AWS faz parceria com Anthropic e OpenAI para integrar o AWS Continuum a fluxos de trabalho de desenvolvedores anuncia que o AWS Continuum para vulnerabilidades de código agora se integra ao Anthropic Claude Code, OpenAI Codex e Kiro, permitindo que desenvolvedores descubram, priorizem, validem e remediem vulnerabilidades diretamente em seus ambientes de codificação.

    Um concorrente direto no Security Hub Extended

    O post Convidamos um concorrente direto para o Security Hub Extended. Veja o porquê. explica a decisão da AWS de incluir a Upwind — empresa de segurança em nuvem com foco em runtime — no Security Hub Extended, oferecendo proteção de workloads baseada em eBPF com precificação pay-as-you-go e cobrança unificada na AWS, reforçando a escolha do cliente mesmo onde as capacidades se sobrepõem às da própria AWS.

    Segurança de Infraestrutura

    AWS Network Firewall passa a contar acertos de regras

    O AWS Network Firewall agora rastreia quantas vezes cada regra stateful corresponde ao tráfego. O post AWS Network Firewall agora suporta contagem de acertos de regras mostra como usar o recurso para identificar regras não utilizadas, validar controles de segurança para conformidade e acelerar a resposta a incidentes — sem custo adicional.

    Governança e Conformidade

    Landing Zone Accelerator e o padrão C5:2020

    O post Relatório de avaliação independente do Landing Zone Accelerator para C5:2020 disponível no AWS Artifact anuncia que uma avaliação independente da Schellman analisa como o Landing Zone Accelerator on AWS se alinha aos requisitos do C5:2020, implementando 325 controles de segurança.

    Aceleração de ambientes ISM e avaliações IRAP

    O post Acelere ambientes prontos para ISM e avaliações IRAP com o Landing Zone Accelerator on AWS apresenta uma nova avaliação independente da gwi.digital que analisa o Landing Zone Accelerator contra 1.081 controles ISM, alcançando 91% de cobertura do escopo endereçável — voltado principalmente para clientes australianos em processo de avaliação IRAP.

    Como a Moeve gerencia SCPs em escala

    O post Como a Moeve escala a governança AWS com Políticas de Controle de Serviço automatizadas mostra como a empresa gerencia 150 SCPs (Políticas de Controle de Serviço) em mais de 300 contas em três AWS Organizations usando um modelo de governança-como-código: políticas versionadas no Git, implantadas via GitHub Actions e vinculadas dinamicamente com base em metadados de conta durante o onboarding. O Amazon EventBridge e o AWS Lambda fornecem observabilidade em tempo real de cada mudança organizacional.

    Boletins de Segurança de Agosto

    Em agosto de 2026, a AWS publicou 23 boletins de segurança cobrindo vulnerabilidades em SDKs de código aberto, servidores MCP, ferramentas para desenvolvedores e o ecossistema OpenSearch. O tema dominante foi a superfície de ataque de agentes de IA: bypasses de consentimento por injeção de prompt no Strands Agents Tools permitiam execução de comandos e código; uma referência direta a objetos insegura expunha memória de agentes entre tenants; e falhas de divulgação de credenciais e autorização afetaram os servidores MCP do Amazon MQ, DocumentDB, AWS Transform e o harness do Bedrock AgentCore.

    Execução remota de código também apareceu em múltiplos pontos: poluição de protótipo e desserialização Java no OpenSearch, path-traversal para root no amazon-ssm-agent, Zip Slip no awsdac e caminho de busca não controlado no Kiro IDE e CLI no Windows. Outros problemas notáveis incluem verificação de chave de host SSH desabilitada no AWS CLI, falhas de segurança de memória no AWS SDK para C++, escalada de privilégio no FreeRTOS-Kernel e negação de serviço por amplificação de memória no Amazon ion-java.

    O fio condutor: autorização insuficiente e validação de entrada na fronteira entre agentes de IA e os sistemas que eles acessam. Todos os patches estão disponíveis — atualize o quanto antes. Consulte os Boletins de Segurança da AWS para detalhes completos.

    Exemplos de Código (AWS Samples)

    Em agosto, a AWS publicou 17 novos exemplos de código em cinco categorias: governança e conformidade (7), segurança de IA (3), proteção de dados e privacidade (3), identidade e gerenciamento de acesso (2) e segurança de infraestrutura (2). A maioria dos exemplos foca em governar, auditar e proteger agentes de IA construídos sobre o Amazon Bedrock AgentCore.

    Governança e Conformidade

    • Agentic Governance Platform: plano de controle nativo AWS para governar agentes de IA com registro centralizado, SSO via Microsoft Entra ID, políticas Cedar e observabilidade com Langfuse, hospedado no Amazon Bedrock AgentCore.
    • Enterprise Agentic AI Platform Accelerator: fundação segura e governada para agentes de IA em produção com stacks CDK modulares cobrindo identidade, gateway, memória, runtime e observabilidade.
    • Video Compliance Agent: pipeline que verifica automaticamente conteúdo de vídeo contra diretrizes de conformidade de transmissão, usando Amazon Bedrock para sinalizar violações potenciais.
    • Intelligent Security for Healthcare APIs: detecção de anomalias comportamentais, classificação de sensibilidade de dados e relatórios de conformidade HIPAA para APIs FHIR, com anonimização de informações de saúde protegidas via Amazon Comprehend Medical e Bedrock Guardrails.
    • Governed Agentic Companion: companion multi-agente com gate de governança sempre ativo que aplica 13 princípios codificados, bloqueando deploys, vazamentos de segredos e respostas sem embasamento.
    • Audit the Agent: pipeline serverless de auditoria executiva diária para agentes de IA (AWS DevOps Agent, AWS Security Agent) usando AWS Step Functions e Lambda, respondendo cinco perguntas: o que o agente acessou, quem autorizou, quanto custou, seu perfil de risco e se há motivo de preocupação.

    Segurança de IA

    • Telemetry Enablement for AgentCore CloudFormation: stack único de AWS CloudFormation que habilita logs do Amazon CloudWatch e traces do X-Ray para todos os tipos de recursos do Amazon Bedrock AgentCore.
    • Bedrock Guardrails to OCSF on CloudWatch: transforma eventos de intervenção do Bedrock Guardrails em registros OCSF Detection Finding e os armazena no CloudWatch, permitindo consultas com Amazon Athena.
    • Bedrock Readiness Agent: agente de avaliação somente leitura que analisa seu ambiente Amazon Bedrock em seis dimensões — governança IAM, retenção de dados, headroom de cotas, adequação de modelos, projeção de custos e observabilidade operacional — gerando findings com templates de remediação para CloudFormation e Terraform.

    Segurança de Infraestrutura

    • DDoS Guardian: skill que revisa uma web ACL do AWS WAF como sistema — ordem de avaliação, interações entre regras e postura L7 contra DDoS — entregando um relatório HTML com remediações prontas para aplicar. Offline e somente leitura.
    • Biosecurity Screening Policy on Amazon Bedrock AgentCore Gateway: usa políticas Cedar com três camadas independentes de triagem (alinhamento de sequência MMseqs2, similaridade de embedding ESMC-600M e homologia estrutural Foldseek) para bloquear sequências de proteínas de alto risco antes que cheguem a ferramentas downstream.
    • MCP Fraud Investigation Agent: agente de investigação de fraude em e-commerce construído com Strands SDK no Amazon Bedrock AgentCore, com dashboard React no AWS Amplify que transmite o raciocínio do agente token a token.

    Identidade

    Proteção de Dados

    • Data Residency Chatbot with Amazon Bedrock AgentCore: chatbot em linguagem natural com conformidade de residência de dados, onde todos os dados e inferências de IA permanecem em uma única região AWS, com guard de residência que rejeita qualquer perfil de inferência cross-region.
    • LLM-based PII Detection: detecta informações de identificação pessoal (PII) em texto conversacional usando Amazon Bedrock, com suporte a categorias customizadas, few-shot examples e chunking por limite de palavras para entradas longas.
    • Agentic Data Classification and Redaction: assistente de pesquisa conversacional que classifica documentos automaticamente para MNPI, PII e sensibilidade de segurança, aplicando redação por usuário usando Amazon Bedrock AgentCore, Guardrails e Amazon OpenSearch Serverless.

    Conclusão

    Agosto de 2026 foi um mês denso em conteúdo de segurança AWS, com foco especial em workloads de IA agêntica em escala corporativa. Os posts e exemplos cobrem desde gates de governança para orquestradores e triagem de biossegurança até pipelines de auditoria executiva diária e telemetria normalizada em OCSF. Para quem trabalha com segurança em ambientes AWS, o mês entregou padrões concretos — com código executável — para console Private Access em VPCs isoladas, ABAC com IAM account access manager, remediação automatizada de menor privilégio via CI/CD e correlação de sinais para detecção de ataques multi-estágio.

    Para acompanhar as publicações conforme saem, assine o RSS feed do AWS Security Blog.

    Fonte

    ICYMI: August 2026 @AWS Security (https://aws.amazon.com/blogs/security/icymi-august-2026-aws-security/)

  • Amazon EVS agora está em conformidade com o FedRAMP Classe C

    O que foi anunciado

    A AWS anunciou que o Amazon Elastic VMware Service (EVS) passou a fazer parte do escopo do Programa Federal de Gerenciamento de Riscos e Autorizações (FedRAMP) na classificação Classe C — anteriormente conhecida como baseline Moderada — em todas as regiões dos Estados Unidos.

    O que é o FedRAMP e por que isso importa

    O FedRAMP é um programa do governo norte-americano que estabelece uma abordagem padronizada para avaliação de segurança, autorização e monitoramento contínuo de produtos e serviços de nuvem. Em termos práticos, quando um serviço entra no escopo do FedRAMP, ele passa a atender aos requisitos de segurança exigidos por agências federais dos EUA para adotar soluções de nuvem.

    Para organizações que operam no setor público americano ou que precisam comprovar conformidade com padrões rigorosos de segurança, essa certificação é um critério essencial na escolha de serviços de nuvem.

    O que é o Amazon EVS

    O Amazon EVS permite executar o software mais recente do VMware Cloud Foundation (VCF) diretamente dentro de uma Nuvem Privada Virtual da Amazon (Amazon VPC), utilizando instâncias bare-metal do EC2. Isso significa que é possível montar um ambiente VCF completo em poucas horas, viabilizando a migração rápida de cargas de trabalho para a AWS.

    Principais benefícios destacados pela AWS

    • Eliminação de infraestrutura legada: facilita a saída de data centers próprios com infraestrutura envelhecida.
    • Redução de riscos operacionais: ao migrar para um ambiente gerenciado e certificado.
    • Cumprimento de prazos críticos: a configuração rápida do ambiente ajuda equipes a cumprir cronogramas apertados de migração.

    Onde encontrar mais informações

    Para verificar todos os serviços AWS que estão dentro do escopo do FedRAMP, a AWS disponibiliza uma página com os serviços AWS em escopo para o FedRAMP. Quem quiser se aprofundar no Amazon EVS pode acessar a página de detalhes do produto e o guia do usuário.

    Fonte

    Amazon EVS now in scope for FedRAMP Class C (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-evs-fedramp-class-c/)

  • Transformando eventos do Bedrock Guardrails em OCSF com o CloudWatch

    O problema: telemetria de IA isolada do resto da segurança

    Equipes de segurança que investigam incidentes relacionados a Inteligência Artificial (IA) precisam cruzar dados de intervenção de guardrails com a telemetria de segurança já existente. Quando um guardrail bloqueia uma tentativa de injeção de prompt ou redige informações sensíveis, esse evento carrega valor investigativo comparável a uma falha de autenticação ou a um alerta de intrusão de rede.

    O AWS Bedrock publica essa telemetria no AWS CloudWatch — em métricas e nos logs de invocação de modelos — para monitoramento operacional. O desafio é que esses dados ficam isolados por Região e em formato bruto, separados dos dados de identidade, rede e auditoria que o time de segurança já utiliza.

    A AWS publicou uma solução que resolve exatamente esse problema: transformar os eventos de intervenção do AWS Bedrock Guardrails em registros estruturados no padrão Open Cybersecurity Schema Framework (OCSF) — Estrutura Aberta de Esquema de Cibersegurança — e armazená-los no CloudWatch unified data store.

    O que é o CloudWatch unified data store?

    Lançado em dezembro de 2025, o CloudWatch unified data store (armazenamento unificado de dados do CloudWatch) consolida dados operacionais, de segurança e de conformidade de serviços AWS e fontes de terceiros em uma única plataforma. Analistas de Centro de Operações de Segurança (SOC) e analistas de ameaças podem consultar eventos de guardrails lado a lado com dados de identidade, rede e endpoints — incluindo AWS CloudTrail e VPC Flow Logs — usando AWS Athena ou CloudWatch Logs Insights.

    Caso de uso: correlação entre guardrails e outras fontes de segurança

    Imagine uma organização que usa o AWS Bedrock em várias aplicações com guardrails como controle de governança. Esses guardrails detectam e bloqueiam conteúdo prejudicial, consultas fora do escopo, informações sensíveis como Informações de Identificação Pessoal (PII) e tentativas de injeção de prompt.

    Sem uma camada de consolidação, as intervenções dos guardrails ficam isoladas como métricas do CloudWatch por Região e entradas nos logs brutos de invocação — separadas dos dados de identidade, rede e auditoria que o time de segurança já usa. O CloudWatch unified data store foi construído para eliminar exatamente esse tipo de silo.

    Com os registros normalizados de guardrail no data store, o time consegue responder perguntas que cruzam múltiplas fontes de dados:

    • Quais contas de usuário geram mais intervenções de guardrail? Essas mesmas contas também apresentam atividade incomum no AWS Identity and Access Management (IAM), como chamadas de API com falha ou alterações de privilégio?
    • Tentativas de injeção de prompt se correlacionam com endereços IP específicos que também aparecem nos VPC Flow Logs? Isso ajuda a distinguir um cliente mal configurado de um padrão coordenado de ataque.
    • Como a tendência de violações de guardrail evoluiu nos últimos 30 dias? O volume atual é ruído de política ou uma mudança emergente no comportamento de atacantes?

    Vale destacar que o AWS GuardDuty já contribui nesse cenário: seu recurso de Proteção de IA analisa eventos de dados do CloudTrail para o AWS Bedrock e produz findings gerenciados de ameaças, incluindo detecção direta de injeção de prompt e achados de invocação anômala de modelos. O pipeline descrito neste artigo é complementar ao GuardDuty — ele captura os próprios registros brutos de intervenção de guardrail, normaliza-os para OCSF e os deposita no data store unificado para correlação entre fontes e análise de tendências de longo prazo.

    Por que é necessário um passo de transformação customizado?

    O CloudWatch oferece conversão nativa para OCSF por meio do processador ParseToOCSF para fontes específicas da AWS. No momento da publicação, esse processador suporta cinco fontes: CloudTrail, AWS Route 53 Resolver, VPC Flow Logs, logs de auditoria do AWS EKS e AWS WAF. O AWS Bedrock Guardrails não está entre essas fontes, portanto os traces de guardrail não são convertidos automaticamente para OCSF.

    Além disso, os traces de guardrail exigem uma lógica de transformação que processadores de ingestão não oferecem: um único log de invocação de modelo pode conter múltiplas avaliações de guardrail — por exemplo, um filtro de política de conteúdo e uma correspondência de política de informações sensíveis na mesma requisição. O passo de transformação divide essa entrada em um registro OCSF Detection Finding (Descoberta de Detecção) por avaliação, em vez de um único registro combinado. Essa expansão de um-para-muitos, combinada com a atribuição condicional de severidade por tipo de política, é lógica de aplicação — não apenas normalização de campos.

    Visão geral da solução e arquitetura

    Em alto nível, a solução captura eventos de intervenção de guardrail nos logs de invocação de modelos do AWS Bedrock, transforma-os em registros OCSF Detection Finding com uma função AWS Lambda, e os deposita no CloudWatch unified data store, onde analistas de SOC os consultam com Athena ou CloudWatch Logs Insights.

    O fluxo de dados segue as seguintes etapas:

    • Uma aplicação chama o AWS Bedrock (API InvokeModel ou Converse) com um guardrail associado.
    • O AWS Bedrock avalia o guardrail e registra a invocação — incluindo os dados de trace do guardrail — em um grupo de logs do CloudWatch via model invocation logging.
    • Um filtro de assinatura identifica entradas de log onde a ação do guardrail é INTERVENED (conteúdo bloqueado ou mascarado).
    • O filtro de assinatura entrega os registros correspondentes a uma função Lambda (OCSF Transform), que expande cada avaliação de guardrail em seu próprio OCSF Detection Finding.
    • A função Lambda grava os registros OCSF JSON em um grupo de logs dedicado do CloudWatch e define campos contextuais (ID da conta e Região) em cada registro durante a transformação.
    • Se a função Lambda falhar ao processar um registro, a mensagem é roteada para uma fila de mensagens mortas do AWS Simple Queue Service (AWS SQS) para análise posterior.
    • O grupo de logs de destino é associado ao AWS S3 Tables por meio da integração gerenciada do CloudWatch unified data store, que armazena os registros OCSF como uma tabela Apache Iceberg.
    • Analistas de SOC consultam os dados com Athena, usando funções json_extract para ler os campos OCSF, e os correlacionam com fontes de segurança nativas (CloudTrail, VPC Flow Logs) que compartilham o mesmo catálogo.
    Imagem original — fonte: Aws

    Como o AWS Bedrock Guardrails é uma fonte customizada, cada registro é armazenado como OCSF JSON em uma coluna gerenciada chamada cwl__message, em vez de colunas tipadas. Os campos OCSF são lidos em tempo de consulta com funções json_extract do Athena, e podem ser correlacionados com as fontes nativas que compartilham o mesmo catálogo.

    Mapeamento de campos OCSF

    A tabela abaixo mostra como os campos de intervenção do AWS Bedrock Guardrails são mapeados para os atributos do OCSF Detection Finding (class_uid 2004):

    • class_uid: estático — 2004 (Detection Finding)
    • category_uid: estático — 2 (Findings)
    • severity_id: derivado do tipo de política — 3 (Medium) para conteúdo/tópico; 4 (High) para injeção de prompt
    • activity_id: estático — 1 (Create)
    • time: timestamp do log de invocação
    • cloud.provider: estático — AWS
    • cloud.region: definido pela função de transformação
    • cloud.account.uid: definido pela função de transformação
    • actor.user.uid: ARN de identidade do log de invocação
    • finding_info.title: derivado do tipo de política (ex: ContentPolicy Intervention)
    • finding_info.desc: ação/tópico do trace do guardrail
    • resource.uid: ARN do modelo
    • resource.type: estático — AwsBedrock:Model
    • unmapped.guardrail_id / guardrail_arn / guardrail_version / guardrail_content_source / guardrail_policy_type: campos do trace do guardrail

    Pré-requisitos e implementação

    Para implantar a implementação de referência, é necessário clonar o repositório:

    git clone https://github.com/aws-samples/sample-bedrock-guardrails-cloudwatch.git
    cd sample-bedrock-guardrails-cloudwatch

    Os pré-requisitos incluem: uma conta AWS com o AWS Cloud Development Kit (AWS CDK) inicializado na Região de destino, Python 3.12 ou superior, Node.js 20 ou superior (para a CLI do AWS CDK), um guardrail do AWS Bedrock existente e o model invocation logging habilitado com trace de guardrail ativado. A Região de destino deve suportar o CloudWatch unified data store e a integração com AWS S3 Tables (consulte a disponibilidade regional do CloudWatch pipelines).

    Habilitando o model invocation logging

    O model invocation logging captura os dados de trace do guardrail necessários. É preciso ativar o logging completo de requisição e resposta para um grupo de logs do CloudWatch e configurar textDataDeliveryEnabled para capturar os corpos de texto que incluem a saída do trace do guardrail. O comando a seguir via AWS Command Line Interface (AWS CLI) habilita essa configuração:

    aws bedrock put-model-invocation-logging-configuration \
      --logging-config '{
        "cloudWatchConfig": {
          "logGroupName": "/aws/bedrock/model-invocation-logs",
          "roleArn": "arn:aws:iam::123456789012:role/BedrockLoggingRole"
        },
        "textDataDeliveryEnabled": true
      }'

    Como o logging é um pré-requisito em nível de conta, as stacks do CDK não o gerenciam. Ele deve ser habilitado uma vez em cada conta antes do deploy.

    Fazendo o deploy do pipeline de transformação

    A implementação de referência implanta duas stacks do CloudFormation: TransformPipelineStack e MonitoringStack. Os comandos a seguir fazem o deploy na ordem correta de dependência:

    cdk deploy TransformPipelineStack \
      -c destination_log_group=/aws/cloudwatch-uds/bedrock-guardrails-ocsf
    
    cdk deploy MonitoringStack \
      -c alarm_email=your-team@example.com

    Ou para fazer o deploy de ambas as stacks de uma vez:

    cdk deploy --all \
      -c destination_log_group=/aws/cloudwatch-uds/bedrock-guardrails-ocsf \
      -c alarm_email=your-team@example.com

    A TransformPipelineStack implanta a função Lambda, o filtro de assinatura, o grupo de logs de destino e a fila de mensagens mortas. O filtro de assinatura captura apenas os eventos onde um guardrail bloqueou ou modificou conteúdo — não os eventos de passagem bem-sucedidos — o que reduz invocações e custos. A severidade é definida como High para intervenções de injeção de prompt e Medium para intervenções de conteúdo, tópico ou informações sensíveis.

    Configurando a integração com S3 Tables

    Para tornar os registros OCSF consultáveis via Athena, é necessário associar o grupo de logs de destino ao AWS S3 Tables. Isso envolve duas etapas: criar uma integração S3 Tables e associar o grupo de logs como fonte de dados.

    Primeiro, adicione as tags cw:datasource:name (por exemplo, bedrock_guardrails) e cw:datasource:type (por exemplo, ocsf) ao grupo de logs de destino. O nome da tabela gerada une os dois valores com sublinhado duplo — essas tags de exemplo produzem uma tabela chamada bedrock_guardrails__ocsf.

    Em seguida, crie a integração com CreateS3TableIntegration (CloudWatch Observability Admin), fornecendo uma configuração de criptografia e uma função IAM. Isso retorna um ARN de integração. Por fim, associe a fonte de dados com AssociateSourceToS3TableIntegration (CloudWatch Logs), passando o ARN da integração e os valores de dataSource. A implementação de referência realiza essas etapas automaticamente via CDK.

    Após a associação, os registros OCSF ficam disponíveis como uma tabela Apache Iceberg no catálogo gerenciado, no caminho "s3tablescatalog/aws-cloudwatch"."logs"."bedrock_guardrails__ocsf". É possível consultá-la com Athena, AWS Redshift ou qualquer ferramenta compatível com Iceberg.

    Para habilitar o acesso analítico, é necessário ainda ativar a integração de analytics do AWS S3 Tables no console do S3 e conceder permissões de leitura via AWS Lake Formation aos papéis IAM que executarão as consultas. Sem essa concessão, as consultas do Athena retornarão erro de acesso negado mesmo com a política IAM correta.

    Consultando as intervenções

    Após o deploy, os dados de intervenção de guardrail ficam disponíveis por dois caminhos de consulta.

    Athena (via AWS S3 Tables): correlação entre fontes e análise histórica

    O exemplo a seguir identifica usuários que disparam tanto intervenções de injeção de prompt quanto atividade com falha no CloudTrail. O lado do guardrail extrai campos de cwl__message; o lado do CloudTrail é uma fonte nativa com colunas OCSF tipadas:

    WITH guardrail_violators AS (
      SELECT json_extract_scalar(cwl__message, '$.actor.user.uid') AS user_arn,
             COUNT(*) AS violation_count
      FROM bedrock_guardrails_ocsf
      WHERE json_extract_scalar(cwl__message, '$.unmapped.guardrail_policy_type') = 'PromptAttack'
      GROUP BY json_extract_scalar(cwl__message, '$.actor.user.uid')
    ),
    iam_failures AS (
      SELECT "actor.user.uid" AS user_arn,
             COUNT(*) AS failure_count
      FROM aws_cloudtrail__management
      WHERE "status_id" = 2
      GROUP BY "actor.user.uid"
    )
    SELECT g.user_arn, g.violation_count, i.failure_count
    FROM guardrail_violators g
    JOIN iam_failures i ON g.user_arn = i.user_arn
    ORDER BY g.violation_count DESC;

    Para acompanhar tendências de violação por tipo de política ao longo do tempo:

    SELECT date_trunc('day', from_unixtime(
             cast(json_extract_scalar(cwl__message, '$.time') as bigint) / 1000)) AS event_day,
           json_extract_scalar(cwl__message, '$.unmapped.guardrail_policy_type') AS policy_type,
           COUNT(*) AS violation_count
    FROM bedrock_guardrails_ocsf
    GROUP BY 1, 2
    ORDER BY event_day, violation_count DESC;

    CloudWatch Logs Insights: consultas operacionais em tempo real

    Para consultas operacionais sobre dados recentes sem join de tabelas, é possível consultar o grupo de logs de destino diretamente no CloudWatch Logs Insights:

    fields @timestamp, severity, finding_info.title, actor.user.uid, unmapped.guardrail_policy_type
    | filter class_uid = 2004
    | filter unmapped.guardrail_policy_type = "PromptAttack"
    | stats count() as attack_count by actor.user.uid
    | sort attack_count desc
    | limit 10

    Deploy multi-conta

    Para organizações que executam o AWS Bedrock em múltiplas contas, o padrão recomendado é transformar localmente e centralizar a saída OCSF — em vez de replicar os logs brutos de invocação e transformar de forma centralizada. O pipeline de transformação é implantado em cada conta de workload onde o model invocation logging está habilitado. Cada conta produz registros OCSF em seu próprio grupo de logs de destino. Em seguida, a centralização de logs do CloudWatch replica automaticamente esses registros OCSF para uma conta central de logging.

    A centralização se integra ao AWS Organizations e detecta novas contas automaticamente. A integração com AWS S3 Tables é criada uma única vez na conta central, permitindo consultas em toda a organização. Transformar em cada conta de workload mantém o parsing próximo da fonte e evita mover logs brutos de invocação — que podem conter texto de prompt e resposta — entre fronteiras de conta.

    Limpeza dos recursos

    Para evitar cobranças contínuas, destrua as stacks na ordem inversa de dependência:

    cdk destroy MonitoringStack --force
    cdk destroy TransformPipelineStack --force

    Conclusão

    A solução publicada pela AWS mostra como transformar eventos de intervenção do AWS Bedrock Guardrails em registros OCSF Detection Finding e ingeri-los no CloudWatch unified data store. Essa integração fornece às equipes de SOC telemetria estruturada de guardrail que se correlaciona com CloudTrail, VPC Flow Logs e outras fontes de segurança já disponíveis no CloudWatch.

    Como as intervenções de guardrail são uma fonte customizada, seus campos OCSF são armazenados como JSON e lidos com funções json_extract do Athena — o que permite juntá-los com as fontes nativas OCSF que compartilham o mesmo catálogo. O pipeline filtra apenas eventos de intervenção, mantendo os custos baixos enquanto captura os sinais relevantes para segurança.

    A implementação de referência está disponível para clone e adaptação conforme a configuração de guardrail de cada ambiente. O mesmo padrão de transformação pode ser estendido para traces de guardrail de agentes, que se mapeiam para a mesma classe OCSF Detection Finding.

    Fonte

    Transforming Bedrock Guardrails events into OCSF with CloudWatch (https://aws.amazon.com/blogs/security/transforming-bedrock-guardrails-events-into-ocsf-with-cloudwatch/)

  • AWS Continuum agora suporta teste de credenciais e sugestões de domínios acessíveis

    O que mudou no AWS Continuum

    A AWS anunciou duas novas capacidades para o AWS Continuum, seu agente voltado para testes de penetração ao longo do ciclo de desenvolvimento de aplicações. A partir de agora, equipes de desenvolvimento e segurança podem testar credenciais de login e receber sugestões de domínios acessíveis antes de iniciar um teste de penetração — uma mudança que promete economizar tempo e evitar retrabalho.

    O problema que essa atualização resolve

    Antes dessa atualização, configurar o escopo de rede de um teste de penetração era um processo manual e propenso a erros. Identificar todas as URLs que uma aplicação acessa exigia esforço manual considerável, e falhas de autenticação só eram descobertas após um ciclo completo de testes — ou seja, tempo e recursos já tinham sido consumidos sem resultado útil.

    Esse fluxo gerava dois problemas práticos: escopos de rede mal configurados e ciclos de teste desperdiçados por falhas de credencial que poderiam ter sido detectadas antes.

    Como as novas capacidades funcionam

    Com a atualização, ao adicionar credenciais de login durante a configuração do teste, o AWS Continuum autentica na aplicação exatamente como um usuário real faria. Durante esse processo, o agente captura todos os domínios acessíveis durante o login e os apresenta como sugestões de URLs dentro do escopo do teste.

    Isso permite que a equipe revise os domínios acessíveis, valide as credenciais e confirme que o agente está cobrindo os endpoints corretos — tudo antes do teste real começar.

    Um detalhe importante: os domínios acessíveis são retornados independentemente do resultado do teste de credencial, seja ele bem-sucedido, com falha ou com timeout. Ou seja, mesmo que a autenticação não funcione, a equipe ainda recebe informações úteis sobre os domínios alcançados.

    Disponibilidade

    Essa capacidade está disponível em todas as regiões onde o AWS Continuum para testes de penetração já está disponível. Para saber mais sobre o funcionamento detalhado do recurso, a AWS disponibilizou a documentação atualizada. Informações sobre o serviço em geral podem ser encontradas na página do produto AWS Continuum.

    Por que isso importa para equipes brasileiras

    Para times de segurança e desenvolvimento que utilizam o AWS Continuum, essa atualização representa uma melhoria direta na eficiência operacional. Configurar o escopo correto desde o início e garantir que as credenciais funcionam antes de rodar um teste completo são passos que evitam desperdício de tempo — e, em ambientes de nuvem, tempo de computação tem custo direto.

    A mudança reforça a proposta do AWS Continuum como um agente proativo de segurança, que busca antecipar problemas em vez de apenas reportá-los depois que o dano já está feito.

    Fonte

    AWS Continuum now supports credential testing and accessible domain suggestions (https://aws.amazon.com/about-aws/whats-new/2026/09/aws-security-agent/)

  • AWS Resilience Hub ganha três novas capacidades

    O que é o AWS Resilience Hub

    O AWS Resilience Hub é o serviço centralizado da AWS voltado para equipes de engenharia de plataforma e de Confiabilidade do Site (SRE — Site Reliability Engineering). Ele permite avaliar e fortalecer a resiliência de cargas de trabalho rodando na AWS, oferecendo descoberta automatizada de dependências, análise de modos de falha com IA generativa, políticas modulares de resiliência, testes de resiliência e relatórios de postura de resiliência em escala organizacional.

    As três novas capacidades anunciadas

    Suporte a labels do EKS como fonte de entrada de serviços

    O Resilience Hub passou a suportar labels do EKS dentro de um namespace como fonte de entrada de serviços. Na prática, isso significa que as equipes podem utilizar as convenções de rotulagem do Kubernetes que já existem em seus ambientes para definir com precisão quais recursos o Resilience Hub vai descobrir e utilizar durante a análise de modos de falha. O resultado é que as avaliações ficam alinhadas com a forma como as equipes já organizam suas cargas de trabalho no EKS — sem precisar reconfigurar nada do zero.

    Insights de dependências com IA generativa

    Para quem já utiliza a descoberta de dependências, agora é possível gerar dependency insights — uma nova funcionalidade baseada em IA generativa que analisa as dependências de aplicações descobertas e destaca padrões relevantes. A capacidade identifica novas dependências, aponta dependências entre regiões (cross-Region) e sinaliza padrões de uso incomuns. O objetivo é ajudar as equipes a acelerar a análise de dependências e identificar potenciais novos riscos antes que se tornem problemas reais.

    Compartilhamento de políticas de resiliência via AWS Organizations

    O Resilience Hub agora suporta o compartilhamento de políticas de resiliência por meio do AWS Organizations. Com isso, equipes centrais podem criar e gerenciar políticas que são aplicadas em múltiplas contas da organização. Além disso, a funcionalidade oferece visibilidade em nível organizacional sobre quais serviços estão utilizando cada política, facilitando o monitoramento da adoção e garantindo uma postura de resiliência consistente em toda a organização.

    Disponibilidade regional

    A nova geração do AWS Resilience Hub está disponível nas seguintes regiões da AWS: Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon), Canadá (Central), Europa (Irlanda), Europa (Londres), Europa (Frankfurt), Europa (Paris), Europa (Estocolmo), Ásia-Pacífico (Mumbai), Ásia-Pacífico (Singapura), Ásia-Pacífico (Sydney), Ásia-Pacífico (Tóquio), Ásia-Pacífico (Seul) e América do Sul (São Paulo).

    Como começar

    Para explorar as novas capacidades, acesse o console da AWS. Para aprofundar o conhecimento, consulte a página do produto ou a documentação oficial.

    Fonte

    AWS Resilience Hub adds three new capabilities (https://aws.amazon.com/about-aws/whats-new/2026/09/resilience-hub-eks-dependency-policy/)

  • AWS Transfer Family passa a preservar o IP de origem do cliente em servidores SFTP atrás de um NLB

    O que mudou no AWS Transfer Family

    A AWS anunciou uma atualização relevante para quem usa o AWS Transfer Family com servidores SFTP (Protocolo Seguro de Transferência de Arquivos) atrás de um Balanceador de Carga de Rede (NLB): a partir de agora, o serviço passa a preservar o endereço IP de origem do cliente por meio do Protocolo Proxy v2 (PPv2).

    Essa novidade se aplica especificamente a cenários em que o servidor SFTP utiliza um endpoint hospedado em Nuvem Privada Virtual (VPC) e há um NLB próprio posicionado à frente dele.

    Qual era o problema antes

    Antes dessa atualização, quando um NLB era colocado na frente do servidor SFTP do Transfer Family, o balanceador substituía o endereço IP real do cliente pelo seu próprio IP privado. Isso causava dois problemas práticos:

    • Os logs e eventos do Transfer Family registravam o IP do NLB, e não o IP verdadeiro de quem estava se conectando.
    • Durante o processo de autenticação com um provedor de identidade personalizado, o endereço apresentado era o do NLB — tornando impossível autorizar ou bloquear usuários com base no IP real de origem.

    Para equipes que precisam de rastreabilidade, conformidade ou controles de acesso baseados em IP, esse comportamento era uma limitação significativa.

    O que muda com o novo suporte a PPv2

    Com a nova funcionalidade, é possível habilitar a preservação do IP de origem diretamente em cada servidor do Transfer Family. Quando ativado, o endereço IP real do cliente é:

    • Registrado nos logs e eventos do Transfer Family;
    • Apresentado ao provedor de identidade personalizado durante a autenticação.

    Isso abre caminho para implementar auditorias baseadas em IP, controles de acesso mais granulares e atender a requisitos de conformidade regulatória que exigem rastreabilidade do endereço de origem das conexões.

    Como habilitar o recurso

    A funcionalidade pode ser ativada individualmente em cada servidor do Transfer Family, por meio de três formas:

    • Console da AWS;
    • Interface de Linha de Comando (CLI) da AWS;
    • Kit de Desenvolvimento de Software (SDK) / Interface de Programação de Aplicações (API) da AWS.

    Disponibilidade

    A preservação do IP de origem para servidores SFTP está disponível em todas as regiões da AWS onde o Transfer Family está disponível. Para aprofundar os detalhes técnicos de configuração, a AWS disponibiliza o Guia do Usuário do Transfer Family.

    Fonte

    AWS Transfer Family now supports source IP preservation for SFTP servers behind a Network Load Balancer (NLB) (https://aws.amazon.com/about-aws/whats-new/2026/09/transfer-family-sftp-source-ip-nlb/)