Inventário criptográfico para migração pós-quântica

A migração para criptografia pós-quântica é, antes de tudo, um problema de inventário. Nenhuma empresa consegue substituir com segurança o que não localiza, não classifica e não relaciona a processos de negócio. O risco não está apenas em servidores antigos ou certificados expirados. Ele aparece em bibliotecas embutidas, integrações de terceiros, dispositivos industriais, backups de longa retenção e protocolos que atravessam redes sem dono claro.

O ponto de partida é objetivo: descobrir onde a organização usa criptografia de chave pública vulnerável a avanços quânticos e decidir o que deve mudar primeiro. O NIST vem estruturando a jornada de migração em fases, com ênfase explícita em visibilidade criptográfica, gestão de risco, interoperabilidade e testes. A orientação atualizada do NCCoE reforça que a adoção de criptografia pós-quântica exige inventário abrangente, não uma atualização isolada de produto.

Por que o inventário criptográfico é a primeira entrega relevante?

Porque o algoritmo raramente está visível para quem opera o negócio. Uma aplicação pode usar TLS para transporte, certificados X.509 para autenticação, uma biblioteca de criptografia para assinar arquivos e um cofre de chaves para proteger segredos. Cada camada pode ter fornecedor, ciclo de atualização e nível de criticidade próprios.

Inventário criptográfico é o registro estruturado de ativos, algoritmos, chaves, certificados, protocolos, bibliotecas, dependências e responsáveis que compõem os controles criptográficos da empresa. Ele é diferente de um inventário tradicional de TI. Uma CMDB informa que um servidor existe. O inventário criptográfico precisa informar como ele protege dados, quais conexões estabelece, quais chaves consome e quais consequências surgem se o mecanismo precisar ser alterado.

A urgência não decorre da previsão exata de quando um computador quântico criptograficamente relevante surgirá. Ela decorre do tempo de transição. Dados sensíveis podem ser capturados agora e decriptados no futuro, cenário conhecido como harvest now, decrypt later: coleta-se conteúdo cifrado hoje para quebrá-lo quando houver capacidade computacional suficiente. O relatório global da DigiCert publicado em 2026 identificou um contraste importante entre consciência executiva e execução técnica: há reconhecimento crescente do risco, mas a descoberta de ativos e a implantação de certificados resistentes ao risco quântico ainda estão no início em grande parte das organizações. Veja o relatório.

O inventário, portanto, não é documentação para auditoria. É o mecanismo que transforma uma ameaça de longo prazo em decisões operacionais de curto prazo.

O que deve entrar no escopo do inventário?

O escopo precisa seguir o fluxo da informação, não apenas a lista de servidores. Comece por quatro grupos de evidência.

1. Dados com janela longa de confidencialidade

Classifique informações cujo valor persiste por anos: propriedade intelectual, dados clínicos, registros financeiros, contratos, estratégias de preço, credenciais, dados biométricos e informações pessoais sob obrigação legal de retenção. Para cada classe, registre por quanto tempo ela precisa permanecer confidencial.

Essa janela define a prioridade. Um dado que perde relevância em seis meses pode tolerar uma abordagem gradual. Um acervo que precisa permanecer sigiloso por dez anos deve entrar cedo no plano, ainda que o sistema correspondente não pareça crítico em disponibilidade.

2. Pontos de uso de criptografia pública

Mapeie onde há RSA, criptografia de curva elíptica, Diffie-Hellman, assinaturas digitais e certificados. Isso inclui TLS, VPN, SSH, e-mail corporativo, APIs, assinatura de código, autenticação federada, dispositivos móveis, Wi-Fi corporativo, DNSSEC, BGP, PKI interna e integrações máquina a máquina.

Uma revisão recente de protocolos amplamente usados indica que TLS e Signal avançaram mais em mecanismos híbridos de troca de chaves, enquanto SSH e IPsec têm padronização disponível, mas adoção produtiva menos disseminada. O estudo também destaca que a migração de autenticação tende a ser mais complexa que a troca de chaves, especialmente quando o tamanho das assinaturas afeta limites de protocolos e equipamentos. Leia a análise comparativa.

3. Implementações invisíveis no código e na cadeia de software

