Auditoria de scripts de automação Bash/Shell: quando a infraestrutura vira evidência

Scripts Bash e Shell são o "tecido conjuntivo" da infraestrutura de TI — deploys, backups, rotinas de limpeza, integrações entre sistemas. São os scripts que ninguém documenta, que "só um cara sabe como funciona", e que viram peça central do litígio quando algo dá errado: backup que não rodou, deploy que apagou dados, script que desligou o ambiente de produção.

O que a auditoria examina

• Histórico de execução: cron logs, systemd journals e history do shell mostram quando cada script rodou e com que parâmetros;
• Conteúdo do script: leitura direta do código para entender o que ele faz (e o que ele deveria fazer);
• Permissões e ownership: quem tem acesso para editar e executar o script;
• Versionamento: se os scripts estavam em Git (raro, mas revelador quando estão), dá para ver quem mudou o quê e quando.

Manipulação versus negligência

A perícia distingue entre: (a) um script que foi alterado intencionalmente para causar dano (ex.: um rm -rf inserido antes de uma saída); (b) um script que falhou por falta de tratamento de erros (ex.: variável não definida que expandiu para o diretório raiz); e (c) um script que nunca existiu (o contrato previa automação de backup, mas ninguém a implementou). Cada cenário tem consequências jurídicas diferentes — e a prova está no código e nos logs.