Category: Uncategorized

O problema que a rotação de chaves não resolve

Imagine o seguinte cenário: você é o administrador de e-mail do domínio da sua organização e recebe um relatório agregado de Autenticação, Relatório e Conformidade de Mensagens Baseadas em Domínio (DMARC) mostrando e-mails passando na verificação de Correio Identificado por Chaves de Domínio (DKIM) como se viessem do seu domínio — mas enviados de endereços IP que você não reconhece, para destinatários que você nunca contatou.

Para resolver, você faz a rotação da chave DKIM, confirma que o novo seletor está ativo e verifica que sua política DMARC já está configurada como p=reject. Dias depois, o mesmo tráfego desconhecido continua se autenticando como se fosse seu domínio.

O blog de segurança da AWS publicou um artigo detalhado explicando por que a rotação de chaves sozinha não consegue parar um ataque de replay DKIM, como confirmar que você está diante de um replay (e não de um relay legítimo ou spoofing comum), e qual etapa de limpeza no DNS a maioria dos guias de rotação deixa de fora. O artigo também mostra como o Amazon Simple Email Service (Amazon SES) pode ajudar a detectar e responder a essa atividade mais rapidamente.

Como funciona o replay DKIM

O DKIM verifica uma coisa: que partes específicas de uma mensagem não foram alteradas entre o assinante e o receptor. O assinante assina a mensagem com uma chave privada, e os receptores buscam a chave pública correspondente no DNS do domínio para verificar a assinatura. Uma assinatura válida continua sendo validada por onde quer que a mensagem trafegue depois — listas de distribuição, regras de encaminhamento e relays de terceiros preservam essa assinatura. Isso é o protocolo funcionando como projetado.

O ataque de replay explora justamente essa durabilidade. O fluxo funciona assim:

• Sua plataforma de e-commerce envia um e-mail legítimo de resposta a um cliente, assinado com sua chave DKIM.
• Um atacante obtém uma cópia dessa mensagem — pode ser assinando sua lista de e-mails, comprometendo uma caixa de entrada, recuperando de um arquivo de lista ou capturando via regra de encaminhamento.
• O atacante reenvia essa mensagem, sem alterações, dos seus próprios servidores para milhares de novos destinatários.
• Cada servidor receptor busca sua chave pública no DNS e verifica a assinatura. A assinatura passa porque o corpo não foi modificado.
• O Quadro de Política de Remetente (SPF) falha porque o IP de envio não é seu, mas o DMARC exige apenas que SPF ou DKIM passe com alinhamento. Como o DKIM passa, o DMARC passa, e a mensagem é entregue como e-mail autenticado do seu domínio.

É fundamental entender o que o atacante pode e não pode fazer. Ele não consegue modificar sua mensagem, adicionar conteúdo novo ou ler seus e-mails — a assinatura só é válida enquanto a mensagem permanece idêntica byte a byte. O que o atacante ganha é a reputação do seu domínio, que ele usa para entregar sua mensagem genuína a um público que você não pretendia alcançar. Um recibo ou fatura se torna uma isca, e e-mails que normalmente seriam filtrados são entregues porque os receptores confiam no seu domínio.

Isso é abuso de reputação e alcance, não falsificação de conteúdo — e essa distinção importa quando você explica o incidente para sua equipe de segurança.

Isso também explica por que uma política DMARC de p=reject não bloqueia esse ataque. O DMARC passa quando SPF ou DKIM passa com alinhamento. Durante um replay, o DKIM passa, então o DMARC passa, e o p=reject não se aplica. Essa política foi projetada para bloquear spoofing, onde o falsificador não tem assinatura válida e o DKIM falha. Ela não faz nada contra uma mensagem que você mesmo assinou.

É replay, spoofing ou relay legítimo?

E-mail vindo de um IP desconhecido que passa no DKIM tem três explicações comuns, e cada uma exige uma resposta diferente. É preciso confirmar qual é o caso antes de fazer qualquer alteração.

Os relatórios agregados DMARC (rua) fornecem o endereço IP de origem, volume de mensagens e resultados de SPF e DKIM. Isso é suficiente para identificar uma anomalia, mas não para provar um replay. Uma linha de relatório pode se parecer com isto:

source IP: 203.0.113.45 | count: 4,200 | SPF: fail | DKIM: pass (d=yourdomain.com)

É necessário avaliar essa linha contra três possibilidades:

• Relay legítimo não inventariado: uma lista de distribuição, um encaminhador ou um gateway de segurança de e-mail (como um CASB inline) pelo qual você roteia. A assinatura sobrevive validamente ao relay — isso é fluxo normal. No relatório, o IP de origem geralmente resolve para um provedor conhecido e o volume acompanha seu envio real.
• Abuso de replay: um atacante redistribui uma mensagem que você assinou legitimamente. O volume passando no DKIM vem de um IP sem relação comercial com você, frequentemente muito acima do número usual de destinatários, e muitas vezes para domínios com os quais você nunca trabalhou.
• Spoofing comum: uma falsificação sem assinatura válida. Nesse caso, a linha mostra DKIM: fail. DKIM passando de um IP desconhecido, portanto, geralmente não é spoofing comum.

Contagens agregadas sozinhas não provam um replay. Para confirmar, é necessária evidência em nível de mensagem: uma mensagem específica que você enviou correspondendo a uma que chegou a destinatários que você não endereçou. Se não for possível fazer essa correspondência, trate a atividade como anomalia não confirmada e comece pelas etapas de enforcement e monitoramento.

Configure uma política DMARC de enforcement primeiro

Antes de qualquer outra ação, confirme que você está aplicando o DMARC. Muitos domínios que encontram esse problema ainda estão em p=none, que é apenas monitoramento. Toda implantação DMARC começa em p=none, e muitas organizações não avançam além disso porque nada parece estar quebrado.

O primeiro passo, portanto, não é remoção de chave — é completar o inventário de remetentes e chegar ao enforcement:

• Inventarie cada remetente e relay legítimo do seu domínio, incluindo provedores de serviço de e-mail, listas de distribuição e gateways de segurança que enviam em seu nome.
• Alinhe cada remetente em SPF e DKIM para que o e-mail legítimo se autentique corretamente.
• Avance a política um estágio por vez: de p=none para p=quarantine para p=reject.
• Revise seus relatórios rua em cada estágio antes de avançar, tipicamente por uma ou duas semanas por estágio.
• A tag pct permite aumentar gradualmente — por exemplo, colocando em quarentena 25% dos e-mails falhando antes de aumentar o percentual.

Após o enforcement, receptores que honram o DMARC descartam spoofing não autenticado em nome do seu domínio. Somente depois dessa linha de base estar em vigor, e somente após confirmar um replay de e-mail genuinamente assinado, é que o próximo passo se aplica.

Remova a chave antiga do DNS: higiene de rotina pós-rotação

