Capítulo 41 — Segurança ofensiva autorizada e red team: otimização do sistema
Mapa da aula
Aula 41 publicada. Mapa, exemplo, EX121.
flowchart TD
N0["41.1 Perfilar primeiro"]
N1["41.2 Preservar as restrições"]
N2["41.3 Veto de segurança"]
N3["41.2b Descarte de carga"]
N4["41.3b Folga de capacidade"]
N5["41.1b Consultas N+1"]
N6["Nota de prática"]
N7["41.4b Registrar decisões de otimização"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX121"]
Desenho lógico
flowchart LR
N0["41.1 Perfilar primeiro"]
N1["41.2 Preservar as restrições"]
N2["41.3 Veto de segurança"]
N3["41.2b Descarte de carga"]
N4["41.3b Folga de capacidade"]
N5["41.1b Consultas N+1"]
N6["Nota de prática"]
N7["41.4b Registrar decisões de otimização"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX121"]
[41.1 Perfilar primeiro]
|
v
[41.2 Preservar as restrições]
|
v
[41.3 Veto de segurança]
|
v
[41.2b Descarte de carga]
|
v
[41.3b Folga de capacidade]
|
v
[41.1b Consultas N+1]
|
v
[Nota de prática]
|
v
[41.4b Registrar decisões de otimização]
|
v
[Exemplo resolvido] --> [Exercício EX121]
Objetivos de aprendizagem
Você vai (1) fazer o perfilamento de pipelines de avaliação de forma ética; (2) otimizar sob as restrições das ROE; (3) rejeitar otimizações que enfraquecem a segurança.
41.1 Perfilar primeiro
Meça para onde vai o tempo: DNS, handshake TLS, avaliação de predicados, escrita de tickets. Otimize o termo dominante. Apenas carga sintética. Otimizar a escrita de tickets quando o handshake TLS domina desperdiça a semana e pode tentar a equipe a atalhos inseguros. Um perfil sobre carga sintética que nomeia o termo dominante mantém a equipe honesta. Sam publica o flame graph ao lado da proposta de mudança, para que os revisores vejam por que um cache foi escolhido em vez de uma biblioteca JSON mais rápida. Sem esse gráfico, debates sobre caches viram concursos de gosto. Sam rejeita PRs de otimização que não citam o termo dominante de um perfil recente.
41.2 Preservar as restrições
Fazer cache da ScopeVersion é aceitável se a invalidação na publicação estiver correta. Fazer cache de decisões de allow entre hosts não é — os hosts diferem. Uma ScopeVersion em cache que sobrevive a uma publicação é um bug de falha aberta com uma desculpa de desempenho. A invalidação precisa fazer parte do caminho de publicação e ser testada. Fazer cache de decisões de allow entre hosts é pior, porque listas de negação e horários diferem. Os testes de cache de Sam incluem uma publicação no meio da carga que precisa virar um alvo antes permitido para negado dentro do limite de parada. Um cache que não passa nesse teste de publicação no meio da carga nunca é lançado.
41.3 Veto de segurança
Qualquer otimização que pule verificações da lista de negação, encurte campos de auditoria ou falhe aberta é rejeitada, seja qual for o ganho de velocidade.
"""Rank synthetic assets for authorized engagement scoping."""
assets = [
("public-web-portal", 3, 3, 3), # exposure, data_sensitivity, blast_radius 1-3
("staging-admin-ui", 2, 3, 2),
("corp-vpn-edge", 3, 2, 3),
("internal-wiki", 1, 2, 1),
("printer-fleet", 2, 1, 1),
("lab-jump-host", 1, 1, 2),
]
print(f"{'asset':20} score exposure data blast")
for name, e, d, b in sorted(assets, key=lambda x: -(x[1]+x[2]+x[3])):
print(f"{name:20} {e+d+b:5} {e:8} {d:4} {b:5}")
Saída esperada:
asset score exposure data blast
public-web-portal 9 3 3 3
corp-vpn-edge 8 3 2 3
staging-admin-ui 7 2 3 2
internal-wiki 4 1 2 1
printer-fleet 4 2 1 1
lab-jump-host 4 1 1 2
Caso sintético — Riverstone Transit. Fazer cache da política assinada em memória cortou a latência em 40%; a invalidação na publicação manteve a segurança. Uma proposta de pular a lista de negação para hosts "sabidamente bons" foi vetada.
O corte de quarenta por cento na latência com o cache da política assinada só foi aceito porque a invalidação na publicação foi provada. Uma proposta de pular verificações da lista de negação para scanners "sabidamente bons" foi rejeitada com esse veto, independentemente do slide de ganho de velocidade. O ADR de Sam para o cache cita tanto o ganho quanto o id do teste de invalidação.
41.4 Erros e limites
Benchmarks em laptops não preveem os links dos pátios (Capítulo 3). Um link gigabit de laptop esconde custos de serialização que um uplink de 10 Mb/s de pátio torna óbvios. Benchmarks usados para a folga das ROE precisam usar as premissas de link do capítulo de física ou taxas medidas no cliente. Sam recusa um aumento do tamanho do pool justificado só por números de laptop. A mesma regra barrou um aumento de rajada que teria saturado o uplink de um pátio no exemplo resolvido de física. Contas de folga que ignoram o exemplo de serialização de 1,2 ms do uplink do pátio são devolvidas.
41.2b Descarte de carga
Sob sobrecarga, descarte trabalho de descoberta antes de descartar a avaliação de negação. Usuários podem esperar por uma varredura; não podem esperar por uma negação que nunca chega. Implemente as filas de prioridade de acordo. Filas de prioridade que descartam a avaliação de negação sob carga invertem o modelo de segurança. Os testes de descarte de Sam empurram carga sintética até as filas de descoberta crescerem e então verificam que todo predicado ainda roda e retorna dentro do orçamento de latência. Descartar descoberta aparece como um aumento de planejado-mas-não-visto no PulseMap, o que é preferível a um allow silencioso. A ordem de descarte fica escrita no ADR, para que um ajuste posterior não possa invertê-la em silêncio.
41.3b Folga de capacidade
Mantenha folga abaixo do limite das ROE para que uma tempestade de novas tentativas (Capítulo 32) não o ultrapasse. Se as ROE permitem 5 req/s, projete para 3–4 sustentados. Documente a premissa de folga. Projetar para 3–4 req/s sob ROE de 5 req/s deixa espaço para as tempestades de novas tentativas medidas no trabalho de confiabilidade. Documentar essa premissa impede que um engenheiro depois "use os 20 por cento não usados" num projeto de velocidade. A planilha de capacidade de Sam mostra o limite das ROE, a taxa sustentada projetada e o orçamento de novas tentativas numa só linha. Usar os vinte por cento não usados exige uma edição das ROE, não um ticket de desempenho.
41.1b Consultas N+1
Atualizações de tickets tagarelas durante uma importação em massa esmagam o FindingsDesk. Agrupe as escritas e meça. O trabalho de desempenho muitas vezes começa como um bug de integração, não como a necessidade de caches exóticos. Uma importação em massa que atualiza tickets com uma chamada HTTP por vez vai parecer uma necessidade de caches exóticos quando a correção real é agrupar. Meça os padrões de escrita no FindingsDesk antes de adicionar Redis. O caminho de importação de Sam envia lotes de cinquenta e reprovou numa revisão que reintroduzia upserts linha a linha em nome de "código mais simples". O argumento do código mais simples perdeu para um perfil que mostrou noventa por cento do tempo em HTTP linha a linha.
Nota de prática
Propostas de otimização exigem um parágrafo de segurança: quais verificações continuam rodando, quais são puladas, como a falha fechada é preservada. Propostas sem esse parágrafo são devolvidas sem leitura. Revisões de velocidade que ignoram parágrafos de segurança causaram mais violações das ROE do que scanners lentos jamais causaram.
Rejeite PRs de otimização que removam códigos de motivo dos logs, mesmo que a latência melhore.
Benchmarks citam o limite das ROE ao lado da taxa alcançada, para que benchmarks sem restrição fiquem óbvios.
41.4b Registrar decisões de otimização
Cada otimização é registrada com o perfil que a justificou, o ganho medido e qualquer verificação de segurança que ela tocou. Quando uma mudança posterior deixa um caminho mais lento, o registro mostra se o ganho anterior dependia de uma premissa que já não vale. Sem o perfil e as verificações de segurança ao lado do ganho, uma regressão parece azar em vez de uma premissa quebrada. O log de otimizações de Sam para o cache de política anota o corte de 40%, o teste de invalidação e o pulo da lista de negação vetado, para que uma lentidão futura seja diagnosticada com base em fatos.
Exercícios
- EX121 — Veto. Dê uma otimização que precisa ser rejeitada. Rubrica: 3 = exemplo que enfraquece a segurança; 2 = vago; 1 = aprova; 0 = nada.
- EX122 — Cache. Quando fazer cache de decisões é seguro? Rubrica: 3 = mesma ScopeVersion+alvo+contexto, TTL curto, invalidar na publicação; 2 = parcial; 1 = sempre; 0 = nada.
- EX123 — Inventário. Por que otimizar o agendamento com pontuações? Rubrica: 3 = janela limitada → maior exposição primeiro; 2 = vago; 1 = aleatório; 0 = nada.
Síntese
Velocidade sob restrições; a segurança tem poder de veto.
Continue estudando — capítulo 41 de 50
← Capítulo 40 (rascunho) · Índice de capítulos do curso · Capítulo 42 (rascunho) →