Capítulo 18 — Segurança quântica e pós-quântica: controles
Mapa da aula
Aula 18 publicada. Mapa, exemplo, EX035.
flowchart TD
N0["18.1 Controles de troca de chaves"]
N1["18.2 Controles de dados e de chaves"]
N2["18.3 Perfis centrais"]
N3["18.4 Risco residual"]
N4["18.5 Caso resolvido"]
N5["18.6 Atividade prática"]
N6["18.8 Implantando os controles"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX035"]
Desenho lógico
flowchart LR
N0["18.1 Controles de troca de chaves"]
N1["18.2 Controles de dados e de chaves"]
N2["18.3 Perfis centrais"]
N3["18.4 Risco residual"]
N4["18.5 Caso resolvido"]
N5["18.6 Atividade prática"]
N6["18.8 Implantando os controles"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX035"]
[18.1 Controles de troca de chaves]
|
v
[18.2 Controles de dados e de chaves]
|
v
[18.3 Perfis centrais]
|
v
[18.4 Risco residual]
|
v
[18.5 Caso resolvido]
|
v
[18.6 Atividade prática]
|
v
[18.8 Implantando os controles]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX035]
Objetivos de aprendizagem
Você vai (1) implementar controles de troca de chaves híbrida para TLS, SSH e IPsec; (2) implementar controles de minimização de dados e de gerenciamento de chaves; (3) aplicar perfis criptográficos centrais; e (4) documentar o risco residual por serviço.
18.1 Controles de troca de chaves
TLS: habilitar o X25519MLKEM768 e preferi-lo nos listeners voltados para a internet e de nível 1. SSH: colocar o mlkem768x25519-sha256 em primeiro lugar no KexAlgorithms do servidor, onde as versões do OpenSSH o suportarem. IPsec: configurar uma troca de chaves ML-KEM adicional segundo a RFC 9370, onde os appliances a suportarem, ou PSKs da RFC 8784 como medida provisória em enlaces fixos entre sites.
Na KLS, isso significa que o gateway, o portal, o balanceador de carga da origem e o ingress recebem o perfil TLS kls-modern; os hosts SFTP recebem a linha KexAlgorithms com o híbrido em primeiro lugar; e a VPN do escritório, cujos appliances não suportam a RFC 9370, usa PSKs da RFC 8784 com rotação trimestral até a renovação dos appliances.
18.2 Controles de dados e de chaves
Envie menos dados de vida longa por enlaces não confiáveis; cifre os campos sensíveis na camada de aplicação com chaves que nunca atravessam a rede sob troca de chaves clássica; encurte a retenção onde os contratos permitirem. Mantenha as chaves num HSM ou KMS; registre os seus algoritmos no inventário.
Na KLS, o controle de dados mais forte é a cifragem na camada de aplicação dos campos dos documentos aduaneiros, com chaves do KMS, de modo que as sessões de transporte gravadas expõem texto cifrado mesmo onde a troca de chaves ainda é clássica. Encurtar a retenção da telemetria dos leitores, de um ano para 90 dias, exigiu apenas uma verificação de contrato.
18.3 Perfis centrais
Defina perfis criptográficos nomeados (por exemplo, kls-modern: somente TLS 1.3, grupos X25519MLKEM768:X25519, certificados ECDSA) e aplique-os por referência no ingress, nos balanceadores de carga e nos modelos de serviço. Mudar o perfil muda todos os usuários, depois dos testes.
A KLS guarda os perfis num único repositório, com números de versão. Os manifestos do ingress referenciam kls-modern@3 em vez de strings de grupos, e o gate de CI renderiza cada manifesto e compara o resultado com o perfil. Uma nova versão é implantada por canário, e a versão anterior continua disponível para reversão sem mexer no código da aplicação.
18.4 Risco residual
Para cada serviço, registre o que continua clássico (geralmente a autenticação), o que é desconhecido e o que depende de terceiros, com dono e data de revisão.
A KLS mantém as notas residuais no inventário, uma por serviço de nível 1. Uma entrada típica: "Gateway de API: troca de chaves híbrida; certificado ECDSA P-256 (forjar depois, aguardando o suporte ao ML-DSA das ACs públicas e dos navegadores); chamadas ao provedor de pagamentos: suporte ao híbrido desconhecido (chamado com o fornecedor aberto); dono Platform Team; revisão em 1º de março." A data de revisão é o que mais importa, porque as notas residuais sem data se tornam, por padrão, uma aceitação permanente.
A entrada do gateway, por exemplo, traz uma linha separada "desconhecido: se o endpoint do provedor de pagamentos suporta grupos híbridos", sob a responsabilidade da Platform Team até que o chamado com o fornecedor seja respondido; fundi-la com a linha clássica teria registrado um palpite como um risco aceito.
18.5 Caso resolvido
SFTP dos parceiros: OpenSSH atualizado; KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256; os parceiros que usam clientes mais antigos ainda negociam curve25519 e são avisados; as sessões que usam o híbrido são monitoradas. Residual: chave de host Ed25519 (forjar depois), parceiros com clientes antigos (HNDL até atualizarem), dono Platform Team, revisão trimestral.
A lista ordenada dá três níveis de suporte de clientes: o OpenSSH atual negocia o híbrido ML-KEM, versões um pouco mais antigas o híbrido sntrup761, e os clientes antigos recuam para o curve25519. O monitoramento por algoritmo mostra quais parceiros estão em cada nível e orienta os avisos.
18.6 Atividade prática
Escreva um perfil kls-modern para um produto que você usa e aplique-o em laboratório.
Para o NGINX, o perfil é um arquivo de include curto, com ssl_protocols TLSv1.3;, ssl_ecdh_curve X25519MLKEM768:X25519; e as diretivas de certificado, referenciado em cada bloco de servidor; para o OpenSSH, é um arquivo drop-in em sshd_config.d com a linha KexAlgorithms. Aplique-o no laboratório, verifique a negociação com dois clientes, depois remova de propósito o grupo híbrido e confirme que a sua verificação reporta clássico. Registre a versão do perfil e o hash do arquivo no registro de laboratório.
18.7 Erros comuns e limites
- Configuração manual por serviço.
- Controles sem notas de risco residual.
- PSKs sem rotação.
A auditoria da KLS encontrou os três antes de existir o repositório de perfis: onze configurações de ingress editadas à mão, com quatro listas de grupos diferentes; uma VPN que usava PSKs sem nenhuma nota residual; e PSKs instaladas na entrada em operação do appliance, nunca rotacionadas desde então. As correções foram um perfil central, uma nota residual por serviço de nível 1 e um calendário de rotação com um dono. Os controles só reduzem a exposição onde são aplicados de forma consistente e onde as suas lacunas estão escritas.
18.8 Implantando os controles
Aplique cada controle pelo processo normal de mudança: teste em homologação com a matriz de clientes, habilite para uma fração canário do tráfego, acompanhe os painéis e depois promova. Mantenha disponível a versão anterior do perfil para uma reversão rápida e direcionada. Anuncie as mudanças que afetam os parceiros — clientes SFTP e de API — com antecedência suficiente e um endpoint de teste, para que os parceiros possam verificar os seus clientes antes das mudanças em produção. Um controle que quebra o envio noturno de um parceiro será revertido sob pressão, muitas vezes sem que ninguém registre o porquê.
A mudança do SFTP da KLS seguiu esse caminho: um aviso aos parceiros com um endpoint de teste três meses antes, um canário num dos dois hosts SFTP e a promoção depois de uma semana sem novos erros no_shared_group nos logs.
Exercícios
- EX035 — Controle de SSH. Escreva a linha de KEX do servidor SSH para uma configuração com o híbrido em primeiro lugar e um recuo clássico. Rubrica: 3 = híbrido primeiro, nomes válidos, recuo presente.
- EX036 — Nota residual. Escreva uma nota de risco residual para a VPN do escritório que usa PSKs da RFC 8784. Rubrica: 3 = riscos restantes, dono, revisão, condição de saída.
Síntese
Os controles de troca de chaves, de dados e de chaves aplicados por meio de perfis centrais reduzem a exposição quântica; o risco residual é registrado por serviço.
Continue estudando — capítulo 18 de 30
← Capítulo 17 · Índice de capítulos do curso · Capítulo 19 →
Siga para a próxima lição escrita.