审计日志（其一）：Web服务中审计日志的思路 ― 需求整理基础篇

投标时常见的“监查日志”，到底需要记录什么？

您好，我是Liberogic的CTO大冢。

参与网站或Web服务的投标时，需求中经常会写明“需要能够获取监查日志”“需要在一定期间内保存日志”。

我们会根据这些需求选择服务、变更套餐，或者添加日志保存选项。但“监查日志”究竟指的是什么呢？

本文将对这一点稍作梳理。

日志的种类多种多样

统称为日志，实际上也有好几种类型。

这些都属于日志，但记录的内容和使用目的各不相同。
例如，记录管理员变更用户权限、工作人员发布内容等操作的日志，通常被称为审计日志。

故障调查与证据保全应分开考虑

日志的用途大致可分为两类。

一类是在发生故障或问题时，用于查明原因的日志。

在调查“昨天提交的表单没有收到”“某个时段曾出现错误”等咨询时使用。

另一个是操作日志，用于事后确认实际发生过的操作。

这类记录包括“是谁更改了设置”“内容是何时发布的”“在管理界面中执行了哪些操作”等信息。

这两者的保存期限和使用方式各不相同。

如果要将所有日志长期保存在可检索的状态下，费用也会随之增加。反之，如果只保留最近的日志，审计或事件调查所需的证据就可能丢失。

从一开始就将两者分开考虑，设计会更加合理、可持续。

将“需要审计日志”落实为需求

仅凭“审计日志”这一说法，无法确定具体的架构。

我们首先确认目的，然后将其落实为所需的记录内容与保存方式。

“能够获取日志”还远远不够

如果云服务的管理界面上显示了日志，人们很容易认为“日志已经能够获取”。

但是，不同服务保存的内容和期限各不相同。

• 错误会被保留，但管理员的操作不会被保留
• 可以在管理界面中查看，但会在一定期限后被删除
• 若要转发至外部，需要更高级别的套餐
• 应用程序自身的操作，需要由我们自行记录

“谁更改了商品信息”“处理了哪些申请数据”之类的业务记录，仅靠云服务未必能够完整掌握。

如果招标需求中写明了“审计日志”，至少有以下几点需要提前确认。

需求梳理检查清单

✅️ 需要记录哪些操作
✅️ 是用户的操作还是管理员的操作
✅️ 目的是故障排查还是审计
✅️ 需要保存多长时间
✅️ 是否需要经常检索
✅️ 哪些人可以查看日志
✅️ 是否可能包含个人信息

如果在这些问题尚不明确的情况下就决定服务或方案，可能会导致架构规模超出实际需要，或者反过来，该保留的日志却没有留下。

现代Web服务中，日志也会分散存储

在传统的Web服务器上，只需将日志文件保存在服务器内，思路相对直观易懂。

如今，越来越多的Web服务会组合使用CDN、托管、数据库、Headless CMS、邮件发送等多种云服务来构建。

Liberogic 也会根据项目需要，除 AWS 之外，还使用 Cloudflare、Vercel、Supabase、microCMS、Kuroco 等服务。

由于日志也分别保存在各项服务中，因此需要从整个系统的角度来审视“最终究竟留下了哪些记录”。

首先确认目的

一听到“需要审计日志”，很多人会觉得必须引入某种特殊服务。

当然，根据需求不同，可能需要外部日志管理服务或长期保存机制。但也并不是从一开始就要准备庞大的架构。

首先需要明确：记录什么、为什么记录，以及要保留多长时间。

在理清这些之后，将可由标准功能满足的部分与需要额外搭建机制的部分区分开来，才是较为务实的做法。

下一篇，我们将简要比较 AWS、Cloudflare、Vercel、Supabase 以及 Headless CMS 等我们经常使用的服务会留下哪些日志。

那就先到这里。