A maioria dos guias de rotação omite essa etapa. Rotacionar uma chave e remover a chave antiga são duas ações separadas. Rotação significa que seu provedor começa a assinar novos e-mails com uma nova chave e seletor. Remoção significa deletar a chave pública antiga do DNS, para que mensagens assinadas anteriormente — incluindo cópias capturadas por um atacante — não possam mais ser verificadas.

Se você rotaciona mas deixa a chave pública antiga publicada, cada mensagem já assinada com aquela chave permanece replayável enquanto o registro existir. Remover a chave antiga é o que fecha essa janela — e é o passo comumente esquecido.

A remoção afeta apenas mensagens ainda em trânsito assinadas com a chave antiga. Após a entrega, o receptor não precisa mais da sua chave. A recomendação é deixar a chave antiga publicada tempo suficiente para e-mails em trânsito chegarem e então removê-la.

Métodos DKIM no Amazon SES

Como você gerencia as chaves depende do método DKIM utilizado com o Amazon SES:

• BYODKIM (Traga Sua Própria Chave DKIM): você gera o par de chaves e publica a chave pública como registro TXT que você controla. É possível rotacionar e remover chaves quando quiser, incluindo remoção sob demanda durante um incidente. Como a documentação do BYODKIM afirma, “você pode rotacionar as chaves DKIM dos seus domínios com a frequência que desejar”.
• Easy DKIM: o Amazon SES gera e gerencia as chaves. Você publica registros CNAME que apontam para chaves hospedadas na AWS. Como o DNS aponta para chaves hospedadas pela AWS através desses CNAMEs, o Amazon SES gerencia o material de chave subjacente, então você não publica ou remove chaves individuais diretamente. Diferente do BYODKIM, o Easy DKIM não oferece opção sob demanda para deletar uma chave específica imediatamente.

Se você usa Easy DKIM durante um replay confirmado, suas defesas são: detecção precoce, o throttling de mensagens duplicadas que os receptores já aplicam, e a longo prazo, a iniciativa DKIM2 — um esforço do IETF para atualizar a especificação DKIM com resistência nativa a replay.

Como o Amazon SES ajuda na detecção e resposta

A primeira resposta é detecção, não mudanças no DNS. O objetivo é identificar volume anômalo passando no DKIM cedo, enquanto se constrói a evidência em nível de mensagem que distingue replay de relay legítimo.

Habilitando o monitoramento

Crie um conjunto de configuração do Amazon SES com destino de eventos (veja Monitorar envio de e-mail usando publicação de eventos do Amazon SES) que transmita eventos por mensagem (Send, Delivery, Bounce e Complaint) para o Amazon Data Firehose ou Amazon EventBridge (veja Adicionar um destino de evento), tagueados com o domínio do From.

Separadamente, confirme que você está recebendo relatórios rua para seu domínio. Esses relatórios são habilitados adicionando um endereço rua= ao registro TXT DMARC do domínio, por exemplo rua=mailto:dmarc-reports@yourdomain.com. Para a sintaxe do registro e um rollout gradual de p=none para p=quarantine para p=reject, consulte Conformidade com o protocolo de autenticação DMARC no Amazon SES. Os relatórios chegam como resumos XML diários, e a maioria das equipes os processa com um analisador DMARC.

Correlação de dados

Com ambas as fontes ativas, é possível correlacioná-las: compare os e-mails que sua conta emitiu (com base nos eventos de entrega do Amazon SES) contra o que os relatórios DMARC mostram que os receptores aceitaram como seu domínio. Quando o DMARC mostra volume passando no DKIM de IPs fora do seu registro SPF que excede os eventos de entrega que o Amazon SES registrou para aquele domínio From no mesmo período, essa diferença é o seu sinal.

Controles adicionais recomendados

• Autorização de envio do Amazon SES: restringe quais principals da AWS podem enviar usando sua identidade verificada. Não impede um replay externo, mas endereça o vetor de insider e terceiros que SPF, DKIM e DMARC não cobrem sozinhos. Use políticas em nível de identidade para limitar o envio a principals específicos do AWS Identity and Access Management (IAM).
• TTLs curtos no DNS: use o Amazon Route 53 para definir valores baixos de Tempo de Vida (TTL) — por exemplo, 300 segundos — nos registros DKIM, para que mudanças se propaguem rapidamente. Habilite o log de consultas DNS com um filtro de métricas do Amazon CloudWatch Logs que monitore consultas a um seletor do qual você já migrou. Um pico de lookups para um seletor antigo é um indicador precoce útil de tentativa de replay.
• Automação de remoção: para domínios BYODKIM durante replay confirmado, o Route 53 é onde você remove o registro TXT do seletor antigo. É possível automatizar essa remoção usando um alarme do CloudWatch que aciona uma função AWS Lambda para chamar a API do Route 53 e aposentar o registro do seletor antigo. Escope a role IAM da função apenas para a hosted zone e registro específicos que ela precisa alterar, seguindo o princípio de menor privilégio. Como uma mudança incorreta no DNS pode ter efeito amplo, condicione qualquer automação a critérios de replay confirmado e teste em domínio não-produtivo primeiro. Para a maioria das equipes, alarme-para-humano é mais seguro do que alarme-para-remoção-automática.

Quando seu domínio é o abusado

A maioria dos guias assume que você é o provedor prevenindo abuso ou o receptor detectando. Em um replay, seu domínio é o que tem a reputação consumida, e você não está na lista de destinatários. Consequentemente, você não tem a mensagem que todos pedem quando você reporta o problema.

Quando você registra uma denúncia de abuso com o provedor que hospeda o IP de origem, eles pedem cabeçalhos completos da mensagem. O e-mail foi para pessoas que você não contatou, então você não tem esses cabeçalhos. Você fornece relatórios DMARC agregados mostrando o IP de origem e volume, e o provedor pede cabeçalhos novamente. Nesse ponto, você fica travado.

Para quebrar esse ciclo: vá aos destinatários. Revise seus relatórios rua para os principais domínios destinatários — frequentemente domínios .gov e .edu — contate esses destinatários diretamente e solicite uma amostra da mensagem com cabeçalhos completos. Além de fornecer os cabeçalhos, essa amostra permite confirmar um replay em vez de relay legítimo.

Construa sua denúncia de abuso em torno do endereço IP e da evidência DMARC, não do conteúdo da mensagem. Se o IP de origem pertence à Amazon Web Services (AWS), reporte através do processo de abuso da AWS e inclua seus relatórios DMARC e registro SPF como evidência.

Resposta a incidentes: ações ordenadas

Se seus relatórios mostram e-mail suspeito passando no DKIM de IPs desconhecidos, siga este procedimento:

