Automatizando a prontidão para criptografia pós-quântica com AWS Config

O problema: saber onde você está antes de migrar

A computação quântica avança em ritmo acelerado, e isso coloca em xeque os algoritmos criptográficos que protegem conexões TLS hoje. Migrar para criptografia pós-quântica (PQC) é inevitável — mas antes de qualquer migração, é preciso entender o estado atual dos seus endpoints. É exatamente para isso que a AWS desenvolveu o PQC Readiness Scanner: uma ferramenta automatizada que faz o inventário e o monitoramento contínuo das configurações TLS dos seus recursos na nuvem.

O scanner avalia endpoints do Application Load Balancer (ALB), do Network Load Balancer (NLB) e do Amazon API Gateway, classificando cada um deles em um sistema de três níveis que facilita a priorização da migração.

Contexto técnico: por que o TLS 1.3 é obrigatório para PQC

Para tráfego web, os algoritmos de troca de chaves pós-quânticos são negociados exclusivamente dentro do TLS 1.3. Isso significa que conexões resistentes a ataques quânticos exigem dois requisitos simultâneos: suporte a TLS 1.3 e uso de algoritmos de troca de chaves PQC.

Dentro do Modelo de Responsabilidade Compartilhada da AWS, a AWS garante a infraestrutura e habilita o suporte a PQC nos seus serviços. A responsabilidade de configurar os recursos para usar políticas de segurança compatíveis com PQC é do cliente. Para conexões TLS terminadas pela AWS — como ALB, NLB, API Gateway e CloudFront — o cliente escolhe a política de segurança que define quais versões de TLS e conjuntos de cifras serão aceitos em cada listener.

Como o PQC Readiness Scanner funciona

A solução é construída sobre pacotes de conformidade do AWS Config. Um pacote de conformidade é um conjunto de regras do AWS Config e ações de remediação que pode ser implantado como uma única entidade em uma conta e região, ou em toda uma organização via AWS Organizations.

O scanner executa duas verificações por recurso:

O endpoint usa uma política de segurança compatível com PQC?
O endpoint ainda aceita TLS 1.0 ou 1.1 (protocolos legados)?

Cada verificação retorna status COMPLIANT ou NON_COMPLIANT, com recomendações específicas de política. Com base nesses resultados, cada recurso é classificado em um dos três níveis do framework:

Os três níveis de prontidão

Nível 1 — PQ-ready (postura mais forte): O endpoint usa apenas TLS 1.3 com troca de chaves PQC. Esses recursos já estão no estado ideal. Nenhuma ação necessária.
Nível 2 — PQ-ready com compatibilidade retroativa: O endpoint suporta TLS 1.2 e TLS 1.3, com troca de chaves PQC negociada nas conexões TLS 1.3. Prioridade de migração baixa — esses recursos já oferecem proteção pós-quântica para clientes que suportam TLS 1.3, mantendo compatibilidade com clientes legados via TLS 1.2.
Nível 3 — Não PQ-ready: Inclui endpoints sem suporte a TLS 1.3 e endpoints com TLS 1.3, mas sem políticas de troca de chaves PQC. Prioridade alta — requerem atenção imediata.

Escopo da avaliação

O scanner avalia os seguintes serviços de borda da AWS que terminam conexões TLS em nome das aplicações:

ALB e NLB: Listeners com protocolos HTTPS, TLS e TCP SSL são avaliados.
API Gateway: REST APIs (endpoints regionais e privados), HTTP APIs (v2) e WebSocket APIs (v2) são avaliadas.

O que fica de fora: Distribuições do Amazon CloudFront estão excluídas do escopo porque o TLS 1.3 com troca de chaves híbrida pós-quântica já é habilitado automaticamente nas políticas de segurança TLS do CloudFront para conexões viewer-to-edge. Nenhuma ação é necessária do lado do cliente para PQC no CloudFront.

Quanto aos Classic Load Balancers, a recomendação da AWS é migrar para ALB ou NLB, pois o Classic Load Balancer não suporta TLS 1.3 nem troca de chaves PQC e não pode ser tornado PQ-ready.

Arquitetura da solução

O PQC Readiness Scanner combina quatro serviços principais:

AWS Config para monitoramento contínuo e avaliação dos recursos.
Pacotes de conformidade para implantação em toda a organização.
AWS Lambda para executar a lógica de avaliação das políticas de segurança.
AWS Serverless Application Model (AWS SAM) para o deploy das funções Lambda.

