Computadores quânticos suficientemente poderosos ainda não existem, mas a ameaça que eles representam para a criptografia convencional já é real — e precisa ser endereçada agora. O motivo é um vetor de ataque chamado coleta agora, decifra depois (HNDL — Harvest Now, Decrypt Later): adversários capturam tráfego cifrado hoje e guardam para decifrar no futuro, quando tiverem acesso a hardware quântico capaz de quebrar os algoritmos assimétricos tradicionais.
É dentro desse contexto que a AWS vem executando seu plano de migração para criptografia pós-quântica (PQC). Parte central desse plano é garantir que os clientes consigam atualizar o lado cliente de suas cargas de trabalho para suportar confidencialidade resistente a computadores quânticos — e a AWS reconhece que essa é uma responsabilidade compartilhada, descrita no modelo de responsabilidade compartilhada de PQC.
O que mudou no AWS Secrets Manager
O AWS Secrets Manager utiliza SSL/TLS para comunicação com recursos AWS, suportando TLS 1.2 e 1.3 em todas as regiões. A novidade é que o serviço agora habilita e prefere, por padrão, a troca de chaves híbrida pós-quântica nas conexões TLS iniciadas pelos clientes que suportam essa capacidade.
A abordagem híbrida pós-quântica combina criptografia tradicional (como X25519) com algoritmos pós-quânticos (ML-KEM) para estabelecer conexões TLS. Isso garante proteção tanto contra ataques clássicos atuais quanto contra ameaças futuras de computadores quânticos.
Vale destacar: os segredos em repouso já estavam protegidos por chaves gerenciadas pelo AWS Key Management Service (AWS KMS). A criptografia simétrica, quando bem implementada, é considerada resistente a computadores quânticos. A vulnerabilidade quântica recai sobre a criptografia assimétrica — exatamente o que é usado na troca de chaves TLS. Para aprofundar o tema, a AWS disponibilizou a sessão AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified.
Quais clientes já suportam a troca de chaves híbrida por padrão
A AWS anunciou que os seguintes clientes do Secrets Manager já habilitam e preferem a troca de chaves pós-quântica ao iniciar conexões:
Para clientes baseados em SDK, a troca de chaves híbrida pós-quântica está disponível nas versões listadas abaixo. Os requisitos variam por linguagem, versão e sistema operacional:
Quando o endpoint do serviço Secrets Manager detecta que o cliente anuncia suporte à troca de chaves pós-quântica durante o handshake TLS, ele a seleciona automaticamente. Atualizar para as versões listadas é a única ação necessária.
Como verificar se suas conexões estão usando a troca de chaves híbrida
Para a maioria dos clientes, não será necessário monitoramento contínuo após a atualização. No entanto, equipes de segurança e compliance podem querer confirmar que as chamadas de API do Secrets Manager estão de fato negociando a troca de chaves híbrida. A verificação pode ser feita tanto no lado servidor, via AWS CloudTrail, quanto no lado cliente, com ferramentas como Wireshark ou as ferramentas de desenvolvedor dos navegadores.
A AWS anunciou que o Amazon Bedrock AgentCore Gateway e o AgentCore Identity passam a oferecer suporte a egresso de Nuvem Privada Virtual (VPC). Com isso, aplicações baseadas em agentes de IA conseguem se comunicar de forma segura e controlada com recursos que estão rodando dentro da VPC do próprio cliente — sem precisar expor esses recursos à internet pública.
Como o egresso de VPC funciona no AgentCore
O suporte ao egresso de VPC está disponível em duas modalidades: gerenciada e autogerenciada. A maioria dos casos de uso é atendida pela configuração gerenciada, que a AWS provisiona e mantém automaticamente. Para cenários de rede mais complexos, os clientes têm a opção de configurar seus próprios recursos do VPC Lattice — o serviço de rede gerenciada da AWS para comunicação entre serviços.
Um exemplo prático: com esse suporte, é possível invocar diretamente, a partir do AgentCore Gateway, servidores MCP hospedados em clusters do Elastic Kubernetes Service (EKS) que estejam rodando dentro de uma VPC privada. Isso amplia bastante as possibilidades de integração em arquiteturas corporativas que priorizam isolamento de rede.
Novidades no AgentCore Identity
O AgentCore Identity também recebe suporte a egresso de VPC, com foco específico em conectividade com Provedores de Identidade (IdPs) que rodam dentro da VPC do cliente. Esse suporte habilita duas capacidades importantes:
Validação de tokens de acesso de entrada: permite verificar tokens emitidos por um IdP privado antes de autorizar requisições recebidas pelo agente.
Obtenção de tokens para autenticação de saída: permite que o agente busque tokens diretamente no IdP privado para autenticar requisições que ele mesmo faz a outros serviços.
Resolução de DNS privado
Outro ponto relevante desse lançamento é o suporte à resolução de DNS privado para recursos de egresso VPC gerenciado, tanto no Gateway quanto no Identity. Isso significa que os recursos internos podem ser acessados pelos seus nomes de domínio privados, sem depender de IPs fixos ou configurações manuais adicionais.
Disponibilidade por região
O suporte a egresso de VPC no AgentCore Gateway e Identity está disponível em 14 regiões da AWS:
US East (Norte da Virgínia e Ohio)
US West (Oregon)
Canada (Central)
Asia Pacific (Mumbai, Seul, Singapura, Sydney e Tóquio)
Europe (Frankfurt, Irlanda, Londres, Paris e Estocolmo)
O problema que o Security Hub Extended tenta resolver
Equipes de segurança modernas enfrentam um desafio que vai muito além das ameaças em si: o peso operacional de gerenciar dezenas de fornecedores ao mesmo tempo. Negociações de contrato, múltiplos ciclos de cobrança, integrações manuais entre ferramentas — tudo isso consome tempo que deveria estar sendo dedicado à gestão de riscos reais.
Além disso, o modelo tradicional de aquisição de soluções de segurança forçava as organizações a assinar contratos plurianuais baseados apenas em testes de prova de conceito (PoC) e estimativas de uso anual. Ou seja, era preciso comprometer orçamento antes de validar se a solução funcionaria em escala real no ambiente da empresa.
É exatamente esse cenário que a AWS busca transformar com o AWS Security Hub Extended: uma oferta de segurança empresarial completa que reúne serviços nativos da AWS com soluções de parceiros cuidadosamente selecionados, entregando procurement unificado, cobrança consolidada e operações integradas.
O que é o Security Hub Extended
O AWS Security Hub já consolidava análise de ameaças do Amazon GuardDuty, gestão de vulnerabilidades do Amazon Inspector e descoberta de dados sensíveis do Amazon Macie, correlacionando esses sinais com findings de exposição para determinar risco geral, alcançabilidade e assumibilidade de recursos.
O Security Hub Extended vai além: ele estende essas operações de segurança unificadas para toda a organização, incluindo ambientes multicloud, on-premises e endpoints, por meio de soluções de parceiros curados integradas diretamente na experiência do Security Hub. Não há console separado para gerenciar — tudo acontece no mesmo lugar onde você já administra a segurança da sua organização.
Para quem ainda não usa o Security Hub, o processo de onboarding é direto: basta acessar o AWS Management Console, buscar por Security Hub e seguir o fluxo de configuração inicial. O primeiro passo é designar uma conta de administrador delegado (Delegated Administrator — DA) da organização AWS, o que permite habilitar e gerenciar o Security Hub de forma centralizada em todas as contas e regiões AWS da organização a partir de um único ponto. Para mais detalhes sobre esse processo, a AWS disponibiliza a Introdução ao AWS Security Hub.
A partir da interface centralizada de configuração, é possível habilitar capacidades de detecção e resposta para toda a organização, definir configurações granulares por unidade organizacional ou conta-membro, selecionar regiões específicas e ativar ou desativar funcionalidades individualmente.
Quem já usa o Security Hub pode navegar diretamente para a seção do plano Extended. Ela fica no painel de navegação à esquerda, em Management, dentro da conta do administrador delegado — e só fica visível a partir dessa conta.
Entendendo riscos por meio de caminhos de ataque
Um dos recursos centrais do Security Hub é o motor de correlação de riscos, que identifica exposições potenciais ao cruzar ameaças, vulnerabilidades e configurações incorretas, revelando como esses fatores se conectam e podem levar ao comprometimento de recursos críticos.
A visualização de caminhos de ataque (attack path) expõe causas-raiz e o raio de explosão (blast radius) — ou seja, o impacto potencial caso um agente malicioso explore uma vulnerabilidade. Em vez de tratar sintomas isolados, a equipe de segurança pode focar na causa original do problema. Por exemplo, atualizar a configuração de um único security group pode eliminar um caminho de ataque inteiro, cortando todas as exposições downstream associadas a ele.
Descobrindo e assinando soluções de parceiros
O plano Extended traz soluções de terceiros curadas diretamente para dentro da experiência do Security Hub. Para adotar uma solução de parceiro, basta selecionar View Product para iniciar um fluxo automatizado de onboarding. Dependendo da solução, o usuário é direcionado ao console do parceiro ou recebe orientações para que o parceiro conduza o processo de ativação conforme o ambiente específico.
A cobrança só começa após a ativação completa na solução do parceiro, e já entra automaticamente na fatura unificada da AWS — sem necessidade de nenhuma ação adicional. Para quem já usa alguma das soluções dos parceiros, a transição para o Security Hub Extended não interrompe os serviços em uso. A diferença é que, em vez de receber faturas separadas para cada parceiro além do Amazon Inspector, GuardDuty e Security Hub, tudo passa a aparecer em uma única fatura consolidada.
Precificação transparente e sem compromissos iniciais
Diferente dos modelos tradicionais que exigem negociações longas, acordos de preço privados e compromissos plurianuais, o Security Hub Extended adota um modelo de preços mensais no modelo pay-as-you-go, com total transparência. Cada solução de parceiro exibe seus valores de forma clara. Como referência, o Cloud Security da Upwind custa US$ 3,75 por recurso por mês, e o Identity Security da Okta custa US$ 20 por usuário por mês.
Todas as ofertas do Security Hub Extended são elegíveis para os descontos do Programa de Desconto Empresarial (Enterprise Discount Program — EDP) da AWS, que são aplicados automaticamente. Se a organização já possui um acordo de desconto empresarial com a AWS, esses descontos se estendem automaticamente às soluções do Extended, reduzindo ainda mais o custo efetivo.
Após validar que uma solução funciona em escala no ambiente real, a organização pode então alinhar sua estratégia com fornecedores e assinar compromissos de longo prazo para obter condições de preço ainda mais favoráveis — mas sem a pressão de fazer isso antes de ter certeza.
Operações unificadas com OCSF
O Security Hub Extended unifica as operações de segurança ao consolidar findings da AWS e das soluções de parceiros em um único fluxo. Todos os findings utilizam o Open Cybersecurity Schema Framework (OCSF) — uma estrutura de esquema aberto para cibersegurança — garantindo consistência sem a necessidade de processos complexos de normalização, transformação ou pipelines de Extração, Transformação e Carga (ETL).
Na prática, ao implantar soluções como CrowdStrike, Noma e Upwind junto com Splunk e 7AI por meio do Security Hub Extended, os findings de segurança fluem automaticamente para o Security Hub e são roteados diretamente para o Splunk e o 7AI, todos no formato OCSF. O resultado é que a equipe de segurança pode se concentrar em responder a ameaças — não em gerenciar pipelines de dados ou integrações manuais.
A visão de segurança full-stack
O Security Hub Extended representa uma mudança na forma como as organizações descobrem, adquirem e consturam programas de segurança abrangentes. Em vez de gerenciar dezenas de relacionamentos com fornecedores, negociar contratos separados e integrar ferramentas díspares manualmente, a proposta é simplificar tudo em cinco pilares:
Um processo de procurement centralizado via AWS
Uma fatura com preços competitivos e transparentes no modelo pay-as-you-go
Um console para operações de segurança unificadas
Um canal de suporte para clientes do AWS Enterprise Support
Um esquema (OCSF) para todos os findings de segurança
O objetivo declarado é reduzir o risco de segurança, melhorar a produtividade das equipes e criar uma abordagem mais coesa para operações de segurança em toda a empresa — abrangendo endpoint, identidade, e-mail, rede, dados, browser, nuvem, IA e operações de segurança.
Disponibilidade
O Security Hub Extended está disponível globalmente em todas as regiões comerciais da AWS onde o Security Hub está disponível. A AWS também publicou um vídeo de demonstração explicando como o Security Hub Extended funciona na prática. Feedbacks podem ser enviados pelo AWS re:Post na categoria de Segurança ou por meio dos canais de suporte da AWS.
A AWS anunciou expansões importantes nas Regras Gerenciadas (Managed Rules) do AWS Network Firewall, disponibilizadas por parceiros do AWS Marketplace. A novidade traz otimizações nos grupos de regras que agora suportam até 10 milhões de indicadores de nomes de domínio e até 1 milhão de endereços IP por grupo — um salto significativo em capacidade de proteção para workloads na nuvem.
O que cada parceiro está entregando
Três parceiros lideram as expansões anunciadas:
Infoblox: amplia os indicadores de nomes de domínio para proteger workloads contra domínios de risco crítico e alto.
Lumen: introduz novos grupos de regras focados em bloquear ataques de comando e controle (command and control).
ThreatSTOP: adiciona regras gerenciadas para conformidade com sanções do Escritório de Controle de Ativos Estrangeiros — OFAC (Office of Foreign Assets Control) — e expande a cobertura de conformidade global com novas regras para sanções da União Europeia, Japão e Nações Unidas.
Por que isso importa para equipes de segurança
Essas melhorias permitem que as equipes acessem inteligência de ameaças mais rica e abrangente diretamente dentro do AWS Network Firewall, sem precisar gerenciar feeds de ameaças manualmente. O resultado prático é uma proteção mais rápida e precisa contra ameaças emergentes — seja para bloquear domínios maliciosos em escala, defender a infraestrutura contra ataques de comando e controle ou aplicar políticas de conformidade baseadas em sanções internacionais.
As regras gerenciadas ficam prontas para implantação e são atualizadas continuamente pelos parceiros, reduzindo a carga operacional das equipes de segurança.
Parceiros disponíveis e expansão regional
Além de Infoblox, Lumen e ThreatSTOP, as regras gerenciadas para o AWS Network Firewall também estão disponíveis por meio de outros parceiros do AWS Marketplace: Check Point, Fortinet, Rapid7 e Trend Micro.
A AWS também expandiu a disponibilidade regional dos grupos de regras do Marketplace para 9 novas regiões:
A AWS anunciou uma novidade importante para quem trabalha com o Amazon EC2: agora é possível controlar se os recursos provisionados por ofertas de instâncias gerenciadas aparecem ou não nas visualizações do console do EC2 e nas operações de listagem via API.
O que são instâncias gerenciadas no EC2
As Instâncias Gerenciadas do Amazon EC2 (Amazon EC2 Managed Instances) são instâncias provisionadas e administradas por um provedor de serviço designado — como o Amazon EKS, o Amazon ECS, o AWS Lambda ou o Amazon Workspaces. Nesses casos, a própria AWS assume a responsabilidade pela configuração, aplicação de patches e monitoramento de saúde dessas instâncias, além de outros recursos associados, como volumes EBS, snapshots e Interfaces de Rede.
Qual era o problema antes dessa mudança
Até agora, por padrão, esses recursos gerenciados apareciam misturados com os recursos autogerenciados nas respostas de API e nos respectivos consoles. Isso gerava confusão, já que esses recursos são de responsabilidade da AWS — e não do time que opera a conta. Ver instâncias, volumes e snapshots que você não criou e não precisa gerenciar no meio da sua lista de recursos não é o ideal para quem quer ter clareza sobre o que está sob sua responsabilidade.
Como funciona a nova configuração de visibilidade
Com as novas configurações de visibilidade de recursos gerenciados (Managed resource visibility settings), qualquer novo recurso gerenciado passa a ficar oculto por padrão nas visualizações do console e nas respostas de APIs como o describe-instances. Essa mudança foi pensada para alinhar melhor a experiência do usuário ao modelo de responsabilidade compartilhada — afinal, se a AWS gerencia aquele recurso, faz sentido que ele não polua a visão de quem está gerenciando os próprios recursos.
A configuração pode ser feita diretamente pelo console do Amazon EC2 ou por meio da AWS CLI. Para saber mais sobre como configurar essa funcionalidade, a AWS disponibiliza o Guia do Usuário do Amazon EC2 com todos os detalhes sobre as configurações de visibilidade de recursos gerenciados.
Por que isso importa para o seu ambiente
Para equipes que utilizam serviços como EKS ou ECS em larga escala, a quantidade de recursos gerenciados automaticamente pela AWS pode ser expressiva. Ter esses recursos aparecendo lado a lado com os recursos autogerenciados dificulta auditorias, inventários e até a identificação de anomalias. Com essa novidade, a visão do console e das APIs fica mais limpa e representativa do que realmente está sob gestão do time.
A AWS anunciou uma expansão importante para o Amazon SageMaker Unified Studio: a plataforma agora suporta replicação multi-região a partir do Centro de Identidade IAM (IAM Identity Center — IdC). Na prática, isso significa que administradores podem implantar domínios do SageMaker Unified Studio em regiões diferentes daquela onde a instância do IdC está configurada.
Antes dessa novidade, a dependência entre a região do IdC e a região dos domínios do SageMaker limitava a flexibilidade de arquiteturas distribuídas. Agora, essa restrição foi removida.
Por que isso importa para empresas reguladas
Essa capacidade foi desenvolvida especialmente para atender clientes corporativos de setores regulados, como serviços financeiros e saúde. Nesses segmentos, é comum que existam exigências rígidas sobre onde os dados podem ser armazenados e processados — as chamadas regras de residência de dados e soberania de dados.
Com a replicação multi-região do IdC, as organizações conseguem endereçar cenários como:
Manter o IdC em uma região enquanto processam dados sensíveis em regiões exigidas por regulamentações;
Suportar operações globais com gerenciamento centralizado de identidade;
Atender requisitos de soberania de dados sem abrir mão das capacidades de Logon Único (SSO — Single Sign-On).
Como funciona na prática
Como administrador do SageMaker Unified Studio, é possível implantar domínios do SageMaker mais próximos da equipe de trabalho, respeitando as necessidades de residência de dados, enquanto o acesso via SSO continua funcionando de forma transparente para os usuários finais. O gerenciamento centralizado de identidade permanece intacto, independentemente de em qual região o domínio foi criado.
Disponibilidade e regiões suportadas
A replicação multi-região do IdC já está disponível em todas as regiões AWS onde o SageMaker Unified Studio é suportado, incluindo:
Ásia-Pacífico (Tóquio)
Europa (Irlanda)
Leste dos EUA (Norte da Virgínia)
Leste dos EUA (Ohio)
Oeste dos EUA (Oregon)
Europa (Frankfurt)
América do Sul (São Paulo)
Ásia-Pacífico (Seul)
Europa (Londres)
Ásia-Pacífico (Singapura)
Ásia-Pacífico (Sydney)
Canadá (Central)
Ásia-Pacífico (Mumbai)
Europa (Paris)
Europa (Estocolmo)
Vale destacar que a região de São Paulo já está na lista, o que é uma boa notícia para times brasileiros que precisam atender exigências da LGPD e outras regulamentações locais.
A Amazon Web Services (AWS) acaba de disponibilizar o relatório de Controles de Sistema e Organização (SOC) 1 referente ao ciclo Inverno 2025. O documento cobre um período de 12 meses — de 1º de janeiro a 31 de dezembro de 2025 — e contempla 184 serviços dentro do escopo de auditoria.
Essa cobertura anual é importante porque oferece às empresas clientes uma visão contínua e consolidada sobre os controles internos da AWS relacionados a relatórios financeiros, facilitando o processo de conformidade e auditorias externas.
Por que o SOC 1 importa para sua empresa
O relatório SOC 1 é um documento de auditoria independente que atesta a eficácia dos controles internos de um provedor de serviços em nuvem no que diz respeito ao impacto sobre os relatórios financeiros dos clientes. Para empresas brasileiras que operam em setores regulados — como financeiro, saúde e varejo — ter acesso a esse relatório é frequentemente um requisito de compliance ou de auditorias internas.
Com 184 serviços cobertos, a AWS demonstra um compromisso crescente em ampliar o escopo dos seus programas de conformidade, ajudando as organizações a atenderem tanto requisitos arquiteturais quanto regulatórios.
Como acessar o relatório
O relatório SOC 1 Inverno 2025 está disponível para download pelo AWS Artifact, o portal de autoatendimento da AWS para acesso sob demanda a documentos de conformidade. Para obtê-lo, basta acessar o AWS Artifact no Console de Gerenciamento da AWS. Caso ainda não conheça a ferramenta, a AWS disponibiliza um guia introdutório em Primeiros Passos com o AWS Artifact.
Serviços no escopo
A lista completa dos serviços cobertos pelos programas de conformidade da AWS pode ser consultada na página de Serviços no Escopo. A AWS atualiza essa lista continuamente à medida que novos serviços são incluídos nos programas de auditoria.
Dúvidas e suporte
Clientes que tiverem perguntas sobre o relatório SOC 1 ou sobre os programas de conformidade da AWS podem entrar em contato com a equipe de conta AWS. Para uma visão geral de todos os programas de conformidade disponíveis, a AWS mantém uma página dedicada em Programas de Conformidade da AWS. Feedbacks e dúvidas específicas sobre compliance também podem ser enviados diretamente pela página de Contato da equipe de conformidade.
Acesso ao Athena Spark sem passar pela internet pública
A AWS anunciou que o Amazon Athena Spark agora conta com suporte ao AWS PrivateLink, permitindo que equipes acessem as APIs e endpoints do serviço diretamente a partir de sua Nuvem Privada Virtual da Amazon (VPC — Virtual Private Cloud), sem que o tráfego precise passar pela internet pública.
O que muda na prática
Com essa novidade, é possível criar endpoints de interface do AWS PrivateLink para conectar clientes dentro da sua VPC ao Athena Spark. Todo o tráfego entre a VPC e as APIs e endpoints do Athena Spark passa a ocorrer inteiramente dentro da rede da AWS, estabelecendo um caminho seguro para os dados.
O endpoint de VPC do Athena oferece suporte a todas as APIs e endpoints do Athena Spark, incluindo:
Spark Connect
Spark Live UI
Spark History Server
Por que isso importa para compliance
Um dos benefícios mais relevantes dessa integração é o auxílio no atendimento a requisitos de conformidade (compliance). Ao manter o acesso às APIs e endpoints do Athena Spark completamente dentro da rede da AWS, as organizações conseguem reduzir a exposição de dados sensíveis e reforçar controles de segurança exigidos por regulamentações e políticas internas.
Como começar a usar
Para habilitar essa funcionalidade, basta criar um endpoint de interface de VPC para se conectar ao Amazon Athena Spark. A AWS disponibiliza três formas de fazer isso:
Console de Gerenciamento da AWS (AWS Management Console)
Interface de Linha de Comando da AWS (AWS CLI — Command Line Interface)
AWS CloudFormation
Disponibilidade
O recurso já está disponível em todas as Regiões da AWS onde o Amazon Athena Spark e o AWS PrivateLink estão presentes. Para mais detalhes, a AWS recomenda consultar a documentação do AWS PrivateLink e a documentação do Athena Spark.
A AWS disponibilizou o AWS IoT Greengrass v2.17, trazendo duas grandes novidades: suporte à instalação como usuário não-root em sistemas Linux e a introdução de componentes mais leves, projetados para consumir muito menos memória na borda.
Para quem não conhece, o AWS IoT Greengrass é um runtime de borda e serviço de nuvem voltado para a Internet das Coisas (IoT — Internet of Things). Ele ajuda equipes a construir, implantar e gerenciar software diretamente nos dispositivos, sem depender de conectividade constante com a nuvem.
Instalação sem root: mais segurança em ambientes regulados
Uma das mudanças mais relevantes desta versão é justamente a possibilidade de instalar e executar o Greengrass sem precisar de privilégios de superusuário (root). Em ambientes corporativos e setores regulados — como saúde, finanças e indústria —, políticas de segurança frequentemente proíbem o uso de root em sistemas de produção. Com essa atualização, a AWS elimina um obstáculo prático que impedia muitas organizações de adotar o serviço nesses contextos.
Ciclo de vida de desinstalação automática
A versão v2.17 também adiciona uma capacidade de ciclo de vida de desinstalação (uninstall lifecycle) que é ativada automaticamente quando um componente é removido de um dispositivo. Isso simplifica o gerenciamento de dependências, evitando que resíduos de componentes antigos causem conflitos ou ocupem recursos desnecessários.
Novos componentes nucleus lite: menos memória, mesma funcionalidade
Outra frente importante desta versão é a expansão das capacidades do nucleus lite, focado em reduzir o consumo de recursos na borda. As novidades incluem:
Componente Secure Tunneling lite: agora utiliza apenas 4 MB de memória, uma redução expressiva em comparação aos 36 MB do componente padrão — uma queda de mais de 88%.
Componente Fleet Provisioning atualizado: passa a suportar o Módulo de Plataforma Confiável (TPM — Trusted Platform Module) 2.0, viabilizando operações criptográficas e gerenciamento seguro de identidade dos dispositivos.
Interface PKCS#11 (Padrão Criptográfico de Chave Pública — Public Key Cryptographic Standard): permite que o componente nucleus lite do Greengrass se autentique com o AWS IoT Core usando chaves e certificados armazenados em um Módulo de Segurança de Hardware (HSM — Hardware Security Module).
Disponibilidade
O AWS IoT Greengrass v2.17 já está disponível em todas as regiões da AWS onde o serviço é oferecido. Para conhecer todos os detalhes das novidades, a AWS disponibiliza a documentação oficial do AWS IoT Greengrass. Quem quiser dar os primeiros passos com o serviço pode acessar o guia de introdução.
O AWS CloudHSM é o serviço da AWS para geração, armazenamento, importação, exportação e gerenciamento de chaves criptográficas em hardware dedicado. Ele também suporta funções de hash para cálculo de resumos de mensagens e Códigos de Autenticação de Mensagens Baseados em Hash (HMACs), além de assinatura e verificação de dados.
Para garantir redundância e simplificar a recuperação de desastres, a AWS recomenda clonar o cluster CloudHSM para uma Região diferente. Esse processo permite sincronizar chaves entre Regiões — incluindo as chamadas chaves não exportáveis, que nunca saem do dispositivo HSM em texto simples e só podem ser sincronizadas para clusters clonados.
Neste guia, a AWS descreve como usar o recurso CopyBackupToRegion para clonar um cluster da Região 1 para uma Nuvem Privada Virtual (VPC) na Região 2. O processo é feito em dois passos: copiar um backup para a Região de destino e criar um novo cluster a partir desse backup.
Atenção: A partir de 1º de janeiro de 2025, as ferramentas do Client SDK 3 (CMU e KMU) não têm mais suporte. Todo este guia usa exclusivamente comandos do Client SDK 5 (versão 5.17 ou superior).
Como funciona o processo
O CloudHSM cria um backup do cluster e o armazena em um bucket do Amazon Simple Storage Service (Amazon S3) pertencente ao próprio serviço. Em seguida, você usa a Interface de Linha de Comando da AWS (AWS CLI) para copiar esse backup para outra Região. Com o backup disponível na Região de destino, você cria um novo cluster e os módulos de segurança de hardware (HSMs) a partir dele.
Permissões de Gerenciamento de Identidade e Acesso da AWS (IAM) para as APIs do CloudHSM em ambas as Regiões
Client SDK 5 instalado na instância de gerenciamento (versão 5.17 ou superior recomendada)
Observação importante: A sincronização de chaves entre clusters em mais de uma Região só funciona se todos os clusters forem criados a partir do mesmo backup. Isso ocorre porque a sincronização exige a presença da mesma chave secreta — chamada de masking key — no HSM de origem e no de destino. Essa chave é específica de cada cluster, não pode ser exportada e serve exclusivamente para sincronizar chaves entre HSMs de um mesmo cluster.
Passo 1: Criar o primeiro cluster na Região 1
Criar o cluster
Substitua <SUBNET_ID_1> por uma das suas sub-redes privadas e anote o ID do cluster retornado:
Substitua <CLUSTER_ID> pelo ID anotado anteriormente e <AVAILABILITY_ZONE> pela Zona de Disponibilidade correspondente à sua sub-rede privada (por exemplo, us-east-1a):
Antes de inicializar o cluster, crie um certificado autoassinado e use-o para assinar a Requisição de Assinatura de Certificado (CSR) do cluster. Com o certificado assinado em mãos, inicialize o cluster:
Após ativar, saia com quit e faça login novamente com a nova senha usando login --username admin --role admin. Em seguida, crie o primeiro usuário criptográfico (CU) com o comando abaixo. Para mais informações sobre tipos de usuário, consulte os tipos de usuário HSM para o CloudHSM CLI.
user create --username <USERNAME> --role crypto-user
Para copiar o backup da Região 1 para a Região 2, você precisa da Região de destino e do ID do cluster ou do backup. Se informar apenas o ID do cluster, o backup mais recente será utilizado. Para um backup específico, use o ID do backup:
Transferência de certificado e configuração do grupo de segurança
Copie o conteúdo do certificado do cluster original para um novo arquivo no cluster da Região 2. O certificado é necessário para conexões criptografadas entre o cliente e as instâncias HSM.
Em seguida, adicione o Grupo de Segurança do cluster clonado à sua instância EC2 cliente: selecione o Grupo de Segurança da instância EC2 no console, escolha “Adicionar regras” e adicione uma regra que permita tráfego do ID do Grupo de Segurança do cluster na porta 2225.
Recupere o endereço IP da ENI do HSM na Região 2 — você precisará dele no próximo passo:
Para que o CloudHSM CLI se comunique simultaneamente com os dois clusters, adicione o cluster da Região 2 à configuração do cliente usando o endereço IP da ENI obtido anteriormente:
A partir desse ponto, o CloudHSM CLI se comunicará com ambos os clusters simultaneamente, usando os certificados já configurados e a masking key compartilhada entre os clusters clonados.
Passo 6: Sincronizar chaves entre os clusters
Listar usuários e chaves
Antes de replicar, verifique quais usuários e chaves existem:
# Listar todos os usuários
cloudhsm-cli user list
# Listar chaves de um usuário específico
cloudhsm-cli key list --username <username>
Replicar chaves
Para replicar uma chave da Região 1 para a Região 2:
Verifique a replicação listando as chaves novamente. O output deve mostrar referências de chaves idênticas em ambos os clusters. Repita o processo para cada chave adicional que precisar sincronizar.
Pontos de atenção após a clonagem
Usuários criados após o backup inicial precisam ser criados manualmente nos dois clusters.
Alterações de senha em um cluster precisam ser replicadas manualmente para o outro.
Chaves criadas após o backup inicial precisam ser sincronizadas com pelo menos um HSM do cluster clonado — depois disso, a sincronização automática do CloudHSM cuida do restante dentro do segundo cluster.
Mantenha as ferramentas do Client SDK 5 atualizadas para ter acesso aos recursos mais recentes e melhorias de segurança.
O Client SDK 5 oferece suporte à arquitetura ARM64 nas seguintes distribuições Linux: Amazon Linux 2023, Amazon Linux 2, Red Hat Enterprise Linux (RHEL) 8 (8.3+), RHEL 9 (9.2+), RHEL 10 (10.0+), Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Debian 12 e SUSE Linux Enterprise Server 15.
Conclusão
Seguindo esse processo, é possível configurar um ambiente AWS CloudHSM tolerante a falhas, com chaves sincronizadas entre Regiões usando as ferramentas e práticas recomendadas mais recentes. A configuração de clusters entre Regiões traz melhorias na recuperação de desastres, reduz o risco de perda de dados e garante a continuidade das operações criptográficas — assegurando que as chaves críticas permaneçam disponíveis mesmo diante de uma falha regional. Dúvidas ou comentários podem ser enviados ao AWS re:Post.
