◇ OpenCyber Academy
Engenharia · Capítulo 14 · Português

Capítulo 14 — Engenharia de software

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 14 — Engenharia de software

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX027.

flowchart TD
  N0["14.1 Ciclo de vida"]
  N1["14.2 Revisão"]
  N2["14.3 SBOM e CBOM"]
  N3["14.4 Versões escalonadas"]
  N4["Nota de engenharia"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX027"]

Desenho lógico

flowchart LR
  N0["14.1 Ciclo de vida"]
  N1["14.2 Revisão"]
  N2["14.3 SBOM e CBOM"]
  N3["14.4 Versões escalonadas"]
  N4["Nota de engenharia"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX027"]
[14.1 Ciclo de vida]
    |
    v
[14.2 Revisão]
    |
    v
[14.3 SBOM e CBOM]
    |
    v
[14.4 Versões escalonadas]
    |
    v
[Nota de engenharia]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX027]

Objetivos de aprendizagem

Você vai (1) gerenciar requisitos, projeto, implementação e testes num projeto de migração; (2) usar controle de versão e revisão de código para mudanças criptográficas; (3) montar uma lista de materiais de software (SBOM) e uma lista de materiais criptográficos (CBOM); e (4) planejar versões escalonadas. O capítulo parte dos Capítulos 4 e 9 e prepara a implementação (Capítulo 28).

14.1 Ciclo de vida

Uma migração é um projeto de software: requisitos (quais funções precisam se tornar resistentes à computação quântica, e até quando), projeto (híbrido ou PQC pura, quais bibliotecas), implementação, testes, versão escalonada e manutenção. As mudanças criptográficas têm alto impacto e baixa visibilidade: se estiverem erradas, falham em silêncio ou de forma catastrófica.

A falha silenciosa é a mais perigosa das duas: um serviço que volta discretamente à troca de chaves clássica parece saudável enquanto a gravação continua a expor o seu tráfego. Por isso, os requisitos da BPA declaram resultados mensuráveis, como o grupo negociado registrado por sessão, para que os testes possam mostrar que a mudança realmente fez efeito.

14.2 Revisão

Toda mudança criptográfica passa pela revisão de alguém com conhecimento de criptografia, além de testes de interoperabilidade. As listas de verificação perguntam: os identificadores de algoritmo vêm da política? Os comprimentos são validados? As comparações são em tempo constante? A versão da biblioteca está fixada e tem suporte?

A BPA mantém um pequeno grupo de revisores que concluíram o treinamento em criptografia, e toda mudança que toca as interfaces Signer ou KEM exige um deles. A lista de verificação fica guardada com o código, e cada item corresponde, quando possível, a um teste automatizado, por exemplo, um teste que falha quando um comprimento de chave é aceito sem validação. Os revisores então dedicam o seu tempo às questões de projeto que os testes não conseguem responder.

14.3 SBOM e CBOM

Um SBOM lista componentes e versões. Um CBOM estende isso aos ativos criptográficos: algoritmos, conjuntos de parâmetros, comprimentos de chave, protocolos, certificados e onde as chaves ficam. Formatos como o CycloneDX suportam campos de CBOM. Um CBOM é a base para responder "onde usamos RSA?" em minutos, e não em meses.

A BPA gera o CBOM no pipeline de build, então cada versão leva um inventário atualizado. Uma consulta por RSA em todos os CBOMs, filtrada para chaves com tempo de vida acima de dez anos, produziu os primeiros itens de trabalho da migração de assinaturas.

14.4 Versões escalonadas

Use feature flags para as escolhas de algoritmo, implantações canário com taxas de falha medidas (Capítulo 37) e planos de reversão. Mantenha disponíveis os algoritmos antigos e os novos durante a transição.

Uma flag permite à equipe desligar o grupo híbrido para um caminho em minutos, como no caso do portal da companhia de navegação, sem reimplantar código. O tamanho do passo do canário começa pequeno, como 1% do tráfego, e só cresce depois que o limite de falhas dado pela regra de três cai abaixo do orçamento combinado. Os dados de cada passo são guardados, para que um incidente posterior possa ser comparado com a linha de base da implantação.

14.5 Exemplo resolvido

A equipe do portal da BPA acrescenta o TLS híbrido atrás de uma flag, executa testes de interoperabilidade contra os 50 principais clientes dos parceiros, implanta em 1% do tráfego, monitora as falhas e promove em passos. O CBOM é atualizado automaticamente a partir dos metadados do build, para que o inventário fique em dia.

Escolher os 50 principais clientes dos parceiros cobre a maior parte do tráfego do portal, de modo que uma falha ali apareceria depressa no canário. Cada passo de promoção exige um número mínimo de conexões sem falha, que a equipe calcula antes da implantação. A atualização automática do CBOM permitiu que o escritório de segurança relatasse a mudança ao conselho na mesma semana em que ela atingiu todo o tráfego.

14.6 Erros comuns e limites

Incorporações sem revisão já levaram código Kyber da época dos rascunhos para a produção em outras organizações; a regra da BPA de que mudanças nas interfaces exigem um revisor treinado impede isso. CBOMs feitos à mão ficam desatualizados em um ciclo de versão, então o build os gera. Versões "big bang" eliminam a chance de detectar as falhas de middlebox que os canários encontram com 1% do tráfego e tornam a reversão uma escolha de tudo ou nada.

Nota de engenharia

Trate o CBOM como um artefato vivo, de propriedade de uma equipe nomeada, gerado a partir dos pipelines de build, da gestão de configuração e da telemetria, e não de planilhas. Cada versão deve comparar o seu CBOM com o anterior: uma nova dependência de RSA introduzida por uma atualização de biblioteca é uma regressão a detectar na revisão, exatamente como um teste que falha. As equipes que ligam essa comparação à integração contínua descobrem acréscimos vulneráveis à computação quântica em dias, e não na próxima auditoria anual, e ainda ganham uma lista precisa para questionários de fornecedores e reguladores.

Exercícios

Síntese

Trate a migração como engenharia de software: mudanças revisadas, flags, canários, reversão e um CBOM mantido automaticamente.

Continue estudando — capítulo 14 de 50

← Capítulo 13 · Índice de capítulos do curso · Capítulo 15 →

Siga para a próxima lição escrita.