Capítulo 38 — Segurança quântica e pós-quântica: validação
Mapa da aula
Aula 38 publicada. Mapa, exemplo, EX075.
flowchart TD
N0["38.1 Verificação versus validação"]
N1["38.2 Testes de aceitação"]
N2["38.3 Validar a redução de risco"]
N3["38.4 Validação independente"]
N4["Nota de engenharia"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX075"]
Desenho lógico
flowchart LR
N0["38.1 Verificação versus validação"]
N1["38.2 Testes de aceitação"]
N2["38.3 Validar a redução de risco"]
N3["38.4 Validação independente"]
N4["Nota de engenharia"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX075"]
[38.1 Verificação versus validação]
|
v
[38.2 Testes de aceitação]
|
v
[38.3 Validar a redução de risco]
|
v
[38.4 Validação independente]
|
v
[Nota de engenharia]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX075]
Objetivos de aprendizagem
Você vai (1) validar que o sistema migrado atende às necessidades das partes interessadas; (2) distinguir as evidências de verificação das evidências de validação; (3) conduzir testes de aceitação com usuários e parceiros; e (4) validar com cuidado as alegações de redução de risco. O capítulo parte dos Capítulos 16, 30 e 37.
38.1 Verificação versus validação
A verificação mostra que os requisitos são cumpridos ("o TLS de borda negocia o X25519MLKEM768 com 99,2% dos clientes que o oferecem"). A validação mostra que o sistema cumpre o seu propósito ("as companhias de navegação, a aduana e a equipe operam normalmente, e os fluxos de dados de vida longa estão protegidos contra a gravação"). As duas são necessárias; uma não implica a outra.
Um sistema pode passar na verificação e ainda assim falhar na validação: a borda pode negociar o grupo híbrido com 99,2% dos clientes que o oferecem enquanto um job em lote de um parceiro falha em silêncio porque o seu cliente antigo expira por timeout. A validação detectaria isso pelos testes de aceitação do próprio parceiro. Inversamente, os parceiros podem estar satisfeitos enquanto um requisito não é cumprido, por exemplo se a replicação ainda usa troca de chaves clássica.
38.2 Testes de aceitação
Os parceiros executam testes de aceitação nos seus fluxos de trabalho; a equipe de operações confirma que não há incidentes novos; o jurídico confirma que os documentos com assinatura dupla são aceitáveis; as equipes de dispositivos confirmam que as atualizações de firmware funcionam em todos os modelos. Registre a aceitação com datas e signatários.
A aceitação é registrada por parte interessada porque cada uma verifica uma propriedade diferente: os parceiros, os seus fluxos de trabalho; o jurídico, o valor probatório das assinaturas; as equipes de dispositivos, o caminho de atualização. Uma assinatura datada de cada uma torna simples resolver disputas posteriores. Quando uma parte interessada não pode aceitar, o motivo se torna um item de trabalho, em vez de ser anotado e esquecido.
38.3 Validar a redução de risco
Afirme com cuidado: "O tráfego de borda gravado e negociado com grupos híbridos está protegido contra a decifração quântica futura se o X25519 ou o ML-KEM-768 continuar seguro" é defensável. "A BPA é segura contra a computação quântica" não é — ainda restam certificados, algumas VPNs, dispositivos e ativos desconhecidos. A validação relata o que está protegido e o que não está.
A afirmação defensável nomeia exatamente o que está protegido, sob qual hipótese e, implicitamente, o que não está. Listar os caminhos clássicos restantes, com datas, transforma a lacuna num plano em vez de uma fraqueza oculta. Os conselhos conseguem tomar decisões com afirmações assim; um slogan como "segura contra a computação quântica" não lhes dá nada sobre o que agir e se torna constrangedor quando uma exceção é descoberta.
38.4 Validação independente
Uma equipe independente (auditoria interna ou avaliador externo) amostra fluxos, verifica os algoritmos negociados a partir do seu próprio ponto de observação e revisa os desconhecidos do CBOM. A independência detecta a autoavaliação otimista.
Uma equipe independente que captura tráfego do seu próprio ponto de observação pode descobrir, por exemplo, que um serviço relatado como híbrido na verdade negocia grupos clássicos com uma determinada família de clientes. Amostrar fluxos, em vez de confiar no painel da equipe, é o que torna a verificação independente. Revisar os desconhecidos importa porque uma autoavaliação tende a tratá-los como menores. As constatações do avaliador entram no dossiê com as respostas da equipe.
38.5 Exemplo resolvido
O relatório de validação da BPA: 64% das conexões de borda híbridas (verificação); aceitação dos parceiros concluída para 11 de 14 companhias (validação); exportações para a aduana com destinatário duplo (validação pendente do teste da agência); bootloader com chave dupla em 40% dos dispositivos; ativos desconhecidos 6%. A declaração de risco residual lista os caminhos clássicos restantes, com datas.
O relatório separa verificação de validação em cada linha, para que os leitores vejam quais alegações se apoiam na telemetria e quais na confirmação das partes interessadas. O teste pendente da aduana é relatado como pendente, não como concluído, e o número de 40% do firmware declara a cobertura de dispositivos, não a assinatura de imagens. É essa precisão que permite ao conselho confiar no restante do relatório.
38.6 Erros comuns e limites
- Tratar as métricas de verificação como validação.
- Alegar em excesso que se é "seguro contra a computação quântica".
- Apenas autovalidação.
Uma parcela híbrida alta é um resultado de verificação; ela não diz nada sobre se os parceiros ainda conseguem trabalhar, o que só a validação confirma. Alegar ser "seguro contra a computação quântica" ignora os certificados clássicos, as VPNs e os ativos desconhecidos que o relatório lista. A autovalidação sozinha tende a deixar escapar o que a equipe não pensou em verificar, e é por isso que uma amostra independente faz parte do processo da BPA. Cada um desses erros aparece nos primeiros relatórios de migração de muitas organizações, geralmente descoberto por um auditor, e não pela equipe.
Nota de engenharia
A validação deve revisitar, uma a uma, as necessidades originais das partes interessadas do Capítulo 21. Para cada uma, declare se está atendida, parcialmente atendida ou não atendida, com evidências, e registre qualquer necessidade que tenha mudado durante o programa — por exemplo, um parceiro cuja exigência de retenção de dados passou de cinco para dez anos após a renovação de um contrato. As necessidades mudam; uma validação que compara apenas com a lista original pode declarar sucesso num alvo que já não reflete o que as partes interessadas realmente exigem.
Exercícios
- EX075 — Risco residual. Escreva a declaração de risco residual da BPA após o primeiro ano. Rubrica: 3 = lista os caminhos não protegidos, com datas e responsáveis.
- EX076 — Independência. Projete uma amostra de validação independente para o TLS de borda. Rubrica: 3 = ponto de observação, tamanho da amostra, comparação com as métricas internas.
Síntese
A validação confirma que o sistema migrado atende às suas partes interessadas e declara o risco residual com honestidade, idealmente verificado por uma equipe independente.
Continue estudando — capítulo 38 de 50
← Capítulo 37 · Índice de capítulos do curso · Capítulo 39 →
Siga para a próxima lição escrita.