Capítulo 7 — Segurança quântica e pós-quântica: integração organizacional
Mapa da aula
Aula 07 publicada. Mapa, exemplo, EX031.
flowchart TD
N0["7.1 Não um projeto, uma capacidade"]
N1["7.2 Plataformas orientadas por política"]
N2["7.3 Atividade prática — Laboratório A"]
N3["7.4 Governança e direitos de decisão"]
N4["7.5 Ciclos de renovação e orçamento"]
N5["7.6 Medindo o progresso"]
N6["7.7 Caso resolvido"]
N7["Síntese"]
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 Não um projeto, uma capacidade"]
N1["7.2 Plataformas orientadas por política"]
N2["7.3 Atividade prática — Laboratório A"]
N3["7.4 Governança e direitos de decisão"]
N4["7.5 Ciclos de renovação e orçamento"]
N5["7.6 Medindo o progresso"]
N6["7.7 Caso resolvido"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[7.1 Não um projeto, uma capacidade]
|
v
[7.2 Plataformas orientadas por política]
|
v
[7.3 Atividade prática — Laboratório A]
|
v
[7.4 Governança e direitos de decisão]
|
v
[7.5 Ciclos de renovação e orçamento]
|
v
[7.6 Medindo o progresso]
|
v
[7.7 Caso resolvido]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX031]
Objetivos de aprendizagem
Você vai (1) integrar a migração para PQC aos processos de arquitetura, de mudança, de compras e de risco; (2) construir agilidade criptográfica nas plataformas por meio de políticas; (3) projetar os papéis de governança e os direitos de decisão; (4) alinhar a migração aos ciclos de renovação e aos orçamentos; e (5) medir o progresso do programa de forma significativa.
7.1 Não um projeto, uma capacidade
Uma migração conduzida como um projeto separado termina com um relatório e deixa a organização tão rígida quanto antes. Integrada aos processos normais, ela deixa uma capacidade: as revisões de arquitetura perguntam sobre algoritmos e agilidade; a gestão de mudanças registra as mudanças criptográficas; as compras exigem inventários e suporte a algoritmos; a gestão de riscos acompanha a exposição quântica. O CSWP 39 enquadra isso como agilidade criptográfica tanto no nível organizacional quanto no técnico.
Na NRHT, a Autoridade de Criptografia é o mecanismo para isso: ela é responsável pela norma criptográfica e revisa as decisões de arquitetura, enquanto as compras acrescentam cláusulas aos contratos. Meça a integração por se os processos normais agora fazem perguntas criptográficas sem que a equipe do programa os provoque.
7.2 Plataformas orientadas por política
As plataformas que leem as escolhas criptográficas de uma política permitem à organização mudar os algoritmos por configuração. O identificador do algoritmo precisa viajar com os dados e ser autenticado, para que um verificador possa recusar um algoritmo aposentado.
O Laboratório A mostra o padrão com códigos de autenticação de mensagens, mas o mesmo projeto se aplica aos KEMs e às assinaturas. Uma plataforma construída assim consegue passar do clássico ao híbrido, e depois a um novo algoritmo, com uma mudança de política e um período de transição. Os algoritmos fixos no código exigem novas versões de código a cada mudança.
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"discharge summary 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
O mesmo padrão — registro, política, lista de aceitos, aposentadoria — se aplica aos KEMs e às assinaturas nas plataformas reais.
O laboratório registra o identificador do algoritmo com cada tag e o confere com a lista de aceitos, para que um algoritmo aposentado possa ser recusado. Durante a transição, os dois algoritmos verificam; depois da aposentadoria, a tag antiga falha. Numa plataforma real, o identificador precisa ser protegido pela própria tag ou assinatura, para que um atacante não consiga mudá-lo. Tente aposentar o algoritmo antigo antes de trocar o padrão e anote o que quebra.
7.4 Governança e direitos de decisão
Defina quem decide a política criptográfica (uma autoridade ou um conselho de criptografia), quem é responsável pela implementação de cada plataforma, quem aprova as exceções e quem aceita o risco residual. Publique uma norma criptográfica que liste os algoritmos e parâmetros aprovados, as datas de transição e o processo de exceção.
Escreva os direitos de decisão na norma e publique-os, para que os responsáveis pelas plataformas saibam a quem perguntar. As exceções devem ser limitadas no tempo e registradas num registro que a Autoridade de Criptografia revisa. Na NRHT, o CISO preside a autoridade e o executivo responsável assina as aceitações de risco residual.
7.5 Ciclos de renovação e orçamento
A maior parte do hardware é substituída em ciclos de cinco a dez anos. Alinhar os requisitos de PQC a esses ciclos evita a substituição prematura; isso exige cláusulas de compras agora, para que o equipamento comprado em 2027 não precise ser substituído em 2031. As assinaturas de software são mais rápidas; exija roteiros com datas.
Associe cada plataforma do nível 1 à sua próxima data de renovação e à cláusula que vai se aplicar à sua substituição. Onde uma renovação cair depois da data em que a migração é necessária, planeje uma medida provisória, como um gateway ou uma PSK. Na NRHT, a substituição da frota de bombas de infusão em 2031 está planejada dessa forma.
7.6 Medindo o progresso
Conte resultados, e não atividades: a parcela dos fluxos do nível 1 com troca de chaves híbrida (evidência de grau A/B); a parcela dos novos contratos com cláusulas de PQC; o tempo mediano para mudar um algoritmo nas plataformas orientadas por política; a parcela de desconhecidos do nível 1. Evite métricas de vaidade, como "número de reuniões realizadas".
Relate cada métrica com a sua fonte e o seu grau de evidência, e mostre as tendências ao longo dos trimestres. Na revisão do segundo ano da NRHT, a cobertura híbrida do nível 1 era de 64 % com evidência de grau A ou B, e a parcela de desconhecidos era de 7 %. Métricas sem denominador ou sem fonte não devem aparecer nos relatórios ao conselho.
7.7 Caso resolvido
A NRHT cria uma Autoridade de Criptografia presidida pelo CISO, com membros de arquitetura, PKI, engenharia clínica e compras. A sua norma (sintética) define o híbrido com ML-KEM-768 como padrão para o novo estabelecimento de chaves, exige identificadores de algoritmo nos novos formatos de dados e acrescenta cláusulas de PQC a todos os contratos acima de um limiar. As métricas de progresso são revisadas trimestralmente pelo comitê de auditoria.
As primeiras decisões da autoridade são registradas com os seus motivos e datas de revisão, para que os membros posteriores vejam por que os padrões foram escolhidos. A sua norma é curta o bastante para que os responsáveis pelas plataformas a leiam e inclui o processo de exceção. A composição abrange as equipes cujos sistemas vão mudar.
7.8 Erros comuns e limites
- Tratar a migração como um projeto pontual.
- Nenhum processo de exceção, o que leva à não conformidade silenciosa.
- Métricas de atividade em vez de métricas de resultado.
Cada erro tem uma salvaguarda. Integre as perguntas criptográficas aos processos de arquitetura, de mudança e de compras. Publique um processo de exceção com expirações. Relate resultados como a cobertura com graus de evidência, e não contagens de reuniões ou de documentos produzidos. Na NRHT, a norma da Autoridade de Criptografia inclui um processo de exceção com datas de expiração, e as suas métricas de progresso são revisadas trimestralmente pelo comitê de auditoria. Confira se cada nova métrica tem denominador e fonte antes de acrescentá-la ao relatório ao conselho.
Exercícios
- EX031 — Pontos de integração. Nomeie quatro processos existentes nos quais os requisitos de PQC devem ser integrados, com um requisito para cada. Rubrica: 3 = quatro processos, requisitos concretos.
- EX032 — Direitos de decisão. Esboce uma matriz RACI para "aprovar uma exceção à troca de chaves híbrida". Rubrica: 3 = responsável, aprovador, consultado e informado atribuídos com sensatez.
- EX033 — Alinhamento com a renovação. A substituição de um PACS está programada para 2029. O que a licitação de 2026 precisa incluir? Rubrica: 3 = suporte a algoritmos, agilidade, inventário, compromissos de atualização.
- EX034 — Métrica de resultado. Converta "sessões de conscientização sobre PQC realizadas" numa métrica de resultado. Rubrica: 3 = mudança mensurável de comportamento ou de estado.
- EX035 — Teste de agilidade. Projete um teste trimestral que mostre que uma plataforma consegue trocar de algoritmo por política. Rubrica: 3 = procedimento, evidência, critério de aprovação.
Síntese
A integração transforma a migração numa capacidade organizacional: plataformas orientadas por política, direitos de decisão claros, compras alinhadas aos ciclos de renovação e métricas de resultado.
Continue estudando — capítulo 07 de 12
← Capítulo 06 · Índice de capítulos do curso · Capítulo 08 →
Siga para a próxima lição escrita.