Preparar a recuperação antes de uma mudança de hardening: acesso por console, backup, rollback automático agendado e registro da mudança

Objetivo

Transformar uma mudança de hardening que afeta rede, autenticação ou firewall em algo que se reverte sozinho caso bloqueie o operador, em vez de exigir acesso físico ou fora de banda para corrigir.

Pré-requisitos

Um caminho fora de banda até o host que não dependa da mudança a ser feita (console serial/IPMI/hipervisor, ou o acesso por console do provedor de nuvem), com a alcançabilidade confirmada antes de começar; permissão para agendar um job de execução única no sistema operacional de destino.

Passos

1. Confirme que o acesso fora de banda funciona agora, antes de mexer em qualquer coisa — não basta "funcionou no mês passado". Se o próprio acesso ao console depender da mudança que está sendo testada (por exemplo, se a mudança afeta o jump host), execute a mudança a partir de uma sessão que não dependa do que será alterado.
2. Faça backup exatamente do que vai mudar: o arquivo de configuração específico, o conjunto de regras de firewall ou a exportação de GPO, com timestamp no nome do arquivo, e não apenas "existem backups recentes em algum lugar".
3. Arme um rollback agendado e incondicional antes de aplicar a mudança arriscada:
   • Linux, execução única e transitória (como root): systemd-run --unit=rollback-net --on-active=10min /usr/local/sbin/rollback-network.sh, usando o timer --on-active= do systemd para disparar em relação ao momento atual, independentemente do que aconteça com o shell ou a sessão SSH atual; isso cria rollback-net.timer e rollback-net.service.
   • Linux, fila clássica: echo /usr/local/sbin/rollback-network.sh | at now + 10 minutes, usando o at, documentado como ferramenta para "queue, examine, or delete jobs for later execution" (enfileirar, examinar ou excluir jobs para execução posterior) — atq lista os jobs pendentes e atrm cancela um deles depois que o sucesso for confirmado. O pacote at e um atd em execução são necessários e estão ausentes em muitas instalações mínimas.
   • Windows: Register-ScheduledTask com um gatilho criado por New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(10), executando um script de rollback sob um principal que não dependa da mudança, por exemplo New-ScheduledTaskPrincipal -UserId SYSTEM -RunLevel Highest.
4. Aplique a mudança de hardening.
5. Confirme o sucesso pelo mesmo canal que será usado daqui em diante (não apenas pela sessão atual, que pode continuar válida por já estar estabelecida). Se confirmado, cancele o rollback agendado (atrm <job>, systemctl stop rollback-net.timer ou Unregister-ScheduledTask -TaskName <name> -Confirm:$false) e verifique que ele não existe mais (atq, systemctl list-timers, Get-ScheduledTask).
6. Registre a mudança, seu timestamp, o local do backup e o ID do job de rollback em um log de mudanças antes de passar para a próxima tarefa — é isso que permite rastrear um incidente posterior até uma ação específica e datada.

Resultado esperado

Se a mudança quebrar o caminho de acesso em uso, o job agendado dispara sem supervisão e restaura a configuração anterior dentro da janela escolhida; se a mudança der certo, o rollback é cancelado e nunca dispara.

Limites e base de verificação

Um rollback agendado só ajuda se o próprio script de rollback estiver correto e tiver sido testado com o formato de backup específico gerado no passo 2 — teste o script de rollback ao menos uma vez, em uma janela fora de produção. O comportamento em reinicializações varia: um timer transitório do systemd-run se perde no reboot, portanto uma mudança que só entra em vigor após reiniciar não é coberta por ele; os jobs do at ficam no diretório de spool e sobrevivem a um reboot, de modo que um rollback atrasado ainda pode ser executado quando o atd voltar a iniciar; uma tarefa agendada do Windows persiste até ser removida. Verifique o estado do atd, do systemd ou do Agendador de Tarefas se um job parecer não ter disparado. Nenhum destes passos exige uma reinicialização por si só.