Capítulo 30 — Avaliação do projeto final | Tecnólogo Segurança quântica e pós-quântica

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 30 — Avaliação do projeto final

Mapa da aula

Aula 30 publicada. Mapa, exemplo, EX059.

flowchart TD
  N0["30.1 Critérios"]
  N1["30.2 Demonstração ao vivo"]
  N2["30.3 Perguntas"]
  N3["30.4 Entrega"]
  N4["30.5 Caso resolvido"]
  N5["30.6 Atividade prática"]
  N6["30.7 Autoavaliação"]
  N7["30.9 Depois da avaliação"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX059"]

Desenho lógico

flowchart LR
  N0["30.1 Critérios"]
  N1["30.2 Demonstração ao vivo"]
  N2["30.3 Perguntas"]
  N3["30.4 Entrega"]
  N4["30.5 Caso resolvido"]
  N5["30.6 Atividade prática"]
  N6["30.7 Autoavaliação"]
  N7["30.9 Depois da avaliação"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX059"]

[30.1 Critérios]
    |
    v
[30.2 Demonstração ao vivo]
    |
    v
[30.3 Perguntas]
    |
    v
[30.4 Entrega]
    |
    v
[30.5 Caso resolvido]
    |
    v
[30.6 Atividade prática]
    |
    v
[30.7 Autoavaliação]
    |
    v
[30.9 Depois da avaliação]
    |
    v
[Exemplo resolvido] --> [Exercício EX059]

Objetivos de aprendizagem

Você vai (1) avaliar o seu projeto final em relação aos critérios; (2) demonstrá-lo ao vivo; (3) responder a perguntas técnicas; e (4) entregar os artefatos para reutilização.

30.1 Critérios

Critérios de avaliação: completude da fatia; correção da configuração (híbrido preferido, recuo controlado); qualidade da automação e do monitoramento; runbooks exercitados; reprodutibilidade; risco residual e exceções documentados; clareza das decisões e da avaliação.

Cada critério corresponde a uma evidência no repositório: a correção da configuração, ao perfil renderizado e aos logs; a automação, ao gate e ao seu teste; o monitoramento, ao painel reconstruído a partir dos logs registrados; os runbooks, ao registro do exercício de mesa. Os examinadores pontuam cada um de 0 a 3, na mesma escala dos exercícios, para que um candidato possa prever o resultado a partir das evidências.

30.2 Demonstração ao vivo

Demonstre: construir o laboratório; mostrar a negociação da KEX híbrida; provocar um recuo revertendo a configuração e mostrar o alerta; seguir o runbook para recuperar; mostrar o gate de CI bloqueando uma mudança ruim.

Cada etapa tem um tempo e um resultado observável: o laboratório é construído sem etapas manuais; os logs mostram o algoritmo híbrido; uma reversão da configuração dispara o alerta de recuo; o runbook restaura o perfil e o alerta se encerra; um pull request com uma lista reordenada reprova no gate. Ensaie as etapas de falha, já que são elas que dão errado ao vivo.

30.3 Perguntas

Espere: "Por que a ordem do servidor é importante?", "O que o híbrido não protege?", "Como você migraria as chaves de host?", "O que acontece se o ML-KEM for enfraquecido?", "Como você sabe que o scanner está certo?" Responda com evidências do seu repositório.

As boas respostas citam o repositório. Sobre a ordem: o registro de laboratório que mostra uma lista mal ordenada negociando o X25519. Sobre o que o híbrido não protege: a autenticação, o tráfego passado já gravado e qualquer salto clássico. Sobre um ML-KEM enfraquecido: o combinador mantém a sessão tão forte quanto o X25519. Sobre o scanner: o seu registro de validação contra os três servidores de laboratório.

30.4 Entrega

Deixe um README, os registros de decisão, os runbooks e as issues abertas, para que outra equipe possa estender o trabalho.

O README declara o que a fatia faz, como construí-la e o que está fora do escopo. As issues abertas são escritas para alguém que não estava na equipe, com a evidência que motivou cada uma e um primeiro passo sugerido. Os registros de decisão e os runbooks ficam no repositório, para que a próxima equipe herde o raciocínio, e não só a configuração.

Para a fatia do SFTP, a fraqueza do cliente apenas emulado se torna a issue 1, com a linha da matriz e o motivo pelo qual nenhum dispositivo real estava disponível.

30.5 Caso resolvido

Avaliação do projeto final do SFTP: construção em 9 minutos; KEX híbrida mostrada nos logs; recuo provocado e alerta disparado em 2 minutos; recuperação pelo runbook em 4 minutos; o gate de CI bloqueou uma linha KexAlgorithms reordenada. O examinador pergunta sobre as chaves de host; o estudante explica o calendário de forjar depois, os certificados SSH como passo de agilidade e a espera por algoritmos de chave de host pós-quânticos no OpenSSH.

Os tempos mostram que a fatia é operável, e não só configurada: um alerta em até dois minutos depois do recuo e a recuperação em até quatro pelo runbook. A resposta sobre as chaves de host recebeu a nota máxima porque separou a troca de chaves da autenticação e nomeou um passo de agilidade concreto, em vez de prometer algoritmos futuros.

30.6 Atividade prática

Ensaie a sua demonstração com um colega no papel de examinador; cronometre cada etapa.

Execute a demonstração completa de ponta a ponta com um colega que faça as cinco perguntas da lista de avaliação sem aviso. Cronometre cada etapa e anote onde você hesitou ou precisou de um comando manual. Corrija qualquer etapa que dependia de algo que não está no repositório e ensaie de novo. Uma demonstração que roda dentro do seu tempo duas vezes seguidas está pronta; uma que funcionou uma vez, não.

Nos ensaios da KLS, a etapa mais lenta costumava ser reconstruir o laboratório depois da demonstração do gate de CI; uma equipe a reduziu de nove minutos para dois guardando em cache as imagens de contêiner no script de construção do repositório.

30.7 Autoavaliação

Antes da avaliação, pontue-se em cada critério, com links para as evidências, e anote uma fraqueza que você corrigiria com mais tempo. Os examinadores valorizam os candidatos que enxergam as próprias lacunas; isso mostra o discernimento de que as equipes de operações dependem. Inclua a autoavaliação na entrega, para que as próximas equipes saibam por onde começar.

Para o projeto final do SFTP, uma nota 3 em verificação tem um link para a execução de avaliação de 3.000 sessões, e não só para o painel.

Nomeie uma fraqueza, a evidência que a mostra e a correção que você faria com mais uma semana. Para o projeto final do SFTP, um exemplo justo é um tipo de cliente testado apenas em emulação. Declare a fraqueza abertamente; os examinadores a tratam como discernimento, e não como nota perdida.

30.8 Erros comuns e limites

Demonstrações que dependem de etapas manuais que não estão no repositório.
Afirmar que o híbrido protege a autenticação.
Nenhuma entrega.

Uma demonstração que precisa de um comando digitado à mão que não está no repositório reprova na reprodutibilidade na hora. Um candidato que diz que a troca de chaves híbrida protege a identidade do host SFTP confundiu o estabelecimento de chaves com a autenticação; a chave de host continua sendo Ed25519. E um projeto final sem README nem issues abertas deixa a próxima equipe redescobrindo tudo. Cada um desses erros fica visível para um examinador em minutos.

30.9 Depois da avaliação

Até uma semana depois da avaliação, o estudante arquiva as perguntas do examinador e as suas respostas junto com o registro do projeto final, corrige qualquer lacuna de documentação que o examinador tenha encontrado e entrega às operações da KLS um resumo de uma página sobre o que o serviço SFTP negocia agora e o que ainda é clássico. Esse resumo é o ponto de partida do próximo passo da migração.

Ele também declara explicitamente o próximo passo: certificados de host para o SSH e, depois, chaves de host pós-quânticas quando estiverem disponíveis.

Esses dois passos se tornam as primeiras issues no repositório da próxima equipe, cada uma com a evidência que a motivou.

Exercícios

EX059 — Roteiro da demonstração. Escreva um roteiro de demonstração de cinco etapas para o seu projeto final. Rubrica: 3 = construir, mostrar, quebrar, recuperar, gate.
EX060 — Resposta ao examinador. Responda a "O que o seu projeto final não protege?" Rubrica: 3 = autenticação/chaves de host, clientes de parceiros no clássico, dispositivos desconhecidos.

Síntese

A avaliação mostra uma fatia funcional, monitorada e recuperável, respostas honestas sobre os seus limites e artefatos que outras pessoas podem reutilizar.

Continue estudando — capítulo 30 de 30

← Capítulo 29 · Índice de capítulos do curso · Resoluções →

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

Resoluções

Respostas-modelo; qualquer resposta que atenda à rubrica recebe a mesma pontuação. Os números sobre a KLS são sintéticos.

EX001. Hardware: appliances de balanceamento de carga/hosts na nuvem (provedor). Firmware: inicialização assinada dos hosts (provedor/fornecedor; troca de hardware). Sistema operacional: distribuição dos nós com OpenSSL (equipe de plataforma; atualização de pacote). Biblioteca: TLS da imagem do ingress/NGINX (equipe de plataforma; reconstrução da imagem). Aplicação: cookies de sessão do portal assinados/cifrados (equipe da aplicação; versão). Gerenciado: TLS da borda da CDN (provedor da CDN; configuração).

EX002. Assinaturas RSA-2048: substituir (Shor). AES-256-GCM: manter (Grover deixa um trabalho de ~128 bits). SHA-256: manter (adequado para colisão/pré-imagem nos tamanhos atuais). ECDHE P-256: substituir (Shor; HNDL).

EX003. TLS 1.3: grupo X25519MLKEM768, RFC 10024. SSH: troca de chaves mlkem768x25519-sha256, notas de versão do OpenSSH. IKEv2: trocas de chaves adicionais, RFC 9370 (mistura provisória de PSK, RFC 8784).

EX004. 1.120 − 32 = 1.088 bytes, que é exatamente o texto cifrado do ML-KEM-768 (FIPS 203).

EX005. ceil(3.309 / 3) = 1.103 grupos × 4 = 4.412 caracteres.

EX006. O == pode retornar assim que um byte difere, então o tempo de resposta vaza quantos bytes iniciais coincidem, o que permite adivinhar a tag; use hmac.compare_digest.

EX007. use_id (qual uso criptográfico); method (passivo, configuração, código, fornecedor); observed_at (data e hora); observer (ferramenta ou pessoa); evidence_ref (ponteiro para o log bruto/hash da configuração); opcionalmente grade.

EX008. SELECT service FROM certs WHERE function='signature' AND algorithm IN ('RSA','ECDSA') AND not_after > '2030-12-31';

EX009. Tráfego da VPN do escritório: HNDL (se os dados forem de vida longa). Chave de assinatura de código do CI: forjar depois (artefatos confiáveis por anos). Backups em AES-256: nenhum (adequado frente a Grover). TLS para o portal do cliente: HNDL para os dados da sessão; forjar depois para o seu certificado.

EX010. Um middlebox descarta o ClientHello de vários segmentos → implantação em etapas e atualização/contorno do proxy. Um servidor apenas híbrido rejeita os clientes clássicos → manter o recuo clássico durante a transição. (Também: latência do HRR, CPU em clientes com recursos limitados.)

EX011. Contêiner NGINX: reconstruir a imagem sobre uma base com um OpenSSL com suporte a PQ e definir os grupos. Serviço Go: atualizar o toolchain do Go e recompilar, configurando as preferências de curvas se necessário. Daemon SSH do host: atualizar o pacote do OpenSSH e definir o KexAlgorithms.

EX012. Uma etapa de CI lê o SBOM da imagem e reprova se o OpenSSL for anterior ao mínimo aprovado (por exemplo, 3.5) nos serviços de nível 1; as exceções exigem um chamado com dono e data de expiração.

EX013. 1) AC raiz interna (confiança de 15 anos, controlada pela KLS). 2) Assinatura de versões (artefatos verificados por anos). 3) Certificados finais de mTLS dos serviços (depois da raiz). 4) Chaves SSH de usuário (rotacionáveis; adotar certificados). 5) Tokens de SSO (tempo de vida de 1 hora, rotação rápida).

