Migração pós‑quântica sem drama: um plano de 12 meses para CTOs

Você não precisa de um quadro branco cheio de matemática de reticulados para tomar a decisão certa sobre criptografia pós‑quântica (PQC). Você precisa de um plano. PQC já saiu da pesquisa e entrou no seu toolchain: GnuPG está incorporando suporte pós‑quântico na mainline, OpenSSH envia há anos uma troca de chaves híbrida PQ, e as grandes clouds e CDNs já rodaram experimentos reais de TLS híbrido. Adversários já estão coletando tráfego criptografado hoje para descriptografar depois. Se seus dados precisam permanecer confidenciais por 5–10+ anos, o relógio está correndo.

Isso não é FUD. É um problema de sequenciamento. Se você esperar cada HSM, smartcard e framework de conformidade “suportar totalmente” PQC, vai perder a janela e pagar duas vezes: uma por uma migração às pressas e outra pelos incidentes de produção que vêm junto. A jogada certa é tornar seu stack cripto‑ágil agora, ativar troca de chaves híbrida e assinaturas duplas onde ajudam, e evitar quebrar os sistemas que ainda vivem na fila de validação FIPS.

What changed in 2026

• Os algoritmos são reais, não brinquedos de rascunho. A rodada do NIST encerrou com seleções para encapsulamento de chaves (ML‑KEM, derivado de Kyber) e assinaturas digitais (ML‑DSA de Dilithium; SLH‑DSA de SPHINCS+ para casos especiais). Publicações e perfis FIPS estão chegando entre 2024–2026.
• PQC está nas ferramentas mainstream. A chegada de suporte pós‑quântico no GnuPG sinaliza que experimentos de PGP/S/MIME estão prontos fora de builds acadêmicos. OpenSSH envia um KEX híbrido (sntrup761x25519) implantado por grandes provedores. Cloudflare, Google e outros já executaram amplos testes de TLS 1.3 híbrido (por exemplo, X25519+Kyber768).
• Harvest‑now‑decrypt‑later (HNDL) é o risco real. AES‑256 sobrevive ao speedup quadrático de Grover; sua cripto simétrica provavelmente está ok. Seu estabelecimento de chaves e assinaturas não. Se a confidencialidade de uma sessão precisa durar uma década, você não deve depender apenas de RSA/ECDH em 2026.

As duas decisões que você realmente precisa tomar

1. Onde vale a pena pagar a dor operacional por PQ híbrido hoje? Seus endpoints TLS públicos e o SSH administrativo são apostas de baixo arrependimento. Eles entregam proteção imediata contra HNDL sem re‑plataformar identidade.
2. Como ganhar tempo no restante? Torne seu software cripto‑ágil para trocar algoritmos sem reescrever apps. Depois, faça a faseação de PQ quando seus fornecedores, HSMs e auditores alcançarem.

Um plano de 12 meses que você pode executar

Phase 0 (Weeks 0–2): Establish the rule of the game

• Defina “tempo de confidencialidade” por classe de dado. Baldes de exemplo: 0–2 anos (logs transitórios), 3–7 anos (PII/PHI de usuários), 8–20 anos (financeiros, contratos governamentais, genômica). Qualquer coisa ≥7 anos entra na pista prioritária de PQ.
• Nomeie um squad DRI: 1 Engenheiro(a) de Segurança, 1 SRE, 1 Engenheiro(a) de Plataforma. Adicione um TPM se você tem grande superfície de fornecedores. Dê a eles um checkpoint executivo semanal e um OKR de 12 meses.

Phase 1 (Weeks 2–8): Build your Crypto Bill of Materials (CBOM)

