Capítulo 21 — Arquitetura e engenharia de segurança: modelos de sistema
Mapa da aula
Aula 21 publicada. Mapa, exemplo, EX061.
flowchart TD
N0["21.1 Construir o modelo"]
N1["21.2 Fronteiras e ativos"]
N2["21.3 Revisão STRIDE"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX061"]
Desenho lógico
flowchart LR
N0["21.1 Construir o modelo"]
N1["21.2 Fronteiras e ativos"]
N2["21.3 Revisão STRIDE"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3 --> Q["EX061"]
[21.1 Construir o modelo]
|
v
[21.2 Fronteiras e ativos]
|
v
[21.3 Revisão STRIDE]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX061]
Objetivos de aprendizagem
Você vai (1) construir um modelo do sistema de pedidos da Fernway; (2) identificar as fronteiras de confiança e os ativos; (3) usar o modelo numa revisão STRIDE.
21.1 Construir o modelo
Lucas desenha um diagrama de fluxo de dados do sistema de pedidos da Fernway: o navegador do cliente, a loja web, o provedor de pagamentos, o banco de dados de estoque, o aplicativo de separação do armazém e o parceiro de entregas. Ele marca os processos, os repositórios de dados, as entidades externas e os fluxos, e rotula o que cada fluxo carrega. Ele valida o diagrama com o desenvolvedor e com o gerente do armazém, que corrigem dois fluxos que ele havia deixado passar: uma importação noturna de preços de um fornecedor e um upload manual de planilha. Os modelos só são úteis se as pessoas que operam o sistema concordarem que estão corretos.
21.2 Fronteiras e ativos
Lucas marca as fronteiras de confiança onde os dados passam entre partes ou níveis de privilégio: entre o navegador e a loja, a loja e o provedor de pagamentos, a Fernway e o parceiro de entregas, e entre a rede do escritório e a nuvem. Ele lista os ativos: dados dos clientes, histórico de pedidos, preços e níveis de estoque. O upload manual de planilha atravessa uma fronteira sem nenhuma validação, o que significa que um arquivo equivocado ou malicioso poderia mudar preços em toda a loja. Marcar as fronteiras torna visíveis lacunas assim, porque toda travessia deveria ter uma verificação definida.
21.3 Revisão STRIDE
Usando as categorias STRIDE de Shostack (2014), Lucas examina cada elemento. Spoofing: os webhooks do parceiro de entregas são assinados. Tampering: o upload de planilha não tem validação. Repudiation: as mudanças de preço não são registradas com o usuário que as fez. Information disclosure: o histórico de pedidos é acessível a todas as contas da equipe. Denial of service: a loja depende de uma única região de hospedagem. Elevation of privilege: o aplicativo de separação roda com direitos de dono do banco de dados. Ele registra sete ameaças com mitigações propostas e responsáveis, e a Fernway agenda as três principais para o próximo trimestre.
Exemplo resolvido
Lucas constrói e valida um modelo de fluxo de dados, marca quatro fronteiras de confiança e conduz uma revisão STRIDE que produz sete ameaças com responsáveis.
Caso sintético. O sistema de pedidos é sintético; Shostack (2014) é real.
Erros e limites
Os modelos envelhecem à medida que os sistemas mudam. O STRIDE encontra categorias de ameaças, não todos os ataques.
Exercícios
-
EX061 — Validar o modelo. O que o desenvolvedor e o gerente do armazém acrescentaram? Rubrica: 3 = uma importação noturna de preços de um fornecedor e um upload manual de planilha;; 2 = um fluxo;; 1 = vago;; 0 = nenhuma.
-
EX062 — Travessia sem validação. Por que o upload de planilha é uma preocupação? Rubrica: 3 = atravessa uma fronteira sem validação e poderia mudar preços;; 2 = validação;; 1 = vago;; 0 = nenhuma.
-
EX063 — Achado de repúdio. Que lacuna de repúdio o STRIDE encontrou? Rubrica: 3 = as mudanças de preço não são registradas com o usuário;; 2 = logging;; 1 = vago;; 0 = nenhuma.
Síntese
Um modelo validado com fronteiras marcadas transforma o STRIDE em uma lista concreta de ameaças, cada uma com dono.
Continue estudando — aula 21 (capítulo 21 de 40)
← Capítulo 20 · Índice das aulas · Capítulo 22 →
Continue para a próxima aula já escrita.