Capítulo 14 — Segurança quântica e pós-quântica: automação
Mapa da aula
Aula 14 publicada. Mapa, exemplo, EX040.
flowchart TD
N0["14.1 Verificações rotineiras"]
N1["14.2 Atividade prática — Laboratório K"]
N2["14.3 Após as janelas de patches"]
N3["14.4 Scripts fáceis de manter"]
N4["14.5 Caso resolvido"]
N5["14.6 Atividade prática"]
N6["14.7 Automação e escopo"]
N7["14.9 Qualidade dos alertas"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX040"]
Desenho lógico
flowchart LR
N0["14.1 Verificações rotineiras"]
N1["14.2 Atividade prática — Laboratório K"]
N2["14.3 Após as janelas de patches"]
N3["14.4 Scripts fáceis de manter"]
N4["14.5 Caso resolvido"]
N5["14.6 Atividade prática"]
N6["14.7 Automação e escopo"]
N7["14.9 Qualidade dos alertas"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]
[14.1 Verificações rotineiras]
|
v
[14.2 Atividade prática — Laboratório K]
|
v
[14.3 Após as janelas de patches]
|
v
[14.4 Scripts fáceis de manter]
|
v
[14.5 Caso resolvido]
|
v
[14.6 Atividade prática]
|
v
[14.7 Automação e escopo]
|
v
[14.9 Qualidade dos alertas]
|
v
[Exemplo resolvido] --> [Exercício EX040]
Objetivos de aprendizagem
Você vai (1) automatizar verificações rotineiras da negociação e da configuração; (2) usar limites de confiança para decidir quando uma etapa de implantação é segura; (3) agendar verificações após patches; e (4) manter os scripts fáceis de manter.
14.1 Verificações rotineiras
Agende scripts para: executar diariamente uma verificação de cliente contra cada serviço no escopo; analisar os logs quanto à proporção híbrida; auditar as exportações de configuração quanto à presença e à preferência. Envie os resultados ao painel e gere alertas quando houver mudanças.
No HHG, o job noturno contra 14 endpoints é um exemplo. Guarde os resultados com datas, para que cada execução possa ser comparada com a anterior, e garanta que todo alvo esteja no escopo. Gere alertas apenas para mudanças que exijam ação. Mantenha os scripts sob controle de versão junto com a sua lista de alvos e revise os dois juntos.
14.2 Atividade prática — Laboratório K
# Lab K (ch 14): 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
Quando uma mudança é implantada em etapas, a decisão de passar à etapa seguinte deve usar o limite superior de confiança da taxa de falhas, e não apenas a taxa observada. Uma amostra pequena pode parecer boa por sorte.
O script calcula um limite superior de Wilson da taxa de falhas em cada etapa e promove apenas se ele ficar dentro da linha de base mais a margem. A primeira etapa fica retida porque 5.000 conexões são poucas para haver confiança, mesmo que a taxa observada esteja boa. A etapa de 10 % é promovida. O site com proxy fica retido porque a sua taxa de falhas está claramente acima da margem, o que aponta para uma falha. Mude as contagens e veja quando cada decisão muda.
14.3 Após as janelas de patches
Execute automaticamente o conjunto completo de verificações após cada janela de patches e compare com a execução anterior. As diferenças vão para o operador de plantão.
No HHG, essa comparação encontrou dois endpoints que tinham passado de híbrido a clássico após um patch do balanceador de carga. Escreva a comparação de modo que uma diferença nomeie o endpoint, o resultado anterior e o novo, e inclua um link para o runbook. Guarde a saída completa de cada execução. Confira a saída antes da próxima janela de patches. Registre quem revisou cada diferença.
14.4 Scripts fáceis de manter
Controle de versão, um README, entradas e saídas claras, mensagens de erro que digam o que deu errado e um pequeno teste com entrada conhecida. Evite senhas embutidas no código; use o cofre de segredos aprovado.
No HHG, o script de verificação noturna é mantido sob controle de versão junto com a sua lista de alvos e uma entrada de teste. Revise as mudanças nos scripts da mesma forma que as mudanças de configuração e registre quem mantém cada script. Escreva mensagens de erro que digam o que deu errado e onde, para que o operador de plantão possa agir sem ler o código.
14.5 Caso resolvido
O HHG agenda um job noturno que executa verificações com openssl s_client contra 14 endpoints de homologação e de produção no escopo, extrai o grupo negociado e grava um CSV. Um diff com a noite anterior sinaliza dois endpoints que passaram de híbrido a clássico após um patch do balanceador de carga; o operador da manhã restaura o perfil.
O job encontrou uma regressão que não causou erros, e o operador da manhã pôde agir antes que hóspedes ou parceiros percebessem. O diff tornou a mudança óbvia sem que ninguém precisasse ler 14 conjuntos de saída.
14.6 Atividade prática
Escreva um script que leia uma lista de hosts de laboratório, execute uma verificação TLS em cada um e imprima o host e o grupo negociado.
Leia os hosts de um arquivo, um por linha, e execute openssl s_client contra cada um com um timeout. Extraia o grupo negociado da saída, imprima o host e o grupo e marque o host como desconhecido se a verificação falhar. Imprima o número de hosts lidos. Teste-o apenas nos seus hosts de laboratório. Acrescente um pequeno arquivo de teste com a saída esperada, para que um colega possa verificar o script depois de alterá-lo.
14.7 Automação e escopo
Verificações automatizadas continuam sendo verificações: precisam estar dentro do escopo escrito, rodar em horários combinados e parar se um alvo se comportar de forma inesperada. Mantenha a lista de alvos no repositório, revisada como código, para que ninguém acrescente por acidente um host fora do escopo.
No HHG, os 14 endpoints do job noturno estão na lista de alvos revisada, cada um com a sua referência de escopo. Revise a lista de alvos sempre que o escopo mudar e remova os hosts que não estiverem mais no escopo. Faça o job parar e alertar se um alvo responder de forma inesperada.
14.8 Erros comuns e limites
- Promover uma etapa com base numa amostra pequena e afortunada.
- Scripts com segredos embutidos.
- Listas de alvos não revisadas.
Cada erro cria risco. Promover uma etapa com base numa amostra pequena pode deixar uma falha chegar a todos os usuários, e é por isso que o Laboratório K usa um limite superior. Segredos embutidos em scripts vazam pelo controle de versão e pelos logs. Uma lista de alvos não revisada pode acrescentar um host fora do escopo, e o job então o testará todas as noites. Confira a sua automação quanto aos três antes de agendá-la. Corrija-os primeiro.
14.9 Qualidade dos alertas
Um alerta que dispara todas as noites por uma exceção conhecida e aceita ensina os operadores a ignorar alertas. Suprima explicitamente as exceções conhecidas, com uma data de expiração que coincida com o registro da exceção, e revise as supressões todo mês. Cada alerta deve ter um link para o seu runbook, para que a pessoa acordada às 03:00 saiba o que fazer primeiro.
No HHG, o listener provisório do Summit deve ser suprimido apenas até a sua exceção expirar. Registre cada supressão com o motivo e o responsável, e remova-a quando a exceção for encerrada. Conte a cada mês os alertas que não exigiram ação.
Exercícios
- EX040 — Decisão de etapa. Usando o Laboratório K, explique por que o primeiro canário fica retido. Rubrica: 3 = limite superior acima da margem por causa da amostra pequena.
- EX041 — Alerta por diff. Descreva como um diff noturno detecta o fallback silencioso. Rubrica: 3 = comparar o grupo negociado por host, alertar em híbrido→clássico.
- EX042 — Higiene de scripts. Liste quatro características de um script de verificação fácil de manter. Rubrica: 3 = controle de versão, README, erros claros, teste.
Síntese
A automação executa as verificações rotineiras, controla as etapas de implantação com limites de confiança, reverifica após patches e permanece dentro do escopo e fácil de manter.
Continue estudando — capítulo 14 de 18
← Capítulo 13 · Índice de capítulos do curso · Capítulo 15 →
Siga para a próxima lição escrita.