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
- Projetos que ignoram a população de clientes antigos.
- Nenhum plano de medição dos grupos negociados.
- Afirmar que o portal é "seguro contra a computação quântica" enquanto os certificados são clássicos.
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
- EX049 — Entregável do ateliê. Produza o diagrama de contexto (com alternativa em texto) e o estudo de compromisso para o enunciado. Rubrica: 3 = duas alternativas reais, pesos antes das notas.
- EX050 — Resposta à crítica. Responda em 150 palavras à pergunta da banca de segurança sobre o fallback. Rubrica: 3 = proteção da transcrição no TLS 1.3 e risco das novas tentativas da aplicação, ambos tratados.
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.