Capítulo 47 — Ensaio de falha e recuperação

Mapa da aula

Aula 47 publicada. Mapa, exemplo, EX139.

flowchart TD
  N0["47.1 Projetar o ensaio"]
  N1["47.2 Observações"]
  N2["47.3 Melhorias"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX139"]

Desenho lógico

flowchart LR
  N0["47.1 Projetar o ensaio"]
  N1["47.2 Observações"]
  N2["47.3 Melhorias"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX139"]

[47.1 Projetar o ensaio]
    |
    v
[47.2 Observações]
    |
    v
[47.3 Melhorias]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX139]

Objetivos de aprendizagem

Você vai (1) projetar um ensaio de falha para um serviço de GRC; (2) observar a detecção e a recuperação; (3) melhorar o serviço a partir dos resultados.

47.1 Projetar o ensaio

Com a gestora de segurança, Nadia planeja um ensaio de como o serviço de monitoramento se comporta sob falha. Três falhas são injetadas numa janela controlada, com os responsáveis avisados de antemão, para que nenhuma falha injetada seja tratada como incidente real: um script coletor trava, um sistema de origem fica indisponível e um arquivo de evidência é alterado depois de guardado. O ensaio testa se cada falha é detectada, com que rapidez e se a recuperação restaura a evidência correta. As regras excluem qualquer ação sobre os sistemas de controle em produção ou sobre dados de clientes.

47.2 Observações

O coletor travado é detectado na execução agendada seguinte e alerta o responsável em menos de um dia. A origem indisponível dispara um alerta de evidência ausente, como projetado. O arquivo alterado é detectado por divergência de hash na verificação semanal de integridade, mas não antes. A recuperação do travamento leva duas horas, porque o runbook omite um passo. Nadia registra cada observação com timestamps e a compara com o esperado, notando que a detecção de adulteração é mais lenta do que a equipe supunha. O Prof. Brenner pergunta por quanto tempo um arquivo alterado poderia passar despercebido, e a resposta, até uma semana, motiva a verificação diária.

47.3 Melhorias

A equipe acrescenta o passo que faltava no runbook e passa as verificações de integridade de semanais para diárias. Também acrescenta um alerta para quando as próprias verificações de integridade deixam de rodar, fechando a mesma lacuna do silêncio tratado como sucesso corrigida na revisão de projeto. Nadia observa que o ensaio revelou fraquezas que continuariam ocultas na operação normal. Ela aprende que os ensaios de falha planejados são o equivalente de governança aos simulados de incêndio: provam se a detecção e a recuperação funcionam, e só são seguros e úteis quando têm escopo cuidadoso e são anunciados.

Exemplo resolvido

Nadia executa três injeções de falha anunciadas, encontra a detecção lenta de adulteração e uma lacuna no runbook e corrige as duas.

Caso sintético. O ensaio é sintético e excluiu os sistemas de controle em produção.

Erros e limites

Ensaios anunciados diferem de falhas reais. As verificações diárias acrescentam carga.

Exercícios

• EX139 — Falhas injetadas. Que três falhas foram injetadas?
  Mostrar critérios de avaliação

  Rubrica: 3 = travamento do coletor, origem indisponível, arquivo de evidência alterado;; 2 = três;; 1 = vago;; 0 = nenhuma.
• EX140 — Detecção lenta. Que falha foi detectada lentamente?
  Mostrar critérios de avaliação

  Rubrica: 3 = o arquivo de evidência alterado, na verificação semanal;; 2 = adulteração;; 1 = vago;; 0 = nenhuma.
• EX141 — Mudança na verificação. Com que frequência as verificações de integridade rodam depois do ensaio?
  Mostrar critérios de avaliação

  Rubrica: 3 = diariamente;; 2 = diariamente, hesitando com semanal;; 1 = semanal;; 0 = nenhuma.

Síntese

Testes de falha anunciados comprovam a detecção e a recuperação e revelam fraquezas ocultas.