ISO 27001 para empresas de TI: evidências de acesso, log e backup

28 de setembro de 20268 min de leitura
ISO 27001SegurançaAuditoriaBackupTI

Introdução

"ISO para empresas de TI" chega na auditoria como três pastas, não como um discurso sobre a norma. Quem audita pede quem entra no servidor, o que ficou registrado quando entrou e se o backup volta. O resto do anexo A só importa depois que esses três existem.

A versão 2022 da ISO/IEC 27001 coloca isso em controles com número, não em capítulo de livro:

A.5.15 controle de acesso A.8.15 registro de eventos (logging) A.8.13 backup da informação

Este artigo é o que eu levo na pasta. A política mora no artigo de governança. Se a empresa também roda IA, o modelo que não sai da máquina está no artigo de RAG local e ISO. Aqui é o servidor comum: acesso, log e restore.


Acesso: quem tem shell hoje

A planilha de acessos desatualizada perde para o que o sistema diz agora. Eu gero a lista na hora e anexo o arquivo com data no nome.

getent passwd | awk -F: '$3>=1000 && $3<65534 {print $1}' > /var/audit/access/users-$(date -I).txt
getent group sudo wheel 2>/dev/null
awk -F: '$2!~/^(\|!)/ {print $1}' /etc/shadow
last -F | head -n 30

A primeira linha são contas humanas. A segunda é quem administra. A terceira mostra senha ainda ativa (hash presente). last é a amostra de quem entrou.

O controle A.5.15 não pede que ninguém tenha sudo. Pede que a lista bata com a função. Se o estagiário aparece em sudo e não está na matriz de acesso, a evidência já falhou antes da pergunta sobre firewall.

Conta de serviço não entra nessa lista de humanos. Ela tem usuário próprio, sem senha interativa, e o nome dela aparece no unit file, não no sudo.


Log: um evento que dá para achar

A.8.15 pede registro que alguém consiga ler meses depois. Um syslog que gira em sete dias não serve. Eu mostro uma busca por um evento real, com hora e host.

ausearch -k sudo-exec --start today -i | head -n 20
logger -t iso-evidence "CHG-1108 alex conferiu backup semanal"
grep "CHG-1108" /var/log/syslog /var/log/messages 2>/dev/null | tail

Se ausearch não devolve nada, a regra de auditd para execve do sudo não está ativa. Sem regra, não há evidência. A regra mínima:

auditctl -w /usr/bin/sudo -p x -k sudo-exec

Isso não substitui a regra persistida em /etc/audit/rules.d/. auditctl sozinho morre no reboot e a auditoria do ano que vem abre um host mudo. Grava a regra no disco e confirma com auditctl -l depois de reiniciar.

O mesmo hábito vale para o chamado. O SLA que o Grafana lê no OTRS é outra evidência operacional, no artigo de Grafana e OTRS. Não mistura com o log de sudo, mas a auditoria pergunta os dois.


Backup: o restore, não a política

A.8.13 não se prova com "temos backup diário" escrito no POP. Se prova com um arquivo restaurado e o hash batendo.

install -d -m 750 /var/audit/restore /tmp/restore-test
tar -C /etc -czf /var/audit/restore/etc-$(date -I).tar.gz ssh sudoers.d
sha256sum /var/audit/restore/etc-$(date -I).tar.gz \
  | tee /var/audit/restore/etc-$(date -I).sha256

sha256sum -c /var/audit/restore/etc-$(date -I).sha256 rm -rf /tmp/restore-test && mkdir /tmp/restore-test tar -C /tmp/restore-test -xzf /var/audit/restore/etc-$(date -I).tar.gz test -f /tmp/restore-test/ssh/sshd_config && echo "restore ok"

O sha256sum -c confere o pacote com o hash gravado no dia do backup, antes de abrir. Só então o tar extrai e o test mostra que o sshd_config voltou. Abrir o arquivo sem o -c prova que ele não está corrompido. Não prova que é o pacote daquela data.

Para o dado de aplicação, o mesmo roteiro: um dump, um checksum, um restore em outro diretório, uma query que devolve uma linha que você escolheu antes. No HANA esse restore é o BACKUP DATA do artigo de SAP Business One na AWS. O princípio é o mesmo em disco local.

Guarde o checksum fora da máquina que gera o backup. Na mesma pasta, quem apaga o tar apaga a prova.


A pasta que vai para a sala

No dia da auditoria eu não abro a norma. Abro três arquivos:

  1. users-AAAA-MM-DD.txt, comparado com a matriz de acesso.
  2. Uma linha de ausearch ou de syslog com a mudança da semana.
  3. O .sha256 e o log do restore de teste.

Se um dos três falta, o discurso sobre ISO 27001 não segura a pergunta seguinte. Os outros controles existem. Estes três são os que separam a empresa de TI que opera a norma da empresa que imprimiu o certificado.

Artigos Relacionados