Procure bibliotecas criptográficas incorporadas em aplicações, containers, SDKs, firmware, appliances e pacotes legados. É comum encontrar dependências que usam algoritmos obsoletos sem que a equipe de produto saiba disso. Faça análise de composição de software, inspeção de repositórios, varredura de imagens e revisão de bibliotecas chamadas por aplicações críticas.

Inclua versões. Saber que uma aplicação usa OpenSSL, Java, .NET, um SDK de nuvem ou uma biblioteca de autenticação não basta. A capacidade de adotar algoritmos pós-quânticos depende de versões, parâmetros, compatibilidade de protocolo e comportamento de clientes.

4. Terceiros e serviços gerenciados

SaaS, provedores de nuvem, gateways de pagamento, plataformas de identidade, CDNs, parceiros B2B e fabricantes de dispositivos precisam entrar no inventário. Para cada fornecedor, registre quais dados são cifrados, quem controla as chaves, quais algoritmos são usados, como ocorrem atualizações e se existe plano público de migração.

O erro recorrente é tratar o serviço contratado como uma caixa-preta segura. Em uma transição pós-quântica, o contrato deve dar visibilidade sobre cronograma, compatibilidade, responsabilidade por testes e alternativas se o fornecedor atrasar a adequação.

Como transformar descoberta técnica em prioridade de negócio?

A lista de ativos será extensa. O valor está em atribuir uma prioridade consistente. Uma forma prática é avaliar cada item por cinco dimensões: sensibilidade do dado, tempo de confidencialidade, exposição externa, dependência operacional e dificuldade de migração.

A exposição externa mede se o ativo recebe conexões públicas, integra parceiros ou trafega em redes não confiáveis. A dependência operacional mede o impacto caso a alteração criptográfica gere incompatibilidade, falha de autenticação ou degradação de desempenho. A dificuldade de migração considera legado, firmware sem suporte, dependência de fornecedor, uso de hardware especializado e volume de clientes externos.

O resultado não deve ser uma pontuação opaca. Use faixas claras:

• Onda 1: dados de longa vida, serviços expostos, autenticação central, PKI e integrações de alto volume.
• Onda 2: aplicações internas críticas, VPNs, plataformas de desenvolvimento, assinatura de código e conectividade entre filiais.
• Onda 3: ativos de menor exposição, ambientes de laboratório, aplicações em descontinuação e dispositivos que dependem de renovação física.

Há uma distinção relevante entre confidencialidade e autenticidade. Trocar a troca de chaves em conexões externas pode reduzir primeiro o risco de interceptação e armazenamento futuro. Migrar assinaturas, por outro lado, afeta certificados, tokens, atualizações de software e cadeias de confiança. As duas frentes precisam de governança própria, mesmo quando aparecem na mesma aplicação.

Como organizar a migração sem gerar ruptura operacional?

A resposta é migrar por capacidades, não por produtos. Uma empresa madura não decide simplesmente “ativar PQC”. Ela cria condições para testar, adotar, medir e reverter mudanças com segurança.

Comece por um ambiente de validação que reproduza tráfego, clientes, dispositivos e políticas reais. Teste tamanho de chaves e assinaturas, latência, fragmentação de pacotes, consumo de CPU, limites de balanceadores, compatibilidade de proxies e comportamento de clientes antigos. Em protocolos com alto volume, pequenas diferenças de tamanho podem alterar custo e desempenho.

Depois, adote onde possível mecanismos híbridos. Criptografia híbrida combina um mecanismo clássico e um pós-quântico durante a transição. A ideia é preservar compatibilidade enquanto se incorpora proteção contra riscos quânticos. Ela não elimina a necessidade de migração completa, mas reduz o risco de depender imediatamente de uma única mudança ampla.

A experiência publicada pela Meta em abril de 2026 mostra que a migração exige coordenação entre inventário, engenharia de protocolos, testes de desempenho e controle de dependências. A empresa destaca que a descoberta de uso criptográfico precisa preceder decisões de implantação e que os desafios variam conforme o contexto de cada serviço. Os aprendizados técnicos estão detalhados pela Meta Engineering.

Defina também critérios de reversão. Se uma alteração causar aumento de erro, incompatibilidade com cliente crítico ou impacto fora do orçamento de latência, a equipe deve conseguir desativar a configuração sem restaurar servidores manualmente. Esse requisito separa um piloto controlado de uma alteração arriscada em produção.