O pacote de conformidade implementa quatro regras customizadas do AWS Config, alimentadas por duas funções Lambda:

ELB PQ-ready: Verifica se os listeners dos load balancers usam políticas que suportam TLS 1.3 com algoritmos PQC.
ELB legacy TLS: Verifica se os listeners ainda permitem conexões TLS 1.0 ou 1.1.
API Gateway PQ-ready: Verifica se os endpoints do API Gateway usam políticas com suporte a TLS 1.3 e PQC.
API Gateway legacy TLS: Verifica se os endpoints do API Gateway ainda permitem TLS 1.0 ou 1.1.

Pré-requisitos para implantação

Antes de implantar a solução, você precisa ter:

AWS CLI (Interface de Linha de Comando da AWS) configurada com as permissões adequadas.
Python 3.12 instalado (requisito do runtime Lambda).
AWS SAM CLI instalado (Guia de instalação).
AWS Config habilitado na região alvo, configurado para registrar os tipos de recurso AWS::ElasticLoadBalancingV2::LoadBalancer, AWS::ApiGateway::RestApi e AWS::ApiGatewayV2::Api (selecionar tipos de recurso específicos).

Implantação em conta única

O deploy é feito em três fases. Os detalhes completos estão no repositório GitHub. As funções Lambda devem ser implantadas antes do pacote de conformidade, pois o pacote referencia os ARNs das funções como parâmetros.

git clone https://github.com/aws-samples/sample-PQC-Readiness-using-AWS-Config.git
cd sample-PQC-Readiness-using-AWS-Config/installation
sam build

Para implantar em uma ou mais regiões:

# Make script executable (first time only)
chmod +x deploy-per-regions.sh

# Deploy to a single region
./deploy-per-regions.sh us-east-1

# Deploy to multiple regions
./deploy-per-regions.sh us-east-1 us-west-2 eu-west-1

O script automaticamente implanta as funções Lambda via SAM, provisiona o pacote de conformidade com as regras do Config, cria as roles IAM com permissões mínimas para operações de describe no ELB, ALB, NLB e API Gateway, e fornece mensagens de status claras ao longo do processo.

Implantação multi-conta via Organizations

Para implantação em múltiplas contas AWS, a solução usa CloudFormation StackSets para distribuir as funções Lambda em cada conta. Um ponto importante: regras do tipo CUSTOM_LAMBDA no AWS Config exigem que a função Lambda esteja na mesma conta que a regra — não é possível usar uma Lambda centralizada em uma conta para avaliar recursos em outras contas.

Passo 1: Criar o bucket S3 compartilhado

Antes de empacotar, é necessário criar um bucket S3 acessível por cada conta-alvo na organização. Esse bucket hospedará os artefatos de deploy que o CloudFormation StackSets distribuirá para as contas-membro.

# Create the shared S3 bucket (run from management/central account)
aws s3 mb s3://<your-org-shared-bucket> --region us-east-1

Conceda acesso de leitura às contas-alvo via política de bucket:

aws s3api put-bucket-policy \
  --bucket <your-org-shared-bucket> \
  --policy '{
  "Statement": [
    {
      "Sid": "BucketOwnerFullAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<bucket-owner-account-id>:root"
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::<your-org-shared-bucket>",
        "arn:aws:s3:::<your-org-shared-bucket>/*"
      ]
    },
    {
      "Sid": "CrossAccountReadAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::<account-id-1>:root",
          "arn:aws:iam::<account-id-2>:root"
        ]
      },
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::<your-org-shared-bucket>",
        "arn:aws:s3:::<your-org-shared-bucket>/*"
      ]
    }
  ]
}'

Atenção: o bucket deve estar na mesma região das implantações do StackSet. Para implantações multi-região, crie um bucket por região e execute o sam package separadamente para cada uma.

Passo 2: Build e upload dos pacotes Lambda para o S3

cd installation

# Make script executable (first time only)
chmod +x deploy-stacksets.sh

# Build, package, upload to S3, and generate resolved template
./deploy-stacksets.sh <your-org-shared-bucket>

Passo 3: Implantar as funções Lambda via StackSets

