Capítulo 22 — Segurança quântica e pós-quântica: automação | Tecnólogo Segurança quântica e pós-quântica

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 22 publicada. Mapa, exemplo, EX043.

flowchart TD
  N0["22.1 Inventário e auditorias nos pipelines"]
  N1["22.2 Seleção orientada por política"]
  N2["22.3 Atividade prática — Laboratório A"]
  N3["22.4 Gates de regressão"]
  N4["22.5 Automação de certificados"]
  N5["22.6 Caso resolvido"]
  N6["22.7 Riscos da automação"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX043"]

Desenho lógico

flowchart LR
  N0["22.1 Inventário e auditorias nos pipelines"]
  N1["22.2 Seleção orientada por política"]
  N2["22.3 Atividade prática — Laboratório A"]
  N3["22.4 Gates de regressão"]
  N4["22.5 Automação de certificados"]
  N5["22.6 Caso resolvido"]
  N6["22.7 Riscos da automação"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX043"]

[22.1 Inventário e auditorias nos pipelines]
    |
    v
[22.2 Seleção orientada por política]
    |
    v
[22.3 Atividade prática — Laboratório A]
    |
    v
[22.4 Gates de regressão]
    |
    v
[22.5 Automação de certificados]
    |
    v
[22.6 Caso resolvido]
    |
    v
[22.7 Riscos da automação]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX043]

Objetivos de aprendizagem

Você vai (1) automatizar no CI/CD o inventário, as auditorias de configuração e as verificações de negociação; (2) implementar a seleção de algoritmos orientada por política; (3) evitar regressões com gates; e (4) automatizar a emissão de certificados com consciência dos algoritmos.

22.1 Inventário e auditorias nos pipelines

Os pipelines já constroem imagens e implantam configurações; acrescente etapas que extraiam as versões das bibliotecas das imagens, comparem os perfis TLS com o perfil aprovado e atualizem a CBOM. Um pull request que muda um perfil do ingress deve mostrar a sua diferença criptográfica, assim como mostra a diferença de código.

O pipeline da KLS imprime a diferença criptográfica como um comentário no pull request: grupos acrescentados ou removidos, mudanças na ordem de preferência e versões das bibliotecas na nova imagem. Os revisores a aprovam da mesma forma que o código.

22.2 Seleção orientada por política

As aplicações que assinam ou cifram dados devem consultar os algoritmos na configuração e registrar os identificadores junto com os dados, para que a migração seja uma mudança de política.

O serviço de assinatura de manifestos da KLS guarda um identificador de algoritmo com cada assinatura, e o verificador lê na configuração quais identificadores são aceitáveis. Quando o ML-DSA estiver disponível na biblioteca de assinatura, a troca será uma edição de política seguida de um canário, e os manifestos antigos continuarão sendo verificados até que o identificador clássico seja aposentado.

Um manifesto assinado antes de os identificadores serem acrescentados é verificado contra uma lista datada de assinaturas legadas, e não supondo ECDSA; qualquer coisa fora dessa lista falha na verificação e vai para a equipe de logística para ser assinada de novo.

22.3 Atividade prática — Laboratório A

# Lab A (ch 22): 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"shipment manifest 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 laboratório modela as três fases de uma migração de algoritmo. Na transição, a política produz novas tags com HMAC-SHA3-256 enquanto a lista de aceitação ainda contém o HMAC-SHA256, então a tag antiga é verificada e nada quebra. Depois da aposentadoria, o identificador antigo é removido da lista de aceitação, e a mesma tag antiga válida agora falha. O identificador de algoritmo viaja com a tag, mas o verificador nunca confia nele por si só: ele também precisa estar na lista de aceitação da política, e é isso que impede um atacante de rerrotular uma tag para escolher um algoritmo mais fraco. A mesma estrutura se aplica às assinaturas quando o ML-DSA substituir o ECDSA.

22.4 Gates de regressão

Os gates reprovam uma implantação se: o perfil de um listener de nível 1 não tiver o grupo híbrido ou não o preferir; a biblioteca TLS de uma imagem base for mais antiga que o mínimo aprovado; uma nova dependência introduzir um algoritmo clássico fixo no código onde a política exige agilidade. Todo gate precisa de um caminho de exceção com dono e data de expiração.

As exceções da KLS são entradas YAML no repositório do gate: listener, motivo, dono e data de expiração. O gate as lê, aprova o listener listado com um aviso e volta a reprovar automaticamente quando a data de expiração passa. Isso mantém as exceções visíveis e impede que elas se tornem desvios permanentes e silenciosos.

22.5 Automação de certificados

O ACME (RFC 8555) e as APIs internas de emissão automatizam a renovação de certificados. Torne os algoritmos de chave e de assinatura solicitados parâmetros explícitos, para que passar os certificados finais internos para o ML-DSA seja uma mudança de modelo, e não de scripts. Teste a renovação de um certificado pós-quântico em homologação antes de depender dela.

O modelo interno de emissão da KLS já nomeia ecdsa-p256 como um parâmetro explícito; o piloto de ML-DSA usa o mesmo modelo com ml-dsa-44. O teste em homologação verifica se a renovação produz uma cadeia válida e se todas as partes confiantes a aceitam, antes que o modelo mude em produção.

22.6 Caso resolvido

A KLS acrescenta um job de CI, crypto-gate, que analisa os manifestos Kubernetes renderizados, extrai os grupos TLS do ingress e reprova se um ingress de nível 1 não tiver o X25519MLKEM768 em primeiro lugar. Na primeira semana, ele bloqueia duas versões que copiaram uma anotação antiga; ambas são corrigidas em minutos, em vez de serem descobertas semanas depois pelo monitoramento.

As duas versões bloqueadas tinham copiado uma anotação de um modelo de serviço antigo. A correção foi ajustar o modelo além dos dois serviços, para que o gate interrompesse o padrão na origem. O gate roda em menos de um minuto e tem um caminho de exceção documentado.

22.7 Riscos da automação

A automação multiplica os erros com a mesma eficiência com que multiplica as correções. Proteja a configuração dos pipelines com revisão, assine as definições dos pipelines onde as ferramentas permitirem e encaminhe as mudanças nos perfis centrais pelo mesmo processo de canário do código. Um perfil errado enviado automaticamente para todos os ingresses é uma grande indisponibilidade; o mesmo perfil enviado para um único ingress canário é uma indisponibilidade pequena e informativa.

A KLS aprendeu isso em homologação: uma mudança de perfil mesclada sem a etapa de canário removeu o X25519 de todos os ingresses de homologação ao mesmo tempo, quebrando o cliente de teste Java em todos os serviços. Agora as mudanças de perfil chegam primeiro a um ingress canário, e as definições dos pipelines são revisadas por duas pessoas.

22.8 Erros comuns e limites

Gates sem caminhos de exceção.
Automatizar a emissão com algoritmos fixos no código.
Enviar as mudanças dos perfis centrais para todos os lugares ao mesmo tempo.

Cada erro volta a automação contra a equipe. Um gate sem caminho de exceção é desabilitado na primeira vez que bloqueia uma versão urgente; o arquivo de exceções da KLS existe para que isso nunca aconteça. Scripts de emissão com um algoritmo fixo numa string teriam de ser reescritos para o ML-DSA, em vez de se mudar um modelo. E um perfil enviado para todos os ingresses ao mesmo tempo transforma um pequeno erro numa indisponibilidade de toda a plataforma, como mostrou o incidente em homologação.

Exercícios

EX043 — Regra do gate. Escreva o pseudocódigo de um gate que verifique a preferência pelo híbrido nos listeners de nível 1. Rubrica: 3 = analisa a lista, verifica o primeiro elemento, condição de nível, código de saída.
EX044 — Agilidade. Usando o Laboratório A, explique por que as tags antigas são verificadas durante a transição, mas não depois da aposentadoria. Rubrica: 3 = mudança da lista de aceitação, com identificador autenticado.

Síntese

A automação incorpora ao pipeline de entrega o inventário, as auditorias, a seleção orientada por política e os gates de regressão, com caminhos de exceção e implantação em etapas das mudanças centrais.