EX014. Repositórios de confiança do sistema operacional dos hosts; pacotes de ACs das imagens base dos contêineres; truststores Java nos serviços; pacotes de confiança dos sidecars da malha; agentes de monitoramento; sistemas dos parceiros que usam mTLS; runners de CI.

EX015. A CDN termina o TLS do cliente e abre uma nova sessão TLS até a origem; cada negociação é independente, então os algoritmos do salto até a origem dependem das configurações de origem da CDN e da configuração da origem.

EX016. Referenciar um perfil nomeado (por exemplo, a anotação tls-profile: kls-modern) resolvido de forma central, com um teste de CI que confirme que os grupos renderizados coincidem com o perfil.

EX017. "Tráfego de navegadores para a CDN: 96 % híbrido (logs da CDN, todas as bordas)." "Tráfego do SDK da API no gateway: 40 % híbrido (logs do gateway)." "SFTP dos parceiros e VPN do escritório: 0 % (logs do daemon, configuração); leitores: desconhecido (sem fonte)."

EX018. Grupo TLS: ServerHello/logs do servidor. Algoritmo do certificado do servidor: configuração do servidor ou inventário de certificados. KEX do SSH: logs do sshd (com o nível de log adequado). Troca de chaves da VPN: logs/configuração do appliance.

