Capítulo 15 — Segurança quântica e pós-quântica: integração e dependências
Mapa da aula
Aula 15 publicada. Mapa, exemplo, EX043.
flowchart TD
N0["15.1 Todo salto conta"]
N1["15.2 Controladores"]
N2["15.3 Pedidos"]
N3["15.4 Atividade prática — Laboratório A"]
N4["15.5 Caso resolvido"]
N5["15.6 Atividade prática"]
N6["15.7 Acompanhando as dependências"]
N7["15.9 Contornando uma dependência"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX043"]
Desenho lógico
flowchart LR
N0["15.1 Todo salto conta"]
N1["15.2 Controladores"]
N2["15.3 Pedidos"]
N3["15.4 Atividade prática — Laboratório A"]
N4["15.5 Caso resolvido"]
N5["15.6 Atividade prática"]
N6["15.7 Acompanhando as dependências"]
N7["15.9 Contornando uma dependência"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX043"]
[15.1 Todo salto conta]
|
v
[15.2 Controladores]
|
v
[15.3 Pedidos]
|
v
[15.4 Atividade prática — Laboratório A]
|
v
[15.5 Caso resolvido]
|
v
[15.6 Atividade prática]
|
v
[15.7 Acompanhando as dependências]
|
v
[15.9 Contornando uma dependência]
|
v
[Exemplo resolvido] --> [Exercício EX043]
Objetivos de aprendizagem
Você vai (1) rastrear um fluxo por todos os saltos; (2) identificar quem controla cada salto; (3) preparar pedidos a fornecedores e parceiros; e (4) entender a agilidade por meio de política, e não de código.
15.1 Todo salto conta
Uma reserva de uma agência de viagem chega ao HHG pelo sistema da agência, pelo servidor de troca de arquivos, por um processador interno e pelo banco de dados de reservas. Cada salto negocia separadamente. Uma conexão híbrida num salto não diz nada sobre o seguinte.
No fluxo de reservas das agências, verifique cada salto e registre a sua evidência separadamente. Um número do painel para o servidor SFTP não cobre o processador interno nem a conexão com o banco de dados. Desenhe o fluxo com todos os saltos e marque quais têm evidência de troca de chaves híbrida e quais não têm.
15.2 Controladores
Escreva quem controla cada salto: as operações do HHG, um fornecedor, um provedor de nuvem ou um parceiro. O HHG pode mudar os seus próprios servidores; para o resto, só pode pedir, exigir em contrato ou contornar.
No fluxo de reservas dos canais, os clientes das agências são controlados pelos parceiros, o servidor SFTP e o processador interno pertencem ao HHG, e o banco de dados de reservas é um serviço gerenciado. Registre cada controlador com um contato e a via que o HHG pode usar para influenciá-lo. Mantenha a lista atualizada.
15.3 Pedidos
Um bom pedido a fornecedor ou parceiro nomeia o produto e a versão, pergunta quais algoritmos e protocolos pós-quânticos são suportados, a partir de qual versão e data, e pede um sistema de teste. Registre as respostas como evidência do fornecedor até que sejam verificadas.
No HHG, o pedido ao provedor do banco de dados gerenciado nomearia o nível de serviço, perguntaria sobre a troca de chaves híbrida nas conexões de clientes e pediria datas e um endpoint de teste. Guarde uma cópia de cada pedido e defina uma data de acompanhamento. Classifique as respostas como evidência do fornecedor.
15.4 Atividade prática — Laboratório A
# Lab A (ch 15): 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"guest folio 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
Sistemas que leem as escolhas de algoritmo de uma política conseguem mudá-las sem alterar o código. Quando perguntar aos fornecedores sobre a prontidão, pergunte se os algoritmos são configuráveis.
O script guarda o nome do algoritmo junto de cada tag e escolhe os algoritmos a partir de uma política, e não do código. Mudar a política faz as novas tags passarem a SHA3-256 enquanto as tags antigas continuam sendo verificadas, e remover o algoritmo antigo da lista de aceitos o aposenta de forma limpa. É isso que significa criptoagilidade na prática. Pergunte se o produto de um fornecedor funciona assim antes de comprá-lo.
15.5 Caso resolvido
O fluxo de SFTP dos canais: cliente da agência de viagem (parceiro) → servidor SFTP do HHG (HHG) → processador interno (HHG) → banco de dados de reservas (provedor do serviço gerenciado). Após atualizar o OpenSSH e habilitar o KEX híbrido, 5 de 9 agências negociam híbrido; quatro usam clientes antigos. O HHG envia a elas um aviso com um endpoint de teste e um prazo de doze meses.
O fluxo mostra que uma atualização no HHG protege apenas parte do caminho. Cinco agências se beneficiam agora; as outras quatro dependem das atualizações dos seus próprios clientes. Cada salto e a sua evidência entram na lista de dependências.
15.6 Atividade prática
Rastreie um fluxo do HHG com todos os saltos e controladores e redija um pedido a fornecedor.
Escolha um fluxo, como as reservas das agências ou os logins no portal do hóspede. Liste cada salto com o seu protocolo, controlador e evidência. Depois redija um pedido a fornecedor para um salto que o HHG não controla: nomeie o produto e a versão, pergunte quais algoritmos e protocolos pós-quânticos são suportados, a partir de qual versão e data, e peça um sistema de teste. Registre o tipo de resposta esperado. Confira-o com um colega.
15.7 Acompanhando as dependências
Mantenha uma lista de dependências simples: salto, controlador, pedido enviado, resposta, grau da evidência, próxima data de acompanhamento. Revise-a todo mês. Dependências que nunca recebem resposta são riscos a levar ao seu gestor, não tarefas a esquecer.
Quando chegar uma resposta, atualize o grau da evidência e a CBOM juntos. No HHG, a lista inclui as quatro agências com clientes SFTP antigos, com as datas dos avisos e o prazo de doze meses, e o pedido ao provedor do banco de dados gerenciado. Remova uma entrada somente quando o salto estiver verificado ou a dependência for formalmente aceita.
15.8 Erros comuns e limites
- Julgar um fluxo por um único salto.
- Tratar as alegações dos fornecedores como fatos.
- Nenhum acompanhamento de pedidos sem resposta.
Cada erro deixa riscos sem ser vistos. Julgar o fluxo das agências apenas pelo salto SFTP deixaria de fora o banco de dados gerenciado. A alegação de um fornecedor não é evidência até ser testada. Um pedido sem data de acompanhamento tende a ser esquecido, deixando o salto desprotegido sem que ninguém tenha decidido isso. Confira a sua lista de dependências quanto aos três todo mês. Corrija o que encontrar. Anote qualquer pedido que espere há mais de um mês.
15.9 Contornando uma dependência
Quando um controlador não puder ou não quiser mudar em breve, às vezes o HHG consegue proteger os dados de outra forma: mover a parte sensível de uma transferência para um canal que o HHG controla, reduzir o que é enviado ou terminar uma conexão híbrida num gateway do HHG próximo ao parceiro. Cada contorno precisa de aprovação e de uma entrada no registro de exceções, porque muda o desenho do serviço.
Registre a data de término de cada contorno. No HHG, o listener provisório do Summit foi uma mudança desse tipo e ficou registrado como exceção até que o firewall fosse corrigido.
Exercícios
- EX043 — Lista de saltos. Liste os saltos e controladores do fluxo do portal do hóspede. Rubrica: 3 = cliente, CDN/balanceador, aplicação, banco de dados, com os controladores.
- EX044 — Pedido a fornecedor. Escreva um pedido de quatro perguntas ao fornecedor sobre o hub das fechaduras. Rubrica: 3 = algoritmos, protocolos, versão/data, sistema de teste.
- EX045 — Pergunta de agilidade. Por que perguntar aos fornecedores se os algoritmos são configuráveis? Rubrica: 3 = mudança futura sem substituição.
Síntese
Integração significa cada salto e o seu controlador; os operadores enviam pedidos precisos, acompanham as respostas e dão preferência a produtos configuráveis.
Continue estudando — capítulo 15 de 18
← Capítulo 14 · Índice de capítulos do curso · Capítulo 16 →
Siga para a próxima lição escrita.