# Create StackSet (--region sets the StackSet "home region" where it is managed)
aws cloudformation create-stack-set \
  --stack-set-name pqc-readiness-lambda-functions \
  --template-body file://packaged-template.yaml \
  --capabilities CAPABILITY_IAM \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
  --region us-east-1

# Deploy stack instances to member accounts
aws cloudformation create-stack-instances \
  --stack-set-name pqc-readiness-lambda-functions \
  --deployment-targets OrganizationalUnitIds=ou-xxxx-xxxxxxxx \
  --regions us-east-1 \
  --region us-east-1

Ponto de atenção sobre regiões: --region em cada comando define a região-home do StackSet (onde o recurso StackSet vive). --regions em create-stack-instances define as regiões-alvo onde as instâncias de stack serão criadas nas contas-membro. São valores independentes. StackSets com SERVICE_MANAGED devem ser criados a partir da conta de gerenciamento ou de uma conta de administrador delegado. A conta de gerenciamento em si é excluída das implantações de instâncias de stack — use o script deploy-per-regions.sh separadamente se precisar do scanner na conta de gerenciamento.

Passo 4: Implantar o pacote de conformidade organizacional

aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name pqc-legacy-tls-compliance \
  --template-body file://conformance-packs/pqc-legacy-tls-conformance-pack.yaml

Isso cria as regras do Config em cada conta-membro, referenciando as funções Lambda locais de cada conta.

Guia de migração e priorização

Com os resultados em mãos, a priorização segue o framework de três níveis:

Alta prioridade — Nível 3 (não PQ-ready)

Recursos sem suporte a PQC e/ou que ainda permitem TLS 1.0 ou 1.1. A ação é atualizar para uma política PQ-ready — como as que terminam com -PQ-2025-09 (consulte a documentação de políticas de segurança do Elastic Load Balancing).

Importante: antes de atualizar, audite as versões TLS dos seus clientes. Políticas PQ-ready exigem TLS 1.3; clientes legados que suportam apenas TLS 1.2 ou anterior falharão na negociação. A recomendação é começar por uma política de Nível 2 (compatível com TLS 1.2 e 1.3 com PQC), monitorar os logs de conexão para falhas de negociação TLS e só migrar para uma política TLS 1.3-only do Nível 1 após confirmar que os clientes suportam TLS 1.3 com PQC.

Baixa prioridade — Nível 2 (PQ-ready com compatibilidade retroativa)

Recursos usando TLS 1.3 com políticas PQ-ready que também suportam TLS 1.2. Esses recursos já oferecem proteção pós-quântica para conexões TLS 1.3. A ação recomendada é monitorar os logs, identificar o volume de conexões TLS 1.2 e planejar a migração desses clientes para TLS 1.3 com PQC quando for viável.

Sem ação necessária — Nível 1 (PQ-ready, estado ideal)

Recursos usando apenas TLS 1.3 com troca de chaves PQC. Esses recursos já estão no estado-alvo.

Visualizando os resultados

Em cada conta-membro, acesse o console do AWS Config na região implantada. Os pacotes de conformidade organizacionais aparecem com o prefixo OrgConformsPack- seguido de um sufixo aleatório (ex: OrgConformsPack-pqc-legacy-tls-compliance-gyv22je0). Ao clicar no pacote, você vê um resumo geral de conformidade para as quatro regras. Em Regras, as quatro regras com prefixo pqc- mostram contagens de recursos conformes e não conformes, anotações detalhadas por recurso, ARNs e configurações de política de segurança atuais.

Conclusão

O PQC Readiness Scanner resolve um problema real e imediato: saber exatamente quais endpoints precisam ser migrados primeiro, sem depender de revisões manuais de configuração. O sistema de níveis traduz achados técnicos em recomendações acionáveis — equipes conseguem entender os próximos passos sem precisar dominar criptografia. O scanner detecta automaticamente mudanças de configuração, ajudando a manter novos deployments dentro dos padrões de prontidão. Os relatórios nativos do AWS Config suportam requisitos de auditoria e permitem demonstrar progresso mensurável.

Para começar, acesse o PQC Readiness Scanner, priorize os recursos de Nível 3 e acompanhe o progresso entre contas usando os aggregators do AWS Config.

Recursos adicionais

Fonte

Automating post-quantum cryptography readiness using AWS Config (https://aws.amazon.com/blogs/security/automating-post-quantum-cryptography-readiness-using-aws-config/)