EX019. Chave de encapsulamento de 1.184 bytes, texto cifrado de 1.088 bytes, segredo compartilhado de 32 bytes.

EX020. Usar bibliotecas/provedores verificados; mantê-los atualizados; preferir híbridos durante a transição; validar os comprimentos e tratar os erros sem vazar detalhes.

EX021. Atrasada quando 10 + 0,5 > z, isto é, z < 10,5 anos.

EX022. Nível 1: confidencialidade ≥ 8 anos, ou âncoras de confiança/assinaturas das quais se depende por ≥ 8 anos, ou dispositivos não atualizáveis. Nível 2: 3–8 anos. Nível 3: < 3 anos e credenciais rotacionáveis em um dia.

EX023. Registros: 8; vulneráveis ao quântico: 5 → 62,5 % ≈ 63 %; um registro é desconhecido, então a fração real pode ser maior.

EX024. Provedor da CDN (híbrido até a origem); provedor do Postgres gerenciado (criptografia da replicação); provedor do armazenamento de objetos/SDK (suporte ao híbrido nos envios de backup).

EX025. Ativo: sessões SFTP dos parceiros. Evento: o cliente do parceiro negocia apenas o clássico. Causa: biblioteca cliente antiga. Efeito: dados aduaneiros expostos a HNDL para esse parceiro. Detecção: fração de KEX por parceiro a partir dos logs do sshd. Probabilidade 4, impacto 3. Controle: aviso aos parceiros, endpoint de teste, prazo de transição. Teste: relatório mensal dos parceiros que não usam o híbrido.

