Logs e auditoria no Proxmox: quem fez o quê e quando

Duas perguntas aparecem depois de todo incidente sério, e as duas costumam ficar sem resposta: "quem apagou aquela VM?" e "o que exatamente aconteceu entre 2h14 e 2h27?".

O Proxmox registra muito mais do que a maioria das equipes sabe. O problema não é falta de informação — é que ela está espalhada entre fontes diferentes, em nós diferentes, e desaparece junto com o nó quando é justamente ele que você precisa investigar.

Onde cada coisa é registrada

Fonte	O que contém	Onde aparece
Log de tarefas	Toda operação: criar, migrar, backup, restaurar, snapshot, com usuário e resultado	Painel, por nó
Log do sistema	Serviços, kernel, autenticação, hardware	`journalctl` no nó
Cluster	Quórum, entrada e saída de nós, eleição	Log do sistema, componente do Corosync
Alta disponibilidade	Decisões de failover, estado dos recursos	Log do sistema
Firewall	Pacotes descartados, conforme o nível configurado	Log do sistema
Storage	Ceph, ZFS, montagens	Log do sistema e ferramentas próprias
Backup	Resultado por tarefa, verificação de integridade	Log de tarefas e log do PBS

O log de tarefas é o mais valioso para a pergunta "quem fez o quê", e o mais subutilizado. Ele registra cada operação com o usuário que a executou, o horário, a duração e o resultado — e é acessível tanto pelo painel quanto pela API, o que permite exportá-lo.

Com uma condição: ele só tem valor se os usuários forem nominais. Se a equipe inteira usa root@pam, todo registro diz root@pam e a pergunta continua sem resposta.

O problema estrutural: log local

Três razões pelas quais log apenas no nó não resolve:

O nó com problema é justamente o que você precisa investigar. Nó que travou, foi reiniciado por watchdog ou perdeu o disco leva o log junto.
Correlação entre nós é impossível na prática. Um evento de cluster envolve todos os nós, e reconstruir a sequência abrindo terminal em cada um, com relógios possivelmente divergentes, é inviável sob pressão.
Quem tem privilégio pode apagar. Log local não serve como evidência de auditoria, porque quem quer esconder algo tem acesso a ele.

A correção é exportar tudo para um coletor central, com armazenamento que só aceita adição, fora dos nós. É um trabalho de algumas horas e muda completamente a capacidade de investigação.

O que centralizar

Log do sistema de todos os nós, incluindo autenticação, kernel, cluster e HA.
Log de tarefas, coletado pela API periodicamente. É a fonte da auditoria de ações.
Log do Proxmox Backup Server, incluindo resultado de verificação de integridade.
Log do firewall, no nível que você configurou.
Log dos switches e do BMC, se possível. Muito incidente de cluster tem causa na rede, e sem o log do switch a investigação para.

E dois pré-requisitos que parecem menores e não são:

Relógio sincronizado em todos os nós e equipamentos, com a mesma fonte. Log com horário divergente é quase inútil para correlacionar, e a divergência costuma ser descoberta durante a investigação, quando já é tarde.
Fuso horário consistente, ou registro em UTC. Nada consome mais tempo em análise do que descobrir que um equipamento estava em outro fuso.

Retenção: quanto tempo guardar

A resposta depende do que você precisa responder:

Operação do dia a dia: 30 dias cobre a maioria dos diagnósticos.
Investigação de incidente descoberto tarde: 90 dias a 1 ano. Comprometimento costuma ser detectado semanas depois do acesso inicial.
Exigência contratual ou regulatória: o que o contrato disser — e vale conferir, porque cliente corporativo frequentemente exige um período específico.

Uma estratégia comum e eficiente: log completo por 30 dias em armazenamento rápido, e log comprimido de eventos relevantes por um ano em armazenamento barato.

Alertar, não só guardar

Log guardado e nunca lido serve para investigação depois do estrago. Alguns eventos merecem alerta no momento em que acontecem:

Uso da conta root — deveria ser excepcional; toda ocorrência merece confirmação.
Falhas repetidas de autenticação, especialmente a partir do mesmo endereço.
Criação, alteração ou remoção de permissão e de token de API.
Perda de quórum ou mudança na composição do cluster.
Ação de alta disponibilidade — failover, autoisolamento de nó.
Falha de backup, e igualmente ausência de backup que deveria ter rodado.
Falha na verificação de integridade de backup.
Storage degradado — disco fora do pool, Ceph em estado não saudável.
Exclusão de VM. Vale alertar sempre; é a operação irreversível mais comum.
Alteração de configuração de cluster ou de firewall.

A lista propositalmente não inclui métrica de uso — CPU alta, disco enchendo — que pertence ao monitoramento, com sua própria política de limiar. São coisas complementares: métrica avisa que algo vai acontecer; log conta o que aconteceu.

Como investigar um incidente

Um método que funciona e evita perder tempo:

Fixe a janela de tempo com margem generosa nos dois lados. O evento que causou costuma preceder o sintoma.
Comece pelo log de tarefas. Alguma ação humana ou automatizada coincide com o início? Isso resolve uma parcela grande dos casos rapidamente.
Verifique o cluster. Houve perda de quórum, saída de nó, mudança de composição? Muito comportamento inexplicável de VM tem origem aí.
Verifique o storage. Latência, disco fora, pool degradado, replicação parada.
Verifique a rede. Log do switch, queda de enlace, mudança de topologia. É a causa mais frequente e a menos investigada.
Só então entre no sistema convidado. A VM é a última camada, não a primeira.
Monte a linha do tempo com tudo em um único fuso, em ordem.

O passo 7 é o que transforma fragmentos em explicação — e é praticamente impossível sem log centralizado.

Auditoria: o que um cliente corporativo vai pedir

Se você opera para terceiros, ou tem auditoria interna, prepare-se para estas perguntas:

Quem tem acesso administrativo ao ambiente, e desde quando?
Como o acesso é revogado quando alguém sai?
Existe registro de cada ação administrativa, com autor e horário?
O registro é protegido contra alteração por quem tem privilégio?
Por quanto tempo o registro é guardado?
Existe alerta para eventos sensíveis?
É possível demonstrar o que aconteceu em uma data específica?

Ter essas respostas prontas, com evidência, é vantagem comercial concreta — e é um trabalho de preparação, não de improviso na semana da auditoria.

Erros comuns

Equipe inteira usando root, tornando o log de tarefas inútil.
Log apenas local, perdido junto com o nó investigado.
Relógio dessincronizado entre nós e equipamentos.
Fusos horários divergentes entre as fontes.
Não coletar o log de tarefas, que é a fonte de auditoria de ações.
Não coletar log de switch e de BMC, e travar a investigação de causa de rede.
Retenção curta demais para incidente descoberto tarde.
Guardar tudo e não alertar nada.
Alertar falha de backup mas não ausência de backup.
Não alertar em exclusão de VM.
Log em armazenamento que quem tem privilégio pode alterar.
Começar a investigação pelo sistema convidado.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, implantamos a camada de registro e auditoria: exportação do log do sistema e do log de tarefas de todos os nós e do PBS para coletor central com armazenamento que só aceita adição, sincronização de relógio e padronização de fuso, retenção dimensionada à sua exigência contratual, alertas nos eventos sensíveis e painéis de correlação que permitem montar a linha do tempo de um incidente em minutos. Também preparamos o material de evidência que auditoria de cliente corporativo costuma pedir.

Você consegue dizer quem apagou uma VM na semana passada? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.