Capítulo 6 — Modelo de sistema para testes autorizados
Mapa da aula
Aula 06 publicada. Mapa, exemplo, EX021.
flowchart TD
N0["6.1 Elementos do modelo"]
N1["6.2 Pontos de entrada"]
N2["6.3 Premissas"]
N3["6.4 Fluxos de dados"]
N4["6.5 Fora do modelo"]
N5["6.6 Modelo vivo"]
N6["6.7 Cores das zonas de confiança"]
N7["6.8 Registro de premissas"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX021"]
Desenho lógico
flowchart LR
N0["6.1 Elementos do modelo"]
N1["6.2 Pontos de entrada"]
N2["6.3 Premissas"]
N3["6.4 Fluxos de dados"]
N4["6.5 Fora do modelo"]
N5["6.6 Modelo vivo"]
N6["6.7 Cores das zonas de confiança"]
N7["6.8 Registro de premissas"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]
[6.1 Elementos do modelo]
|
v
[6.2 Pontos de entrada]
|
v
[6.3 Premissas]
|
v
[6.4 Fluxos de dados]
|
v
[6.5 Fora do modelo]
|
v
[6.6 Modelo vivo]
|
v
[6.7 Cores das zonas de confiança]
|
v
[6.8 Registro de premissas]
|
v
[Exemplo resolvido] --> [Exercício EX021]
Objetivos de aprendizagem
Você vai (1) construir um modelo de sistema simples para o planejador de viagens; (2) marcar pontos de entrada e repositórios de dados; (3) mapear os temas do OWASP WSTG para o modelo; (4) listar premissas.
6.1 Elementos do modelo
Um modelo de sistema nomeia atores (passageiro, funcionário), pontos de entrada (web, API), zonas de confiança, repositórios de dados (BD de viagens, logs) e dependências externas (blocos de mapa). Para a NMT, o modelo diz: passageiro → HTTPS → API → BD de viagens; funcionário → VPN → interface administrativa; blocos de mapa como externos; nuvem de tarifas riscada. O modelo de uma página de Sam é a imagem do escopo antes de as ferramentas rodarem: a nuvem de tarifas e as caixas do fornecedor de blocos de mapa estão riscadas, e há responsáveis nomeados apenas na web, na API e na VPN. As ferramentas ficam fechadas até que essa página esteja atualizada.
6.2 Pontos de entrada
Cada ponto de entrada recebe uma lista curta de temas do WSTG: autenticação, sessão, controle de acesso, tratamento de entradas. Na NMT, os pontos de entrada são o site público, a API do planejador de viagens e a VPN dos funcionários. Validadores de tarifa não são pontos de entrada do ENG-512; listá-los como interessantes é um erro de modelo corrigido antes da abertura. Cada um dos três recebe sua própria lista de temas do WSTG, para que as verificações da VPN nunca tomem emprestados os testes de tratamento de entradas da web. Para a VPN dos funcionários, os temas param em autenticação e tratamento de sessão, porque o tratamento de entradas pertence ao site e à API do planejador de viagens. Manter as listas separadas também torna precisa a declaração de cobertura: o relatório pode dizer quais temas foram exercitados em qual ponto de entrada e quais ficaram de fora.
6.3 Premissas
"A homologação espelha a autenticação da produção" é uma premissa a validar, e não um fato. Premissas como "a homologação tem a mesma configuração da produção" são escritas no registro de premissas com um responsável, porque premissas não escritas viram brigas de escopo no meio da janela. Cada linha do registro de premissas nomeia quem acreditou nela e a data da última verificação. Uma linha de "a homologação espelha a produção" sem data de verificação é marcada como inválida até que o responsável compare as duas configurações e date a entrada. Achados que dependem de uma premissa inválida ficam fora do relatório até a comparação ser feita.
6.4 Fluxos de dados
Anote por onde passam os dados pessoais, como as viagens salvas, para que os testes minimizem a exposição. Os fluxos de dados da NMT mostram consultas de viagem e ações administrativas dos funcionários, e as setas param no BD de viagens e na interface administrativa dos funcionários. Eles não mostram a liquidação de tarifas. Sam se recusa a desenhar fluxos de tarifa no modelo comum, porque desenhar convida a sondar; uma seta de liquidação de tarifas no modelo comum é um defeito de documentação que ele corrige antes do ENG-512. A seta das viagens salvas é a que ele marca para minimização, de modo que as verificações sobre ela usam apenas contas sintéticas.
6.5 Fora do modelo
Os validadores de tarifa são omitidos porque estão fora do escopo. Fora do modelo significa a rede de tarifas, o rádio e os processadores de cartão. Essas caixas ficam pretas no mapa de cores e trazem a legenda "somente com ROE especializadas", e os achados do ENG-512 nunca reivindicam cobertura nelas. Deixá-las visíveis, mas pretas, importa: o leitor vê que os sistemas existem e foram excluídos de propósito, em vez de supor que foram esquecidos ou cobertos em silêncio pelos testes comuns. Qualquer pedido de teste dentro de uma caixa preta volta ao responsável pelas ROE como um engajamento separado.
6.6 Modelo vivo
Atualize o modelo quando a API ganhar um novo callback de pagamento, mesmo que o pagamento seja de terceiros. O modelo também é atualizado quando uma CDN ou um gateway muda. Sam data cada revisão e guarda a data ao lado do hash das ROE; um modelo mais antigo que a última mudança de arquitetura é inválido para a próxima janela, então, se a arquitetura mudou depois da data do modelo, ele atualiza a figura antes da janela. O histórico de revisões mostra aos revisores contra qual versão do modelo cada janela foi planejada.
6.7 Cores das zonas de confiança
Sam pinta a internet de vermelho, a homologação de âmbar, os funcionários de verde e a tarifa de preto (não entrar). O preto é reservado à tarifa para que não possa ser confundido com nenhuma zona onde testar é permitido. A cor torna o escopo visível nas revisões quando os gestores passam os olhos depressa demais para ler as exclusões. O mapa de cores é impresso para a reunião rápida de abertura, para que os gestores que só passam os olhos pelo texto ainda vejam a exclusão. Um mapa impresso em preto e branco perde o sentido, por isso a cópia da abertura também rotula cada zona por escrito.
6.8 Registro de premissas
Uma lista corrente de premissas fica embaixo do modelo, e cada uma é marcada como confirmada, rejeitada ou aberta antes de o relatório ser emitido. As entradas nomeiam quem acreditou, por exemplo, que a homologação espelhava a produção e quando isso foi verificado. Premissas que falham viram texto das ROE ou achados; Sam não deixa uma crença quebrada de que a homologação espelha a produção como nota de rodapé não dita. As entradas ainda abertas na hora do relatório são listadas na seção de limitações, para que os leitores saibam quais conclusões dependem de crenças não confirmadas e quem precisa fechá-las.
6.9 Disciplina de campo
Construir o modelo de sistema com o responsável pelo produto leva uma hora e evita dias de confusão. Sam projeta um diagrama em branco, pede ao responsável que posicione as caixas e só então acrescenta as próprias setas. Os responsáveis corrigem premissas equivocadas sobre qual banco de dados guarda as viagens salvas e se a interface administrativa compartilha a autenticação com a API dos passageiros, e essas correções mudam quais temas do WSTG importam mais. O registro de premissas anota cada correção com a data em que foi confirmada. A disciplina de campo para a modelagem é um diagrama datado, zonas coloridas, o registro de premissas e a tarifa em preto; Sam não abre as ferramentas do ENG-512 até que esses quatro estejam atualizados, e qualquer lacuna atrasa o início.
Exemplo resolvido (NMT sintética)
O modelo de uma página de Sam mostra passageiro → HTTPS → API → BD de viagens; funcionário → VPN → interface administrativa; blocos de mapa como externos; nuvem de tarifas riscada.
Caso sintético — Northline Municipal Transit (NMT). A operadora de transporte, Sam Park e todos os números foram inventados para fins didáticos.
Erros e limites
Sistemas de transporte reais e equipamentos de tarifa nunca são testados sem uma autorização separada e especializada. Este livro usa apenas dados sintéticos e não concede autorização para testar sistemas reais.
Exercícios
- EX021 — Atores. Nomeie dois atores do modelo. Rubrica: 3 = passageiro e funcionário; 2 = um; 1 = vago; 0 = nada.
- EX022 — Tema do WSTG. Escolha um ponto de entrada e um tema do WSTG a aplicar. Rubrica: 3 = par concreto, por exemplo API + controle de acesso; 2 = parcial; 1 = vago; 0 = nada.
- EX023 — Verificação de premissa. Como Sam validaria a premissa de que a homologação espelha a autenticação da produção? Rubrica: 3 = comparar configurações/confirmação dos responsáveis; não supor; 2 = parcial; 1 = supor verdadeira; 0 = nada.
- EX024 — Por que omitir a tarifa. Por que omitir os validadores de tarifa deste modelo? Rubrica: 3 = fora do escopo; 2 = parcial; 1 = sem importância; 0 = nada.
Síntese
Um modelo de sistema claro concentra o esforço do WSTG e registra as premissas de forma explícita.
Continue estudando — capítulo 06 de 18
← Capítulo 05 (rascunho) · Índice de capítulos do curso · Capítulo 07 (rascunho) →