• Faça o inventário por evidência, não por achismo. Use testssl.sh ou ztls para escanear endpoints TLS externos e registrar KEX/assinaturas suportados. Para mTLS interno, adicione telemetria do Envoy/HAProxy sobre cifras negociadas. Para SSH, faça parse de sshd_config em toda a frota e capture as listas de KEX do servidor.
• Busque nos códigos dos seus repositórios por bibliotecas de cripto (OpenSSL, BoringSSL, BouncyCastle, libsodium, provedores JCE). Anote versões. Sinalize cripto “feita em casa” frágil e strings de cifras pinadas.
• Catalogue chaves e certs: cadeias de CA, certs folha, chaves de assinatura de JWT, certs de code‑signing, chaves de KMS que protegem DEKs/KEKs, chaves PGP. Registre curvas, tamanhos de RSA e cadências de rotação.
• Mapeie capacidades de HSM/KMS e roadmaps dos fornecedores. Faça perguntas objetivas: cronogramas de suporte a ML‑KEM/ML‑DSA, suporte a TLS híbrido, status FIPS, caminhos de upgrade de firmware, impactos de throughput e custos.

Phase 2 (Weeks 8–16): Make the platform crypto‑agile

• Abstraia a cripto uma vez só. Se seus serviços chamam OpenSSL diretamente, introduza uma camada fina de provider com negociação de algoritmos. No mundo JVM, configure via provedores JCE e flags de propriedades em vez de fixar suites no código. Em Go, prefira tls.Config com CurvePreferences dinâmicas e cipher suites carregadas de configuração.
• Remova pins frágeis. Substitua pins explícitos no estilo “TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256” por nomes de política (por exemplo, “prod‑tls‑policy‑2026”) resolvidos na inicialização a partir de config. Essa única indireção é a diferença entre um flip de config e um redeploy.
• Habilite suporte a assinatura dupla nos pipelines. Para artefatos, garanta que o fluxo de assinatura possa anexar uma assinatura clássica e outra PQ (por exemplo, cosign com múltiplas assinaturas, estruturas JOSE/COSE ou metadados destacados). Você pode não ligar PQ hoje, mas poderá fazê‑lo quando seus trust stores permitirem.

Phase 3 (Months 4–6): Ship hybrid where it pays now

• TLS para endpoints públicos: Levante um domínio canário usando X25519+Kyber768 como KEX híbrido via uma CDN ou edge proxy que suporte. Espere os bytes do handshake crescerem ~1–2 KB e um aumento de CPU desprezível em CPUs modernas. Direcione 10–20% do tráfego externo por 2–4 semanas, acompanhe taxas de falha de handshake e o mix de clientes. Se middleboxes se comportarem mal, faça fallback por SNI enquanto mantém o híbrido para clientes modernos.
• SSH para caminhos admin: Habilite sntrup761x25519-sha512@openssh.com no OpenSSH para acesso da equipe. É drop‑in, testado e dá proteção PQ para as credenciais que mais importam: as que têm shell na produção.
• Dados em repouso: Confirme AES‑256‑GCM em todos os lugares. Se algum serviço ainda usa AES‑128 ou 3DES, corrija agora. Para key wrapping (KEKs protegendo DEKs), prefira wrapping simétrico local ou KMS que se comprometa publicamente com suporte a PQ KEM; evite segredos de longa duração protegidos por RSA para dados de alta longevidade.

Phase 4 (Months 6–9): Extend to identity and messaging

• JWT e identidade de serviço: Mantenha RS256/ES256 pela interoperabilidade, mas adicione encanamento pronto para PQ. Se você opera sua própria CA, pilote uma CA interna que emita certs com dupla assinatura (clássica + assinatura PQ) para clientes não‑browser sob seu controle. Para SPIFFE/SPIRE ou mTLS em service mesh, teste KEM PQ em ambientes de staging onde houver suporte.
• Email e criptografia de arquivos: Com o suporte PQ do GnuPG chegando, crie um keyring paralelo para papéis sensíveis (jurídico, finanças, operações de saúde) usando certs híbridos ou apenas PQ. Rode um piloto de grupo fechado: 20–50 pessoas, opt‑in, com fallbacks. Espere aumento nos tamanhos de mensagem (assinaturas Dilithium ~2–3 KB; SPHINCS+ ainda maiores). Documente a compatibilidade de clientes.
• Assinatura de código e supply chain: A maioria dos trust stores de SO ainda não aceita assinaturas PQ. O movimento hoje é assinatura dupla: mantenha sua assinatura clássica para os trust stores e anexe uma assinatura PQ como atestação adicional registrada na proveniência (SLSA, GUAC). Isso permite verificar PQ internamente e virar externamente quando os stores alcançarem.

