Capítulo 26 — Segurança quântica e pós-quântica: passagem para as operações
Mapa da aula
Aula 26 publicada. Mapa, exemplo, EX051.
flowchart TD
N0["26.1 Pacote de passagem"]
N1["26.2 Runbooks"]
N2["26.3 Responsabilidade"]
N3["26.4 Treinamento"]
N4["26.5 Caso resolvido"]
N5["26.6 Atividade prática"]
N6["26.7 Critérios de aceite"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX051"]
Desenho lógico
flowchart LR
N0["26.1 Pacote de passagem"]
N1["26.2 Runbooks"]
N2["26.3 Responsabilidade"]
N3["26.4 Treinamento"]
N4["26.5 Caso resolvido"]
N5["26.6 Atividade prática"]
N6["26.7 Critérios de aceite"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX051"]
[26.1 Pacote de passagem]
|
v
[26.2 Runbooks]
|
v
[26.3 Responsabilidade]
|
v
[26.4 Treinamento]
|
v
[26.5 Caso resolvido]
|
v
[26.6 Atividade prática]
|
v
[26.7 Critérios de aceite]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX051]
Objetivos de aprendizagem
Você vai (1) preparar um serviço para a passagem às operações; (2) escrever runbooks para as falhas específicas do pós-quântico; (3) definir a responsabilidade pelos perfis, certificados e exceções; e (4) treinar os operadores.
26.1 Pacote de passagem
As operações precisam de: a arquitetura e o rastreamento do fluxo; o perfil criptográfico aplicado e a sua versão; as entradas do inventário; os painéis e os alertas; os runbooks; o registro de riscos residuais; a lista de exceções com as datas de expiração; os contatos de fornecedores e parceiros; e o relatório de avaliação.
Cada item é um link no repositório do serviço, e não um anexo, para que as operações sempre vejam a versão atual. O índice do pacote da KLS lista 12 itens, com dono e data da última revisão.
A KLS testou isso na passagem: um SRE que não tinha visto o trabalho do SFTP respondeu a um alerta simulado de "falhas de handshake híbrido acima do limite" apenas com o pacote, usando as etapas de isolar e de exceção do runbook.
26.2 Runbooks
Escreva runbooks para: queda da fração híbrida; falhas de handshake por um proxy; no_shared_group de um parceiro; falhas de verificação de certificados depois de mudanças na PKI; erros de HSM ou KMS na emissão. Cada um tem sintomas, verificações, ações seguras, reversão e escalonamento.
O runbook da KLS para a queda da fração híbrida começa com as três verificações que resolveram o seu incidente real: a última implantação, as anotações do ingress e o hash do perfil em produção comparado com o aprovado. A ação segura restaura o perfil aprovado sem mexer no código da aplicação; a reversão restaura a versão anterior do perfil; o escalonamento vai para o plantão da plataforma e, nos saltos de provedores, para o contato da CDN. Todo runbook é testado num exercício de mesa antes de contar.
26.3 Responsabilidade
Nomeie os donos dos perfis centrais, da AC interna, das aprovações de exceções, das alimentações da CBOM e dos painéis. As lacunas de responsabilidade são onde vivem as regressões.
Na KLS, a Platform Team é dona dos perfis centrais e das alimentações da CBOM, a equipe de PKI é dona da AC interna, o escritório de segurança aprova as exceções e o SRE é dono dos painéis e dos alertas. Cada dono é uma equipe com uma escala de plantão, registrada no catálogo de serviços, nunca uma única pessoa nomeada que pode sair.
A primeira revisão trimestral encontrou a alimentação da CBOM dos appliances de VPN ainda listada sob uma equipe que tinha sido incorporada à Platform Team; a alimentação continuou rodando, mas os seus alertas iam para um canal vazio.
26.4 Treinamento
Faça uma sessão curta para os operadores: o que mudou, como ler o painel, o que os runbooks dizem e um exercício de mesa. Registre a presença e as perguntas; atualize os runbooks com as respostas.
A sessão da KLS para o SRE levou 45 minutos: 10 sobre o que mudou, 10 sobre o painel, 10 sobre os runbooks e 15 sobre o exercício de mesa. A pergunta "podemos simplesmente remover o grupo híbrido se os handshakes falharem?" surgiu e agora está respondida no runbook: não, isole o caminho e use uma exceção.
A pergunta sobre o grupo híbrido e a sua resposta têm um link no registro da passagem, junto com os nomes das pessoas do SRE que participaram e uma pergunta ainda em aberto: como ler o painel quando um parceiro só se conecta uma vez por mês.
26.5 Caso resolvido
A KLS passa o fluxo da API do cliente para a equipe de SRE com um pacote no repositório do serviço. O exercício de mesa: "a fração híbrida cai para 5 % depois de uma versão". Os operadores seguem o runbook, identificam a anotação, restauram o perfil e confirmam a recuperação em 12 minutos. Uma lacuna encontrada: o runbook supunha acesso a um painel que os SREs não tinham — corrigido antes do aceite.
A recuperação em 12 minutos é a linha de base para os próximos exercícios. A lacuna de acesso é o tipo de constatação para a qual existe um exercício de mesa: no papel, o runbook estava correto; na prática, o seu primeiro passo era impossível para as pessoas que o seguiriam.
26.6 Atividade prática
Escreva o índice do pacote de passagem e um runbook para o fluxo do seu ateliê.
O índice lista cada item do pacote de passagem com a sua localização, o dono e a data da última revisão: rastreamento, perfil aplicado e versão, entradas do inventário, painéis, alertas, runbooks, registro de riscos residuais, exceções com datas de expiração, contatos e avaliação. O runbook cobre uma falha que o fluxo do seu ateliê pode produzir, com sintomas, as três primeiras verificações, a ação segura, a reversão e o escalonamento. Teste-o pedindo a um colega de equipe que não o escreveu que o siga no laboratório.
26.7 Critérios de aceite
As operações só devem aceitar uma passagem quando os critérios forem atendidos: painéis visíveis para a equipe de plantão, alertas roteados e testados, runbooks exercitados num exercício de mesa, donos nomeados no catálogo de serviços e o registro de riscos residuais revisado. Escrever os critérios transforma a passagem de uma reunião numa checklist, e dá às operações uma base justa para dizer "ainda não".
A equipe de SRE da KLS recusou a primeira passagem porque os alertas eram roteados para o canal da plataforma, e não para o plantão.
A passagem foi aprovada uma semana depois, quando o roteamento foi corrigido e um alerta foi testado de ponta a ponta.
26.8 Erros comuns e limites
- Passagens sem runbooks.
- Perfis ou exceções sem dono.
- Treinamento sem exercícios.
Antes de a KLS exigir runbooks, um alerta de recuo disparou à noite e o engenheiro de plantão, sem orientação, desabilitou o alerta. Uma exceção para o proxy de um cliente não tinha dono, então passou da data de expiração e ninguém a renovou nem a encerrou. E um treinamento só com slides deixou os operadores sem saber encontrar a verificação do hash do perfil quando precisaram dela. Cada lacuna foi encontrada num incidente, e não na passagem, que é o lugar mais caro para encontrá-la.
Exercícios
- EX051 — Runbook. Escreva um runbook para "um parceiro reporta
no_shared_groupno SFTP". Rubrica: 3 = sintomas, verificações, ações, reversão, escalonamento. - EX052 — Critérios de aceite. Liste cinco critérios de aceite da passagem. Rubrica: 3 = cinco critérios verificáveis.
Síntese
Uma passagem completa dá às operações o mapa, os controles, os alarmes, os runbooks, os donos e a prática para manter as proteções pós-quânticas no lugar.
Continue estudando — capítulo 26 de 30
← Capítulo 25 · Índice de capítulos do curso · Capítulo 27 →
Siga para a próxima lição escrita.