OpenCyber Academy
Tecnólogo · Capítulo 5 · Português
Código do curso: OCA-090Capítulo 05: OCA-090-C005

Capítulo 5 — Letramento em segurança

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 05 publicada. Mapa, exemplo, EX009.

flowchart TD
  N0["5.1 Propriedades e mudanças"]
  N1["5.2 Vocabulário de risco"]
  N2["5.3 Dois padrões"]
  N3["5.4 Caso resolvido"]
  N4["5.5 Atividade prática"]
  N5["5.7 Transformando o risco em tarefas"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX009"]

Desenho lógico

flowchart LR
  N0["5.1 Propriedades e mudanças"]
  N1["5.2 Vocabulário de risco"]
  N2["5.3 Dois padrões"]
  N3["5.4 Caso resolvido"]
  N4["5.5 Atividade prática"]
  N5["5.7 Transformando o risco em tarefas"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX009"]
[5.1 Propriedades e mudanças]
    |
    v
[5.2 Vocabulário de risco]
    |
    v
[5.3 Dois padrões]
    |
    v
[5.4 Caso resolvido]
    |
    v
[5.5 Atividade prática]
    |
    v
[5.7 Transformando o risco em tarefas]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX009]

Objetivos de aprendizagem

Você vai (1) aplicar confidencialidade, integridade, disponibilidade e autenticidade às mudanças em serviços; (2) relacionar ativos, ameaças, vulnerabilidades e controles; (3) explicar colher agora, decifrar depois e forjar depois; e (4) reconhecer o risco de disponibilidade numa mudança criptográfica.

5.1 Propriedades e mudanças

Os implementadores mudam a criptografia para melhorar a confidencialidade e a autenticidade, mas toda mudança arrisca a disponibilidade. Um grupo híbrido que um balanceador de carga não consegue interpretar é uma indisponibilidade. A boa prática trata a disponibilidade como um requisito de mesmo peso: implantação em etapas, reversão, monitoramento.

A regra aparece nos próprios registros da KLS: a sonda de monitoramento que expirou no gateway de homologação teria sido uma tempestade de alertas em produção se o grupo tivesse entrado no ar em todos os lugares ao mesmo tempo. Por isso, cada mudança híbrida traz no seu plano uma reversão, um painel e uma etapa canário.

5.2 Vocabulário de risco

Um ativo (os registros de embarque), uma ameaça (um adversário gravando o tráfego), uma vulnerabilidade (a troca de chaves clássica) e um controle (a troca de chaves híbrida) se combinam num cenário de risco. As vulnerabilidades quânticas são propriedades dos algoritmos, não defeitos, e se tornam exploráveis quando surge uma capacidade.

Escrever as quatro partes separadamente também mostra onde um controle atua. A troca de chaves híbrida remove a vulnerabilidade apenas para as sessões futuras; ela não faz nada pelo tráfego já gravado. Encurtar a retenção, por sua vez, reduz o valor do ativo. Para o SFTP dos parceiros da KLS, o cenário completo é: documentos aduaneiros, gravados por um adversário numa rede de trânsito, legíveis por causa da troca de chaves ECDH, mitigados pelo mlkem768x25519-sha256 a partir da data da atualização.

5.3 Dois padrões

Colher agora, decifrar depois: o tráfego gravado é decifrado quando existir um computador quântico; é urgente para dados cuja confidencialidade dura além desse momento. Forjar depois: quando existir um computador quântico, as assinaturas podem ser forjadas; é urgente para a confiança de longa duração (ACs raiz, assinatura de firmware, documentos verificados por anos) e para dispositivos que não podem ser atualizados.

A urgência de cada um é uma questão de datas. A exposição a HNDL começa no dia em que o tráfego é gravado, então, para os dados de embarque de dez anos da KLS, cada sessão clássica de hoje importa. A exposição a forjar depois só começa quando a falsificação se torna possível e dura enquanto a chave for confiável, então a raiz interna de 15 anos é urgente e uma chave de JWT semanal não é.

5.4 Caso resolvido

O serviço SFTP dos parceiros da KLS transporta documentos aduaneiros mantidos confidenciais por dez anos; ele usa troca de chaves ECDH: exposto a HNDL agora. A sua chave de host é Ed25519: exposição a forjar depois, de menor urgência, porque as chaves de host podem ser rotacionadas rapidamente quando os clientes SSH suportarem algoritmos de chave de host pós-quânticos. As chaves de assinatura de JWT da API são rotacionadas semanalmente: a exposição a forjar depois é mínima até que exista um computador quântico.

Os três casos dão à KLS três respostas diferentes. A troca de chaves do SFTP é agendada para a próxima janela de manutenção. A chave de host é registrada como risco residual com um gatilho: quando o OpenSSH lançar um algoritmo de chave de host pós-quântico que os clientes da KLS suportem, rotacionar. As chaves de JWT não precisam de nada além de manter a rotação automatizada.

5.5 Atividade prática

Escreva três cenários de risco para serviços da KLS usando o padrão ativo–ameaça–vulnerabilidade–controle; rotule cada um como HNDL, forjar depois ou nenhum.

Um cenário completo nomeia as quatro partes e o rótulo. Exemplo: ativo, a replicação do banco de dados de faturamento transportando faturas de sete anos; ameaça, gravação na rede entre zonas do provedor; vulnerabilidade, ECDHE-P256 no TLS da replicação; controle, híbrido suportado pelo provedor ou cifragem de campos na camada de aplicação; rótulo HNDL. Inclua um cenário rotulado nenhum, como os backups em AES-256, e explique por quê: a aceleração de Grover deixa uma chave de 256 bits com ampla margem, então nenhuma ação motivada pelo quântico é necessária.

5.6 Erros comuns e limites

Cada erro leva a uma falha reconhecível. Um plano sem trabalho de disponibilidade habilita o híbrido no portal e descobre o proxy antigo num cliente por meio de um chamado de suporte. Tratar toda exposição como urgente coloca as chaves de JWT semanais na mesma fila do tráfego SFTP de dez anos e atrasa as duas. Chamar o RSA de "defeito" convida a uma mentalidade de correção; não há correção, só substituição, e o cronograma depende de uma capacidade que ainda não existe.

5.7 Transformando o risco em tarefas

Os implementadores traduzem cada cenário de risco em itens de trabalho com uma definição clara de pronto. "Exposição a HNDL do SFTP dos parceiros" se torna: confirmar que a versão do OpenSSH nos hosts SFTP suporta mlkem768x25519-sha256; habilitá-lo em primeiro lugar na lista de troca de chaves do servidor em homologação; verificar quais clientes dos parceiros o negociam; publicar um aviso aos parceiros; promover para produção; monitorar a fração de sessões que o usam. Cada item tem um dono e uma evidência que prova que está concluído. Declarações de risco que nunca viram tarefas são a forma mais comum de o trabalho de segurança empacar entre o registro de riscos e o backlog da plataforma.

Mantenha a disponibilidade em toda definição de pronto: uma tarefa não está concluída até que a reversão tenha sido testada e o monitoramento não mostre aumento de falhas.

Exercícios

Síntese

Os implementadores precisam pesar os ganhos de confidencialidade e de autenticidade contra o risco de disponibilidade, e distinguir os padrões ligados ao tempo de colher agora, decifrar depois e de forjar depois.

Respostas comentadas

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.)