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
- Esquecer a disponibilidade nos planos de mudança.
- Tratar todo risco quântico como igualmente urgente.
- Chamar os algoritmos de "defeitos".
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
- EX009 — Classificar. Rotule como HNDL, forjar depois ou nenhum: o tráfego da VPN do escritório, a chave de assinatura de código do CI, os backups em AES-256, o TLS para o portal do cliente. Rubrica: 3 = quatro corretos, com motivos.
- EX010 — Disponibilidade. Nomeie duas formas pelas quais habilitar a troca de chaves híbrida poderia causar uma indisponibilidade e um controle para cada uma. Rubrica: 3 = dois modos de falha, com controles.
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.