Capítulo 21 — Modelos de sistemas
Mapa da aula
Aula 21 publicada. Mapa, exemplo, EX061.
flowchart TD
N0["21.1 Elementos"]
N1["21.2 Pontos de entrada"]
N2["21.3 Premissas"]
N3["21.4 Fluxos de dados"]
N4["21.5 Exclusões"]
N5["21.6 Modelos vivos"]
N6["21.7 Fichas físicas para premissas abertas"]
N7["21.8 Manter os callbacks de pagamento no modelo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX061"]
Desenho lógico
flowchart LR
N0["21.1 Elementos"]
N1["21.2 Pontos de entrada"]
N2["21.3 Premissas"]
N3["21.4 Fluxos de dados"]
N4["21.5 Exclusões"]
N5["21.6 Modelos vivos"]
N6["21.7 Fichas físicas para premissas abertas"]
N7["21.8 Manter os callbacks de pagamento no modelo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[21.1 Elementos]
|
v
[21.2 Pontos de entrada]
|
v
[21.3 Premissas]
|
v
[21.4 Fluxos de dados]
|
v
[21.5 Exclusões]
|
v
[21.6 Modelos vivos]
|
v
[21.7 Fichas físicas para premissas abertas]
|
v
[21.8 Manter os callbacks de pagamento no modelo]
|
v
[Exemplo resolvido] --> [Exercício EX061]
Objetivos de aprendizagem
Você vai (1) modelar o internet banking; (2) listar os pontos de entrada; (3) registrar as premissas.
21.1 Elementos
Atores, pontos de entrada, armazenamentos, zonas de confiança, processadores externos. Um modelo de sistema para testes autorizados é um mapa do que pode ser alcançado e do que precisa ser protegido, não uma arquitetura corporativa completa. Atores são pessoas ou serviços que iniciam ações: clientes, funcionários, rotinas em lote, testadores. Pontos de entrada são onde esses atores encontram o sistema: a aplicação web, a API móvel, a VPN dos funcionários. Armazenamentos guardam dados que importam: o banco de dados de clientes, o cofre de evidências. Zonas de confiança agrupam componentes que compartilham um nível de exposição. Processadores externos ficam fora do controle do TRB. Nomear cada elemento antes de testar evita que a equipe descubra no meio do engajamento que um par de lote esquecido consegue alcançar o razão.
21.2 Pontos de entrada
Web, API móvel, VPN dos funcionários, pares de lote. Cada ponto de entrada tem usuários diferentes, autenticação diferente e formas diferentes de dar errado. A aplicação web pública fica de frente para qualquer pessoa na internet. A API móvel pode compartilhar backends com a aplicação web, mas usar tokens diferentes. A VPN dos funcionários aproxima os administradores dos sistemas internos. Os pares de lote são sistemas de outras instituições que trocam arquivos num cronograma. Um modelo que lista apenas a aplicação web vai deixar passar achados que só aparecem na API móvel ou só depois do login na VPN. Sam confere o log de tickets de mudança em busca de novos pontos de entrada antes de cada engajamento.
21.3 Premissas
"O staging espelha a AuthZ da produção" precisa ser validado. Os modelos estão cheios de premissas, e as não validadas são onde os achados se escondem. As equipes frequentemente presumem que o staging usa as mesmas regras de autorização que a produção, que um deep link móvel reutiliza as verificações de sessão da web ou que um callback de um processador de pagamentos é autenticado. Cada premissa é escrita num post-it e marcada como Aberta até que alguém a confira. Uma premissa Aberta na abertura vira uma frase de risco residual no plano: o teste pode deixar passar fraquezas que só existem onde a premissa falha. Fechar premissas faz parte da preparação, não é uma tarefa paralela.
21.4 Fluxos de dados
Os caminhos de dados pessoais de clientes dirigem a minimização. O modelo marca todo caminho que transporta dados pessoais de clientes: do navegador para a camada web, da camada web para o armazenamento de clientes, do armazenamento para uma extração de relatórios. Esses caminhos decidem onde as regras de minimização se aplicam durante os testes. Um caminho que nunca transporta dados pessoais pode ser exercitado com mais liberdade, com tráfego sintético. Um caminho que os transporta exige a regra de prova, e não de volume, e um manuseio cuidadoso das evidências. Desenhar os caminhos também revela surpresas, como um site de marketing que posta na API central e, portanto, num armazenamento de dados pessoais.
21.5 Exclusões
O gateway SWIFT é omitido quando está fora do escopo. As exclusões precisam aparecer no modelo com a mesma clareza das inclusões. Deixar o gateway SWIFT totalmente fora do diagrama o faz parecer esquecido. Desenhá-lo e marcá-lo como fora do escopo torna a fronteira visível para todos que usam o modelo. Testadores que veem um caminho interessante em direção ao gateway sabem imediatamente que não lhes cabe segui-lo. A mesma disciplina se aplica aos processadores terceiros e aos bancos de dados de clientes de produção quando o engajamento se limita ao staging.
21.6 Modelos vivos
Atualize ao surgirem novas rotas de callback de pagamento. Um modelo que não é atualizado vira um perigo, porque as pessoas confiam nele. A regra do TRB é que todo ticket de mudança que acrescente ou altere um ponto de entrada, um armazenamento ou um callback externo precisa atualizar o modelo em até uma semana. A revisão semanal de Sam compara os tickets de mudança abertos com as arestas do modelo e lista os retardatários. A revisão é curta e um pouco irritante, e é por isso que funciona. As equipes atualizam o modelo para não aparecer na lista, e o modelo fica perto o bastante da realidade para planejar testes com base nele.
21.7 Fichas físicas para premissas abertas
As oficinas com os donos usam fichas físicas para as premissas. Uma ficha deixada em Aberta no fim bloqueia a abertura. A regra tátil parece infantil e funciona melhor que uma coluna de planilha que ninguém atualiza. Cada premissa Aberta ganha uma ficha na mesa. Fechá-la move a ficha para uma tigela de Fechadas, com uma nota de quem conferiu e como. As fichas ainda em Aberta no fim da oficina são fotografadas para o plano como riscos residuais, e a abertura não pode ser marcada como pronta até que o líder do engajamento as aceite. Colunas de planilha convidam a uma negligência educada. Uma ficha na mesa convida a uma decisão.
21.8 Manter os callbacks de pagamento no modelo
Novos callbacks de pagamento precisam aparecer no modelo em até uma semana após os tickets de mudança. A comparação semanal de Sam entre tickets de mudança e arestas do modelo pega os retardatários. Os callbacks de pagamento são fáceis de deixar passar porque chegam de fora e muitas vezes são acrescentados por equipes de produto sob pressão de entrega. Um callback que não está no modelo também não está no registro de fluxos, o que significa que pode não ter dono nem uma verificação de autenticação acordada. A comparação semanal é uma junção simples: tickets de mudança que mencionam callback, webhook ou notify, versus as arestas do modelo. Tudo o que não casa vira uma tarefa para o dono do ticket antes do próximo engajamento.
21.9 Desenhar os processadores como caixas-pretas
Os processadores aparecem como caixas-pretas, com os tipos de dados que cruzam a fronteira, e não como falsos hosts internos. Desenhar os servidores internos de um fornecedor convida os testadores a pensar em atacá-los. Desenhar uma caixa-preta rotulada "fornecedor de SMS", com códigos únicos saindo e recibos de entrega chegando, mantém a atenção no lado do TRB da fronteira: os recibos são validados, as falhas são tratadas, o fornecedor é autenticado? Os tipos de dados nas setas importam mais do que qualquer coisa dentro da caixa. Eles dizem aos testadores quais dados pessoais saem do TRB e o que volta que pode receber confiança demais.
21.10 Um deep link vira uma premissa aberta
Um novo deep link móvel aparece num ticket de mudança. Em três dias, o modelo de Sam ganha um ponto de entrada e um post-it de premissa: "AuthZ igual à da web?". O post-it continua Aberto na abertura e vira uma frase de risco residual. O deep link poderia reutilizar as verificações de autorização da web ou poderia ter sido ligado às pressas, com uma verificação mais fraca. Ninguém tinha validado qual. Deixar a premissa Aberta foi correto. A frase de risco residual disse a todos que a autorização do deep link móvel não estava coberta pelos testes web planejados, o que impediu que um relatório web limpo fosse lido erroneamente como uma cobertura móvel limpa.
21.11 Uma rota silenciosa a partir do site de marketing
A comparação do inventário de callbacks encontrou uma rota silenciosa do site de marketing para a core-api. Ela virou uma revisão de conduíte, e não uma surpresa de marketing em produção. O site de marketing tinha recebido um endpoint de conveniência para preencher previamente formulários de proposta. O endpoint alcançava a core-api e, portanto, o armazenamento de clientes, e nunca tinha aparecido no diagrama de arquitetura. Encontrá-lo numa comparação semanal significou que o conduíte pôde ser revisado, autenticado e ter sua taxa limitada antes que um engajamento ou um atacante o encontrasse. Surpresas são mais baratas em revisões de inventário do que em incidentes de produção.
21.12 Fotografar as premissas abertas para o plano
Os post-its de premissas abertas são fotografados para o pacote das ROE antes da abertura. Uma fotografia congela o estado da oficina sem depender de alguém digitá-lo depois. A imagem vai para o pacote das regras de engajamento, ao lado das frases de risco residual, para que qualquer pessoa que leia a autorização possa ver o que ainda era desconhecido. Depois da abertura, os post-its podem ir para o lixo. A fotografia permanece. Se um achado depois depender de uma premissa que estava Aberta, o pacote mostra que a equipe conhecia a lacuna.
A fotografia também resolve disputas sobre o que foi dito na oficina. A memória diverge; uma foto dos post-its não.
21.13 Premissas abertas no sumário executivo
As frases de risco residual vindas dos post-its Abertos são coladas automaticamente no rascunho do sumário executivo. Os executivos raramente leem registros de premissas. Eles leem o sumário executivo. Colar ali as premissas Abertas, numa frase simples cada uma, significa que as pessoas que aceitam o risco residual o veem antes de aceitar o relatório. A automação importa porque colar à mão é a etapa que é pulada sob prazo. As frases são curtas de propósito: a autorização do deep link móvel não foi validada contra as regras de produção.
Se a automação falhar, o líder do engajamento cola as frases à mão e abre um ticket contra o pipeline. O sumário ainda precisa trazer os riscos.
21.14 Do quadro branco para o registro de premissas
O plantão de modelos termina com uma fotografia do quadro branco e uma passagem de OCR para o registro de premissas. Post-its que o OCR não consegue ler são reescritos. Premissas ilegíveis são premissas negadas. Os erros de OCR são tratados como premissas Abertas até serem corrigidos, o que motiva uma letra caprichada. O caminho de fotografia mais OCR também significa que a oficina pode continuar analógica e colaborativa enquanto o registro duradouro continua pesquisável. Notas ilegíveis não podem virar Fechadas em silêncio. Uma premissa negada não pode ser tratada como Fechada no plano, o que mantém a pressão sobre quem é dono da nota ilegível para reescrevê-la.
Exemplo resolvido (TRB sintético)
O modelo de Sam mostra web→ledger-db tracejado em vermelho como não intencional.
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
- EX061 — Premissa. Como validar que o staging espelha a AuthZ da produção? Rubrica: 3 = comparar configurações/testes com os donos; 2 = parcial; 1 = presumir; 0 = nada.
- EX062 — Por que omitir o SWIFT. Por que omitir o SWIFT deste modelo? Rubrica: 3 = fora do escopo; 2 = parcial; 1 = sem importância; 0 = nada.
- EX063 — Pontos de entrada. Nomeie três pontos de entrada do internet banking. Rubrica: 3 = três entre web, API móvel, VPN dos funcionários, lote; 2 = dois; 1 = um; 0 = nada.
Síntese
Os modelos tornam visíveis os fluxos não intencionais e explícitas as premissas.
Continue estudando — capítulo 21 de 40
← Capítulo 20 (rascunho) · Índice de capítulos do curso · Capítulo 22 (rascunho) →