Capítulo 10 — Segurança quântica e pós-quântica: configuração de controles
Mapa da aula
Aula 10 publicada. Mapa, exemplo, EX028.
flowchart TD
N0["10.1 Configuração do TLS"]
N1["10.2 Configuração do SSH"]
N2["10.3 Atividade prática — Laboratório T"]
N3["10.4 Controle de mudanças"]
N4["10.5 Caso resolvido"]
N5["10.6 Atividade prática"]
N6["10.7 Mantenha o fallback por ora"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX028"]
Desenho lógico
flowchart LR
N0["10.1 Configuração do TLS"]
N1["10.2 Configuração do SSH"]
N2["10.3 Atividade prática — Laboratório T"]
N3["10.4 Controle de mudanças"]
N4["10.5 Caso resolvido"]
N5["10.6 Atividade prática"]
N6["10.7 Mantenha o fallback por ora"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX028"]
[10.1 Configuração do TLS]
|
v
[10.2 Configuração do SSH]
|
v
[10.3 Atividade prática — Laboratório T]
|
v
[10.4 Controle de mudanças]
|
v
[10.5 Caso resolvido]
|
v
[10.6 Atividade prática]
|
v
[10.7 Mantenha o fallback por ora]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX028]
Objetivos de aprendizagem
Você vai (1) configurar a troca de chaves híbrida em servidores TLS e SSH num laboratório; (2) auditar configurações quanto à presença e à preferência; (3) manter o fallback clássico durante a transição; e (4) aplicar as mudanças por meio do controle de mudanças.
10.1 Configuração do TLS
Em servidores baseados em OpenSSL, defina a lista de grupos com o híbrido primeiro, por exemplo X25519MLKEM768:X25519:secp256r1. Os servidores web e os balanceadores de carga expõem isso por meio de uma diretiva ou de um perfil; consulte a documentação do seu produto para os nomes exatos. A ordem importa quando é o servidor que decide.
No HHG, o balanceador de carga do portal do hóspede listava o X25519 primeiro, então a maioria dos clientes negociava clássico. Mantenha os grupos clássicos depois do híbrido, e não no lugar dele, e salve a string exata de grupos na linha de base, para que todos os listeners usem a mesma ordem.
10.2 Configuração do SSH
Na configuração do servidor OpenSSH, coloque mlkem768x25519-sha256 primeiro em KexAlgorithms, seguido de sntrup761x25519-sha512@openssh.com e curve25519-sha256 por compatibilidade. Recarregue o serviço e teste com ssh -v a partir de um cliente que suporte o híbrido.
No HHG, essa é a mudança de que o servidor de troca de arquivos precisa após a atualização do seu OpenSSH. Salve a linha KexAlgorithms antes e depois da edição, verifique a sintaxe da configuração antes de recarregar e mantenha uma sessão existente aberta enquanto testa, para que um erro não o deixe trancado do lado de fora.
10.3 Atividade prática — Laboratório T
# Lab T (ch 10): audit synthetic TLS and SSH server configurations for post-quantum key exchange and preference order.
configs = { # service: ordered list of offered groups (server preference) - synthetic
"booking-api": ["X25519MLKEM768", "X25519", "secp256r1"],
"guest-portal": ["X25519", "X25519MLKEM768", "secp256r1"],
"channel-sftp": ["ecdh-sha2-nistp256"],
"ops-grafana": ["X25519", "secp384r1"]}
HYBRID = {"X25519MLKEM768", "SecP256r1MLKEM768", "SecP384r1MLKEM1024"}
for svc, groups in configs.items():
offered = [g for g in groups if g in HYBRID]
if not offered: verdict = "CLASSICAL ONLY"
elif groups[0] in HYBRID: verdict = "OK (hybrid preferred)"
else: verdict = "WARN hybrid offered but not preferred"
print(f"{svc:17s} {verdict}")
Saída esperada:
booking-api OK (hybrid preferred)
guest-portal WARN hybrid offered but not preferred
channel-sftp CLASSICAL ONLY
ops-grafana CLASSICAL ONLY
O portal do hóspede oferece híbrido, mas prefere o X25519 — o problema encontrado no Capítulo 5. O SFTP dos canais e o painel de operações são apenas clássicos.
O script audita a lista ordenada de cada serviço quanto a duas propriedades: se algum método híbrido é oferecido e se um deles vem primeiro. A API de reservas passa nas duas verificações, enquanto o portal do hóspede falha na preferência e os outros dois falham na presença. Repare que a entrada de channel-sftp é um método SSH, que a lista TLS do script não conhece; uma auditoria de SSH precisa da sua própria lista de nomes híbridos, como mlkem768x25519-sha256. Estenda o script para tratar esse caso.
10.4 Controle de mudanças
Toda mudança em produção passa por um ticket de mudança: o quê, por quê, quando, risco, evidência de teste, reversão, aprovador. Faça a mudança na homologação, verifique, depois aplique em produção numa janela de baixo tráfego, verifique de novo e feche o ticket com evidências.
No HHG, o ticket OPS-430 é um exemplo de registro completo. Anexe a evidência da homologação antes de pedir a aprovação e feche o ticket somente após a verificação em produção. No HHG, a mudança em produção do OPS-430 foi feita às 06:00 de uma terça-feira, um horário de baixo tráfego para o portal do hóspede. Registre o nome do aprovador.
10.5 Caso resolvido
Ticket OPS-430: reordenar os grupos no balanceador de carga do portal do hóspede para X25519MLKEM768:X25519:secp256r1. Teste na homologação: híbrido negociado pelos clientes atuais, X25519 por um cliente antigo. Mudança em produção na terça-feira às 06:00; a verificação às 06:10 mostra híbrido negociado; a proporção híbrida no painel sobe de 3 % para 85 % até o meio-dia. Plano de reversão (restaurar a ordem anterior) não necessário.
O ticket segue todos os passos: teste na homologação com os dois tipos de cliente, uma janela de baixo tráfego, verificação imediata e um resultado mensurável. A reversão foi escrita com antecedência, embora não tenha sido usada. A subida da proporção híbrida também confirma a constatação do Capítulo 5.
10.6 Atividade prática
No laboratório, configure um servidor TLS e um servidor SSH com o híbrido primeiro; verifique com clientes; escreva o ticket de mudança que você abriria para a produção.
Coloque o método híbrido primeiro e mantenha os métodos clássicos depois dele nos dois servidores. Verifique do lado do cliente com openssl s_client e ssh -v, e do lado do servidor com os logs. Teste também com um cliente antigo, para confirmar o fallback. Depois escreva o ticket de produção com o quê, por quê, quando, risco, evidência de teste, reversão e aprovador, usando o OPS-430 como modelo.
10.7 Mantenha o fallback por ora
Durante a transição, mantenha as opções clássicas depois do híbrido, para que os clientes mais antigos continuem se conectando. Removê-las é uma decisão separada e posterior, baseada num monitoramento que mostre poucos clientes clássicos restantes e no acordo com os responsáveis pelos serviços e com os parceiros.
No HHG, quatro agências de viagem ainda usavam clientes SFTP antigos após a atualização, então remover os métodos clássicos as teria desconectado. Monitore a proporção clássica por serviço e por parceiro antes de propor a remoção, e registre a decisão e quem concordou com ela. A remoção não é uma decisão apenas do operador.
10.8 Erros comuns e limites
- Híbrido listado depois do clássico.
- Remover o fallback cedo demais.
- Mudanças sem tickets ou sem verificação.
Cada erro enfraquece a proteção ou o controle. Listar o híbrido depois do clássico significa que a maioria dos clientes negocia clássico, como no portal do hóspede do HHG. Remover o fallback cedo demais desconecta clientes mais antigos, como as quatro agências com clientes SFTP antigos. Uma mudança sem ticket ou sem verificação não pode ser revisada, revertida de forma confiável nem comprovada. Confira cada mudança de configuração quanto aos três antes da aprovação. Corrija o que encontrar.
Exercícios
- EX028 — Linha do TLS. Escreva uma lista de grupos com o híbrido primeiro e dois fallbacks clássicos. Rubrica: 3 = híbrido primeiro, nomes válidos.
- EX029 — Linha do SSH. Escreva uma linha
KexAlgorithmscom o híbrido primeiro e fallbacks compatíveis. Rubrica: 3 = lista ordenada válida. - EX030 — Ticket. Escreva o ticket de mudança para habilitar o SSH híbrido no servidor SFTP dos canais. Rubrica: 3 = o quê, por quê, quando, risco, evidência de teste, reversão, aprovador.
Síntese
Os operadores configuram o híbrido primeiro, com fallback clássico, no TLS e no SSH, auditam a preferência além da presença e fazem as mudanças por meio de tickets testados e verificados.
Continue estudando — capítulo 10 de 18
← Capítulo 09 · Índice de capítulos do curso · Capítulo 11 →
Siga para a próxima lição escrita.