Capítulo 27 — Arquitetura e engenharia de segurança: verificação

Mapa da aula

Aula 27 publicada. Mapa, exemplo, EX079.

flowchart TD
  N0["27.1 Planejar a verificação"]
  N1["27.2 Escolher os métodos"]
  N2["27.3 Registrar as evidências"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX079"]

Desenho lógico

flowchart LR
  N0["27.1 Planejar a verificação"]
  N1["27.2 Escolher os métodos"]
  N2["27.3 Registrar as evidências"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX079"]

[27.1 Planejar a verificação]
    |
    v
[27.2 Escolher os métodos]
    |
    v
[27.3 Registrar as evidências]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX079]

Objetivos de aprendizagem

Você vai (1) planejar a verificação dos requisitos de segurança; (2) usar testes, revisões e varreduras de forma adequada; (3) registrar as evidências de verificação.

27.1 Planejar a verificação

Para o serviço de click-and-collect, Lucas escreve os requisitos de segurança como enunciados testáveis: deve ser exigido um código de retirada para liberar um pedido; os códigos devem expirar depois de catorze dias; as telas do aplicativo da equipe devem mascarar os números de telefone depois da retirada; e o serviço deve registrar cada liberação com a identidade do funcionário. Para cada requisito, ele nomeia um método de verificação e quem o executa. Requisitos escritos como objetivos vagos, como "o serviço deve ser seguro", não podem ser verificados e dão um falso conforto a todos que os leem.

27.2 Escolher os métodos

Lucas associa métodos aos requisitos. A expiração dos códigos é verificada por um teste automatizado com o relógio adiantado. O mascaramento é verificado por um revisor usando o aplicativo da equipe numa conta de teste. O logging é verificado fazendo uma liberação e lendo o log. Uma varredura de dependências procura bibliotecas com vulnerabilidades conhecidas, como recomenda o SP 800-218. Ele observa que as varreduras encontram problemas conhecidos, mas não falhas de lógica, como liberar um pedido sem código, que só um teste projetado para isso consegue captar. Cada método cobre o que pode.

27.3 Registrar as evidências

Toda verificação produz um registro: data, método, resultado e quem a executou. Um teste falha: os códigos não expiram porque a tarefa de expiração não foi agendada em produção. O desenvolvedor corrige, e Lucas roda o teste de novo. O registro mostra tanto a falha quanto a correção, o que convence mais um auditor do que uma folha impecável. Lucas acrescenta os testes ao checklist de release, para que as mudanças futuras sejam verificadas de novo, em vez de se supor que preservaram o comportamento.

Exemplo resolvido

Lucas escreve quatro requisitos testáveis, associa cada um a um método de verificação, encontra uma tarefa de expiração não agendada e registra a falha e a correção.

Caso sintético. O serviço e os resultados são sintéticos; o SP 800-218 é real.

Erros e limites

Os testes verificam apenas o que foram projetados para verificar. As evidências envelhecem a cada mudança.

Exercícios

• EX079 — Requisito não testável. Por que "o serviço deve ser seguro" é um requisito ruim?

  Mostrar critérios de avaliação

  Rubrica: 3 = não pode ser verificado;; 2 = não testável;; 1 = está bom;; 0 = nenhuma.

• EX080 — Limite da varredura. O que uma varredura de dependências não consegue encontrar?

  Mostrar critérios de avaliação

  Rubrica: 3 = falhas de lógica, como liberação sem código;; 2 = falhas de lógica;; 1 = tudo;; 0 = nenhuma.

• EX081 — Teste que falhou. Que teste falhou, e por quê?

  Mostrar critérios de avaliação

  Rubrica: 3 = expiração dos códigos; a tarefa não estava agendada em produção;; 2 = expiração;; 1 = mascaramento;; 0 = nenhuma.

Síntese

A verificação precisa de requisitos testáveis, métodos correspondentes e evidências registradas, inclusive das falhas.