Esta aplicação autoalojada deixa um rasto de auditoria? Uma checklist para compradores

Os logs de auditoria são um requisito na seleção da aplicação

Uma aplicação autoalojada pode ser fácil de implementar e, ainda assim, ser inadequada para dados cuja utilização exige responsabilização. Se a aplicação guardar dados empresariais de clientes, colaboradores, finanças, operações ou outros dados sensíveis, faça uma pergunta desde cedo: conseguirá a equipa estabelecer mais tarde quem fez o quê, a que objeto, quando e através de que interface?

Isto é mais abrangente do que a resposta a incidentes. Um rasto de auditoria utilizável pode apoiar a investigação de uma alteração inesperada, fluxos de trabalho de aprovação e exceção, revisões periódicas de acessos, a responsabilização por alterações de configuração e a recolha de evidências após uma disputa. As orientações do [NIST sobre conhecimento de eventos](https://pages.nist.gov/FederalProfile-8259A/technical/event/) identificam a interação do utilizador e o momento, ações de configuração e o acesso e utilização de dados armazenados como capacidades relevantes para auditoria.

Não considere que «tem logs» é uma resposta suficiente. A auditabilidade é uma propriedade do produto e da implementação. A aplicação tem de gerar os eventos necessários, a implementação tem de os reter, os revisores autorizados têm de conseguir recuperá-los e interpretá-los, e os controlos têm de os proteger contra alteração ou eliminação não autorizadas.

• Torne a auditabilidade um requisito pontuado antes de selecionar uma aplicação, em vez de uma tarefa adiada para depois da entrada em produção.
• Defina requisitos em termos das decisões que os registos têm de suportar, como «identificar quem atribuiu uma função» ou «rever exportações de registos de clientes».
• Atribua a responsabilidade pelas definições de auditoria da aplicação, procedimentos de revisão de logs, decisões de retenção e acesso a evidências exportadas.

Logs operacionais, logs de auditoria e histórico da base de dados respondem a perguntas diferentes

Os logs operacionais destinam-se sobretudo à operação do software. Os controladores de logging do [Docker](https://docs.docker.com/engine/logging/configure/) obtêm informações de contentores e serviços em execução; o controlador json-file predefinido armazena internamente os logs de contentores, salvo se for utilizada outra configuração. Esses registos podem ajudar a diagnosticar uma falha, um aviso ou um erro de execução, mas não estabelecem inerentemente que um utilizador empresarial identificado alterou um registo específico de cliente.

Os logs de proxy reverso descrevem uma camada diferente. O [Traefik](https://doc.traefik.io/traefik/observe/logs-and-access-logs/) distingue os seus próprios logs, que cobrem aspetos como arranque, configuração, eventos e encerramento, dos logs de acesso para pedidos tratados pelo proxy. Os logs de acesso podem estabelecer que um pedido chegou a um endpoint, mas podem não identificar de forma fiável o interveniente empresarial autenticado, o objeto empresarial afetado ou o resultado da ação. Os seus campos também podem ser deliberadamente retidos, descartados ou sujeitos a ocultação.

O histórico da base de dados é diferente, mais uma vez. O [write-ahead logging do PostgreSQL](https://www.postgresql.org/docs/15/wal-intro.html) regista alterações nos ficheiros de dados antes de os ficheiros subjacentes serem alterados, para que a recuperação possa refazer alterações depois de uma falha. A [descodificação lógica](https://www.postgresql.org/docs/17/logicaldecoding-explanation.html) pode tornar legíveis, a partir do WAL, alterações persistentes em tabelas. Nenhum dos mecanismos fornece automaticamente uma narrativa empresarial pronta para investigação: o contexto da aplicação, a identidade do utilizador, o contexto de autorização e o significado de uma alteração podem estar ausentes ou ser difíceis de reconstruir.

Utilize cada fonte para a finalidade apropriada. Os logs operacionais e de proxy continuam a ser valiosos para resolução de problemas e investigações de infraestrutura. Os mecanismos de base de dados podem ser úteis para recuperação ou análise técnica. Mas não substitua nenhum deles por registos de auditoria ao nível da aplicação sem testar se satisfazem o requisito real de evidência.

• Log operacional: «O que reportou o processo ou contentor?»
• Log de acesso do proxy: «Que pedido foi tratado pela camada de entrada?»
• Histórico da base de dados: «Que alteração ao nível do armazenamento ocorreu?»
• Registo de auditoria da aplicação: «Que interveniente realizou que ação empresarial ou administrativa relevante, sobre o quê, quando e com que resultado?»

Comece pelas decisões que o rasto tem de suportar

Uma lista extensa de eventos não é um requisito. Comece por enumerar as perguntas a que um revisor tem de conseguir responder em condições realistas. Isto evita que as equipas sobrevalorizem o logging técnico de elevado volume, ignorando as poucas ações que criam o maior risco empresarial.

Por exemplo, uma revisão trimestral de acessos precisa de informação fiável sobre associação e alteração de funções. Uma investigação sobre dados financeiros alterados pode exigir a entidade afetada, valores antes e depois quando apropriado, identidade do interveniente, hora e resultado da ação. Um fluxo de aprovação pode exigir prova de que uma pessoa designada aprovou, rejeitou ou contornou uma etapa. Os campos exatos e o período de retenção devem decorrer destas perguntas.

Torne o âmbito explícito. Um sistema pode auditar atividade de administradores, mas não alterações de utilizadores comuns, ou registar autenticações bem-sucedidas, mas não falhas. Nenhuma destas situações é inerentemente inaceitável; a questão é saber se a cobertura documentada e testada corresponde aos seus casos de utilização declarados.

• Investigações: consegue identificar o interveniente, objeto, ação, hora, resultado e contexto relevante?
• Aprovações: consegue demonstrar quem aprovou, rejeitou, delegou ou alterou uma regra de aprovação?
• Revisões de acesso: consegue identificar associação, funções, alterações de permissões e o interveniente responsável?
• Responsabilização por alterações: consegue rastrear alterações administrativas de configuração, alterações de integrações e definições relevantes para a segurança?
• Revisão da utilização de dados: consegue identificar o acesso a dados sensíveis armazenados e ações de alto risco, como exportações, quando a sua política o exige?

Eventos que vale a pena verificar antes da adoção

Utilize a documentação oficial da aplicação para identificar famílias de eventos e, depois, mapeie-as para os seus casos de utilização. Não assuma que um evento descrito na documentação está ativado, é armazenado ou está disponível em todos os modos de implementação. Por exemplo, a documentação do [Keycloak](https://www.keycloak.org/docs/latest/server_admin/) refere que os eventos de utilizador não são armazenados nem apresentados por predefinição até que um administrador ative o respetivo armazenamento.

A atividade de autenticação e autorização é um ponto de partida: inícios de sessão bem-sucedidos, falhados, recuperação de conta quando relevante, eventos relacionados com sessões quando documentados, alterações de funções ou grupos e alterações de privilégios. Para atividade administrativa, inclua alterações feitas na interface de gestão e, quando for relevante, nas APIs de gestão. O Keycloak documenta a auditoria de ações de administrador na Admin Console e de invocações REST utilizadas para essas ações.

A cobertura de dados empresariais merece uma análise separada. Procure criação, atualização, eliminação, acesso ou utilização de dados sensíveis armazenados quando necessário, operações em massa, exportações, importações, alterações de partilha e alterações de credenciais ou conectores de integração. Uma aplicação pode disponibilizar uma excelente auditoria administrativa, oferecendo ao mesmo tempo visibilidade limitada sobre ações em registos empresariais individuais.

Um evento útil deve ter contexto suficiente para poder ser interpretado mais tarde. O esquema publicado de [eventos de auditoria do GitLab](https://docs.gitlab.com/user/compliance/audit_event_schema/) ilustra uma base de comparação sólida: identidade do autor, carimbo temporal do evento, identificação e tipo da entidade, tipo de evento, ID único do evento e detalhes adicionais. A aplicação escolhida não tem de usar o mesmo esquema, mas os seus registos devem responder a perguntas equivalentes para os seus requisitos.

• Atividade de autenticação bem-sucedida e falhada
• Alterações de utilizadores, grupos, funções e permissões
• Criação, atualização e eliminação de registos sensíveis ou regulamentados, quando necessário
• Acesso ou utilização de registos quando a política ou o risco o exigir
• Exportações, transferências, importações, alterações em massa e ações de partilha
• Alterações administrativas de configuração
• Alterações de integrações, tokens de API, webhooks ou conectores
• Ações administrativas realizadas através de interfaces de utilizador e APIs, quando aplicável

Verifique a documentação, a configuração e o percurso da evidência

Uma página de funcionalidades do fornecedor não é suficiente. Leia a documentação oficial de administração para o modelo de implementação específico que está a considerar e, depois, verifique as predefinições de configuração e os registos resultantes num teste. Trate qualquer incógnita como uma lacuna até que a documentação do fornecedor ou o seu teste a resolva.

Primeiro, determine a cobertura de eventos. Que ações criam eventos? As ações bem-sucedidas e malsucedidas são ambas registadas quando necessário? As ações de utilizadores comuns, ações administrativas e ações de API são abrangidas separadamente? É possível ativar ou desativar categorias de eventos?

Em seguida, inspecione a qualidade dos registos. Determine se o registo identifica um interveniente de forma consistente, regista data e hora, com fuso horário ou outra referência temporal inequívoca, identifica a entidade afetada, captura o tipo de ação e o resultado e inclui um identificador único ou informação de correlação. Determine também como o sistema representa contas de serviço, automação e atividade anónima. Um evento atribuído apenas a «API» ou «sistema» pode ser insuficiente para efeitos de responsabilização, a menos que possa ser correlacionado com uma fonte de identidade mais forte.

Depois, verifique o comportamento de recuperação e ciclo de vida. Analise os campos pesquisáveis, filtros, paginação, formatos de exportação, acesso por API e qualquer capacidade de transmissão de eventos. O [GitLab documenta](https://docs.gitlab.com/user/compliance/audit_events/) a filtragem por interveniente e intervalo de datas, mas refere que a pesquisa de texto nos detalhes dos eventos de auditoria não é suportada na sua interface; recomenda transmissão externa para pesquisa e análise abrangentes. É por isso que «visível na interface» e «pesquisa pronta para investigação» devem ser linhas separadas na folha de avaliação.

Por fim, avalie a proteção. O [NIST AU-9](https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1-derived-OSCAL.pdf) trata a proteção das informações de auditoria e das ferramentas de logging de auditoria contra acesso, modificação e eliminação não autorizados como um objetivo distinto. Um log que um administrador comum possa alterar ou limpar silenciosamente não se torna imutável apenas por existir.

• Cobertura: que ações exigidas são registadas e quais não são?
• Interveniente: o utilizador humano, a conta de serviço ou o administrador é identificado de forma fiável?
• Tempo: existe uma hora precisa do evento e os registos podem ser correlacionados entre sistemas?
• Objeto: o registo identifica o registo, conta, definição ou entidade afetada?
• Resultado e detalhes: regista sucesso, falha e contexto suficiente para compreender a ação?
• Pesquisa: os revisores conseguem filtrar por interveniente, objeto, tipo de evento e intervalo temporal? O texto dos detalhes é pesquisável, se necessário?
• Exportação: os registos podem ser exportados ou recuperados através de uma interface suportada, num formato útil?
• Retenção: o armazenamento está ativado, durante quanto tempo os eventos são retidos e quem os pode alterar ou limpar? A configuração de retenção e os controlos de limpeza devem ser testados quando existirem, como ilustra a documentação do Keycloak. [Ver documentação](https://www.keycloak.org/docs/latest/server_admin/).","Proteção: quem pode ler, modificar ou eliminar registos e que salvaguardas independentes existem?"

Fontes primárias

Esta checklist baseia-se em documentação primária de fornecedores e numa orientação do NIST. Confirme sempre o comportamento da versão e do modo de implementação que está a avaliar.

[Docker — Configure logging drivers](https://docs.docker.com/engine/logging/configure/)

[Traefik — Logs and Access Logs](https://doc.traefik.io/traefik/observe/logs-and-access-logs/)

[PostgreSQL — Write-Ahead Logging (WAL)](https://www.postgresql.org/docs/15/wal-intro.html) e [Logical Decoding Concepts](https://www.postgresql.org/docs/17/logicaldecoding-explanation.html)

[Keycloak — Server Administration Guide: Configuring auditing to track events](https://www.keycloak.org/docs/latest/server_admin/)

• [GitLab — Audit events](https://docs.gitlab.com/user/compliance/audit_events/)
• [GitLab — Audit event schema and examples](https://docs.gitlab.com/user/compliance/audit_event_schema/)
• [GitLab — Audit event streaming for top-level groups](https://docs.gitlab.com/user/compliance/audit_event_streaming/)
• [NIST — Cybersecurity Event Awareness](https://pages.nist.gov/FederalProfile-8259A/technical/event/)
• [NIST SP 800-53 Rev. 5.1 — AU-9, Protection of Audit Information](https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1-derived-OSCAL.pdf)