OpenCyber Academy
Engenharia · Capítulo 50 · Português
Código do curso: OCA-123Capítulo 50: OCA-123-C050

Capítulo 50 — Defesa final

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

Mapa da aula

Aula 50 publicada. Mapa, exemplo, EX148.

flowchart TD
  N0["50.1 Preparar a defesa"]
  N1["50.2 Responder a perguntas sobre trade-offs"]
  N2["50.3 Responsabilidade contínua"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX148"]

Desenho lógico

flowchart LR
  N0["50.1 Preparar a defesa"]
  N1["50.2 Responder a perguntas sobre trade-offs"]
  N2["50.3 Responsabilidade contínua"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX148"]
[50.1 Preparar a defesa]
    |
    v
[50.2 Responder a perguntas sobre trade-offs]
    |
    v
[50.3 Responsabilidade contínua]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX148]

Objetivos de aprendizagem

Você vai (1) defender as decisões de projeto diante de uma banca examinadora; (2) responder a perguntas sobre trade-offs de segurança; (3) refletir sobre a responsabilidade contínua da engenheira.

50.1 Preparar a defesa

Aiyana prepara uma apresentação de vinte minutos: o problema, as principais escolhas de projeto, as evidências e os limites. Ela antecipa as perguntas: por que chaves simétricas para as leituras, por que três de cinco custodiantes, por que assinaturas pós-quânticas híbridas e o que acontece se o serviço de chaves for comprometido. Para cada uma, prepara uma resposta concisa que aponta para as evidências na tese ou no dossiê. Marcus e seu orientador fazem uma defesa simulada, pressionando-a sobre premissas de custo que ela não tinha justificado plenamente, e ela as reforça. Ela ensaia as respostas em voz alta até que cada uma caiba em menos de dois minutos.

50.2 Responder a perguntas sobre trade-offs

Durante a defesa, um examinador pergunta por que a Ridgeway não usou assinaturas de chave pública nas leituras para eliminar o risco central das chaves. Aiyana explica o orçamento de 32 bytes por mensagem e as restrições de energia, as mitigações do risco central (HSMs, derivação por medidor, monitoramento e controle duplo) e a condição sob a qual ela reverteria a decisão. Outro examinador pergunta se o código dos laboratórios poderia ser usado em produção; ela responde com firmeza que não, porque ele existe para verificar a compreensão contra vetores de teste, enquanto a produção depende de bibliotecas avaliadas.

50.3 Responsabilidade contínua

Ao concluir, Aiyana reflete que o serviço de confiança vai durar mais do que o envolvimento dela. Algoritmos ficarão obsoletos, a computação quântica pode amadurecer, a equipe vai mudar e as ameaças vão evoluir. Sua responsabilidade como engenheira é deixar um sistema que outras pessoas consigam entender, operar, testar e mudar com segurança, com documentação, runbooks, métricas e uma trilha de evidências. A banca aprova sua tese, destacando a clareza dos seus limites. Ela começa a trabalhar na Ridgeway como engenheira de segurança no mês seguinte. Ela agenda sua própria primeira revisão do sistema para dali a um ano.

Exemplo resolvido

Aiyana defende o projeto simétrico das leituras, o quórum de custodiantes e a migração híbrida, recusa-se a chamar o código dos laboratórios de pronto para produção e enquadra sua responsabilidade como deixar um sistema manutenível.

Caso sintético. A defesa e o resultado são inventados.

Erros e limites

Defender todas as decisões como perfeitas mina a credibilidade; reconheça os trade-offs. A responsabilidade da engenharia continua depois da passagem.

Exercícios

Síntese

Uma defesa demonstra domínio ao explicar os compromissos com honestidade, e a responsabilidade de engenharia continua por toda a vida do sistema.

Respostas comentadas

EX148. Suas premissas de custo não tinham sido justificadas adequadamente.

EX149. Módulos de segurança de hardware, derivação de chaves por medidor, monitoramento e controle duplo.

EX150. Deixar um sistema que outras pessoas consigam entender, operar, testar e mudar com segurança, apoiado em documentação, runbooks, métricas e evidências.