Capítulo 34 — Segurança ofensiva autorizada e red team: integração
Mapa da aula
Aula 34 publicada. Mapa, exemplo, EX100.
flowchart TD
N0["34.1 Contrato de eventos"]
N1["34.2 Consumidores idempotentes"]
N2["34.3 Testes de contrato"]
N3["34.2b Eventos envenenados"]
N4["34.3b Treino de evolução de esquema"]
N5["34.1b Filas de mensagens mortas"]
N6["Nota de prática"]
N7["34.4b Propriedade do contrato de eventos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX100"]
Desenho lógico
flowchart LR
N0["34.1 Contrato de eventos"]
N1["34.2 Consumidores idempotentes"]
N2["34.3 Testes de contrato"]
N3["34.2b Eventos envenenados"]
N4["34.3b Treino de evolução de esquema"]
N5["34.1b Filas de mensagens mortas"]
N6["Nota de prática"]
N7["34.4b Propriedade do contrato de eventos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX100"]
[34.1 Contrato de eventos]
|
v
[34.2 Consumidores idempotentes]
|
v
[34.3 Testes de contrato]
|
v
[34.2b Eventos envenenados]
|
v
[34.3b Treino de evolução de esquema]
|
v
[34.1b Filas de mensagens mortas]
|
v
[Nota de prática]
|
v
[34.4b Propriedade do contrato de eventos]
|
v
[Exemplo resolvido] --> [Exercício EX100]
Objetivos de aprendizagem
Você vai (1) integrar os eventos do TrackScope ao FindingsDesk; (2) definir consumidores idempotentes; (3) testar contratos com fixtures.
34.1 Contrato de eventos
Eventos de negação/permissão: versão do esquema, ids, carimbos de tempo (UTC), alvos, motivos. Os consumidores ignoram campos desconhecidos; os produtores permanecem aditivos. Carimbos de tempo em UTC e esquemas aditivos mantêm os consumidores compatíveis. Ignorar campos desconhecidos é obrigatório para que os produtores possam evoluir. Sam publica o contrato num repositório de que as duas equipes são donas, com exemplos para cada código de motivo. Os exemplos são fixtures de referência; mudá-los exige a revisão do dono do contrato. Quando um produtor e um exemplo discordam, as implantações param até que o pacote bata — a mesma disciplina que impediu a tempestade de reprodução de gerar tickets duplicados depois que a idempotência por event_id entrou.
34.2 Consumidores idempotentes
O FindingsDesk indexa os eventos processados pelo event_id. Reproduzir o log não pode criar achados duplicados. Chaves por event_id transformam a reprodução de um bug de duplicação numa ferramenta de recuperação. Os três tickets duplicados na história da tempestade são o conto de advertência. A suíte de consumidores de Sam inclui um fixture de entrega dupla para cada tipo de evento. Os fixtures de entrega dupla afirmam que a contagem de tickets fica em um depois da reprodução, contando pela API de achados em vez de usar grep nos logs, porque a rotação de logs durante a tempestade de reprodução teria escondido as três duplicatas que primeiro expuseram o bug.
34.3 Testes de contrato
JSON de fixture para cada código de motivo; os testes do consumidor afirmam os campos resultantes do ticket. Rode na CI sobre fixtures sintéticos. Fixtures por código de motivo prendem os campos do ticket ao contrato. A CI sobre JSON sintético pega quebras antes dos engajamentos. Sam exige que o PulseMap e o FindingsDesk consumam o mesmo pacote de fixtures. Os pacotes de fixtures compartilhados ficam no repositório do contrato, não copiados para cada serviço. A CI faz hash do pacote e reprova qualquer árvore de serviço que contenha uma cópia divergente, e foi assim que o PulseMap e o FindingsDesk continuaram nos mesmos fixtures de códigos de motivo depois que o catálogo ganhou resume-expired.
Caso sintético — Riverstone Transit. Uma tempestade de reprodução duplicou três tickets até que a idempotência por event_id entrou.
34.4 Erros e limites
A diferença de relógio entre hosts embaralha as linhas do tempo; prefira hora do evento + hora de recebimento. Hora do evento mais hora de recebimento explica a diferença sem culpar o relógio de um host. A interface de linha do tempo de Sam sempre mostra as duas, e os analistas são treinados a ordenar pela hora do evento enquanto observam a hora de recebimento para atrasos de transporte ao reconstruir uma parada. A orientação de ordenação está impressa no manual do analista ao lado de uma captura de tela sintética de diferença de relógio, rotulada como material didático. Quando a interface de linha do tempo mudou no último período, a captura foi atualizada no mesmo pull request, para que os analistas não aprendessem um layout que já não existia.
34.2b Eventos envenenados
Os consumidores precisam validar o esquema e rejeitar eventos com carimbos de tempo no futuro, versões de política desconhecidas ou alvos que reprovam nas verificações de formato. Um fluxo de eventos envenenado deve ir para quarentena, não criar achados contra hosts aleatórios. A quarentena vence criar achados contra hosts sem sentido. Sam aciona alertas quando a quarentena cresce, da mesma forma que aciona em picos de negação. Os alertas de quarentena incluem o nome do serviço produtor. O runbook de rollback abre nesse nome a partir do conteúdo do alerta, para que um operador diante de um fluxo envenenado de eventos com carimbo no futuro possa parar o produtor sem adivinhar qual serviço derrubar.
34.3b Treino de evolução de esquema
Pratique acrescentar um campo opcional de ponta a ponta num ensaio: produtor, consumidor, fixture, documentação. Equipes que só evoluem esquemas em emergências inventam atalhos incompatíveis. Campos opcionais de ponta a ponta mantêm honesta a memória muscular. Sam agenda um treino a cada período, com um nome de campo descartável. Os campos descartáveis são apagados no fim do período com uma nota de migração que cita a equipe dona. Essa equipe precisa confirmar a nota no repositório do contrato antes que o campo desapareça, para que um campo de ensaio não suma enquanto um consumidor ainda o lê.
34.1b Filas de mensagens mortas
Eventos que reprovam na validação vão para uma fila de mensagens mortas com um alerta — não para /dev/null e não para os achados. Os operadores reproduzem depois de corrigir o produtor. Descartes invisíveis recriam o repúdio. O runbook de Sam proíbe filtrar alertas dessa fila sem uma nota AUTH. Notas AUTH para filtros de alerta expiram depois de sete dias, a menos que sejam renovadas com a mesma aprovação dupla da nota original. Filtros expirados se rearmam automaticamente; essa regra pegou um filtro esquecido que tinha silenciado os alertas de mensagens mortas por nove dias durante um período tranquilo de provas.
Nota de prática
Os testes de contrato rodam num agendamento contra os fixtures de homologação mesmo quando não há PR aberto, pegando derivas silenciosas do produtor. Uma CI verde na segunda-feira e um consumidor quebrado na quinta costumam significar que alguém editou um fixture à mão num ambiente que a CI não vê. Testes de contrato agendados fecham essa lacuna.
Inclua um canário de consumidor que reprove a implantação se eventos envenenados não forem para quarentena em até um minuto na homologação.
A idade das mensagens mortas é um gráfico de SLO ao lado da latência do caminho de negação.
34.4b Propriedade do contrato de eventos
Cada tipo de evento no barramento tem uma equipe dona que aprova as mudanças. O PulseMap consome eventos do FindingsDesk, mas não pode alterar seu esquema; em vez disso, abre uma solicitação, o que mantém o contrato estável para todos os outros consumidores. As aprovações ficam registradas no repositório do contrato. Sam bloqueia merges que mexem num tipo sem a revisão da equipe dona. Os aliases das equipes donas são endereços de grupo, como trackscope-contract@riverstone.example, para que a propriedade sobreviva quando pessoas saem do esquadrão da plataforma e toda mudança de esquema ainda chegue a alguém de plantão.
Exercícios
- EX100 — Campo. Por que incluir policy_version em todo evento? Rubrica: 3 = auditar qual ROE se aplicou; 2 = vago; 1 = errado; 0 = nada.
- EX101 — Reprodução. Como o event_id impede achados duplicados? Rubrica: 3 = upsert/ignorar duplicatas; 2 = vago; 1 = errado; 0 = nada.
- EX102 — Fixture. Cite dois fixtures exigidos antes de integrar um novo código de motivo. Rubrica: 3 = exemplo do produtor + ticket esperado do consumidor; 2 = um; 1 = vago; 0 = nada.
Síntese
Contratos, consumidores idempotentes, testes com fixtures.
Continue estudando — capítulo 34 de 50
← Capítulo 33 (rascunho) · Índice de capítulos do curso · Capítulo 35 (rascunho) →