Phase 5 (Months 9–12): Bake it into operations and procurement

• Observabilidade: Adicione métricas de tamanho de handshake TLS e falhas por grupo aos seus dashboards. Acompanhe “híbrido negociado” como razão. Defina um SLO: menos de 0,1% de falhas de handshake atribuíveis à negociação de KEX durante os rollouts.
• Política de rotação: Encurte as validades de certificados e chaves (por exemplo, 30–90 dias) para tornar mudanças de cripto de baixo risco. Na prática, você fará mais rotações, mas com automação isso é um seguro barato para trocas rápidas de algoritmo.
• Gate de fornecedores: Atualize seu questionário de segurança: “Liste KEMs e esquemas de assinatura suportados; confirme a capacidade de negociar ML‑KEM/ML‑DSA; forneça status e roadmap FIPS.” Recuse caixas‑pretas que hardcodam cifras.
• Runbooks de incidentes: Documente o comportamento de downgrade/fallback para que um engenheiro de operações não desabilite o híbrido no site inteiro sob pressão. A resposta certa para falha em middlebox é uma política direcionada por SNI ou faixa de IP, não um rollback global.

O que isso custa (e o que economiza)

• Pessoas/tempo: Um squad de 3–4 pessoas conclui um CBOM crível em 6–8 semanas, adiciona a abstração de cripto‑agilidade em 4–6 semanas para os 10 principais serviços e pilota TLS/SSH híbridos em mais 4–6 semanas. São ~3–4 meses de calendário para começar a proteger onde mais importa.
• Overhead de infra: Handshakes TLS híbridos adicionam cerca de 1–2 KB e CPU modesta (a decapsulação ML‑KEM é rápida em CPUs modernas). Espere um aumento de CPU de handshake de poucos por cento na borda. Para a maioria dos perfis de tráfego SaaS, isso fica no ruído.
• Gasto com fornecedores: A parte cara são os upgrades de HSM e KMS se você exigir PQ em hardware. Se você tolera terminar TLS híbrida em software na borda pelos próximos 12–24 meses, adia capex grande enquanto o mercado de HSM amadurece.

Compatibilidade e performance: os trade‑offs que você deve aceitar

• Assinaturas e chaves maiores. Tamanhos aproximados importam para planejamento: chaves públicas ML‑KEM‑768 ~1,1 KB; ciphertexts ~1,1 KB. Assinaturas ML‑DSA ficam em ~2–3 KB. SPHINCS+ pode ter assinaturas de 8–30 KB. Isso afeta email, logging e contabilização de banda.
• Middleboxes vão surpreender você. Alguns proxies corporativos e IDS derrubam grupos TLS desconhecidos. Por isso você começa com um domínio canário e políticas baseadas em SNI. Não ligue o híbrido no seu hostname principal de login no primeiro dia.
• FIPS e auditorias ficam para trás. Ambientes regulados precisam de módulos validados FIPS. Sem problema — rode PQ em pilotos controlados e caminhos de código cripto‑ágeis agora, depois anexe um módulo validado quando chegar. Esperar o carimbo antes de escrever uma linha de código é como você acaba fazendo heroísmo no Q4.

Brazil e realidades de LatAm que você deve considerar

