Quem mudou o quê: uma trilha de auditoria para o host
Em um host compartilhado, a pergunta mais difícil depois de um incidente não é o que quebrou; é quem mudou o quê antes de quebrar. O Atlas escreve uma trilha de auditoria das operações críticas: o autor, a ação, a hora e o resultado, mantida no host em dois lugares.
Por que quem fez o quê costuma ficar sem resposta
As ferramentas padrão espalham as evidências. O registro de tarefas do PVE conhece algumas operações, o histórico do shell conhece outras, e as edições de configuração muitas vezes não conhecem nada. Reconstruir uma noite significa costurar carimbos de hora entre os três.
O acesso root compartilhado piora tudo. Quando várias pessoas podem agir como root, as ações deixam de ter autor; os arquivos de histórico podem ser editados pelo mesmo poder que fez a mudança.
E a maioria das auditorias acontece na pior hora: depois de um incidente, sob pressão, com a pessoa que sabe a resposta sendo talvez a mesma que o causou.
Reconstruindo um incidente à mão
Sem trilha, a investigação habitual segue assim:
Ler o registro de tarefas do PVE na janela do incidente e anotar o que ele viu.
Vasculhar os históricos de shell do host, torcendo para ninguém ter usado conta compartilhada.
Percorrer o journalctl na mesma janela e tentar casar carimbos de hora.
Comparar as configurações atuais com o último backup para achar edições silenciosas.
Perguntar no chat da equipe quem mexeu no host naquele dia.
Escrever uma nota de incidente construída sobre provavelmente, e seguir em frente.
O que o Atlas põe por escrito
As operações críticas deixam trilha enquanto acontecem, não um mistério depois.
Ações críticas, registradas
Operações que mudam ou põem o sistema em risco, trabalhos destrutivos de armazenamento e rede, encerramentos de processos, ações sensíveis a privilégios, são escritas na trilha enquanto rodam.
Autor, ação, hora, resultado
Cada entrada responde de uma vez às quatro perguntas do incidente: quem disparou, o que exatamente rodou, quando, e se deu certo.
Duas cópias, resistentes a adulteração
As entradas vão para o journal do sistema, que usuários sem root não conseguem reescrever, e para um arquivo separado. Apagar rastros significa vencer os dois.
Papéis do Proxmox, respeitados
O Atlas não inventa um mundo próprio de permissões. Quem pode fazer o quê vem dos usuários e papéis do Proxmox, então a trilha corresponde a identidades reais.
Nenhum segredo no registro
Senhas e tokens nunca são escritos. A trilha registra que uma ação aconteceu, não as credenciais que a carregavam.
Os achados chegam sozinhos
O sentinela Watch avisa por e-mail dos achados críticos quando acontecem; a trilha é lida antes do incidente, não só depois.
Perguntas frequentes
- O que exatamente é registrado?
- Operações críticas e sensíveis a privilégios: mudanças destrutivas de armazenamento e rede, sinais a processos, ações no nível de serviços e afins. Leituras rotineiras não viram ruído na trilha.
- Um admin pode apagar os próprios rastros?
- A trilha é guardada duas vezes: no journal do sistema, que não se reescreve sem adulteração em nível root, e em um arquivo separado. Editar a história em silêncio deixa de ser trivial.
- Senhas ou corpos de requisição são guardados?
- Não. Segredos nunca são escritos na trilha; as entradas carregam autor, ação, hora e resultado.
- Onde o registro mora?
- No próprio host, no journal do sistema mais um arquivo separado. Nada é enviado a um serviço externo.
- Ele usa as contas do Proxmox?
- Sim. O Atlas espelha usuários, grupos e papéis do Proxmox em vez de inventar os próprios; as entradas de auditoria correspondem às identidades já gerenciadas no Proxmox.
- Registrar deixa o host lento?
- Não. Só as operações críticas são registradas, não cada clique; a trilha ocupa poucas linhas por ação arriscada.
Verbetes relacionados
- Tirei o acesso e a pessoa continua dentro: sessão não é a mesma coisa que permissão Você tirou a permissão, até desativou a conta, e a pessoa ainda consegue fazer coisas. Nada quebrou: tirar o acesso e encerrar a sessão são duas ações diferentes.
- Parar de trabalhar como root: a decisão que ninguém obriga e a que mais rende Trabalhar como root não explode um dia. Ele quebra em silêncio duas coisas: para quem o registro aponta e onde um clique errado para. A solução não é desativar o root, é tirar dele o trabalho diário.
- O registro de auditoria: a resposta a "quem fez", não a "o que aconteceu" A monitoração diz o que aconteceu, o registro de auditoria diz quem fez. O valor dele aparece nos dias que você espera que não cheguem, e se naquele dia você não o tiver, ele nunca existiu.