Capítulo 26 — Arquitetura e engenharia de segurança: passagem operacional

Capítulo 26 — Arquitetura e engenharia de segurança: passagem operacional

Mapa da aula

Aula 26 publicada. Mapa, exemplo, EX076.

flowchart TD
  N0["26.1 Quem opera depois"]
  N1["26.2 Runbooks"]
  N2["26.3 Verificação de prontidão"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX076"]

Desenho lógico

flowchart LR
  N0["26.1 Quem opera depois"]
  N1["26.2 Runbooks"]
  N2["26.3 Verificação de prontidão"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX076"]

[26.1 Quem opera depois]
    |
    v
[26.2 Runbooks]
    |
    v
[26.3 Verificação de prontidão]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX076]

Objetivos de aprendizagem

Você vai (1) preparar a equipe de operações da Brightwater para operar os novos controles; (2) escrever runbooks; (3) confirmar a prontidão antes da passagem.

26.1 Quem opera depois

O estágio de Tomás vai terminar, e a equipe de TI de duas pessoas da Brightwater precisará operar os controles que ele ajudou a introduzir. Ele lista cada controle e rotina: revisão semanal de alertas, atualizações mensais, o script de desligados, as verificações de manifestos, os backups e testes de restauração, as aprovações das sessões do fornecedor e as revisões trimestrais de acesso. Para cada um, nomeia o futuro responsável e o substituto. Sem uma passagem planejada, os controles introduzidos por um trabalhador temporário tendem a se deteriorar em poucos meses, porque ninguém mais sabe por que existem nem como operá-los.

26.2 Runbooks

Tomás escreve um runbook para cada rotina: propósito, quando executá-la, instruções passo a passo, como é a saída normal, o que fazer se falhar e para quem ligar. Ele mantém cada um com uma ou duas páginas, com capturas de tela. Ele pede a uma colega de Sam que siga sem ajuda o runbook de restauração de backup. Ela trava numa etapa em que faltava a indicação de onde fica uma senha, e Tomás corrige o runbook. Testar os runbooks com as pessoas que vão usá-los é a única forma de saber se eles funcionam.

26.3 Verificação de prontidão

Antes de sair, Tomás e Sam fazem uma verificação de prontidão. Cada responsável executa sua rotina uma vez, enquanto Tomás observa em silêncio. Todas as rotinas são concluídas, embora a aprovação do fornecedor demore mais do que o esperado porque o papel do aprovador não estava claro. Eles o esclarecem por escrito. Sam aprova a passagem. Tomás deixa seus contatos para dúvidas durante o primeiro mês. Ruth observa que uma boa passagem se mede por quão pouco a pessoa que sai é necessária depois. O registro de prontidão, com os tempos e o papel do aprovador esclarecido, é arquivado com o pacote de passagem para referência futura.

Exemplo resolvido

Tomás lista os controles com responsáveis e substitutos, escreve runbooks testados e faz uma verificação silenciosa de prontidão antes da aprovação.

Caso sintético. As rotinas e as pessoas são sintéticas.

Erros e limites

Os runbooks envelhecem conforme os sistemas mudam. Equipes de duas pessoas são frágeis durante as férias.

Exercícios

• EX076 — Por que a passagem. Por que os controles se deterioram sem passagem? Rubrica: 3 = ninguém mais sabe por que existem nem como operá-los;; 2 = conhecimento;; 1 = vago;; 0 = nenhuma.

• EX077 — Teste do runbook. O que o teste do runbook de restauração revelou? Rubrica: 3 = uma etapa sem a indicação de onde fica a senha;; 2 = lacuna;; 1 = vago;; 0 = nenhuma.

• EX078 — Medida da passagem. Como se mede uma boa passagem? Rubrica: 3 = por quão pouco a pessoa que sai é necessária depois;; 2 = independência;; 1 = extensão;; 0 = nenhuma.

Síntese

O repasse operacional dá certo com donos nomeados, runbooks testados e uma verificação de prontidão antes da saída.

Continue estudando — aula 26 (capítulo 26 de 30)

← Capítulo 25 · Índice das aulas · Capítulo 27 →

Continue para a próxima aula já escrita.