Capítulo 30 — Laboratório de verificação I
Mapa da aula
Aula 30 publicada. Mapa, exemplo, EX088.
flowchart TD
N0["30.1 Plano"]
N1["30.2 Execução"]
N2["30.3 Relatório"]
N3["30.2b Fixtures de referência"]
N4["30.3b Executor independente"]
N5["30.1b Retenção dos dados do laboratório"]
N6["Nota de prática"]
N7["30.4b O que a primeira execução do laboratório provo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX088"]
Desenho lógico
flowchart LR
N0["30.1 Plano"]
N1["30.2 Execução"]
N2["30.3 Relatório"]
N3["30.2b Fixtures de referência"]
N4["30.3b Executor independente"]
N5["30.1b Retenção dos dados do laboratório"]
N6["Nota de prática"]
N7["30.4b O que a primeira execução do laboratório provo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX088"]
[30.1 Plano]
|
v
[30.2 Execução]
|
v
[30.3 Relatório]
|
v
[30.2b Fixtures de referência]
|
v
[30.3b Executor independente]
|
v
[30.1b Retenção dos dados do laboratório]
|
v
[Nota de prática]
|
v
[30.4b O que a primeira execução do laboratório provo]
|
v
[Exemplo resolvido] --> [Exercício EX088]
Objetivos de aprendizagem
Você vai (1) executar um plano de verificação contra o TrackScope; (2) registrar aprovado/reprovado com hashes de evidência; (3) parar o laboratório se um teste de segurança falhar.
30.1 Plano
Testes: permitir dentro do escopo; negar a lista de exclusão; negar porta inválida; falhar fechado com política ausente; etapa de horário; etapa de concorrência. Cada linha: id, preparação, ação, esperado, caminho da evidência. Linhas com ids e caminhos de evidência esperados tornam o laboratório executável por alguém que não escreveu a funcionalidade. A falha fechada com política ausente fica ao lado dos casos de permissão mais felizes, para que não possa ser pulada. Sam imprime o plano como uma lista de verificação que o executor independente rubrica com um carimbo de tempo UTC. Numa release, um hotfix entrou às 14:02 UTC enquanto o relatório do laboratório mostrava as rubricas às 14:10 UTC; o carimbo provou que a execução verde foi contra o hotfix, não contra a construção quebrada.
30.2 Execução
Use só hosts sintéticos. Capture a stdout e os hashes de configuração. Qualquer falha de segurança (falha aberta) para o laboratório e abre um ticket bloqueador — nada de "continuar para coletar dados".
"""Evaluate proposed actions against synthetic rules of engagement."""
ROE = {
"hours": ("09:00", "17:00"),
"deny_actions": {"denial-of-service", "phishing-staff", "exfiltrate-real-data"},
"require_approval": {"password-spray-lab", "privilege-escalation-lab"},
"max_concurrency": 5,
}
proposals = [
("service-enum", "10:30", 3, False),
("denial-of-service", "10:30", 1, False),
("password-spray-lab", "10:30", 2, False),
("password-spray-lab", "10:30", 2, True),
("service-enum", "18:00", 2, False),
("service-enum", "11:00", 20, False),
]
def ok_time(t):
return ROE["hours"][0] <= t <= ROE["hours"][1]
for action, when, conc, approved in proposals:
reasons=[]
if action in ROE["deny_actions"]: reasons.append("deny-action")
if action in ROE["require_approval"] and not approved: reasons.append("needs-approval")
if not ok_time(when): reasons.append("outside-hours")
if conc > ROE["max_concurrency"]: reasons.append("concurrency")
print(f"action={action:20} when={when} conc={conc:2} approved={approved} -> {'ALLOW' if not reasons else 'DENY'} {','.join(reasons) or '-'}")
Saída esperada:
action=service-enum when=10:30 conc= 3 approved=False -> ALLOW -
action=denial-of-service when=10:30 conc= 1 approved=False -> DENY deny-action
action=password-spray-lab when=10:30 conc= 2 approved=False -> DENY needs-approval
action=password-spray-lab when=10:30 conc= 2 approved=True -> ALLOW -
action=service-enum when=18:00 conc= 2 approved=False -> DENY outside-hours
action=service-enum when=11:00 conc=20 approved=False -> DENY concurrency
Hosts sintéticos mantêm o laboratório dentro da fronteira de segurança do curso. Um resultado de falha aberta é um bloqueador, não um dado para terminar depois. Capturar hashes de configuração amarra a execução a uma construção conhecida. O script de laboratório de Sam aborta as linhas restantes quando qualquer linha de segurança falha, e essas linhas bloqueadas mantêm caminhos de evidência vazios até uma nova execução completa, para que ninguém consiga colar um log parcial num dossiê de release.
30.3 Relatório
Um relatório de laboratório de uma página: versão do ambiente, tabela de resultados, bloqueadores abertos, aprovação. Anexe os hashes. Hashes vencem capturas de tela que não podem ser reverificadas. A falha de política ausente que parou uma release mostra por que a lista de bloqueadores do relatório importa. Sam anexa o relatório sob a mesma tag do binário. Quando o Laboratório I reprovou na linha de política ausente, o relatório devolvido voltou pela mesma fila de revisão de um pacote novo, com o id do ticket bloqueador impresso no topo, para que os gerentes de release não deixassem de ver por que o trem parou.
Caso sintético — Riverstone Transit. O Laboratório I reprovou uma vez na linha de política ausente; a release ficou parada até que o S-3 fosse corrigido (Capítulo 21).
30.4 Erros e limites
Laboratórios em clientes compartilhados colidem; reserve o ambiente sintético. Ambientes sintéticos compartilhados precisam de reserva, da mesma forma que janelas de produção. Colisões produzem falhas instáveis que ensinam as pessoas a ignorar o vermelho do laboratório. O calendário de Sam bloqueia o ambiente e publica o link da reserva no ticket do laboratório, e uma execução sem reserva é descartada mesmo que todas as linhas pareçam verdes. Execuções descartadas guardam os logs sob uma tag de falha; no último período, três tags de falha tinham a mesma causa raiz — duas equipes reservando o ambiente sintético para a mesma sexta-feira —, e é por isso que o calendário agora rejeita sobreposições.
30.2b Fixtures de referência
Mantenha um diretório selado de fixtures sintéticos com decisões esperadas conhecidas. As execuções de laboratório precisam bater por hash com o conjunto de fixtures antes de contar como evidência de release. Fixtures derivam quando alguém os "corrige" para combinar com uma construção com bug — proteja-os com CODEOWNERS. CODEOWNERS nos fixtures impede edições silenciosas que escondem bugs. O processo de mudança de fixtures de Sam exige uma atualização pareada das decisões esperadas e um segundo revisor que não seja autor da construção sob teste, para que um binário com bug não possa ser escondido editando discretamente as respostas de referência.
30.3b Executor independente
O Laboratório I é executado por alguém que não implementou a mudança sob teste. Trabalhar em par é bom para depurar depois; o aprovado registrado precisa de uma lista de verificação verde independente. Independência é questão de incentivos, não de desconfiança da competência. Sam designa executores a partir de uma escala rotativa publicada toda sexta-feira para a semana seguinte, e o líder do laboratório resolve conflitos para que o autor de uma mudança nunca seja o executor registrado dessa mudança. O nome de quem executou fica registrado no relatório do laboratório, ao lado do hash do binário.
30.1b Retenção dos dados do laboratório
Logs de resultados do laboratório são evidência; retenha-os com a tag da release. Apagar logs verdes do laboratório para economizar espaço destrói a capacidade de investigar uma regressão posterior. Logs verdes explicam regressões posteriores quando um hotfix alega que nada mudou. A retenção amarrada à tag da release torna o vínculo mecânico. Os scripts de exclusão de Sam recusam caminhos de laboratório ainda referenciados por uma tag viva e imprimem a tag que os referencia, para que os operadores saibam o que quebraria. Um quase-incidente no último trimestre gerou um alerta quando um operador tentou rm num caminho de laboratório ainda referenciado por TrackScope-v0.9.2; o alerta incluía o comando recusado e o id do usuário, e a tag ficou intacta.
Nota de prática
Fotografe ou exporte o inventário do ambiente do laboratório (versões de pacotes, kernel, ids das chaves de política) para o relatório do laboratório. Um "passou na minha máquina" sem inventário não é evidência transferível. O Laboratório I existe para criar confiança transferível para pessoas que não estavam na sala, inclusive você mesmo numa revisão de incidente seis meses depois.
30.4b O que a primeira execução do laboratório provou
A primeira execução de verificação provou que o TrackScope nega todo endereço fora do escopo no conjunto de fixtures de referência e registra cada negação com a regra que disparou. Não provou o comportamento sob requisições concorrentes nem com arquivos de escopo malformados; Sam lista esses pontos como itens abertos para o Laboratório II. Nomear os itens abertos, concorrência e arquivos malformados, impede que o Laboratório I prometa demais. Negar tudo nos fixtures de referência é necessário e não suficiente. Sam copia esses itens abertos para o plano do Laboratório II no primeiro dia do sprint seguinte.
Exercícios
- EX088 — Linha. Escreva a linha de laboratório de falha fechada. Rubrica: 3 = linha completa; 2 = parcial; 1 = vago; 0 = nada.
- EX089 — Regra de parada. O que acontece numa falha aberta? Rubrica: 3 = parar, bloqueador, nenhum uso em engajamento; 2 = só uma nota; 1 = continuar; 0 = nada.
- EX090 — Evidência. Cite três hashes a anexar. Rubrica: 3 = política, binário/versão, log de resultados; 2 = dois; 1 = um; 0 = nada.
Síntese
Verifique a segurança primeiro; pare na falha aberta; faça hash de tudo.
Continue estudando — capítulo 30 de 50
← Capítulo 29 (rascunho) · Índice de capítulos do curso · Capítulo 31 (rascunho) →