• Confirme que é um replay. Correlacione uma mensagem que você enviou com uma que chegou a destinatários que você não endereçou. Descarte relays e gateways legítimos. Dados agregados sozinhos não são prova.
• Chegue a uma política DMARC de enforcement. Inventarie seus remetentes legítimos, alinhe-os e avance de p=none para p=quarantine para p=reject. Isso bloqueia spoofing.
• Endureça o SPF para -all em vez de ~all, mas somente após o inventário de remetentes estar completo, já que -all faz hard-fail em qualquer fonte legítima não listada.
• Verifique o cabeçalho DKIM-Signature de uma mensagem recente para confirmar que seu provedor assina apenas com o seletor atual.
• Reporte o IP de origem ao provedor de hospedagem e inclua sua evidência DMARC.
• Investigue o ponto de captura: caixa de entrada comprometida, lista de distribuição, regra de encaminhamento ou assinatura de newsletter.
• Remova a chave pública DKIM antiga após e-mails em trânsito terem sido entregues. Para BYODKIM, delete o registro TXT do seletor antigo. Para Easy DKIM, confie na rotação gerenciada do Amazon SES junto com o monitoramento e defesas do lado receptor descritas anteriormente.

Resumo das ações e seus limites

• Confirmar replay (nível de mensagem): separa replay de relay legítimo ou spoofing — mas não pode ser feito apenas com dados agregados DMARC.
• Enforcement DMARC (p=reject): descarta spoofing não autenticado — mas não faz nada contra replay porque o DKIM ainda passa.
• Rotação de chave: assina novos e-mails com nova chave — mas não invalida mensagens já assinadas.
• Remoção da chave antiga (pós-rotação): invalida assinaturas da chave antiga, incluindo cópias capturadas — mas não protege e-mails em trânsito com chave antiga; remoção sob demanda disponível apenas com BYODKIM.
• Autorização de envio do Amazon SES: restringe quais principals enviam como sua identidade — mas não impede replay externo de mensagens capturadas.

Conclusão

O replay DKIM funciona porque uma assinatura válida continua validando, e uma política DMARC de enforcement não muda isso. Para responder de forma eficaz, é necessário: confirmar que a atividade é um replay com evidência em nível de mensagem, chegar a uma política DMARC de enforcement e então remover a chave antiga do DNS como higiene de rotina pós-rotação.

A defesa primária deve estar no monitoramento e enforcement DMARC, não em mudanças emergenciais no DNS. A correção durável para replay está do lado do receptor: contagem de mensagens duplicadas hoje, e sinais mais fortes em nível de protocolo através do DKIM2 no futuro.

Para começar, a recomendação é: revisar a política DMARC atual e confirmar o recebimento de relatórios rua, habilitar a publicação de eventos do Amazon SES, e documentar como você rotaciona e remove chaves DKIM para cada domínio.

Saiba mais

• Autenticação de e-mail com DKIM no Amazon SES
• Conformidade com o protocolo DMARC no Amazon SES
• Usando autorização de envio com o Amazon SES
• DKIM2: Uma Revisão do DKIM (Grupo de Trabalho IETF)
• Logging de consultas DNS públicas do Route 53 com Amazon CloudWatch Logs

Fonte

