Capítulo 14 — Infraestrutura crítica e segurança setorial: métodos I
Mapa da aula
Aula 14 publicada. Mapa, exemplo, EX040.
flowchart TD
N0["14.1 Linhas de base de configuração"]
N1["14.2 Um controle de mudanças que as pessoas vão usar"]
N2["14.3 Planejar uma mudança num ambiente operacional"]
N3["14.4 Evidências da mudança"]
N4["14.6 Atividade prática: escreva um plano de mudança"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX040"]
Desenho lógico
flowchart LR
N0["14.1 Linhas de base de configuração"]
N1["14.2 Um controle de mudanças que as pessoas vão usar"]
N2["14.3 Planejar uma mudança num ambiente operacional"]
N3["14.4 Evidências da mudança"]
N4["14.6 Atividade prática: escreva um plano de mudança"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX040"]
[14.1 Linhas de base de configuração]
|
v
[14.2 Um controle de mudanças que as pessoas vão usar]
|
v
[14.3 Planejar uma mudança num ambiente operacional]
|
v
[14.4 Evidências da mudança]
|
v
[14.6 Atividade prática: escreva um plano de mudança]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX040]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- escrever uma linha de base de configuração para uma classe de host e mantê-la sob controle de versões;
- conduzir um controle de mudanças proporcional: mudanças padrão, normais e de emergência;
- planejar uma mudança num ambiente operacional, com verificações prévias, uma janela, um rollback e uma etapa de verificação;
- ligar toda mudança a evidências de que ela foi feita como aprovada.
Os Capítulos 1–13 descreveram sistemas, dados e riscos. Este capítulo e o Capítulo 16 tratam de métodos: as rotinas que um tecnólogo executa toda semana. Métodos I cobre linhas de base e mudanças, porque quase todos os outros controles dependem de saber como um sistema deveria ser e de controlar como ele muda.
14.1 Linhas de base de configuração
Uma linha de base é a configuração aprovada para uma classe de sistema: pacotes instalados e as suas versões, serviços habilitados e os seus endereços de escuta, contas e grupos, permissões de arquivos, configurações de logs e de hora, e parâmetros de segurança. O guia do NIST sobre gestão de configuração focada em segurança descreve como estabelecer linhas de base, controlar as mudanças nelas e monitorar desvios (NIST SP 800-128). Escreva a linha de base como um arquivo sob controle de versões, e não como um documento na pasta de alguém: o Capítulo 22 a usa para detectar a deriva automaticamente.
14.2 Um controle de mudanças que as pessoas vão usar
O controle de mudanças existe para impedir que mudanças não revisadas causem interrupções ou enfraqueçam a segurança. Processos pesados demais são contornados; é assim que surgem listeners de depuração e scripts auxiliares sem explicação (Capítulo 6). Um esquema proporcional tem três tipos de mudança:
- Mudanças padrão — pré-aprovadas, de baixo risco, repetíveis (acrescentar uma estação à allowlist a partir de uma solicitação aprovada). Seguem um procedimento escrito e são registradas.
- Mudanças normais — revisadas e aprovadas antes da implementação, com um plano e um rollback.
- Mudanças de emergência — feitas rapidamente para restaurar o serviço ou conter um incidente, aprovadas por uma autoridade de plantão nomeada e revisadas depois.
Na TO, a aprovação de qualquer mudança que possa afetar o processo físico inclui o responsável pela operação, e não apenas a TI.
14.3 Planejar uma mudança num ambiente operacional
Um plano de mudança do LANTERN declara: o que vai mudar e por quê; os sistemas e clientes afetados; as verificações prévias (backups feitos, rollback preparado, operação informada); a janela (acordada com a operação — não durante o pico de demanda da manhã nem durante uma execução programada de relatórios); a implementação passo a passo; a verificação (como você vai saber que funcionou — verificações específicas, e não "testar o serviço"); os critérios e as etapas do rollback; e para quem ligar. O Capítulo 27 estende isso para implantações com canários.
Mover o listener SSH do RLY-02 é um caso típico: o rollback não pode depender do SSH.
14.4 Evidências da mudança
Depois de uma mudança, três coisas devem concordar: o registro da mudança (o que foi aprovado), a linha de base sob controle de versões (o que agora deveria ser verdade) e o próprio sistema (o que é verdade, verificado pela verificação de integridade do Capítulo 6 e pela verificação de deriva do Capítulo 22). Quando discordam, ou a mudança não foi feita como aprovada, ou o registro está errado. As duas coisas são constatações.
Depois da CHG-118, as três concordavam para allow.list e discordavam para o listener de depuração.
Para o listener de depuração não havia registro de mudança algum, então a própria discordância foi a constatação, e ela levou à investigação do Capítulo 6.
14.5 Exemplo resolvido: acrescentar a PS-11 (sintético)
A operação de Água comissiona uma nova estação, a PS-11. Acrescentá-la ao LANTERN é uma mudança padrão com um procedimento escrito: (1) receber a solicitação de comissionamento com o ID da estação, o endereço e o responsável; (2) confirmar que o conduíte já cobre a sub-rede da estação; (3) acrescentar PS-11 à allowlist sob controle de versões, com revisão de um segundo tecnólogo; (4) implantar a allowlist nos relays; (5) verificar: as primeiras mensagens da PS-11 aparecem como accept no log do relay; a verificação de integridade mostra que allow.list mudou sob a CHG-118 e nada mais; (6) atualizar o inventário e o registro de fluxos de dados. No laboratório do Capítulo 6, essa foi a única diferença aprovada. As outras três diferenças não tinham registro de mudança — e foi assim que o método as revelou.
14.6 Atividade prática: escreva um plano de mudança normal
Escreva um plano de mudança completo para: "Mover o listener SSH do RLY-02 de todas as interfaces apenas para a interface de gerenciamento." Inclua todos os elementos do Capítulo 14 ("Planejar uma mudança num ambiente operacional"). Preste atenção ao risco de se trancar do lado de fora: como você vai alcançar o host se a mudança falhar?
Para a mudança do RLY-02, um plano seguro mantém uma segunda forma de entrar: acesso ao console pelo hipervisor, ou uma sessão aberta na interface de gerenciamento, testada antes que o listener seja movido. A verificação é específica: o SSH responde no endereço de gerenciamento, não responde no endereço voltado às estações, e a verificação de deriva mostra que só a linha pretendida mudou. Escolha a janela com a operação de Água, evitando o pico de demanda da manhã e as execuções semanais de relatórios nos dias 6 e 7.
14.7 Erros comuns e limites
- Linhas de base mantidas como documentos que ninguém compara com os sistemas.
- Processos de mudança tão pesados que as pessoas os contornam.
- Janelas de mudança escolhidas pela conveniência da TI, e não da operação.
- "Verificar se o serviço funciona" como etapa de verificação.
- Planos de rollback que nunca foram testados.
- Mudanças de emergência nunca revisadas depois, que assim se tornam permanentes.
O controle de mudanças controla as mudanças autorizadas. Ele não detecta mudanças não autorizadas; esse é o trabalho das verificações de integridade e de deriva.
A fusão do NTP no Capítulo 25 é o quarto erro na prática: o seu critério de aceitação dizia apenas "atualizar os servidores NTP".
Exercícios — capítulo 14
EX040 — Classifique as mudanças. Objetivo: aplicar um controle de mudanças proporcional. Entradas: (a) acrescentar uma estação à allowlist; (b) atualizar o software do relay para uma nova versão menor; (c) desabilitar uma conta de fornecedor comprometida às 02:00; (d) mudar a retenção do historiador de 730 para 365 dias; (e) rotacionar a chave HMAC do relay. Restrições: padrão, normal ou de emergência para cada uma, com um motivo. Etapas: classifique e diga quem aprova. Evidência esperada: tabela. Rubrica: 3 = (a) padrão, (b) normal, (c) de emergência, com aprovação do plantão e revisão, (d) normal, com aprovação do responsável pelos dados, porque afeta registros e obrigações, (e) normal (ou padrão, quando existir um procedimento testado), coordenada com as estações; aprovadores sensatos; 2 = uma mal classificada; 1 = todas normais; 0 = nada.
EX041 — Etapas de verificação. Objetivo: escrever uma verificação específica. Entradas: a mudança "o relay encaminha ao HIST-01 por TLS 1.3 em vez de TLS 1.2". Restrições: pelo menos quatro verificações; cada uma observável. Etapas: liste as verificações e a evidência que cada uma produz. Evidência esperada: lista. Rubrica: 3 = por exemplo, o log de conexões mostra TLS 1.3 negociado, o historiador recebe leituras de todas as estações dentro da latência normal, nenhum aumento de erros ou rejeições no relay, a validação de certificados continua aplicada, a verificação de integridade mostra que só o arquivo aprovado mudou; 2 = três; 1 = "testar"; 0 = nada.
EX042 — Revise uma mudança de emergência. Objetivo: fechar o ciclo de uma mudança de emergência. Entradas: durante uma interrupção às 03:00, um engenheiro abriu a tcp/22 da zona corporativa diretamente para todos os relays, "temporariamente". Restrições: revisão pós-mudança em até um dia útil. Etapas: (1) liste as perguntas que a revisão faz; (2) decida o que acontece com a regra; (3) diga qual mudança de processo impede uma repetição. Evidência esperada: nota de revisão. Rubrica: 3 = pergunta por que a rota pelo host de salto falhou, quem aprovou, o que foi acessado durante a janela (logs), remove ou estreita a regra com um registro de mudança, corrige a resiliência do host de salto ou o projeto do acesso de emergência; 2 = regra removida, mas sem causa raiz; 1 = regra mantida; 0 = nada.
Síntese do capítulo
Escreva as configurações aprovadas como linhas de base sob controle de versões. Conduza o controle de mudanças de forma proporcional — padrão, normal e de emergência —, com a operação aprovando as mudanças que podem afetar o processo físico. Planeje as mudanças com verificações prévias, uma janela acordada, uma verificação específica e um rollback testado. Depois de toda mudança, o registro, a linha de base e o sistema devem concordar; quando não concordam, você tem uma constatação.
Continue estudando — capítulo 14 de 30
← Capítulo 13 · Índice de capítulos do curso · Capítulo 15 →
Siga para a próxima lição escrita.