Modelo de avaliação de risco quântico, com um método de pontuação transparente

Um modelo de avaliação de risco quântico é uma única tabela com uma linha por ativo criptográfico e seis colunas que definem a sua prioridade: ativo, algoritmo em uso, vida útil dos dados, exposição, tempo de migração e dependência de fornecedor. O método de pontuação abaixo é deliberadamente transparente: cada número vem das suas próprias estimativas e de prazos de migração publicados, nunca de uma data prevista para a chegada de um computador quântico. Copie a estrutura, mantenha as evidências ao lado e você terá um inventário que pode defender em uma auditoria.

As seis colunas e a pergunta que cada uma responde

Mantenha o modelo enxuto. Seis colunas bastam para priorizar o trabalho, e uma tabela enxuta de fato é preenchida. Responsável, referência de chamado e data de revisão são informações administrativas: úteis, mas não alteram uma prioridade.

Por que a troca de chaves precisa de um indicador próprio

O tráfego gravado é protegido apenas pela troca de chaves. Essa é toda a lógica do harvest now, decrypt later (HNDL), ou seja, coletar agora e descriptografar depois: um adversário armazena o texto cifrado hoje e o descriptografa quando a matemática permitir. As assinaturas se comportam de outra forma, porque forjar uma assinatura no futuro não expõe retroativamente uma sessão passada. Por isso, o modelo inclui um indicador de vulnerabilidade que separa os dois casos, em vez de tratar todos os algoritmos vulneráveis ao quântico como um único risco.

Pontuação: três faixas por coluna

Cada coluna recebe 1, 2 ou 3, com as definições das faixas escritas no próprio modelo, para que dois avaliadores cheguem ao mesmo número a partir dos mesmos fatos. As faixas de vida útil abaixo são um ponto de partida: ajuste-as à sua tabela de retenção e aos seus contratos, e registre o ajuste no modelo para que a pontuação continue auditável.

Em seguida, calculam-se duas somas, que devem permanecer separadas. Urgência, U = Q + S + E, de 3 a 9, mede o custo de um atraso. Prazo de execução, L = M + D, de 2 a 6, mede quanto tempo a mudança leva depois de iniciada. Calcular a média das duas em um único número destrói exatamente a informação de que você precisa, porque uma linha urgente e barata e uma linha cara e lenta exigem decisões diferentes.

A inequação de Mosca como raciocínio, não como profecia

Michele Mosca formulou o problema da migração com três grandezas: X, o tempo durante o qual seus dados devem permanecer confidenciais; Y, o tempo de que você precisa para migrar; Z, o tempo até que o algoritmo possa ser quebrado. Se X mais Y for maior que Z, os dados que saem dos seus sistemas hoje já estão fora da sua janela de proteção.

Z não pode ser conhecido, e este site não publica nenhuma estimativa dele. A substituição útil é trocar Z por um horizonte de planejamento pelo qual você responde: o primeiro marco com data no seu próprio escopo regulatório. A inequação deixa então de ser uma previsão e se torna um cálculo de conformidade, sem nenhuma probabilidade inventada.

A aritmética é curta. Uma linha com vida útil de 10 anos e tempo de migração de 2 anos precisa de 12 anos de proteção. Um horizonte no fim de 2030 está a cerca de 4 anos. Doze é maior que quatro, portanto o indicador é ativado: comece agora. Essa afirmação não diz nada sobre quando um computador quântico existirá, apenas que a janela de proteção ultrapassa a data definida pelo seu próprio escopo. Registre o horizonte utilizado em uma coluna ao lado do indicador, para que um revisor possa contestar o horizonte sem refazer a avaliação.

Transformar pontuações em uma ordem de trabalho

1. As linhas com o indicador de Mosca ativado e Q igual a 3 vêm primeiro, começando pelo maior U. São as linhas HNDL, nas quais um atraso não pode ser recuperado depois.
2. Com urgência igual, coloque primeiro o maior prazo de execução. A substituição de um HSM precisa começar antes de uma alteração de configuração de uma linha, mesmo que a alteração de configuração termine antes.
3. As linhas com Q igual a 1 saem da fila e entram em uma lista de monitoramento, revisada no mesmo ciclo que todo o resto, porque uma implantação híbrida hoje pode regredir amanhã.

U = Q + S + E          # urgency, 3 to 9
L = M + D              # lead time, 2 to 6
sort by (mosca_flag, Q, U, L), all descending

Não há pesos nem multiplicações, e isso é intencional. Uma pontuação composta ponderada esconde de qual estimativa o revisor discorda. Quatro componentes visíveis permitem que um auditor conteste uma célula, e não a priorização inteira.

Preencher as colunas com evidências, não com opiniões

Três fontes cobrem a maioria das linhas. Para tudo o que tem um endpoint público, leia diretamente o grupo negociado. O OpenSSL 3.5 ou posterior é necessário para os grupos ML-KEM, e os nomes dos grupos híbridos são registrados pela IANA: X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) e SecP384r1MLKEM1024 (0x11ED).

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
  | grep -i 'Negotiated TLS1.3 group'

ssh -Q kex | grep mlkem

Para o acesso administrativo, o OpenSSH tornou mlkem768x25519-sha256 o acordo de chaves padrão na versão 10.0 (9 de abril de 2025), e a versão 10.1 (6 de outubro de 2025) emite um aviso quando uma conexão negocia um acordo de chaves não pós-quântico, segundo as notas de versão do OpenSSH. Para código, bibliotecas e artefatos de build, um CBOM (cryptographic bill of materials, inventário de materiais criptográficos) preenche a coluna de algoritmo em escala, o que é importante porque um inventário digitado à mão fica desatualizado no dia em que é concluído. Teste qualquer mudança de grupo em homologação e mantenha um fallback clássico, como X25519, listado depois de X25519MLKEM768.

Relacionar o modelo às obrigações

Esta seção tem caráter informativo e não constitui aconselhamento jurídico. Quando uma linha acima reflete a nossa leitura e não o próprio texto, ela está identificada como interpretação, e a sua cópia do modelo deve manter essa distinção visível para os auditores.

Medir primeiro, pontuar depois

Pontuações baseadas em uma configuração presumida não valem nada. Comece pelos fatos visíveis externamente: faça uma varredura gratuita do seu domínio com o PQC Status para ver os grupos TLS negociados, as versões e a cadeia de certificados, cole o resultado nas colunas Algoritmo e Exposição das primeiras linhas e, em seguida, avance para dentro com ssh -Q kex e um CBOM. Uma varredura descreve apenas a configuração TLS visível externamente: não é uma certificação nem um atestado de conformidade, mas é a única coluna que ninguém pode contestar.