Beyond DKIM key rotation: understanding email replay attacks (https://aws.amazon.com/blogs/security/beyond-dkim-key-rotation-understanding-email-replay-attacks/)

Um marco para a soberania digital na nuvem

No sábado, 24 de outubro de 2026, a AWS realizou um exercício técnico histórico: demonstrou, publicamente e com evidências verificáveis, que a AWS European Sovereign Cloud é capaz de operar de forma totalmente independente, sem depender de qualquer infraestrutura fora da União Europeia (UE). De acordo com a própria AWS, foi a primeira demonstração técnica pública desse tipo para uma região de nuvem soberana.

Para quem acompanha o tema de soberania digital, esse exercício representa uma virada importante: sai do campo das promessas arquiteturais e entra no campo da evidência operacional concreta.

O que é a AWS European Sovereign Cloud

A AWS European Sovereign Cloud é uma partição de nuvem nova e independente para a Europa, que passou a estar disponível para o público geral em janeiro de 2026, com sua primeira Região AWS localizada em Brandenburg, na Alemanha.

A proposta é clara: trata-se de uma infraestrutura fisicamente e logicamente separada das demais Regiões AWS, sem dependências críticas em infraestrutura fora da UE. Todo o conteúdo dos clientes e os metadados criados por eles permanecem dentro do território europeu. Além disso, a operação é gerenciada por entidades jurídicas europeias dedicadas, constituídas sob a lei alemã, e conduzida integralmente dentro da Europa — com controle exclusivo nas mãos de residentes da UE localizados na UE.

O que foi feito no exercício

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

• O backbone da AWS Global Network
• Um sistema dedicado, operado pela equipe local europeia, para gerenciar transferências limitadas e controladas de dados operacionais da AWS

Como a AWS explicou antes do exercício, nenhum desses dois sistemas é crítico para o funcionamento da AWS European Sovereign Cloud. Durante o teste, a equipe desligou ambos os sistemas. O tráfego que normalmente passa pelo backbone da AWS Global Network foi redirecionado de forma segura pela internet pública.

Por várias horas naquele sábado, a AWS European Sovereign Cloud operou exclusivamente com seus próprios recursos de software e hardware, gerenciados por equipes residentes na UE e dentro do território europeu. Os workloads continuaram em execução e os clientes mantiveram acesso aos seus dados sem interrupções.

É importante destacar: o exercício não afetou a disponibilidade dos serviços dentro da AWS European Sovereign Cloud, nem das demais Regiões AWS, nem da conectividade privada via AWS Direct Connect. Ao final do teste, o tráfego retornou normalmente ao seu caminho habitual.

Por que esse exercício importa

A motivação declarada pela AWS para realizar o exercício de forma aberta é a transparência como pilar do compromisso com a soberania digital. Ao conduzir e divulgar publicamente os resultados, a empresa transforma uma afirmação de design em um resultado verificado.

Na prática, isso tem implicações diretas para organizações em setores regulados e para o setor público europeu: o resultado do exercício pode ser apresentado a reguladores e conselhos de administração como evidência técnica e operacional para documentos de conformidade e garantia.

Em outras palavras, deixa de ser uma promessa no papel e passa a ser uma prova concreta de que a independência operacional funciona em condições reais.

O que parceiros e clientes estão dizendo

Grandes empresas do ecossistema de tecnologia comentaram sobre o resultado do exercício. A Capgemini destacou que a soberania digital é, em essência, uma questão de confiança e continuidade de negócios, e que a demonstração representa um ponto de prova importante para organizações europeias com os requisitos mais rigorosos de soberania.

A Atos reforçou que alcançar soberania exige mais do que uma arquitetura sólida — demanda evidência operacional para construir confiança. A empresa mencionou seu envolvimento com a AWS European Sovereign Cloud desde o início do projeto e seu papel como parceira de lançamento da AWS Digital Sovereignty Competency.

A Genesys apontou que ver a AWS European Sovereign Cloud operar de forma independente em condições reais ajuda a dar mais confiança aos clientes compartilhados para migrar seus workloads mais sensíveis para a nuvem, mantendo dados e operações dentro da UE.

Já a Accenture classificou a independência operacional como um pilar definidor da soberania digital e destacou sua posição como colaboradora desde antes do lançamento da plataforma, o que a coloca em posição privilegiada para ajudar clientes a navegar pelos requisitos de soberania.

Para saber mais

Para quem quiser se aprofundar no design e nos controles de soberania digital da AWS European Sovereign Cloud, a AWS disponibiliza informações detalhadas em aws.eu. Dúvidas sobre o exercício ou sobre workloads específicos podem ser direcionadas ao AWS Support ou à equipe de conta AWS.

Fonte

Inside a successful AWS European Sovereign Cloud exercise to demonstrate independent operation (https://aws.amazon.com/blogs/security/inside-a-successful-aws-european-sovereign-cloud-exercise-to-demonstrate-independent-operation/)

O que foi anunciado

A AWS anunciou a disponibilidade do app desktop do ChatGPT integrado ao Amazon Bedrock no AWS GovCloud (US). A integração oferece acesso aos modelos de fronteira da OpenAI por meio de dois componentes principais: o Work, voltado para tarefas complexas de múltiplas etapas que entregam resultados prontos para revisão, e o Codex, um agente de codificação para desenvolvimento, testes e revisão de software.

Este guia é direcionado a organizações cuja arquitetura de segurança exige que a inferência de modelos utilize identidades, endpoints e controles regionais do AWS GovCloud (US). A configuração roteia as requisições do Codex pelo Amazon Bedrock Mantle na região us-gov-west-1, onde o acesso pode ser governado pelo Gerenciamento de Identidade e Acesso da AWS (IAM) e pelos controles de rede existentes no AWS GovCloud (US).

Entendendo o Codex e suas capacidades

O Codex é o agente de codificação da OpenAI para desenvolvimento de software com inteligência artificial. Alimentado pelos modelos GPT, ele foi otimizado para fluxos de trabalho complexos de desenvolvimento de longa duração. Os desenvolvedores podem utilizá-lo por meio do app desktop do ChatGPT, da Interface de Linha de Comando (CLI) do Codex e de integrações com ambientes de desenvolvimento como Visual Studio Code, JetBrains e Xcode.

A inferência dos modelos é roteada pela Responses API no Amazon Bedrock. Para clientes com requisitos de residência de dados, o processamento permanece dentro da Região AWS do Amazon Bedrock selecionada. O modelo de cobrança é por token, sem licenças por assento e sem compromissos por desenvolvedor.

A integração também suporta Retenção Zero de Dados (ZDR — Zero Data Retention). Nesse modo configurável, prompts e respostas são processados sem serem gravados em armazenamento durável pela AWS ou compartilhados com os provedores de modelos, o que ajuda a proteger informações sensíveis e atender a requisitos rigorosos de governança de dados, privacidade e segurança.

Visão geral da solução

O app desktop do ChatGPT pode ser utilizado de duas formas principais:

• Work: para tarefas maiores que envolvem planejamento, pesquisa, arquivos e entrega de um resultado finalizado.
• Codex: para trabalho técnico, como edição de código, execução de testes e revisão de pull requests.

O app roda em um computador gerenciado pela organização e utiliza as credenciais AWS configuradas para enviar requisições de forma segura ao endpoint do Amazon Bedrock Mantle em us-gov-west-1. Como a configuração usa a AWS diretamente, as regras de workspace e os papéis de usuário do ChatGPT não exercem controle sobre ela. Os principais controles de segurança são as políticas do computador e a identidade e permissões AWS em uso.

Atenção: utilizar o AWS GovCloud (US) e seguir este guia não autoriza automaticamente sua carga de trabalho. A organização continua responsável por revisar o modelo selecionado, os serviços AWS, a região, o endpoint, os controles da estação de trabalho, os repositórios, as credenciais e os fluxos de dados em relação ao seu plano de segurança do sistema e ao processo de autorização vigente.

Passo a passo de configuração

A configuração envolve três etapas principais: configurar a autenticação, criar os arquivos de configuração do app e, por fim, iniciar, inicializar e verificar o deployment.

Pré-requisitos

Antes de iniciar, é necessário garantir que sua versão do app desktop do ChatGPT suporta o Amazon Bedrock no AWS GovCloud (US). Além disso, são necessários: uma conta aprovada no AWS GovCloud (US), uma identidade IAM com credenciais aprovadas, acesso ao modelo, à Região AWS e ao endpoint aprovados, além de permissão para utilizá-los. Também é necessário preparar os arquivos requirements.toml e config.toml.

Etapa 1: Configurar a autenticação

Selecione a conta AWS GovCloud (US) aprovada e a identidade ou papel IAM com acesso ao modelo aprovado em us-gov-west-1. Obtenha as credenciais pelo mecanismo aprovado pela organização. O guia utiliza o perfil nomeado codex-il5 como exemplo.

É fundamental manter credenciais, tokens de portador (bearer tokens), tokens de sessão e outros segredos fora dos arquivos TOML.

O app desktop do ChatGPT suporta dois caminhos de autenticação com o Amazon Bedrock:

• Uma chave de API do Amazon Bedrock
• A cadeia de credenciais do AWS SDK

O Logon Único da AWS (SSO — Single Sign-On) via AWS IAM Identity Center é suportado dentro do caminho de cadeia de credenciais. O app verifica primeiro a variável AWS_BEARER_TOKEN_BEDROCK no seu ambiente. Para uso no desktop, essa variável pode ser fornecida via %USERPROFILE%\.codex\.env no Windows ou ~/.codex/.env no Linux e macOS. Quando presente, o bearer token tem precedência sobre a autenticação baseada em perfil.

Se nenhum bearer token estiver disponível, o app recorre à cadeia de credenciais padrão do AWS SDK, que lê as credenciais de ~/.aws/credentials e as configurações de perfil de ~/.aws/config. No Windows, os caminhos padrão correspondentes são %USERPROFILE%\.aws\credentials e %USERPROFILE%\.aws\config. A cadeia também suporta perfis SSO, usando as configurações do arquivo de configuração AWS e a sessão SSO em cache para obter credenciais temporárias de papel, sem necessidade de armazená-las manualmente no arquivo de credenciais. Para mais detalhes, consulte a documentação de autenticação Bedrock da OpenAI e a documentação do provedor de credenciais do AWS IAM Identity Center.

Etapa 2: Criar os arquivos de configuração do app

É necessário criar dois arquivos de configuração: config.toml e requirements.toml. Importante: os arquivos de configuração devem estar criados antes do primeiro lançamento do aplicativo.

Os locais dos arquivos variam conforme o sistema operacional:

• Windows: %USERPROFILE%\.codex\config.toml (usuário) e %ProgramData%\OpenAI\Codex\requirements.toml (administrador)
• Linux e macOS: ~/.codex/config.toml (usuário) e /etc/codex/requirements.toml (administrador)

O arquivo requirements.toml é controlado pelo administrador e define limites de segurança que os usuários não podem sobrescrever — como restrições de nível de permissão, ferramentas e configurações. Use a seguinte configuração base para o deployment aprovado do Amazon Bedrock no AWS GovCloud (US). A seção [windows] se aplica apenas ao Windows, e sandbox_private_desktop deve ser suportado pelo runtime aprovado:

allowed_login_methods = ["api"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
allowed_approvals_reviewers = ["user"]
allowed_approval_policies = [
  { granular = { sandbox_approval = false, rules = true, mcp_elicitations = false, request_permissions = false, skill_approval = true } },
]
allowed_web_search_modes = ["disabled", "cached"]
allow_browser_and_computer_use = false
allow_appshots = false
allow_remote_control = false
allow_login_shell = false
allow_managed_hooks_only = true
check_for_update_on_startup = false
mcp_servers = {}

[feedback]
enabled = false

[features]
network_proxy = true
in_app_chat = false
in_app_dictation = false
in_app_browser = false
browser_use = false
browser_use_external = false
browser_use_full_cdp_access = false
computer_use = false
in_app_updates = false
image_generation = false
memories = false
chronicle = false
external_agent_memory_import = false
guardian_approval = false
guardianv2 = false
guardian_ext = false
apps = false
enable_mcp_apps = false
plugins = false
remote_plugin = false
plugin_sharing = false
recommended_plugins = false
skill_mcp_dependency_install = false
skill_search = false
workspace_dependencies = false
hooks = false
standalone_web_search = false

[experimental_network]
enabled = true
managed_allowed_domains_only = true
domains = {}
unix_sockets = {}
allow_upstream_proxy = false
dangerously_allow_non_loopback_proxy = false
dangerously_allow_all_unix_sockets = false
allow_local_binding = false

[application.network]
enabled = true

[application.network.domains]
"bedrock-mantle.us-gov-west-1.api.aws" = "allow"
"api.openai.com" = "deny"
"chat.openai.com" = "deny"
"chatgpt.com" = "deny"
"ab.chatgpt.com" = "deny"
"platform.openai.com" = "deny"
"auth.openai.com" = "deny"
"gov.api.openai.com" = "deny"
"gov.chatgpt.com" = "deny"
"sdfedpreastus2.oaiusercontent.com" = "deny"
"o33249.ingest.us.sentry.io" = "deny"
"persistent.oaistatic.com" = "deny"
"oaisidekickupdates.blob.core.windows.net" = "deny"

[windows]
allowed_sandbox_implementations = ["elevated"]
sandbox_private_desktop = true

Em seguida, configure o arquivo config.toml, que instrui o app sobre como operar: qual provedor de modelo usar (amazon-bedrock), qual modelo selecionar e configurações como permissões e limites de contexto. Substitua o ID do modelo e o perfil nomeado (por exemplo, codex-il5) pelos valores aprovados pela sua organização:

model = "REPLACE_WITH_APPROVED_MODEL_ID"
model_provider = "amazon-bedrock"
forced_login_method = "api"
approval_policy = { granular = { sandbox_approval = false, rules = true, mcp_elicitations = false, request_permissions = false, skill_approval = true } }
approvals_reviewer = "user"
sandbox_mode = "workspace-write"
web_search = "cached"
allow_login_shell = false
check_for_update_on_startup = false

[model_providers.amazon-bedrock]
base_url = "https://bedrock-mantle.us-gov-west-1.api.aws/openai/v1"
wire_api = "responses"
requires_openai_auth = false
supports_websockets = false
supports_standalone_web_search = false

[model_providers.amazon-bedrock.aws]
region = "us-gov-west-1"
profile = "codex-il5"

[sandbox_workspace_write]
network_access = false

[features]
network_proxy = true

[analytics]
enabled = false

[feedback]
enabled = false

[otel]
exporter = "none"
trace_exporter = "none"
metrics_exporter = "none"
log_user_prompt = false

[memories]
generate_memories = false
use_memories = false

[skills.bundled]
enabled = false

[apps._default]
enabled = false

[windows]
sandbox = "elevated"

Etapa 3: Iniciar, inicializar e verificar

Baixe o app no site do ChatGPT e instale-o. Deixe o app fechado após a instalação. Se ele abrir automaticamente ou já tiver sido iniciado anteriormente, encerre completamente o ChatGPT e finalize quaisquer processos remanescentes do ChatGPT ou do Codex.

Certifique-se de que os arquivos requirements.toml e config.toml estejam nos locais corretos antes do primeiro lançamento. Ao iniciar o app, ele carregará as configurações desses arquivos. Verifique se o provedor de modelo exibido é amazon-bedrock. Na CLI do Codex, uma aba /status confirmará o provedor. No app desktop do ChatGPT, as configurações também exibirão amazon-bedrock como provedor de modelo.

Solução de problemas comuns

• O app solicita uma conta OpenAI: verifique se os arquivos requirements.toml e config.toml estão nos locais exatos indicados na tabela, encerre todos os processos do ChatGPT e do Codex e reinicie. Os arquivos devem existir antes do lançamento do app.
• O endpoint do AWS GovCloud (US) é reportado como não suportado: confirme a versão exata do desktop ou do app-server, o endpoint e o modelo diretamente com a OpenAI. Alterar apenas a URL não estabelece o suporte.
• A identidade AWS incorreta está sendo usada: inspecione a fonte de credencial efetiva e o perfil nomeado. Verifique se uma chave de API do Amazon Bedrock está tendo precedência sobre o perfil.
• As restrições de capacidade estão ausentes: inspecione as configurações efetivas completas após a reinicialização. A configuração de login apenas por API não aplica a política de capacidades automaticamente.

Rollback e limpeza

Se uma verificação de validação falhar, interrompa o rollout. Retorne os dispositivos afetados às configurações de política e provedor previamente aprovadas e reinicie o app desktop do ChatGPT. Revogue quaisquer credenciais AWS temporárias ou chaves de API e confirme que esses dispositivos não conseguem mais se conectar ao Amazon Bedrock. Mantenha um registro do teste e documente claramente o que falhou antes de tentar novamente.

Conclusão

O app desktop do ChatGPT no Amazon Bedrock no AWS GovCloud (US) oferece uma forma controlada de utilizar os modelos de fronteira da OpenAI e assistência de codificação, mantendo a inferência dentro das regiões do AWS GovCloud (US). Ao validar a configuração, confirmar a identidade AWS aprovada e o endpoint, e verificar os controles de segurança, as equipes podem preparar o deployment com confiança para uma adoção mais ampla. A abordagem equilibra inovação e conformidade, alinhando as decisões de deployment com os requisitos de segurança, autorização e tratamento de dados de cada organização.

Recursos relacionados

• Configuração do AWS GovCloud (US) para Bedrock — orientações sobre dispositivo, provedor, rede, verificação e solução de problemas para o app desktop do ChatGPT.
• Responses API no Amazon Bedrock — Regiões AWS, comportamento de endpoint, autenticação e permissões para a Responses API.
• Conformidade do AWS GovCloud (US) — programas de conformidade e considerações de autorização para clientes.
• Documentação de autenticação Bedrock da OpenAI — autenticação por chave de API do Amazon Bedrock e cadeia de credenciais do AWS SDK, incluindo SSO.
• Documentação do provedor de credenciais do AWS IAM Identity Center — configuração de perfil SSO e credenciais AWS temporárias.

Fonte

Configure the ChatGPT desktop app with Amazon Bedrock in AWS GovCloud (US) (https://aws.amazon.com/blogs/machine-learning/configure-the-chatgpt-desktop-app-with-amazon-bedrock-in-aws-govcloud-us/)

Novos cabeçalhos de visibilidade no CloudFront

A AWS anunciou que o Amazon CloudFront passa a oferecer suporte a dois novos cabeçalhos opcionais que podem ser encaminhados para a sua origem. A novidade amplia a visibilidade sobre quem está acessando suas aplicações e como essas conexões estão sendo protegidas.

O que cada cabeçalho oferece

CloudFront-Viewer-ISP: identificando a rede de origem

O cabeçalho CloudFront-Viewer-ISP traz o nome do Provedor de Serviços de Internet (ISP) do visitante — ou seja, a operadora ou empresa de telecomunicações pela qual a requisição chegou. Com essa informação, é possível segmentar o tráfego e analisar o desempenho por rede, além de identificar comportamentos incomuns originados de um único provedor.

CloudFront-Viewer-TLS-Details: visibilidade sobre a criptografia da conexão

Já o cabeçalho CloudFront-Viewer-TLS-Details descreve os detalhes criptográficos da conexão TLS de cada visitante. Ele inclui informações sobre a troca de chaves, o esquema de assinatura e o tipo de chave pública de assinatura utilizados. O ponto de destaque aqui é a possibilidade de identificar se a conexão utilizou criptografia pós-quântica (PQC — Post-Quantum Cryptography).

Com esse cabeçalho, equipes de segurança conseguem medir qual parcela dos visitantes já se conecta usando PQC e identificar quais clientes ainda não adotaram esse padrão — informação cada vez mais relevante à medida que a migração para criptografia resistente a computadores quânticos avança no setor.

Como habilitar os novos cabeçalhos

Para começar a usar qualquer um dos dois cabeçalhos, basta adicioná-lo a uma política de requisição de origem (origin request policy) e associar essa política à sua distribuição no CloudFront. Para mais detalhes, a AWS disponibiliza a documentação oficial sobre como adicionar cabeçalhos do CloudFront e sobre como controlar requisições de origem com uma política no Amazon CloudFront Developer Guide.

Fonte

Amazon CloudFront now provides viewer ISP and post-quantum TLS details (https://aws.amazon.com/about-aws/whats-new/2026/10/cloudfront-viewer-isp-post-quantum-visbility/)

IA avançada para equipes de segurança ofensiva

A AWS anunciou a disponibilidade do Daybreak Red, modelo de inteligência artificial desenvolvido pela OpenAI com foco em segurança cibernética ofensiva, para clientes elegíveis no Amazon Bedrock na região AWS GovCloud (US-East).

Equipes de segurança que atuam com pesquisa de vulnerabilidades, testes de exploração e construção de defesas passam a contar com uma ferramenta de IA especializada diretamente no ambiente gerenciado da AWS.

O que é o Daybreak Red

O Daybreak Red faz parte da iniciativa Daybreak de defesa cibernética da OpenAI. O modelo específico disponibilizado é o GPT-5.6 Cyber, construído para três finalidades principais:

• Pesquisa autorizada de vulnerabilidades
• Reprodução de exploits
• Desenvolvimento de mitigações

Um diferencial importante do modelo é que ele oferece menos recusas para esse tipo de trabalho em comparação com modelos de uso geral — desde que o acesso seja feito por defensores verificados. Em contrapartida, a solução conta com verificação de identidade mais rigorosa, monitoramento e controles de acesso reforçados.

Infraestrutura e privacidade dos dados

O Daybreak Red roda sobre o mecanismo de inferência de próxima geração do Bedrock, com acesso zero ao operador aplicado diretamente no nível do chip. Na prática, isso significa que:

• Os dados de inferência não são utilizados para treinar modelos
• Não é necessário compartilhar os dados do Daybreak Red com a OpenAI

Esse nível de isolamento é especialmente relevante para organizações que operam em ambientes regulados ou com dados sensíveis — o que explica a disponibilização prioritária no GovCloud.

Regiões disponíveis

O modelo está disponível nas seguintes regiões da AWS:

• US East (Ohio)
• AWS GovCloud (US-East)

Como obter acesso

O acesso ao Daybreak Red não é aberto — ele exige elegibilidade aprovada pela OpenAI. O processo funciona assim:

• Primeiro, é necessário se inscrever para o programa de acesso Daybreak da OpenAI
• Após aprovação, o cliente deve trabalhar com o time de conta da AWS para habilitar o acesso no Bedrock

Para iniciar o processo, o recomendado é entrar em contato diretamente com a OpenAI ou com o time de conta da AWS para verificar a elegibilidade. Mais detalhes técnicos estão disponíveis no blog oficial da AWS.

Fonte

Daybreak Red from OpenAI now available to eligible customers on Amazon Bedrock in AWS GovCloud (US-East) (https://aws.amazon.com/about-aws/whats-new/2026/10/openai-daybreak-red-govcloud-east/)

O que foi anunciado

A AWS anunciou que o Amazon Aurora PostgreSQL-Compatible Edition passa a oferecer suporte à troca de chaves TLS pós-quântica — conhecida como PQ-TLS (Post-Quantum Transport Layer Security). Com isso, equipes que utilizam o serviço ganham novas opções de criptografia pós-quântica para proteger dados em trânsito.

Como funciona na prática

A partir do Amazon Aurora PostgreSQL versão 18, é possível modificar o parâmetro ssl_groups do serviço. Por meio dessa configuração, times de segurança e engenharia podem selecionar grupos criptográficos disponíveis na lista de permissões do Aurora PostgreSQL, garantindo alinhamento com os padrões de segurança exigidos pela organização.

Por que isso importa

A criptografia pós-quântica representa a próxima fronteira da segurança digital. Computadores quânticos, quando suficientemente avançados, terão capacidade de quebrar algoritmos criptográficos clássicos amplamente usados hoje. Ao introduzir suporte a PQ-TLS, a AWS permite que empresas comecem a preparar suas infraestruturas de banco de dados para esse cenário, protegendo a comunicação entre aplicações e o Aurora com algoritmos projetados para resistir a esse tipo de ameaça.

Sobre o Amazon Aurora

O Amazon Aurora é um banco de dados relacional gerenciado pela AWS, projetado para oferecer alta performance e disponibilidade em escala global com compatibilidade total com PostgreSQL. Entre os principais recursos do serviço estão:

• Computação serverless com escala até zero — o serviço ajusta automaticamente a capacidade conforme a demanda;
• Aurora Global Database — resiliência multi-região para aplicações críticas;
• Aurora I/O-Optimized — melhor relação custo-benefício para cargas de trabalho intensivas em operações de entrada e saída;
• Segurança integrada e backups contínuos — proteção e recuperação de dados sem configuração adicional.

Como começar

Para explorar o recurso de troca de chaves PQ-TLS no Aurora PostgreSQL, a AWS disponibiliza uma página de introdução ao serviço com orientações para dar os primeiros passos.

Fonte

Amazon Aurora now supports post-quantum TLS key exchange (https://aws.amazon.com/about-aws/whats-new/2026/10/aurora-postgresql-post-quantum-tls-key-exchange/)

O problema da fadiga de aprovações em agentes de IA

À medida que agentes de inteligência artificial passam a executar mais ações em nome dos usuários — como enviar e-mails, atualizar registros e criar tickets — solicitar aprovação manual para cada etapa do processo começa a gerar um efeito indesejado: a fadiga de aprovações. Com o tempo, o excesso de prompts faz com que as pessoas aprovem tudo automaticamente, enfraquecendo justamente a supervisão humana que se queria garantir.

Para endereçar esse desafio, a AWS anunciou o suporte a aprovações inteligentes (smart approvals) no Amazon Quick.

Como funcionam as aprovações inteligentes

O recurso introduz uma camada de revisão intermediária baseada em um modelo separado chamado classificador. Esse classificador avalia cada ação elegível em relação à solicitação original do usuário e toma uma de duas decisões:

• Aprova automaticamente ações rotineiras e de baixo impacto;
• Encaminha ao usuário as ações consideradas mais consequentes.

Um ponto importante: as políticas existentes sempre têm prioridade. As aprovações inteligentes atuam apenas sobre ações em que a configuração do usuário está definida como “perguntar a cada vez”. Ações negadas continuam negadas, e o sistema nunca concede novos acessos por conta própria.

Quais ações são encaminhadas para revisão humana

O classificador identifica ações de maior impacto e as direciona para revisão manual. Entre os exemplos listados pela AWS estão:

• Envio de conteúdo para fora da organização;
• Alteração de permissões;
• Exclusão de conteúdo;
• Realização de pagamentos;
• Ações que excedam o escopo do que o usuário solicitou originalmente.

Cada aprovação automática cobre exclusivamente a ação exata que foi avaliada. Caso uma revisão falhe ou expire, a ação é automaticamente encaminhada ao usuário.

Controle administrativo e auditoria

As aprovações inteligentes vêm habilitadas por padrão para todos os usuários. Administradores podem controlar quem tem acesso ao recurso por meio de permissões customizadas. Já os próprios usuários podem desativá-lo para suas conversas e execuções agendadas nas opções de chat.

Para fins de auditoria, o AWS CloudTrail registra cada revisão de ação realizada pelo sistema de aprovações inteligentes, bem como cada alteração feita nas configurações do recurso por parte dos usuários.

Disponibilidade

As aprovações inteligentes estão disponíveis no Amazon Quick em todas as regiões AWS onde as capacidades agênticas do serviço são suportadas. Consulte a tabela de regiões AWS para verificar a disponibilidade na sua região.

Para se aprofundar no funcionamento do recurso, a AWS disponibiliza a documentação sobre aprovações inteligentes no Guia do Usuário do Amazon Quick. Mais informações gerais sobre o serviço podem ser encontradas na página do produto Amazon Quick.

Fonte

Quick now supports smart approvals for agentic actions (https://aws.amazon.com/about-aws/whats-new/2026/10/quick-smart-approvals-agentic-actions/)

O que foi anunciado

A AWS anunciou suporte a coleções de séries temporais no Amazon OpenSearch Serverless de nova geração. Trata-se de um tipo de coleção voltado especificamente para ingestão, armazenamento e análise de logs, métricas, rastreamentos e dados de eventos — tudo isso sem precisar provisionar ou gerenciar clusters.

Como funciona na prática

As coleções de séries temporais foram projetadas para absorver picos de ingestão automaticamente, mantendo os dados recentes com acesso rápido para consultas e tornando meses ou anos de histórico pesquisáveis com custo reduzido — tudo dentro de uma mesma coleção.

Para viabilizar esse equilíbrio entre desempenho e custo, o recurso introduz uma nova camada de armazenamento warm (quente-frio), complementar à camada hot (quente) já existente. Com isso, os dados acessados com menos frequência podem ser retidos sem pagar o preço do armazenamento hot. Os clientes têm a flexibilidade de definir por quanto tempo os dados permanecem na camada hot antes de migrarem automaticamente para a camada warm.

Capacidade e casos de uso

Cada coleção suporta até 100 TB de armazenamento hot, o que torna o recurso adequado para cargas de trabalho de observabilidade de alto volume, como:

• Monitoramento de aplicações
• Análise de segurança
• Telemetria de Internet das Coisas (IoT)

Além disso, alertas e detecção de anomalias agora também estão disponíveis nas coleções de séries temporais. Isso permite que as equipes sejam notificadas sobre problemas e identifiquem padrões incomuns em logs e dados de eventos sem precisar de ferramentas separadas.

Disponibilidade

As coleções de séries temporais já estão disponíveis em todas as regiões AWS onde o OpenSearch Serverless está presente. Para conhecer os detalhes de precificação do novo armazenamento warm, consulte a página de preços do OpenSearch Serverless.

Para se aprofundar no recurso, a AWS disponibiliza a página de funcionalidades do OpenSearch Serverless, o blog de lançamento e a documentação oficial.

Fonte

Introducing time series collections for the next generation of Amazon OpenSearch Serverless (https://aws.amazon.com/about-aws/whats-new/2026/10/time-series-collection-next-generation-opensearch-serverless/)

O que foi anunciado

A AWS anunciou que o Amazon Relational Database Service (Amazon RDS) para Oracle passou a suportar o Patch Mensal Recomendado (MRP) de setembro de 2026. A atualização está disponível para as versões 19c e 26ai do Oracle Database.

O que é um MRP e por que ele importa

Um Patch Mensal Recomendado (MRP) é uma versão secundária do engine de banco de dados que se apoia em uma Atualização de Release (RU) trimestral. Na prática, ele empacota a Atualização Crítica de Segurança (CSPU) da Oracle junto com outras correções recomendadas pela própria Oracle — tudo em um único pacote de atualização.

O MRP de setembro de 2026 é aplicado sobre a Atualização de Release (RU) de julho de 2026 e inclui o CSPU da Oracle de setembro. A AWS recomenda que os clientes realizem o upgrade para essa versão, pois ela traz as correções de segurança mais recentes para o Oracle Database.

Atualização do arquivo de fuso horário

Além das correções de segurança, este release inclui o arquivo de fuso horário atualizado da Oracle na versão DST 46. Essa versão reflete mudanças recentes nas regras de horário de verão em diversas regiões do mundo, incluindo:

• Colúmbia Britânica e Alberta (Canadá) — com vigência a partir de 1º de novembro de 2026, essas províncias passarão a adotar offsets UTC permanentes.
• Marrocos e Saara Ocidental — com vigência a partir de 20 de setembro de 2026, também migrando para offsets UTC permanentes.

Para quem armazena dados de timestamp com informações de fuso horário referentes a essas regiões, a atualização do arquivo DST garante que os dados continuem alinhados às novas regras vigentes.

Como aplicar o MRP de setembro de 2026

O patch pode ser aplicado tanto em novas instâncias de banco de dados quanto em instâncias existentes. Para realizar o upgrade, basta acessar o Console de Gerenciamento do Amazon RDS e selecionar uma das versões de engine abaixo, conforme a versão utilizada:

• 19.0.0.0.ru-2026-07.mrp-2026-09.r2 — para Oracle Database 19c
• 26.0.0.0.ru-2026-07.mrp-2026-09.r2 — para Oracle Database 26ai

O upgrade também pode ser realizado via AWS SDK ou AWS CLI, para quem prefere automação ou integração com pipelines existentes.

Para consultar todos os MRPs suportados no Amazon RDS para cada versão de engine, a AWS disponibiliza as notas de release do Amazon RDS para Oracle.

Fonte

Amazon RDS for Oracle now supports September 2026 Monthly Recommended Patch (https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-rds-oracle-september-mrp)

AWS lidera como primeiro CSP a concluir a avaliação Cloud High no Canadá

A Amazon Web Services (AWS) acaba de alcançar um marco significativo no cenário de conformidade em nuvem: a empresa se tornou o primeiro Provedor de Serviços de Nuvem (CSP, do inglês Cloud Service Provider) no Canadá a concluir a avaliação de segurança Cloud High, conhecida pelo perfil PBHH. A conquista, com vigência a partir de 18 de setembro de 2026, coloca a AWS em uma posição inédita no mercado canadense — e tem implicações diretas para organizações que precisam operar com os mais altos padrões de segurança para dados sensíveis.

O escopo desta avaliação é expressivo: foram avaliados 172 serviços e funcionalidades da AWS pelo Centro Canadense de Segurança Cibernética (CCCS, do inglês Canadian Centre for Cyber Security). Isso representa um conjunto robusto de recursos que clientes governamentais e comerciais podem utilizar com a garantia de que atendem ao nível mais elevado de exigência de segurança estabelecido pelo Governo do Canadá (GC, do inglês Government of Canada).

O que é a avaliação Cloud High e por que ela importa?

Para entender o peso dessa conquista, é importante compreender o que o perfil Cloud High representa dentro do ecossistema de segurança do Governo do Canadá.

O perfil Cloud High (PBHH) foi criado para proteger a integridade e a disponibilidade de cargas de trabalho organizacionais que possuem um nível elevado de sensibilidade. Isso inclui sistemas utilizados pelo Governo do Canadá e seus prestadores de serviços para suportar a entrega de serviços em escala nacional, além de sistemas considerados críticos para o tratamento de informações sensíveis.

A base técnica desse perfil está no catálogo de controles e atividades de garantia de segurança e privacidade, o Catálogo de Controles e Atividades de Segurança e Privacidade (ITSP.10.033). Trata-se de um documento de referência que define os controles mínimos esperados de sistemas que operam em ambientes de nuvem com dados sensíveis.

A relação entre Cloud High e Cloud Medium

O perfil Cloud High (PBHH) não existe de forma isolada — ele é construído sobre o perfil Cloud Medium (PBMM). Na prática, isso significa que o Cloud High incorpora todos os controles e melhorias presentes no Cloud Medium, acrescentando controles adicionais voltados especificamente para requisitos mais elevados de integridade e disponibilidade.

Juntos, os perfis Cloud Medium e Cloud High estabelecem os requisitos de segurança de linha de base para serviços de nuvem que suportam cargas de trabalho e processamento de informações do Governo do Canadá até o nível Protected B. Esse nível de classificação é reservado para informações cuja divulgação não autorizada poderia causar danos sérios a indivíduos ou organizações.

Quais serviços e regiões estão no escopo?

A avaliação realizada pelo CCCS abrange serviços e funcionalidades disponíveis em duas regiões da AWS no Canadá: Canada (Central) e Canada West (Calgary). Isso garante que clientes localizados nessas regiões possam contar com a cobertura da avaliação ao arquitetar suas soluções.

O total de 172 serviços e funcionalidades avaliados representa um portfólio amplo, oferecendo às organizações canadenses — especialmente as do setor público — flexibilidade para construir arquiteturas completas dentro dos limites de conformidade exigidos.

Como acessar o relatório da avaliação?

O resumo da avaliação está disponível diretamente pelo AWS Artifact, que é o repositório central da AWS para documentos de conformidade e relatórios de auditoria. Clientes com acesso à plataforma podem consultar o documento para fins de due diligence, auditorias internas ou requisitos regulatórios.

Além disso, é possível obter mais informações sobre as avaliações Cloud High e Cloud Medium na página de conformidade da avaliação CCCS da AWS. Para quem deseja ter uma visão mais ampla de todos os programas de conformidade da empresa, a página de Programas de Conformidade da AWS é o ponto de partida recomendado.

Organizações com dúvidas específicas sobre como as avaliações Cloud High e Cloud Medium se aplicam às suas arquiteturas podem entrar em contato com a equipe de contas da AWS ou enviar perguntas pela página de contato da equipe de conformidade.

O que isso significa para o mercado?

Ser o primeiro CSP a completar essa avaliação no Canadá não é apenas um diferencial competitivo — é um sinal claro de que a AWS está investindo ativamente em ampliar o escopo de seus programas de conformidade para atender mercados com exigências regulatórias rigorosas. Para clientes do setor público canadense, isso representa uma garantia formal de que a infraestrutura de nuvem utilizada atende ao padrão de segurança mais elevado disponível no país.

Para profissionais de segurança e arquitetos de nuvem que atuam em projetos com requisitos regulatórios elevados — seja no Canadá ou em outros mercados com estruturas similares —, acompanhar a evolução desses programas de conformidade é fundamental para garantir que as arquiteturas projetadas permaneçam dentro dos limites exigidos.

Fonte

AWS becomes first CSP to complete the Cloud High profile assessment with 172 services and features in scope (https://aws.amazon.com/blogs/security/aws-becomes-first-csp-to-complete-the-cloud-high-profile-assessment-with-172-services-and-features-in-scope/)