• Âncoras de confiança: Se você atende clientes no Brazil, monitore as orientações do ICP‑Brasil para assinaturas digitais usadas em e‑invoicing e licitações públicas. Não antecipe o root program; em vez disso, assine artefatos e atestações internas em duplicidade para estar pronto quando perfis PQ aparecerem.
• Pagamentos e fintech: Provedores de PIX/Open Finance se importam com orçamentos de latência. Um aumento de 1–2 KB no handshake normalmente fica dentro da tolerância se você terminar em PoPs de borda em São Paulo e Rio. Meça o p95 do tempo de handshake antes e depois; reserve 5–10 ms extras em links congestionados.
• Execução nearshore: Um squad baseado no Brazil com 6–8 horas de overlap com os EUA consegue tocar seu CBOM, a abstração de cripto‑agilidade e os canários de tráfego sem dor de fuso. Isso não é P&D exótico; é engenharia de plataforma forte com controle de mudança disciplinado.

O que não fazer

• Não “ferva o oceano”. Você não precisa de PQ em todo microserviço até dezembro. Proteja primeiro o ingresso público e os caminhos de raiz de confiança.
• Não se prenda a um appliance sem saída. Se um fornecedor não consegue nomear seus KEMs/esquemas de assinatura suportados e mostrar um demo híbrido funcionando, ele não está pronto — por mais brilhante que seja o datasheet.
• Não confunda cripto‑agilidade com caos. Centralize a política de cifras em um lugar, rode com canários e observe. Você quer movimentos reversíveis com raios de impacto controlados.

Um framework simples de decisão

Use isto para priorizar onde PQ entra primeiro:

• Os dados precisam de confidencialidade ≥7 anos? Sim → priorize PQ híbrido no transporte e no key wrapping. Não → mantenha o clássico por ora; garanta caminhos de código cripto‑ágeis.
• Você controla totalmente as duas pontas da conexão? Sim → avance mais rápido (mTLS, service mesh, SSH). Não → use canários em TLS público e meça quebras de clientes.
• O caminho é raiz de confiança? Assinatura de código, proveniência de CI/CD, acesso admin → implemente assinaturas duplas ou KEX híbrido cedo, independentemente do mix de clientes.

Respondendo às perguntas executivas que você vai receber

• “Estamos expostos hoje?” Se você roda TLS apenas com RSA/ECDHE para tráfego cuja confidencialidade deve durar uma década, sim — HNDL é um risco real. Você consegue reduzir isso materialmente em um trimestre adicionando KEX híbrido na borda.
• “Os clientes vão perceber?” Quase certamente não. Bytes e CPU do handshake sobem um pouco; a cauda de latência move alguns milissegundos em piores casos. Isso fica muito abaixo da variância típica do “clima” de rede.
• “E se os algoritmos mudarem?” É por isso que você implementa cripto‑agilidade. Você não está tatuando Kyber na testa; está transformando em um parâmetro de configuração.

Por que agora, não depois

Esperar não compra certeza; compra dívida. Os padrões estão suficientemente maduros, ferramentas mainstream estão entregando, e o custo para pilotar é baixo. O preço de não fazer nada é embarcar mais segredos de longa duração sob cripto clássica enquanto adversários gravam seu tráfego. Você consegue capturar 80% do benefício com 20% do esforço focando no TLS de ingresso, no SSH administrativo e em software cripto‑ágil. Todo o resto pode amadurecer atrás desse beachhead.

Principais conclusões

• Comece com um CBOM em 6–8 semanas e torne seu código cripto‑ágil; isso destrava todo o resto.
• Entregue TLS híbrido (X25519+Kyber768) no ingresso público e SSH híbrido para admin; meça, faça canários e mantenha fallbacks por SNI.
• Use AES‑256‑GCM para dados em repouso e evite KEKs protegidos por RSA de longa duração para dados de alta longevidade.
• Assine em duplicidade artefatos e proveniência agora para poder virar a confiança externa quando os stores adotarem PQ.
• Espere pequenos custos de performance (KBs e milissegundos), assinaturas maiores e problemas ocasionais com middleboxes — planeje os rollouts de acordo.
• Trate PQ como uma capacidade de produto: observabilidade, rotação, linguagem de procurement e runbooks — não um upgrade de cripto pontual.