Capítulo 45 — Revisão independente de projeto
Mapa da aula
Aula 45 publicada. Mapa, exemplo, EX089.
flowchart TD
N0["45.1 Método de revisão"]
N1["45.2 Lista de verificação da revisão de PQC"]
N2["45.3 Severidade"]
N3["Nota de engenharia"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX089"]
Desenho lógico
flowchart LR
N0["45.1 Método de revisão"]
N1["45.2 Lista de verificação da revisão de PQC"]
N2["45.3 Severidade"]
N3["Nota de engenharia"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX089"]
[45.1 Método de revisão]
|
v
[45.2 Lista de verificação da revisão de PQC]
|
v
[45.3 Severidade]
|
v
[Nota de engenharia]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX089]
Objetivos de aprendizagem
Você vai (1) conduzir e receber uma revisão independente de projeto; (2) usar uma lista de verificação estruturada para projetos de PQC; (3) classificar as constatações por severidade; e (4) responder com mudanças ou com uma aceitação justificada. O capítulo examina o Projeto Final I antes do Projeto Final II.
45.1 Método de revisão
Revisores independentes da equipe de projeto leem os requisitos, a arquitetura, a análise de ameaças e as evidências e depois entrevistam a equipe. As constatações são escritas, classificadas (crítica, maior, menor, observação) e respondidas.
Independência significa que os revisores não participaram do projeto e não se reportam ao seu líder. As entrevistas testam se a equipe entende os próprios documentos; um projeto que só um membro consegue explicar já é um risco em si. Cada constatação recebe uma resposta escrita: uma mudança ou uma aceitação fundamentada do risco, com um responsável. As constatações e as respostas, juntas, fazem parte do dossiê de evidências.
45.2 Lista de verificação da revisão de PQC
- Todos os usos de chave pública estão inventariados, com os desconhecidos relatados?
- Os algoritmos e os conjuntos de parâmetros vêm das normas atuais (FIPS 203/204/205, SP 800-208), e as implementações da era dos rascunhos estão excluídas?
- Os combinadores híbridos são padronizados e vinculados ao contexto?
- A negociação é autenticada, e o fallback é registrado e datado?
- As chaves de assinatura com estado estão protegidas contra a reutilização?
- As âncoras de confiança de vida longa têm diversidade de algoritmos?
- A agilidade é demonstrada (tempo de substituição), e não apenas alegada?
- Os riscos de disponibilidade (tamanho, middleboxes, dispositivos) são testados?
- Os riscos residuais são declarados com honestidade?
Cada pergunta corresponde a um capítulo anterior, então uma constatação pode apontar o método que foi pulado.
45.3 Severidade
Crítica: uma falha de projeto que derrota o objetivo de segurança (por exemplo, um combinador XOR sem vínculo, chaves com estado em software com backups). Maior: lacuna significativa (sem monitoramento do fallback). Menor: documentação ou clareza. Observações: sugestões.
A severidade orienta o que precisa ser corrigido antes de prosseguir: as constatações críticas bloqueiam o estágio seguinte, as maiores precisam de um plano com datas, as menores são corrigidas no curso normal. Definições claras mantêm os revisores coerentes, de modo que dois revisores que avaliam o mesmo problema cheguem ao mesmo nível. Uma constatação classificada como crítica precisa explicar como ela derrota o objetivo, o que impede que o rótulo seja usado apenas para dar ênfase.
45.4 Exemplo resolvido
Revisão do Projeto Final I modelo: uma constatação maior — as exportações para a aduana usariam apenas ML-KEM, sem componente tradicional e sem evidências de interoperabilidade da agência; resposta: acrescentar um destinatário RSA-OAEP paralelo durante a transição e agendar o teste da agência. Uma menor — fonte de evidência do CBOM ausente em 40 registros; corrigida.
A constatação das exportações é maior, e não crítica, porque o ML-KEM sozinho não é inseguro, mas confiar nele sem um componente tradicional e sem os testes da agência arrisca tanto uma surpresa criptoanalítica quanto uma exportação ilegível. A resposta restaura a abordagem híbrida usada nos outros lugares e acrescenta um teste datado.
45.5 Erros comuns e limites
- Revisões feitas pela própria equipe de projeto.
- Constatações sem severidade ou sem resposta.
- Respostas defensivas em vez de mudanças ou de aceitação fundamentada.
Uma equipe de projeto que revisa a si mesma compartilha os próprios pontos cegos, por isso revisores independentes são exigidos. Constatações sem severidade não podem ser priorizadas, e constatações sem resposta tendem a ser esquecidas. As respostas defensivas desperdiçam a revisão: ou se muda o projeto, ou se aceita o risco com motivos declarados e um responsável, como mostrou a constatação das exportações, com o seu teste datado da agência e o responsável nomeado.
Nota de engenharia
Os revisores também devem confrontar o que a equipe de projeto mediu com o que ela alegou. Amostre três métricas do painel da equipe e recalcule-as a partir das evidências brutas; as divergências revelam desvios de definição ou bugs no pipeline. Uma revisão que só lê documentos pode deixar escapar que a métrica "negociada" é, na verdade, calculada a partir dos grupos oferecidos — exatamente o tipo de erro que faz um programa parecer mais adiantado do que está.
Exercícios
- EX089 — Revisão. Revise o projeto de um colega (ou o modelo) com a lista de verificação e escreva três constatações com severidade. Rubrica: 3 = específicas, acionáveis, corretamente classificadas.
- EX090 — Resposta. Escreva uma resposta a uma constatação maior aceitando o risco, com justificativa. Rubrica: 3 = responsável pelo risco, justificativa, data de revisão.
Síntese
Uma revisão independente com uma lista de verificação específica de PQC e uma classificação de severidade detecta as falhas de projeto antes que se tornem implantações.
Continue estudando — capítulo 45 de 50
← Capítulo 44 · Índice de capítulos do curso · Capítulo 46 →
Siga para a próxima lição escrita.