OpenCyber Academy
Engenharia · Capítulo 25 · Português
Código do curso: OCA-136Capítulo 25: OCA-136-C025

Capítulo 25 — Ateliê de projeto I

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 25 publicada. Mapa, exemplo, EX049.

flowchart TD
  N0["25.1 Enunciado"]
  N1["25.2 Método do ateliê"]
  N2["25.3 Esboço da solução de referência"]
  N3["25.4 Exemplos de crítica"]
  N4["Nota de engenharia"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX049"]

Desenho lógico

flowchart LR
  N0["25.1 Enunciado"]
  N1["25.2 Método do ateliê"]
  N2["25.3 Esboço da solução de referência"]
  N3["25.4 Exemplos de crítica"]
  N4["Nota de engenharia"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX049"]
[25.1 Enunciado]
    |
    v
[25.2 Método do ateliê]
    |
    v
[25.3 Esboço da solução de referência]
    |
    v
[25.4 Exemplos de crítica]
    |
    v
[Nota de engenharia]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX049]

Objetivos de aprendizagem

Você vai (1) conduzir um ateliê de projeto estruturado sobre um problema com forma real; (2) produzir um projeto de troca de chaves híbrida para a borda da BPA; (3) apresentá-lo e defendê-lo com evidências; e (4) incorporar as críticas. O capítulo integra os Capítulos 20–24.

25.1 Enunciado

Projete o estabelecimento de chaves resistente à computação quântica para o portal público da BPA e a borda das APIs de parceiros: 2 milhões de conexões por dia, uma população mista de clientes (navegadores, software dos parceiros, scanners portáteis antigos), um proxy de inspeção num dos caminhos e uma CDN à frente do portal. Restrições: nenhuma regressão de disponibilidade além do requisito do Capítulo 21, orçamento para a atualização de um único equipamento, prazo de seis meses.

As restrições puxam em direções diferentes. Dois milhões de conexões diárias significam que até taxas de falha pequenas produzem muitos incidentes; os scanners antigos talvez nunca suportem grupos híbridos; o orçamento de um único equipamento não substitui todos os dispositivos. Bons projetos dizem explicitamente qual restrição relaxam e por quê.

25.2 Método do ateliê

As equipes produzem: diagrama de contexto; subconjunto de requisitos; duas alternativas; estudo de compromisso; projeto escolhido com esboço de configuração; plano de testes; riscos. Cada equipe apresenta por dez minutos e recebe as críticas de uma banca que representa operações, segurança, parceiros e finanças.

Apresentar duas alternativas obriga as equipes a justificar a escolha, em vez de defender a primeira ideia. Os papéis da banca refletem os revisores reais que a BPA enfrentaria: operações pergunta sobre monitoramento, finanças sobre custo, parceiros sobre compatibilidade. As equipes que preparam evidências para cada papel, como um plano de testes mostrando que o firmware do proxy foi verificado, costumam lidar melhor com as críticas do que as que se apoiam em argumentos gerais. As críticas são registradas para que as equipes possam revisar o projeto depois.

25.3 Esboço da solução de referência

Terminar o TLS na CDN e no proxy de borda com o X25519MLKEM768 oferecido primeiro e o X25519 como alternativa para clientes que não suportam o grupo híbrido (RFC 10024); atualizar o firmware do proxy de inspeção ou desviar a inspeção do TLS 1.3 para as APIs de parceiros; deixar os scanners portáteis em grupos clássicos, sob uma exceção de curto prazo com data de substituição; medir os grupos negociados pelos logs; implantação escalonada com portões de canário. Nota: a troca de chaves híbrida protege contra a gravação; os certificados continuam clássicos por enquanto — documentado como lacuna conhecida, com um pacote de trabalho posterior.

25.4 Exemplos de crítica

Operações pergunta como o fallback é monitorado; segurança pergunta se o fallback poderia ser forçado (no TLS 1.3, só quebrando a autenticação ou explorando a lógica de novas tentativas no nível da aplicação, que precisa ser verificada); parceiros perguntam sobre as versões das bibliotecas dos seus clientes; finanças pergunta sobre os custos dos equipamentos. Boas equipes respondem com evidências ou acrescentam itens de trabalho.

A pergunta de segurança é a mais sutil: se uma aplicação repete todo handshake malsucedido sem o grupo híbrido, um atacante pode forçar falhas e obter conexões clássicas. Uma boa resposta verifica a lógica de novas tentativas do portal e registra qualquer fallback.

25.5 Erros comuns e limites

Os scanners portáteis não podem ser ignorados: precisam de uma exceção com data de substituição, como mostra o esboço de referência. Sem medir os grupos negociados, ninguém sabe se a implantação funcionou. Chamar o portal de "seguro contra a computação quântica" enquanto os certificados continuam clássicos engana as partes interessadas, já que ataques ativos com um futuro CRQC ainda seriam possíveis; em vez disso, o esboço documenta essa lacuna, com um pacote de trabalho posterior.

Nota de engenharia

Os ateliês também treinam o hábito de anotar o que o projeto não faz. A solução de referência protege as trocas de chaves gravadas, mas não a autenticação, não cobre os scanners portáteis até a substituição e depende do firmware do fornecedor para o proxy de inspeção. Listar isso explicitamente no registro do projeto transforma esses pontos em pacotes de trabalho acompanhados, com responsáveis, em vez de descobertas feitas por um auditor. Um projeto que declara as suas lacunas é mais fácil de aprovar do que um que parece completo, mas não é.

Exercícios

Síntese

Um ateliê de projeto transforma normas num projeto configurado, medido e escalonado, cujas lacunas estão declaradas e cujos críticos foram respondidos.

Respostas comentadas

EX049. Diagrama de clientes, CDN, proxy de borda, proxy de inspeção e APIs, com alternativa em texto; alternativas (híbrido agora vs. esperar suporte nativo do fornecedor); pesos fixados antes da pontuação.

EX050. O TLS 1.3 assina a transcrição do handshake, então a remoção dos grupos híbridos é detectada, a menos que a autenticação seja quebrada; o risco residual é uma lógica de novas tentativas na aplicação que recorre ao fallback após qualquer erro — registrada, restrita a erros de incompatibilidade conhecidos e com data de remoção.