EX026. Fonte: logs do appliance de VPN por túnel. Métrica: túneis que negociam sem a troca adicional ML-KEM (ou PSK). Limite: qualquer túnel de nível 1 por > 1 hora → alerta.

EX027. A chave derivada mistura o transcript; segredos reutilizados em outro handshake geram uma chave diferente, o que impede a repetição ou a combinação entre sessões.

EX028. A preferência do servidor lista o clássico primeiro e a escolha do servidor prevalece; ou os clientes não suportam o grupo híbrido.

EX029. Configurar o sshd do laboratório sem a KEX híbrida; a verificação precisa reportar o algoritmo clássico; depois restaurar e confirmar o híbrido.

EX030. Pergunta; versões do ambiente; hash da configuração; comandos; saídas; interpretação (e data, autor).

EX031. 15.524 − 1.290 = 14.234 bytes.

EX032. ML-DSA-65 (ou -44, conforme a política), possivelmente como assinatura dupla ao lado do ECDSA durante a transição, porque os verificadores (registros, controladores de admissão) precisam suportá-lo; registrar os identificadores nas assinaturas.

EX033. Acrescentar if len(groups) > 4: verdict += " (review: long group list)" antes de imprimir; a saída não marca nenhum serviço atual (todas as listas ≤ 3), e um serviço de teste com cinco grupos mostra a nota de revisão.

EX034. Executar o scanner contra servidores de laboratório com configurações conhecidas: híbrido preferido, híbrido não preferido, apenas clássico; ele precisa reportar cada um corretamente; registrar a versão do scanner.

EX035. KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256

EX036. Residual: comprometimento da PSK ou rotação deficiente; autenticação clássica; escalabilidade. Dono: Network Team. Revisão: trimestral. Saída: os appliances suportam o ML-KEM da RFC 9370 e são migrados; PSKs revogadas.

EX037. Métrica: fração híbrida dos handshakes no gateway de API (janela de 5 minutos). Alertar se < 90 % por 15 minutos ou se cair > 5 pontos em uma hora; ação: verificar a última implantação e o hash do perfil, seguir o runbook.

EX038. Reter: o limite superior de 0,234 % excede o limite de 0,09 % (linha de base mais orçamento), com uma taxa realmente elevada; investigar o proxy, excluir ou corrigir esse local e depois executar de novo.

EX039. A KLS provavelmente removeu a KEX clássica (apenas híbrido) e o cliente do parceiro não tem suporte ao híbrido; restaurar o recuo clássico e avisar o parceiro para atualizar dentro da janela de transição.

EX040. Acrescentar elif f["err"] == "hrr_timeout": c = "HelloRetryRequest latency"; uma linha de log com err=hrr_timeout passa então a ser contada nessa causa.

EX041. Cliente → borda da CDN (os logs da CDN mostram o híbrido); CDN → LB da origem (os logs do LB da origem mostram o híbrido); LB → ingress (logs do ingress); ingress → pods/malha (estatísticas dos sidecars); SDK de saída para o provedor (logs do cliente ou declaração do provedor). Resultados do teste sintético de ponta a ponta por região.

