Capítulo 29 — Construção do projeto final
Mapa da aula
Aula 29 publicada. Mapa, exemplo, EX057.
flowchart TD
N0["29.1 Escopo"]
N1["29.2 Ordem de construção"]
N2["29.3 Reprodutibilidade"]
N3["29.4 Registros de decisão"]
N4["29.5 Caso resolvido"]
N5["29.6 Atividade prática"]
N6["29.7 Segurança da construção"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX057"]
Desenho lógico
flowchart LR
N0["29.1 Escopo"]
N1["29.2 Ordem de construção"]
N2["29.3 Reprodutibilidade"]
N3["29.4 Registros de decisão"]
N4["29.5 Caso resolvido"]
N5["29.6 Atividade prática"]
N6["29.7 Segurança da construção"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX057"]
[29.1 Escopo]
|
v
[29.2 Ordem de construção]
|
v
[29.3 Reprodutibilidade]
|
v
[29.4 Registros de decisão]
|
v
[29.5 Caso resolvido]
|
v
[29.6 Atividade prática]
|
v
[29.7 Segurança da construção]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX057]
Objetivos de aprendizagem
Você vai (1) construir em laboratório uma fatia migrada completa de um serviço; (2) integrar inventário, configuração, automação, monitoramento e runbooks; (3) manter tudo reproduzível; e (4) documentar as decisões.
29.1 Escopo
Escolha um fluxo do tipo da KLS, de ponta a ponta, com pelo menos três saltos. Entregue: a infraestrutura do laboratório como código; as entradas do inventário e o rastreamento; o perfil criptográfico central aplicado em cada salto; o gate de CI; o registro das negociações e o painel; os runbooks; o registro de exceções e de riscos residuais; os dados da avaliação.
Três saltos é o mínimo porque o projeto final precisa mostrar que cada terminação está configurada e evidenciada, e não só uma. Todas as entregas ficam num único repositório, e os avaliadores julgam a fatia como um todo: um perfil perfeito sem monitoramento está incompleto.
29.2 Ordem de construção
Infraestrutura do laboratório → inventário e rastreamento → perfil → gate de automação → monitoramento → runbooks → avaliação. Faça um commit a cada etapa, com um registro de decisão curto.
A ordem segue as dependências: nada pode ser inventariado antes que o laboratório exista, o perfil precisa do inventário para saber onde se aplica, o gate precisa do perfil para verificar contra ele, e o monitoramento precisa de um perfil em execução para observar. Os runbooks precisam do monitoramento para nomear os sintomas, e a avaliação precisa de tudo isso. Cada etapa termina com um commit e um registro de decisão curto, para que o histórico do repositório conte a história da construção. As equipes que começam pelo painel costumam reconstruí-lo depois.
29.3 Reprodutibilidade
Qualquer pessoa deve conseguir clonar o repositório, executar um comando para construir o laboratório e reproduzir os números do painel a partir das execuções registradas. Fixe as versões; fixe as sementes aleatórias dos dados sintéticos.
O teste é literal: um avaliador executa o comando de construção numa máquina limpa. Fixe as versões dos pacotes e das imagens pelo digest, mantenha as chaves do laboratório geradas no momento da construção e guarde os logs de sessão registrados, para que o painel possa ser reconstruído a partir deles. Uma semente aleatória fixada no gerador de dados sintéticos torna os números idênticos a cada reconstrução, e é isso que permite a um avaliador compará-los com o relatório.
29.4 Registros de decisão
Registre decisões como "híbrido com ML-KEM-768 em vez de ML-KEM-1024 porque a política exige a categoria 3 e o grupo da RFC 10024 usa o -768" ou "certificados clássicos mantidos porque a biblioteca X de uma parte confiante não tem o ML-DSA".
Um registro de decisão tem o contexto, as opções consideradas, a decisão e as suas consequências, e é datado. Os exemplos no estilo da KLS também incluem a evidência por trás da decisão, como o registro de laboratório que mostra uma parte confiante falhando na validação ML-DSA, e a condição que a reabriria. Os registros são curtos; o seu valor é que uma equipe posterior possa ver por que algo é como é.
29.5 Caso resolvido
Projeto final (sintético): SFTP dos parceiros através de um bastion e de um processador interno de arquivos. Construção: scripts de laboratório no estilo Terraform, OpenSSH com a KEX híbrida em primeiro lugar, um script de auditoria no CI que verifica o KexAlgorithms, um analisador de logs alimentando um painel da fração de KEX, runbooks para no_shared_group e para o recuo, uma exceção para um cliente de parceiro legado emulado. Dados de avaliação de 3.000 sessões em seis tipos de cliente.
Os seis tipos de cliente correspondem à matriz de parceiros do ateliê, então a avaliação reaproveita os seus resultados conhecidos. A exceção do cliente legado mostra na prática o registro de exceção completo, e as 3.000 sessões bastam para dar um limite superior significativo para as falhas.
29.6 Atividade prática
Crie o repositório do seu projeto final com a ordem de construção como marcos.
Crie um marco por etapa da ordem de construção, com o artefato que o fecha: script de construção do laboratório, arquivos de inventário e de rastreamento, perfil, gate de CI, registro de logs e painel, runbooks e dados da avaliação. Acrescente um README que declare o fluxo, os saltos e como construir. Abra uma issue para cada desconhecido conhecido, como um tipo de cliente que você não consegue emular, para que ele seja acompanhado desde o início, em vez de descoberto na avaliação.
Para a fatia do SFTP, o marco do perfil tem links para o registro que escolheu o grupo híbrido e para o registro que lista quais clientes de parceiros continuam clássicos, para que um examinador possa ver por que o gate os permite.
29.7 Segurança da construção
Trate o repositório do projeto final como de nível de produção: nenhum segredo real commitado, chaves de laboratório geradas no momento da construção, acesso limitado à equipe e aos avaliadores, e versões das dependências fixadas. Inclua uma nota de ameaças curta para o próprio laboratório — o que um atacante poderia fazer com o repositório e como você o impediu. Os avaliadores vão procurar isso, e é um hábito que vale a pena manter.
Os avaliadores da KLS verificam o histórico em busca de chaves commitadas com um scanner de segredos.
Eles também confirmam que as chaves do laboratório são regeneradas a cada construção, para que uma chave vazada de um clone antigo seja inútil.
29.8 Erros comuns e limites
- Construir sem infraestrutura como código.
- Pular o gate de CI.
- Decisões não documentadas.
Um projeto final construído à mão numa máquina de laboratório não pode ser reconstruído pelo avaliador, então os seus números não podem ser verificados. Um projeto final sem o gate de CI torna impossível a etapa "o gate bloqueia uma mudança ruim" da demonstração e perde o critério de automação. E as decisões não documentadas, como por que as chaves de host continuaram clássicas, se transformam em perguntas do examinador que o estudante não consegue responder com evidências. Esses três respondem pela maior parte das notas perdidas.
Exercícios
- EX057 — Registro de decisão. Escreva um registro de decisão para manter as chaves de host clássicas no projeto final do SFTP. Rubrica: 3 = contexto, opções, decisão, consequências.
- EX058 — Teste de reprodutibilidade. Descreva como um avaliador verifica os números do seu painel. Rubrica: 3 = clonar, construir, reproduzir os logs, comparar.
Síntese
A construção do projeto final integra todas as habilidades de implementação numa fatia de laboratório única, reproduzível, documentada e segura, pronta para a avaliação.
Continue estudando — capítulo 29 de 30
← Capítulo 28 · Índice de capítulos do curso · Capítulo 30 →
Siga para a próxima lição escrita.