Capítulo 21 — Segurança quântica e pós-quântica: integração de serviços
Mapa da aula
Aula 21 publicada. Mapa, exemplo, EX041.
flowchart TD
N0["21.1 Camada por camada"]
N1["21.2 Serviços gerenciados"]
N2["21.3 Parceiros e clientes"]
N3["21.4 Compatibilidade durante a transição"]
N4["21.5 Caso resolvido"]
N5["21.6 Atividade prática"]
N6["21.7 Testes de integração"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX041"]
Desenho lógico
flowchart LR
N0["21.1 Camada por camada"]
N1["21.2 Serviços gerenciados"]
N2["21.3 Parceiros e clientes"]
N3["21.4 Compatibilidade durante a transição"]
N4["21.5 Caso resolvido"]
N5["21.6 Atividade prática"]
N6["21.7 Testes de integração"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX041"]
[21.1 Camada por camada]
|
v
[21.2 Serviços gerenciados]
|
v
[21.3 Parceiros e clientes]
|
v
[21.4 Compatibilidade durante a transição]
|
v
[21.5 Caso resolvido]
|
v
[21.6 Atividade prática]
|
v
[21.7 Testes de integração]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX041]
Objetivos de aprendizagem
Você vai (1) integrar as configurações pós-quânticas nas camadas de CDN, balanceador de carga, ingress, malha e aplicação; (2) coordenar com os provedores de serviços gerenciados; (3) lidar com as integrações de parceiros e clientes; e (4) manter a compatibilidade durante a transição.
21.1 Camada por camada
Integração significa que todos os saltos concordam. Na CDN, habilite a troca de chaves híbrida para os clientes e para a origem, onde o provedor a suportar. No balanceador de carga da origem e no ingress, aplique o perfil central. Na malha de serviços, atualize os proxies sidecar e os certificados do plano de controle; o mTLS da malha é interno, mas pode atravessar redes compartilhadas entre zonas de disponibilidade. Nas aplicações, atualize os SDKs que fazem chamadas de saída para parceiros e APIs de nuvem.
Na KLS, a ordem dos saltos no fluxo da API do cliente fixa a ordem do trabalho: primeiro as configurações da CDN, porque o provedor as controla e precisa de antecedência; depois o balanceador de carga e o ingress da própria KLS; depois a malha, no ciclo de versões da plataforma; e os SDKs por último, porque os clientes os adotam no seu próprio ritmo.
21.2 Serviços gerenciados
Os bancos de dados, as filas e o armazenamento de objetos gerenciados negociam o TLS com bibliotecas que o provedor controla. Pergunte aos provedores quais grupos os seus endpoints oferecem, se o híbrido está disponível e como exigi-lo. Registre as respostas como evidência de fornecedor e verifique pelos logs do lado do cliente, sempre que possível. Alguns provedores expõem opções pós-quânticas por endpoint ou região; outros só publicam roadmaps.
As perguntas da KLS aos provedores são escritas sempre da mesma forma: quais grupos o endpoint oferece hoje, se há um grupo híbrido disponível e em quais regiões, se a KLS pode exigi-lo e como a KLS pode verificá-lo. As respostas são datadas e guardadas como evidência de fornecedor; um slide de roadmap é registrado como "planejado", nunca como suportado.
21.3 Parceiros e clientes
Os parceiros se integram por SFTP, APIs e VPNs. Publique um aviso de compatibilidade: o que a KLS oferece agora, o que a KLS vai exigir e quando, e um endpoint de teste. Mantenha o recuo clássico durante uma janela de transição publicada; defina uma data de término alinhada à política e aos contratos, e acompanhe a adoção pelos parceiros.
A KLS acompanha a adoção pelos parceiros a partir dos seus próprios logs do sshd, que mostram o algoritmo de KEX que o cliente de cada parceiro negocia. Dos seis tipos de cliente vistos, dois eram apenas clássicos no início da janela. Esses parceiros recebem um lembrete direto nas marcas de seis e de nove meses, com o endpoint de teste e a data de término.
21.4 Compatibilidade durante a transição
Ofereça o híbrido e o clássico, prefira o híbrido, monitore o recuo e remova o clássico apenas quando a fração de recuo estiver abaixo de um limite acordado por um período acordado e as exceções estiverem documentadas. Para os certificados, use cadeias duplas ou endpoints duplos apenas onde os produtos os suportarem de forma limpa; caso contrário, mantenha os certificados clássicos até que as partes confiantes consigam verificar o ML-DSA.
O limite da KLS para remover os grupos clássicos de um listener é uma fração de recuo abaixo de 1 % por 30 dias consecutivos, com cada cliente restante listado como exceção, com dono e data de expiração. Até lá, o perfil oferece e prefere o híbrido, enquanto ainda aceita o X25519, e o painel mostra a fração de recuo ao lado da fração híbrida.
21.5 Caso resolvido
O plano de integração da KLS para a API do cliente: CDN híbrida para os clientes (feito) e para a origem (o provedor a suporta a partir do 1º trimestre; habilitar e verificar nos logs da origem); perfil kls-modern no LB da origem e no ingress; sidecars da malha atualizados na próxima versão da plataforma; as chamadas de saída do SDK para o provedor de pagamentos continuam clássicas até que o provedor suporte o híbrido (chamado com o fornecedor). Aviso aos parceiros publicado com um endpoint de homologação e uma janela de doze meses antes que os parceiros apenas clássicos precisem atualizar.
O plano lista cada salto com um dono e a evidência que vai fechá-lo, para que a situação seja contada por salto, e não por esforço. Dois saltos, o enlace da CDN até a origem e as chamadas ao provedor de pagamentos, dependem de terceiros; ambos são acompanhados como pedidos datados, e o fluxo é reportado como parcialmente migrado até que os dois sejam fechados.
21.6 Atividade prática
Escreva uma checklist de integração para um fluxo da KLS, cobrindo cada salto, o dono, a evidência de conclusão e as dependências externas.
Para a API do cliente, liste os saltos cliente → CDN, CDN → balanceador de carga da origem, balanceador de carga → ingress, ingress → pods e pod → provedor de pagamentos. Para cada um, dê o dono, a configuração ou a atualização necessária, a evidência que o comprova (um campo de log, o resultado de um teste sintético, uma declaração escrita do provedor) e a dependência externa com o seu contato. Acrescente o teste de ponta a ponta como última linha. Um salto sem evidência continua aberto, por mais confiante que o dono esteja.
21.7 Testes de integração
Os testes de integração devem exercitar o caminho inteiro, e não cada salto isoladamente: um cliente sintético em cada região de clientes chama a API pela CDN e registra o grupo negociado na borda e, pelos logs da origem, na origem. Execute o teste depois de cada mudança em qualquer salto. Quando o teste falha num salto, as evidências por salto dizem onde procurar. Essa verificação de ponta a ponta é o que permite à equipe afirmar que um fluxo, e não um componente, está migrado.
21.8 Erros comuns e limites
- Migrar os saltos de forma independente, sem verificação de ponta a ponta.
- Remover o suporte clássico antes que os parceiros estejam prontos.
- Tratar os roadmaps dos provedores como recursos entregues.
A KLS cometeu o primeiro erro quando o ingress e o balanceador de carga foram migrados em sprints separadas e ninguém testou o caminho; o salto até a origem continuava clássico porque a opção de origem da CDN não tinha sido habilitada. O segundo foi evitado pela janela dos parceiros; uma remoção de teste no host SFTP de homologação mostrou dois tipos de cliente de parceiros falhando ao mesmo tempo. O terceiro é comum: um slide de um provedor que prometia o híbrido "no 1º trimestre" foi citado como concluído num relatório de situação e precisou ser corrigido.
Exercícios
- EX041 — Checklist de saltos. Liste todos os saltos do fluxo da API do cliente da KLS e a evidência de que cada um está migrado. Rubrica: 3 = todos os saltos, com evidências concretas.
- EX042 — Aviso aos parceiros. Redija um aviso de cinco frases aos parceiros sobre a troca de chaves híbrida no SFTP. Rubrica: 3 = o quê, quando, endpoint de teste, janela de recuo, contato.
Síntese
A integração de serviços alinha todos os saltos, documenta as dependências de provedores e parceiros e mantém a compatibilidade ao longo de uma janela de transição medida, com testes de ponta a ponta.
Continue estudando — capítulo 21 de 30
← Capítulo 20 · Índice de capítulos do curso · Capítulo 22 →
Siga para a próxima lição escrita.