EX042. "A partir de 1º de março, os servidores SFTP da KLS oferecem troca de chaves pós-quântica híbrida (mlkem768x25519-sha256). Testem o seu cliente contra sftp-test.kls.example até 1º de junho. A troca de chaves clássica continua disponível até 1º de março do ano que vem. Depois disso, os clientes sem suporte ao híbrido não conseguirão se conectar. Para ajuda, contatem platform@kls.example."

EX043. for l in listeners: if l.tier == 1: groups = parse(l.groups); if not groups or groups[0] not in HYBRID: fail(l); sair com código diferente de zero se houver alguma falha; imprimir os listeners problemáticos.

EX044. Durante a transição, a lista de aceitação contém os dois identificadores, então as tags antigas são verificadas; depois da aposentadoria, o identificador antigo é removido da lista de aceitação e a verificação falha, mesmo que a tag seja válida sob o algoritmo antigo.

EX045. 9/14 ≈ 64 % completos; 4/14 ≈ 29 % parciais; 1/14 ≈ 7 % desconhecidos.

EX046. As operações do ML-KEM são rápidas nas CPUs modernas, enquanto os ~2,3 kB acrescentados por handshake podem cruzar os limites de pacote/janela inicial e provocar idas e voltas extras ou um HelloRetryRequest.

EX047. A carga e as condições de rede de cada dia da semana confundem a comparação; desenho sem pareamento — clientes/condições diferentes em cada dia.

EX048. Cerca de 3/300 = 1 % (regra de três, limite superior de ~95 %).

EX049. Laboratório + inventário → atualização/configuração do OpenSSH → matriz de clientes dos parceiros → monitoramento/runbook → avaliação. Cada uma exige o artefato anterior.

EX050. Feito: KEX híbrida configurada; quatro tipos de cliente testados. Próximo: os dois clientes restantes, painel. Bloqueado: imagem do cliente do parceiro — precisamos dela do gerente de parceiros até quinta-feira. Riscos: a emulação pode não corresponder ao cliente real.

EX051. Sintomas: a conexão do parceiro falha com no_shared_group. Verificações: versão do cliente do parceiro; KexAlgorithms atual; mudanças recentes. Ações: confirmar que o recuo clássico está presente; se foi removido, restaurar o perfil aprovado. Reversão: configuração anterior do sshd. Escalonamento: plantão da plataforma, contato do parceiro.

EX052. Painéis visíveis para o plantão; alertas roteados e testados; runbooks exercitados; donos no catálogo de serviços; registro de riscos residuais revisado.

EX053. Limite superior da taxa de falhas ≤ linha de base + 0,04 ponto; fração de recuo ≤ 5 % (clientes legados conhecidos); nenhum alerta sem explicação por 7 dias; runbooks e donos confirmados.

EX054. Escopo: faixa de IPs do proxy corporativo do cliente X; motivo: o proxy descarta ClientHellos grandes; controle: listener dedicado compatível com o clássico, monitoramento; dono: Platform Team com o gerente de conta; expiração: seis meses.

EX055. Sistemas: servidores TLS de laboratório e hosts de homologação aprovados; métodos: execuções do scanner com as opções listadas; janela: semanas 2–3, horário comercial; dados: resultados guardados no repositório, nenhum dado de produção; contatos: mentor e escritório de segurança.

EX056. Tarefa: validei o scanner. Evidência: resultados de laboratório mostrando o relato errado. Surpresa: biblioteca embutida antiga. Lição: sempre validar as ferramentas. Próximo: atualizar e validar de novo.

EX057. Contexto: as chaves de host do OpenSSH são Ed25519; nenhum algoritmo de chave de host PQ adotado. Opções: manter o clássico; chaves de host PQ experimentais. Decisão: manter, adotar certificados SSH para a rotação. Consequências: risco residual de forjar depois registrado; rotação rápida possível mais tarde.

EX058. Clonar o repositório; construir o laboratório com um comando; reproduzir os logs de sessão registrados pelo analisador; comparar os números do painel com o relatório.

EX059. Construir o laboratório; mostrar a KEX híbrida nos logs; reverter a configuração para disparar o alerta de recuo; recuperar pelo runbook; enviar uma mudança ruim e mostrar o bloqueio do gate de CI.

EX060. Autenticação de host e de usuário (clássica); clientes de parceiros ainda na KEX clássica; dispositivos desconhecidos ou não gerenciados; dados já gravados antes da migração.

Rota de ensino de trinta disciplinas

Este é o curso de tecnólogo para implementadores, acompanhando a sintética Kestrel Logistics Software (KLS) desde os fundamentos até serviços pós-quânticos configurados, automatizados, monitorados e passados para as operações.