Logs de auditoria: o que registar, como mantê-los íntegros, e quem os pode ler

O que é

O OWASP Logging Cheat Sheet (citado) pede que cada entrada registe quando, onde, quem e o quê: os timestamps do evento e do log, a aplicação e o anfitrião, a identidade do utilizador ou máquina que atuou e o seu endereço de origem, o tipo de evento, o objeto afetado, o resultado e o motivo. A sua lista de eventos a registar sempre inclui sucessos e falhas de autenticação, falhas de autorização, ações de administração de utilizadores, uso de privilégios administrativos, acesso a dados sensíveis, uso e rotação de chaves, e alterações de configuração. Um log de auditoria é o subconjunto disto que documenta ações tomadas em nome de um principal, mantido como registo permanente, e não como output de diagnóstico.

Por que importa

Um log de auditoria só tem valor se for completo para as ações que importam e não puder ser silenciosamente editado pela própria pessoa cujas ações regista. A lista de ataques a logs do próprio cheat sheet inclui um atacante impedir escritas ou danificar o log para apagar os seus rastos, e fazer com que seja registada a identidade errada para ocultar o responsável.

Como aplicar

• Emita eventos de auditoria a partir da camada de aplicação, onde o principal e o objeto são conhecidos, como registos estruturados com um esquema estável: ator, tipo de ator, ação, tipo e id do objeto, resultado, motivo, id do pedido, timestamp em UTC.
• Registe o ator como um identificador, não como um nome de exibição, e inclua explicitamente a impersonação ("admin X a atuar como utilizador Y").
• Não escreva identificadores de sessão, tokens de acesso, palavras-passe, chaves ou dados pessoais completos; o cheat sheet lista estes itens entre os dados a excluir ou mascarar.
• Envie as entradas prontamente para um armazenamento que a aplicação não consiga alterar: uma tabela append-only sob um papel de base de dados apenas de escrita, ou armazenamento de objetos com bloqueio de retenção. O Amazon S3 Object Lock (citado) descreve um modelo write-once-read-many cujo modo de conformidade impede a substituição ou eliminação por qualquer utilizador durante o período de retenção.
• Acrescente evidência de adulteração, por exemplo uma cadeia de hashes ou resumos assinados periodicamente, e verifique-a regularmente.
• Restrinja o acesso de leitura a um grupo nomeado, registe cada leitura, e reveja periodicamente a lista de privilégios, como o cheat sheet pede.
• Defina a retenção antecipadamente e elimine segundo esse calendário; manter dados de auditoria para além do seu propósito é, em si, um risco.

Armadilhas

Misturar registos de auditoria com logs de aplicação que rodam ao fim de uma semana. Registar a intenção ("eliminação pedida") mas não o resultado. Mensagens em texto livre que não podem ser consultadas por queries. Confiar num id de utilizador fornecido pelo cliente dentro do evento. Um log imutável que ninguém lê até ao incidente.