Capítulo 19 — Segurança quântica e pós-quântica: monitoramento
Mapa da aula
Aula 19 publicada. Mapa, exemplo, EX037.
flowchart TD
N0["19.1 O que registrar"]
N1["19.2 Painéis e alertas"]
N2["19.3 Atividade prática — Laboratório K"]
N3["19.4 Atraso e cobertura"]
N4["19.5 Caso resolvido"]
N5["19.7 Privacidade dos logs"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX037"]
Desenho lógico
flowchart LR
N0["19.1 O que registrar"]
N1["19.2 Painéis e alertas"]
N2["19.3 Atividade prática — Laboratório K"]
N3["19.4 Atraso e cobertura"]
N4["19.5 Caso resolvido"]
N5["19.7 Privacidade dos logs"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX037"]
[19.1 O que registrar]
|
v
[19.2 Painéis e alertas]
|
v
[19.3 Atividade prática — Laboratório K]
|
v
[19.4 Atraso e cobertura]
|
v
[19.5 Caso resolvido]
|
v
[19.7 Privacidade dos logs]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX037]
Objetivos de aprendizagem
Você vai (1) registrar em log os algoritmos negociados nos serviços TLS, SSH e VPN; (2) construir painéis e alertas para a fração híbrida e o recuo; (3) usar limites de confiança nas decisões de canário; e (4) lidar com o atraso da medição.
19.1 O que registrar
TLS: grupo negociado, versão do protocolo, suíte de cifras, algoritmo de assinatura do certificado (do lado do servidor), indícios da biblioteca do cliente, se disponíveis. SSH: algoritmo de KEX e algoritmo da chave de host. VPN: métodos de troca de chaves por túnel. Muitos servidores conseguem registrar isso com mudanças de configuração; acrescente campos aos logs de acesso, em vez de habilitar logs de depuração detalhados em produção.
O log de acesso do ingress da KLS ganhou três campos: grupo negociado, versão do TLS e suíte de cifras. Os hosts sshd registram o algoritmo de KEX por sessão no nível padrão depois de uma pequena mudança de configuração, e o appliance de VPN exporta os parâmetros dos túneis para a plataforma de logs. Juntos, eles alimentam o painel de fração híbrida sem nenhum log de depuração em produção.
19.2 Painéis e alertas
Por serviço e local: fração híbrida, fração de recuo, taxa de falhas de handshake por causa. Alertas: a fração híbrida cai mais de cinco pontos em uma hora (reversão ou configuração errada); a taxa de falhas excede o orçamento durante a implantação.
A KLS escolheu a regra dos cinco pontos depois de observar um mês de variação normal: a fração híbrida horária no gateway variou no máximo dois pontos sem nenhuma mudança. Uma queda de cinco, portanto, sinaliza um evento real, enquanto o piso absoluto de 90 % apanha a deriva lenta. Cada alerta tem um link para o runbook de queda da fração híbrida.
19.3 Atividade prática — Laboratório K
# Lab K (ch 19): canary gate for enabling a hybrid group - promote only if failures stay within budget.
import math
def upper95(k, n): # Wilson upper bound
z = 1.96; p = k / n; d = 1 + z*z/n
return ((p + z*z/(2*n)) + z*math.sqrt(p*(1-p)/n + z*z/(4*n*n))) / d
baseline, budget = 5e-4, 4e-4 # baseline failure rate, allowed increase
for stage, k, n in [("1% canary", 3, 5000), ("10% canary", 28, 50000), ("10% canary (proxy site)", 96, 50000)]:
ub = upper95(k, n); ok = ub <= baseline + budget
print(f"{stage:24s} {k}/{n} upper95={ub:.5f} {'PROMOTE' if ok else 'HOLD'}")
Saída esperada:
1% canary 3/5000 upper95=0.00176 HOLD
10% canary 28/50000 upper95=0.00081 PROMOTE
10% canary (proxy site) 96/50000 upper95=0.00234 HOLD
O gate compara o limite superior de Wilson de 95 % da taxa de falhas observada com a linha de base de 0,05 % mais um orçamento de 0,04 %, um teto de 0,09 %. O canário de 1 % viu apenas 3 falhas em 5.000 handshakes, uma taxa de 0,06 %, mas, com tão poucos ensaios, o limite superior é 0,176 %, então o gate diz HOLD: não é evidência de dano, apenas não há evidência suficiente de segurança. Com 10 %, 28 em 50.000 dão um limite de 0,081 % e o gate promove. Os 96 em 50.000 do local com proxy são uma elevação real, 0,19 % observado, e ficam retidos para investigação.
19.4 Atraso e cobertura
Os logs podem chegar com minutos ou dias de atraso; as mudanças do lado dos parceiros só ficam visíveis quando os parceiros se conectam. Anote nos painéis a cobertura e o atraso, para que as decisões usem a janela de tempo certa.
Na KLS, os logs do ingress chegam em até dois minutos, o appliance de VPN exporta de hora em hora, e as evidências do SFTP dos parceiros só aparecem quando o job noturno de cada parceiro roda. O painel mostra o horário do último dado de cada painel, e as decisões de canário no SFTP esperam pelo menos uma semana inteira, para que todos os parceiros tenham se conectado.
Dois parceiros da KLS só enviam no fim do mês, então uma janela de SFTP de uma semana os reportaria como não testados, e não como falhando; o painel os lista separadamente, com a data da última conexão.
19.5 Caso resolvido
A KLS acrescenta $ssl_curve (ou o equivalente do produto) aos logs do ingress e constrói um painel. Uma semana depois, o alerta dispara: a fração híbrida no portal do cliente caiu de 93 % para 4 % depois de uma versão. Causa: a versão restaurou uma anotação antiga do ingress. A reversão da anotação restaurou a fração em uma hora.
Dois detalhes tornaram a recuperação rápida. O alerta tinha um link para um runbook que começava com "comparar o hash do perfil em produção com o aprovado", o que apontou diretamente para a anotação. E, como o perfil era versionado separadamente, a correção restaurou a anotação sem reverter a versão. O gate de CI do Capítulo 22 foi acrescentado depois, para que a mesma anotação não pudesse ser entregue de novo.
19.6 Erros comuns e limites
- Log de depuração em produção.
- Monitorar as falhas, mas não o recuo.
- Ignorar o atraso nas decisões.
A KLS considerou ativar o log de depuração TLS completo para ver as negociações e o rejeitou: o volume teria sobrecarregado a plataforma de logs e registrado mais detalhes dos clientes do que o necessário. O seu primeiro painel mostrava apenas as falhas, então a queda silenciosa do portal de 93 % para 4 % de híbrido teria sido invisível. E um canário quase foi promovido com base em uma hora de dados da VPN que, por causa da exportação horária, na verdade descreviam a hora anterior.
19.7 Privacidade dos logs
Os logs de negociação contêm endereços de clientes e datas e horas. Registre apenas o que o monitoramento precisa — campos de algoritmo, serviço, local e identificadores de cliente grosseiros — e aplique as mesmas regras de retenção e de acesso dos outros logs operacionais. As métricas agregadas podem ser mantidas por mais tempo do que os logs brutos. Isso mantém o monitoramento coerente com as obrigações de privacidade e reduz o valor dos logs para um atacante.
Ao compartilhar painéis com fornecedores ou parceiros durante um diagnóstico conjunto, exporte visões agregadas em vez de extratos de logs brutos e remova os identificadores dos clientes.
Exercícios
- EX037 — Regra de alerta. Escreva uma regra de alerta para a fração híbrida no gateway de API. Rubrica: 3 = métrica, limite, janela, ação.
- EX038 — Leitura do canário. Usando o Laboratório K, decida o que fazer com o canário de 10 % no local com proxy e por quê. Rubrica: 3 = reter, investigar o proxy, excluir/corrigir.
Síntese
Registrar os algoritmos negociados permite painéis e alertas que apanham o recuo e as falhas; os gates de canário usam limites de confiança, com o atraso e a cobertura visíveis.
Continue estudando — capítulo 19 de 30
← Capítulo 18 · Índice de capítulos do curso · Capítulo 20 →
Siga para a próxima lição escrita.