Capítulo 7 — Segurança quântica e pós-quântica: controles e verificação

Mapa da aula

Aula 07 publicada. Mapa, exemplo, EX031.

flowchart TD
  N0["7.1 Controles"]
  N1["7.2 Associando controles"]
  N2["7.3 Atividade prática — Laboratório A"]
  N3["7.4 Verificação"]
  N4["7.5 Risco residual"]
  N5["7.6 Caso resolvido"]
  N6["7.7 Tarefa prática"]
  N7["7.8 Exceções"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX031"]

Desenho lógico

flowchart LR
  N0["7.1 Controles"]
  N1["7.2 Associando controles"]
  N2["7.3 Atividade prática — Laboratório A"]
  N3["7.4 Verificação"]
  N4["7.5 Risco residual"]
  N5["7.6 Caso resolvido"]
  N6["7.7 Tarefa prática"]
  N7["7.8 Exceções"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[7.1 Controles]
    |
    v
[7.2 Associando controles]
    |
    v
[7.3 Atividade prática — Laboratório A]
    |
    v
[7.4 Verificação]
    |
    v
[7.5 Risco residual]
    |
    v
[7.6 Caso resolvido]
    |
    v
[7.7 Tarefa prática]
    |
    v
[7.8 Exceções]
    |
    v
[Exemplo resolvido] --> [Exercício EX031]

Objetivos de aprendizagem

Você vai (1) descrever os principais controles disponíveis para o risco quântico; (2) associar os controles à exposição; (3) entender a criptoagilidade como objetivo de governança; (4) definir o que conta como verificação; e (5) registrar o risco residual.

7.1 Controles

Troca de chaves híbrida (X25519MLKEM768 no TLS; ML-KEM no IKEv2 por meio da RFC 9370; mlkem768x25519-sha256 no SSH). Chaves pré-compartilhadas provisórias misturadas às VPNs (RFC 8784) para enlaces fixos. Minimização de dados: enviar e guardar menos dados de vida longa. Planejamento da migração de assinaturas: AC interna pós-quântica, planos de assinatura de código, renovação de carimbos de tempo do arquivo. Cláusulas de compras: suporte a algoritmos, inventários, compromissos de atualização. Gestão de exceções: aceitação por tempo limitado com controles compensatórios.

Nem todo controle se aplica a todo item, e vários costumam ser combinados, como no caso do arquivo da MTI. Registre quais controles cada item usa.

7.2 Associando controles

Exposição HNDL → troca de chaves híbrida e minimização primeiro. Exposição de forjar depois → planos de assinatura, compras e renovação do arquivo. Desconhecido → investigação. Controlado pelo fornecedor → cláusulas contratuais e acompanhamento do roteiro.

Na MTI, as transferências do arquivo estão expostas a HNDL, então a troca de chaves híbrida e menos transferências vieram primeiro; as assinaturas dos documentos do arquivo são de forjar depois, então foram planejados um prazo para o fornecedor e a renovação dos carimbos de tempo; e o gravador de chamadas, ainda desconhecido, foi para investigação. Registre no rastreador o motivo de cada associação, para que revisores posteriores vejam por que um controle foi escolhido e possam mudá-lo se a exposição mudar.

7.3 Atividade prática — Laboratório A

# Lab A (ch 7): crypto-agility through a policy-driven registry instead of hard-coded algorithms.
import hashlib, hmac
REGISTRY = {"hmac-sha256": lambda k, m: hmac.new(k, m, hashlib.sha256).digest(),
            "hmac-sha3-256": lambda k, m: hmac.new(k, m, hashlib.sha3_256).digest()}
POLICY = {"tag-algorithm": "hmac-sha256", "accept": ["hmac-sha256", "hmac-sha3-256"]}
def protect(key, msg):
    alg = POLICY["tag-algorithm"]; return alg, REGISTRY[alg](key, msg)
def check(key, msg, alg, tag):
    if alg not in POLICY["accept"]: return False            # algorithm identifier is authenticated by policy
    return hmac.compare_digest(REGISTRY[alg](key, msg), tag)
k, m = b"k" * 32, b"policy schedule 42"
a1, t1 = protect(k, m)
POLICY["tag-algorithm"] = "hmac-sha3-256"                   # migration = one policy change
a2, t2 = protect(k, m)
print("old tag still verifies during transition:", check(k, m, a1, t1))
print("new tag verifies:", check(k, m, a2, t2), "| algorithms:", a1, "->", a2)
POLICY["accept"] = ["hmac-sha3-256"]                        # retire the old algorithm
print("old tag after retirement:", check(k, m, a1, t1))

Saída esperada:

old tag still verifies during transition: True
new tag verifies: True | algorithms: hmac-sha256 -> hmac-sha3-256
old tag after retirement: False

Quando os algoritmos são escolhidos por política e rotulados nos dados, a migração é uma mudança de configuração, e um algoritmo antigo pode ser aposentado de forma limpa. Pergunte aos responsáveis pelos sistemas e aos fornecedores se os seus produtos funcionam assim; o CSWP 39 do NIST discute essas considerações de criptoagilidade.

Pergunte aos responsáveis pelos sistemas da MTI se o algoritmo é nomeado na configuração ou fixado no código. Onde um algoritmo está fixado no código, a migração exige uma mudança de código e uma nova versão, o que leva mais tempo e deve ser planejado mais cedo. Registre a resposta no rastreador como um fator do tempo de migração do item.

7.4 Verificação

Verificação significa evidência de que o controle funciona em operação: logs de negociação mostrando híbrido no serviço pretendido, inventário de certificados mostrando os novos algoritmos, respostas de questionários confirmadas por observação, minimização confirmada por revisão dos fluxos de dados. Um ticket de mudança é evidência de intenção, não de efeito.

Na MTI, o item do SFTP das resseguradoras só foi marcado como Verificado quando os logs do sshd mostraram os parceiros negociando o método híbrido. Sem essa evidência, o item continua Implementado, por mais confiante que esteja o responsável. Peça evidências que cubram um período normal de trabalho, para que os clientes ocasionais sejam incluídos, e registre a sua data.

7.5 Risco residual

Para cada item verificado, registre o que resta: normalmente a autenticação clássica, parceiros com clientes antigos ou dispositivos aguardando substituição. Dê a cada risco residual um responsável e uma data de revisão.

No item do SFTP das resseguradoras da MTI, o risco residual eram três parceiros com clientes antigos e as chaves de host clássicas. Registrá-lo mantém o item honesto: verificado não significa concluído. Quando um risco residual for resolvido, anote a evidência e encerre-o; quando persistir além da data de revisão, considere uma exceção. Mantenha a lista curta e específica.

7.6 Caso resolvido

SFTP das resseguradoras: controle — troca de chaves SSH híbrida após a atualização do OpenSSH; verificação — os logs do sshd mostram 7 de 10 resseguradoras negociando o híbrido; residual — três resseguradoras com clientes antigos (notificadas, prazo de 12 meses), chaves de host clássicas; responsável: Infraestrutura; revisão trimestral.

Esse registro está completo porque cada parte aponta para uma evidência ou uma pessoa: o controle nomeia o método, a verificação dá uma proporção medida nos logs, o risco residual nomeia o que resta e o responsável e o ciclo de revisão dizem quem acompanha e quando. Use-o como modelo.

7.7 Tarefa prática

Para três itens da MTI, escreva o controle, a evidência de verificação e o risco residual.

Escolha itens em estados diferentes: por exemplo, os servidores SFTP das resseguradoras, o portal de sinistros e as transferências do arquivo. Para cada um, nomeie o controle, diga que evidência mostraria que ele funciona em operação e liste o que resta depois, com responsável e data de revisão. Onde a evidência ainda não existir, escreva como e quando ela será coletada. Compare os seus registros com o exemplo do SFTP das resseguradoras e preencha qualquer lacuna que encontrar.

7.8 Exceções

Quando um controle não puder ser aplicado a tempo, abra uma exceção: escopo, motivo, controles compensatórios, responsável, expiração. O patrocinador aprova; o rastreador a mostra; a expiração aciona uma revisão. Exceções são normais; exceções sem expiração não são.

Na MTI, os dois escritórios aguardando a renovação de hardware são o exemplo: PSKs provisórias como controle compensatório, expiração na renovação. Cada exceção nomeia o seu controle compensatório, para que o patrocinador saiba o que reduz o risco enquanto o controle principal aguarda. Revise as exceções abertas na reunião mensal e relate qualquer exceção vencida no relatório trimestral.

7.9 Erros comuns e limites

• Tickets de mudança aceitos como verificação.
• Risco residual omitido.
• Exceções sem expiração.

Cada erro faz o rastreador superestimar a proteção. Um ticket de mudança aceito como verificação teria escondido a regressão do portal de corretores da MTI. Omitir o risco residual faz um item parcialmente protegido parecer concluído, de modo que as chaves de host clássicas ou os clientes antigos dos parceiros saem de vista. Uma exceção sem expiração vira uma aceitação permanente que ninguém decidiu. Revise cada item Verificado e cada exceção quanto a esses três a cada trimestre. Corrija o que encontrar. Registre o que você mudou.

Exercícios

• EX031 — Associar. Associe controles a: transferências do arquivo (HNDL), AC interna (forjar depois), gravador de chamadas (desconhecido), CDN (fornecedor). Rubrica: 3 = quatro associações sensatas.
• EX032 — Evidência de verificação. No portal de corretores, o que verifica a troca de chaves híbrida? Rubrica: 3 = logs de negociação/saída de ferramenta, datados.
• EX033 — Agilidade. Usando o Laboratório A, explique por que a aposentadoria é uma mudança de política de uma linha. Rubrica: 3 = lista de aceitos, identificador nos dados.
• EX034 — Residual. Escreva a nota de risco residual do SFTP das resseguradoras. Rubrica: 3 = riscos restantes, responsável, revisão, prazo.
• EX035 — Exceção. Esboce uma exceção para o gravador de chamadas enquanto se aguarda a resposta do fornecedor. Rubrica: 3 = escopo, motivo, controles compensatórios, responsável, expiração.

Síntese

Os controles são associados à exposição, verificados por evidências operacionais e acompanhados de risco residual registrado e de exceções por tempo limitado; a agilidade torna mais barata a mudança futura.