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

在竞赛中经常看到的"审计日志"应该记录些什么？

你好，我是大塚，在Liberogic担任CTO。

在参加网站和网络服务的竞标项目时，经常会在需求中看到"能够获取审计日志"和"日志需保存一定时期"这样的要求。

您可以根据需求选择服务、更改计划、或添加日志保存选项，但首先——"审计日志"到底指的是什么呢？

这次我想稍微理一下这些问题。

日志有很多种类

虽然统称为日志，但实际上有几种不同的类型。

它们都是日志，但记录的内容和使用目的各不相同。
例如，记录管理员更改用户权限、负责人发布内容等操作的日志，通常更接近所谓的审计日志。

故障调查和证据保留要分开进行

日志的目的可以分为两大类。

其中之一是在出现故障或问题时用于排查原因的日志。

"昨天提交的表单没有收到"、"特定时间段出现错误"等此类问询的调查工作中会用到这个工具。

另一种是事后确认操作事实的日志。

"谁改变了设置"、"内容是何时发布的"、"管理面板中进行了哪些操作"等这样的记录。

这两种用途的保存期限和使用方式都不同。

如果想要长期保存所有日志并保持可搜索状态，成本会非常高。相反，如果只保留最近的日志，审计或事件调查时所需的证据可能会丢失。

从一开始就分开考虑，才能设计出合理的方案。

将"需要审计日志"转化为具体要求

仅凭"审计日志"这个词还不足以确定具体的构成。

首先确认目的，然后将其转化为必要的记录内容和保存方法。

仅仅能够取日志还不够

如果云服务管理面板中显示了日志，就容易误认为"已经记录日志了"。

但是，不同服务保存的内容和期限会有所不同。

• 错误仍然存在，但不会保留到管理员操作为止。
• 可在管理面板中查看，但会在一定时期后消失
• 需要升级至更高级别方案才能进行外部转发
• 应用程序特有的操作需要由我们自己进行记录

「谁更改了产品信息」「处理了哪些申请数据」这样的业务记录，仅通过云服务有时是无法了解的。

如果招标要求中写有「审计日志」，至少应该确认以下几点。

需求整理检查表

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

如果在不清楚这些的情况下就决定使用某个服务或方案，就可能导致配置规模超出必要，或者反而缺少必需的日志记录。

现代Web服务中日志也是分布式的

传统的Web服务器可以采用相对简单明了的思路——在服务器内保存日志文件。

现在越来越多的Web服务是通过组合多个云服务构建的，包括CDN、主机托管、数据库、headless CMS、邮件发送等。

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

日志也分别保存在各个服务中，因此需要从整体视角思考「系统全体会保留什么」。

首先要确认目的

当被要求提供"审计日志"时，人们往往会觉得需要引入专门的服务。

当然，根据需求，可能需要外部日志管理服务或长期存储机制。但这并不意味着必须从一开始就准备庞大的架构。

首先，要明确保留什么、保留的目的是什么，以及保留多少。

在整理清楚后，更现实的做法是区分哪些部分可以用标准功能来实现，哪些部分需要额外构建解决方案。

下次，我们将粗略比较一下 AWS、Cloudflare、Vercel、Supabase、headless CMS 等我们经常处理的服务中会留下什么样的日志。

那就这样了。