◇ OpenCyber Academy
Técnico · Capítulo 17 · Português

Capítulo 17 — Gestão de mudanças e documentação

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 17 — Gestão de mudanças e documentação

Mapa da aula

Aula 17 publicada. Mapa, exemplo, EX065.

flowchart TD
  N0["17.1 Por que o controle de mudanças é segurança"]
  N1["17.2 Uma solicitação de mudança"]
  N2["17.3 Reversão"]
  N3["17.4 Manter os documentos atualizados"]
  N4["17.5 Revisores"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX065"]

Desenho lógico

flowchart LR
  N0["17.1 Por que o controle de mudanças é segurança"]
  N1["17.2 Uma solicitação de mudança"]
  N2["17.3 Reversão"]
  N3["17.4 Manter os documentos atualizados"]
  N4["17.5 Revisores"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX065"]
[17.1 Por que o controle de mudanças é segurança]
    |
    v
[17.2 Uma solicitação de mudança]
    |
    v
[17.3 Reversão]
    |
    v
[17.4 Manter os documentos atualizados]
    |
    v
[17.5 Revisores]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX065]

Objetivos de aprendizagem

Você vai (1) explicar por que toda mudança na linha precisa de um chamado; (2) escrever uma solicitação de mudança com um plano de reversão; e (3) manter os desenhos e os registros em dia com a realidade.

17.1 Por que o controle de mudanças é segurança

A maioria dos problemas nas plantas vem de mudanças que ninguém registrou: uma regra de firewall acrescentada às pressas, um programa editado durante uma pane, uma câmera parafusada por um empreiteiro. Controle de mudanças significa que toda mudança é solicitada, revisada, aprovada, executada e registrada. Ele também facilita perceber uma mudança não registrada, que pode ser o primeiro sinal de um ataque.

Na HPFL, vários problemas deste livro começaram como mudanças não registradas: o programa da embaladora editado no Capítulo 11, a regra temporária de firewall no Capítulo 12 e a porta de área de trabalho remota no Capítulo 16. Cada uma teria ficado visível mais cedo com um chamado.

17.2 Uma solicitação de mudança

Ela declara o que vai mudar, por quê, quais dispositivos, quem faz, quando, o risco para o processo, como o sucesso é verificado e como desfazer. Mudanças emergenciais durante uma pane são permitidas, mas são registradas depois, em até um turno.

Na HPFL, a solicitação de Tomás para a atualização da VIS-CAM cobriu tudo isso em poucas linhas. Mantenha o formulário curto, para que as pessoas realmente o usem. O aprovador verifica se o teste de sucesso e a reversão são realistas antes de concordar.

17.3 Reversão

Antes da mudança, salve o programa ou a configuração atual e o seu hash. Se a verificação falhar, restaure-o. Uma mudança sem reversão é uma aposta.

Na HPFL, a reversão da VIS-CAM era reinstalar o firmware 1.0.7 a partir de um arquivo salvo, com o seu hash registrado. Teste se o arquivo salvo está completo antes de começar a mudança. Se a própria reversão falhar, pare e chame o engenheiro de controle. Na HPFL, os hashes dos arquivos salvos eram registrados no chamado de mudança, para que um arquivo restaurado pudesse ser verificado antes de ser carregado. Sem isso, uma reversão poderia carregar uma cópia corrompida ou editada sem que ninguém percebesse.

17.4 Manter os documentos atualizados

Atualize o registro de ativos, o desenho da rede e a tabela de regras no mesmo chamado. Marque os desenhos com um número de revisão e uma data.

Na HPFL, o desenho da rede ainda estava na revisão 3, enquanto a VLAN de IoT aparecia apenas nos rascunhos da revisão 4, o que a vistoria final encontrou. Atualizar os documentos no mesmo chamado impede que essa lacuna se abra. Quando um desenho mudar, marque a revisão antiga como substituída e guarde-a, para que as decisões passadas ainda possam ser entendidas. Confira os números de revisão em cada vistoria; um desenho cuja revisão está atrás da realidade é, ele mesmo, uma constatação, como a HPFL aprendeu.

17.5 Revisores

Quem faz uma mudança não deve ser a única pessoa a aprová-la. Na HPFL, o engenheiro de controle revisa as mudanças de programas, o dono da rede revisa as mudanças de firewall e de switches, e o supervisor confirma a janela de produção. Um segundo par de olhos pega erros de digitação em endereços e valores antes que cheguem à linha.

Registre o nome do revisor no chamado. Se a única pessoa capaz de revisar estiver indisponível, espere a próxima janela, a menos que a mudança seja emergencial.

Exemplo resolvido (HPFL sintética)

O fornecedor da câmera de visão precisa do firmware 1.1.0 na VIS-CAM. Tomás escreve: "Mudança 512 — atualizar a VIS-CAM de 1.0.7 para 1.1.0 para correção da precisão de rejeição; pelo técnico de qualidade; terça-feira, 06:00, parada planejada; risco: as rejeições deixam de funcionar; verificação: 20 embalagens de teste, incluindo 5 selagens ruins rejeitadas; reversão: reinstalar a 1.0.7 a partir do arquivo salvo, hash registrado." A atualização passa na verificação, e o registro de ativos mostra 1.1.0.

Caso sintético — HPFL. A mudança e a correção do fornecedor são inventadas.

Erros e limites

O controle de mudanças pode virar um exercício de papelada; mantenha os formulários curtos e exija os campos-chave. As mudanças emergenciais não devem virar o caminho normal.

Exercícios

Síntese

Mudanças solicitadas, revisadas, reversíveis e registradas mantêm a linha conhecida; as não registradas são avisos.

Continue estudando — capítulo 17 de 18

← Capítulo 16 · Índice de capítulos do curso · Capítulo 18 →

Siga para a próxima lição escrita.