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

Capítulo 16 — Engenharia de sistemas

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 16 — Engenharia de sistemas

Mapa da aula

Aula 16 publicada. Mapa, exemplo, EX031.

flowchart TD
  N0["16.1 Visão de ciclo de vida"]
  N1["16.2 Interfaces e dependências"]
  N2["16.3 Estudos de compromisso"]
  N3["16.4 Planejamento de V&V"]
  N4["Nota de engenharia"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX031"]

Desenho lógico

flowchart LR
  N0["16.1 Visão de ciclo de vida"]
  N1["16.2 Interfaces e dependências"]
  N2["16.3 Estudos de compromisso"]
  N3["16.4 Planejamento de V&V"]
  N4["Nota de engenharia"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX031"]
[16.1 Visão de ciclo de vida]
    |
    v
[16.2 Interfaces e dependências]
    |
    v
[16.3 Estudos de compromisso]
    |
    v
[16.4 Planejamento de V&V]
    |
    v
[Nota de engenharia]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX031]

Objetivos de aprendizagem

Você vai (1) aplicar um ciclo de vida de sistemas a uma migração de vários anos; (2) gerenciar interfaces e dependências entre organizações; (3) usar estudos de compromisso (trade studies); e (4) planejar a verificação e a validação desde o início. O capítulo parte do Capítulo 14 e prepara os requisitos (Capítulo 21).

16.1 Visão de ciclo de vida

Uma migração de todo o porto abrange concepção (por quê e o quê), requisitos, arquitetura, implementação, integração, verificação, validação, operação e desativação. Normas de ciclo de vida como a ISO/IEC/IEEE 15288 descrevem esses processos. A migração criptográfica difere da maioria das mudanças de sistema porque toca todas as interfaces ao mesmo tempo e porque parceiros de fora da organização precisam mudar no mesmo passo.

Para a BPA, a desativação é uma fase real: as chaves e os certificados RSA precisam ser retirados e os algoritmos antigos desativados assim que todos os parceiros tiverem migrado; caso contrário, os caminhos de rebaixamento ficam abertos indefinidamente. Planejar a desativação desde o início, com uma data-alvo por interface, impede que o programa termine com os algoritmos antigos e novos ativados permanentemente.

16.2 Interfaces e dependências

A BPA depende das companhias de navegação (pares de VPN), da agência aduaneira (formatos de exportação), dos fornecedores (equipamentos, HSMs, firmware dos guindastes) e dos fabricantes de navegadores (clientes TLS). Um documento de controle de interfaces lista, por interface, os algoritmos atuais, o alvo, quem precisa mudar e até quando. As dependências explicam os cronogramas melhor do que as estimativas de esforço.

Para a exportação aduaneira, o documento de controle registra RSA-OAEP hoje, CMS com ML-KEM-768 como alvo, a agência aduaneira como a parte que precisa mudar primeiro e uma data combinada numa carta conjunta. Uma dependência como essa define o cronograma, independentemente de quão depressa os desenvolvedores da própria BPA terminem a sua parte.

16.3 Estudos de compromisso

Um estudo de compromisso compara opções segundo critérios ponderados. Para a VPN da BPA: (a) IKEv2 híbrido com ML-KEM agora, (b) esperar pelo suporte nativo do fornecedor, (c) acrescentar uma camada de chave pré-compartilhada como mitigação provisória. Critérios: ganho de segurança, risco de disponibilidade, custo, prontidão dos parceiros, conformidade com as normas. Os pesos vêm dos requisitos, não de preferências.

Fixar os pesos antes da pontuação impede que uma equipe os ajuste para favorecer a opção que já prefere. A equipe da BPA publica os pesos na revisão de requisitos, pontua cada opção de forma independente e depois verifica se uma mudança moderada em algum peso mudaria a vencedora. Se mudar, o resultado é registrado como apertado, e a decisão cita explicitamente o fator decisivo.

16.4 Planejamento de V&V

A verificação pergunta "construímos certo?" (requisitos atendidos); a validação pergunta "construímos a coisa certa?" (necessidades das partes interessadas atendidas). Planeje as duas antes da implementação: por exemplo, verificar que a VPN negocia ML-KEM-768 ou mais forte em todos os túneis e validar que as operações das companhias de navegação continuam sem atraso.

A verificação, aqui, é uma consulta de logs: o algoritmo negociado de cada túnel é registrado, e qualquer túnel sem ML-KEM-768 ou mais forte reprova na verificação. A validação precisa da equipe de operações das companhias de navegação, que confirma que os tempos de troca de documentos e de estabelecimento das conexões não mudaram depois da virada. Escrever as duas verificações antes da implementação garante que o registro necessário para a verificação seja construído desde o início.

16.5 Exemplo resolvido

O estudo de compromisso dá à opção (a) a maior nota em segurança e normas, à (b) a maior em disponibilidade e à (c) o papel de solução provisória barata. Decisão: (c) imediatamente para os dois parceiros de maior valor, (a) num piloto com um parceiro, (b) para os demais quando os fornecedores entregarem — documentado com datas de revisão.

Cada opção tem uma data de revisão para que a decisão não congele: o piloto é revisto após três meses para decidir se (a) pode se estender a mais parceiros, e as chaves pré-compartilhadas provisórias são rotacionadas e verificadas ao mesmo tempo. Anotar essas datas transforma um meio-termo num plano que avança.

16.6 Erros comuns e limites

Os parceiros são donos de metade de cada interface externa, então um plano só com tarefas internas vai travar na primeira VPN ou no primeiro formato de exportação. Pesos escolhidos depois da pontuação fazem do estudo de compromisso um argumento a favor de uma decisão já tomada. A V&V inventada depois da implantação costuma não ter os logs necessários para verificar qualquer coisa, como mostrou a verificação do algoritmo dos túneis.

Nota de engenharia

A engenharia de sistemas também pergunta quando parar. Uma migração tem um critério de saída por interface — por exemplo, "negociação só clássica abaixo de 0,5% dos túneis por 90 dias e confirmação do parceiro recebida" —, após o qual o caminho antigo é removido, em vez de ficar como alternativa permanente. Sem critérios de saída, as configurações de transição se tornam permanentes, e a organização carrega tanto o risco antigo quanto a nova complexidade. Registre os critérios de saída no documento de controle de interfaces, para que as revisões de progresso possam encerrar os pacotes de trabalho de forma objetiva.

Exercícios

Síntese

A migração é um problema de sistemas dominado por interfaces e parceiros; estudos de compromisso com pesos prévios e um planejamento precoce de V&V mantêm as decisões defensáveis.

Continue estudando — capítulo 16 de 50

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

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