Capítulo 22 — Dados e dependências
Mapa da aula
Aula 22 publicada. Mapa, exemplo, EX064.
flowchart TD
N0["22.1 Dependências"]
N1["22.2 Laboratório de fluxos"]
N2["22.3 Titularidade"]
N3["22.4 Terceiros"]
N4["22.5 Interrupções"]
N5["22.6 Segredos"]
N6["22.7 Expirar os fluxos temporários"]
N7["22.8 Varrer os repositórios do TRB"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX064"]
Desenho lógico
flowchart LR
N0["22.1 Dependências"]
N1["22.2 Laboratório de fluxos"]
N2["22.3 Titularidade"]
N3["22.4 Terceiros"]
N4["22.5 Interrupções"]
N5["22.6 Segredos"]
N6["22.7 Expirar os fluxos temporários"]
N7["22.8 Varrer os repositórios do TRB"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[22.1 Dependências]
|
v
[22.2 Laboratório de fluxos]
|
v
[22.3 Titularidade]
|
v
[22.4 Terceiros]
|
v
[22.5 Interrupções]
|
v
[22.6 Segredos]
|
v
[22.7 Expirar os fluxos temporários]
|
v
[22.8 Varrer os repositórios do TRB]
|
v
[Exemplo resolvido] --> [Exercício EX064]
Objetivos de aprendizagem
Você vai (1) mapear as dependências; (2) sinalizar fluxos não aprovados; (3) designar donos.
22.1 Dependências
API central, banco de dados do razão, serviço antifraude, SMS, processador de cartões. Uma lista de dependências para testes é o conjunto de sistemas de que o alvo precisa para se comportar normalmente. O internet banking do TRB precisa da API central, do banco de dados do razão, de um serviço de pontuação antifraude, de um provedor de SMS para códigos únicos e de um processador de cartões para as etapas de pagamento. Se algum deles estiver fora do ar ou fora do escopo, partes da aplicação não podem ser testadas com honestidade. A lista também mostra onde os achados podem de fato pertencer. Uma falha que parece um bug do aplicativo bancário pode ser um serviço antifraude mal configurado. Sam confirma o dono e o status de autorização de cada dependência antes da abertura.
22.2 Laboratório de fluxos
O lab_flows marca web→ledger-db como UNAPPROVED. O laboratório compara o tráfego observado com o registro de fluxos aprovados e imprime qualquer caminho que não tenha uma entrada. Um caminho direto da web para o razão é o exemplo clássico: ele pula as verificações de autorização da API central e dá a um host web comprometido uma rota para dentro do banco de dados. Rodar o laboratório não é o achado. O achado é o caminho não aprovado mais o ticket de mudança e o dono ausentes. Os testadores salvam a saída do laboratório ao lado do registro do engajamento, para que uma disputa posterior sobre se o caminho existia possa ser respondida com um artefato datado.
22.3 Titularidade
Cada fluxo tem um dono de controle. A titularidade responde quem pode aprovar uma mudança, quem recebe um achado e quem pode parar um teste que usa o fluxo. Um fluxo sem dono não pode ser testado com segurança, porque ninguém pode aceitar o risco nem corrigir o que quebrar. O registro do TRB rejeita fluxos novos sem campo de dono, e a verificação pré-engajamento de Sam lista todos os fluxos do escopo cujo dono saiu do banco. Substituir um dono que saiu é uma tarefa de planejamento, não uma surpresa no meio da janela. Achados registrados contra fluxos sem dono tendem a ficar intocados, o que é mais um motivo para exigir a titularidade de antemão.
22.4 Terceiros
Autorização separada. As dependências que pertencem a outras empresas precisam da permissão dessas empresas antes que alguém as sonde. A autorização do TRB cobre os sistemas do TRB. O fornecedor de SMS, o processador de cartões e o provedor de nuvem têm, cada um, suas próprias regras. Sam pode observar como o TRB os chama e se o TRB valida as respostas deles, o que testa o código do TRB. Ele não pode rodar varreduras de vulnerabilidades contra os endpoints deles, a menos que seus programas digam que pode. A distinção está escrita nos cartões de método, para que um testador curioso não improvise.
22.5 Interrupções
Indisponibilidades de fornecedores são paradas, não oportunidades de martelar. Quando uma dependência está falhando, continuar a enviar tráfego raramente produz evidência de segurança útil e muitas vezes piora a indisponibilidade. As regras de engajamento tratam uma indisponibilidade confirmada de fornecedor como condição de parada para os métodos que precisam desse fornecedor. Sam registra a indisponibilidade, avisa o líder do engajamento e passa para métodos que não dependem do caminho quebrado. Martelar um serviço fora do ar para ver como ele falha é um teste de negação de serviço disfarçado e é proibido, a menos que as ROE o permitam explicitamente numa janela dedicada.
22.6 Segredos
Chaves de API em repositórios são achados do TRB. Uma chave de API incluída num commit de um repositório de código-fonte é uma credencial em todo clone, todo backup e, muitas vezes, todo log de integração contínua. Mesmo depois que a chave é removida do commit mais recente, o histórico ainda a guarda. Os achados de Sam para chaves em repositórios recomendam rotacionar a chave, removê-la do histórico quando viável, acrescentar um scanner de segredos ao pipeline e registrar um dono para o novo segredo no cofre. A severidade do achado depende do que a chave destrava. Uma chave de analytics somente leitura é diferente de uma chave que pode movimentar dinheiro.
22.7 Expirar os fluxos temporários
As datas de desativação dos fluxos temporários acionam o dono e Sam três dias antes. Se ninguém responde, o TrackScope marca o fluxo como expirado e nega os testes que dependiam dele até que seja renovado por escrito. Fluxos temporários sem expiração se tornam permanentes. O acionamento e a expiração automática transformam o temporário num limite de tempo real. Negar os testes que usavam o fluxo expirado é deliberado. Isso impede que um engajamento passe a depender em silêncio de um caminho que o banco já não pretendia manter e força uma renovação escrita que reafirme o motivo de negócio.
22.8 Varrer os repositórios do TRB
As varreduras de segredos em repositórios rodam sobre o código do TRB listado nas ROE. Sam abre achados para chaves sem dono no modelo de ativos. A varredura cobre apenas os repositórios que o engajamento está autorizado a examinar. Os achados distinguem as chaves que já têm donos no cofre das chaves que parecem órfãs. Uma chave órfã é urgente porque ninguém a está rotacionando. Ligar cada achado ao modelo de ativos também mostra quando uma chave pertence a um sistema fora do escopo; nesse caso, Sam a relata ao dono do sistema sem testar mais nada.
22.9 Renovações precisam de um motivo
Os acionamentos das datas de desativação incluem o motivo de negócio original. Renovações sem motivo são negadas. Uma renovação que diz "prorrogar por três meses" não ensina nada e convida a regras temporárias eternas. Exigir o motivo original, e uma frase sobre por que ele ainda se aplica, faz o dono perceber quando o projeto que precisava do fluxo já terminou. As renovações negadas aparecem numa lista semanal que Sam revisa com o dono da arquitetura. Padrões de negação muitas vezes apontam para um projeto que deveria terminar ou aceitar um conduíte permanente e revisado.
22.10 Quando o dono principal está de licença
Os acionamentos da data de desativação disparam; o dono está de licença. O dono substituto renova com um motivo. Sam passa a tratar como obrigatório o campo de dono substituto — acionamentos de expiração com um único dono são frágeis. Um controle que depende de uma pessoa estar à sua mesa falha durante férias e doenças. O dono substituto já tinha sido informado sobre a finalidade do fluxo, de modo que a renovação levou minutos. Tornar obrigatório o campo de substituto significa que o próximo fluxo temporário não pode ser criado até que duas pessoas possam responder por ele. Uma fragilidade removida no momento do registro não precisa ser descoberta durante uma tempestade de acionamentos.
22.11 Uma renovação que tornou o risco visível
Uma expiração sem motivo foi negada; o dono escreveu "atraso no projeto de segmentação PCI". Agora o risco está visível, não eterno. A frase fez dois trabalhos. Ela renovou o fluxo por um tempo limitado e disse a qualquer pessoa que lesse o registro por que um caminho arriscado ainda existia. Atrasos de projeto são reais; atrasos não ditos viram folclore. Quando o projeto de segmentação depois terminou, a mesma entrada do registro tornou óbvio que o motivo do fluxo tinha acabado e que a data de desativação não deveria ser renovada de novo.
22.12 Os donos substitutos precisam confirmar
Os donos substitutos precisam confirmar na interface do ticket; silêncio não é aceitação. Listar alguém como substituto sem a sua confirmação cria uma falsa sensação de cobertura. A interface exige um clique que registra a pessoa, o horário e o fluxo. Até que esse clique aconteça, o fluxo temporário não pode ser aprovado. A regra atrasou alguns registros e evitou várias lacunas silenciosas em que o substituto nomeado nunca tinha ouvido falar do fluxo. Nomes de substitutos escritos num ticket sem um clique desaparecem quando essa pessoa muda de equipe. O clique de confirmação é o que transforma um nome num dever.
22.13 Bloquear o encerramento sem um substituto
Campos obrigatórios de dono substituto bloqueiam o encerramento do ticket. Sam adora bloquear encerramentos. Os tickets de mudança que abrem fluxos temporários não podem ser encerrados até que exista a confirmação do substituto. Bloquear o encerramento é mais confiável do que enviar lembretes, porque a pressão de entrega já se concentra em fechar tickets. O bloqueio fica visível no mesmo lugar para onde os gerentes de projeto já olham. A preferência de Sam por bloqueios em vez de lembretes vem de ter visto processos baseados em lembretes falharem sempre que a equipe está ocupada.
A pressão de entrega dissolve os acordos de corredor. O bloqueio obriga o dono substituto nomeado a confirmar o fluxo antes que o ticket de mudança possa ser encerrado, e é isso que constitui o controle.
22.14 Post-mortems de fluxos expirados
Os post-mortems de expiração de fluxos perguntam se o motivo de negócio original ainda existe. Se o projeto terminou, o fluxo morre. Se o projeto continua, uma nova data de desativação é obrigatória. Regras temporárias eternas são rebatizadas como achados nas notas do post-mortem. O post-mortem é curto: motivo, resultado, próxima data de desativação ou exclusão. Rebatizar as regras temporárias eternas como achados torna o padrão visível para as mesmas pessoas que veem os outros riscos. Um fluxo que sobrevive a todo post-mortem sem um motivo vivo é uma falha de processo, não uma necessidade de rede. Escrever o post-mortem na semana em que o fluxo expira, e não meses depois, mantém honesto o motivo de negócio.
Exemplo resolvido (TRB sintético)
Sam abre um ticket conjunto para os donos da rede e da aplicação sobre o UNAPPROVED web→ledger-db.
Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.
Erros e limites
Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.
Exercícios
- EX064 — Linha do laboratório. Cite a linha UNAPPROVED do laboratório. Rubrica: 3 = web -> ledger-db UNAPPROVED; 2 = parcial; 1 = errado; 0 = nada.
- EX065 — Ticket conjunto. Por que abrir o ticket para a rede e a aplicação juntas? Rubrica: 3 = o fluxo exige mudanças tanto no roteamento quanto no comportamento da aplicação; 2 = parcial; 1 = só uma; 0 = nada.
- EX066 — Martelar o fornecedor. E se o fornecedor de SMS der timeout? Rubrica: 3 = parar as verificações relacionadas; nenhuma tempestade de novas tentativas; 2 = parcial; 1 = inundar de novas tentativas; 0 = nada.
Síntese
Dependências e fluxos têm donos; arestas não aprovadas viram tickets.
Continue estudando — capítulo 22 de 40
← Capítulo 21 (rascunho) · Índice de capítulos do curso · Capítulo 23 (rascunho) →