O que é criptoagilidade e por que ela deve virar requisito de arquitetura?

Criptoagilidade é a capacidade de substituir ou reconfigurar algoritmos, chaves, parâmetros e bibliotecas criptográficas sem reescrever sistemas inteiros. Não é um produto específico. É uma propriedade arquitetural.

Uma aplicação criptoágil evita algoritmos fixos no código. Ela centraliza políticas, usa APIs padronizadas, separa lógica de negócio de implementação criptográfica e mantém mecanismos de rotação de chaves. Também registra onde cada certificado é usado e permite testar novas configurações em grupos limitados.

A ausência dessa capacidade cria dívida criptográfica. Ela aparece quando uma mudança aparentemente simples exige alterar centenas de repositórios, recompilar clientes, atualizar dispositivos físicos e renegociar integrações externas. Quanto maior a dívida, mais cedo o ativo deve ser descoberto e tratado, mesmo que sua migração final ocorra depois.

Inclua requisitos de criptoagilidade em compras e renovações. Perguntas objetivas ajudam: o fornecedor suporta os padrões pós-quânticos definidos pelo NIST? Há suporte para modos híbridos? Qual é o prazo de atualização para versões gerenciadas? A configuração pode ser automatizada por API? O cliente antigo continuará funcionando? Como a empresa notifica mudanças de algoritmo?

O NIST já publicou padrões pós-quânticos que podem ser implementados em múltiplos cenários de proteção de informação. Isso muda a conversa de pesquisa para planejamento de engenharia, embora a adoção ainda dependa de maturidade de cada protocolo e fornecedor. A página oficial de PQC do NIST resume os padrões disponíveis.

Quem deve governar o programa de migração pós-quântica?

A responsabilidade não pode ficar restrita à equipe de criptografia, quando ela existe. O programa precisa de patrocínio de segurança, arquitetura, plataforma, desenvolvimento, infraestrutura, jurídico, compras e donos de dados. Cada área controla parte da superfície de risco.

Crie um comitê enxuto, com decisão mensal e indicadores simples. Os principais são: percentual de ativos com descoberta concluída; percentual de dados classificados por janela de confidencialidade; cobertura de fornecedores avaliados; proporção de certificados e integrações com responsável definido; ativos críticos aptos a teste híbrido; e exceções com prazo de tratamento.

Evite medir apenas “percentual migrado”. Esse indicador é tardio e pode induzir mudanças apressadas. Antes da migração, o melhor sinal de progresso é a redução de zonas desconhecidas. Um ativo sem dono, sem algoritmo identificado ou sem evidência de atualização é um risco que não pode ser priorizado corretamente.

O papel da governança é manter decisões rastreáveis. Toda exceção deve registrar o motivo, o dado afetado, o controle compensatório, o fornecedor envolvido, o responsável executivo e a data de revisão. Em ambientes regulados, essa disciplina também demonstra que a organização tratou a transição como risco arquitetural, e não como reação pontual a uma tendência tecnológica.

Qual plano de 90 dias cria tração real?

Nos primeiros 30 dias, estabeleça escopo, taxonomia de ativos e critérios de risco. Selecione de três a cinco fluxos de dados de alta confidencialidade. Nomeie responsáveis por sistemas, certificados, chaves e integrações. Em paralelo, configure coleta de evidências por varredura de rede, gestão de certificados, repositórios e ferramentas de observabilidade.

Entre os dias 31 e 60, consolide os achados em um inventário único. Identifique algoritmos, protocolos, versões, dependências e lacunas de propriedade. Classifique os ativos nas três ondas. Dispare questionários técnicos para fornecedores críticos e abra planos de remediação para ativos sem suporte ou sem atualização viável.

Entre os dias 61 e 90, escolha dois casos controlados para teste. Um pode ser uma conexão TLS externa com suporte híbrido. Outro pode ser uma aplicação interna com alto valor de dados e ciclo de mudança previsível. Meça desempenho, compatibilidade, erros e esforço operacional. Ao final, apresente ao comitê executivo um mapa de risco, não apenas uma lista de tecnologias.

A transição pós-quântica será longa. A empresa que começa por inventário, prioridade e criptoagilidade ganha liberdade de escolha. A que espera por uma data definitiva tende a descobrir tarde que seu maior problema não era o algoritmo: era não saber onde ele estava.