结论先行：审计日志设计围绕三件事：记什么（4W1H 字段）、存多久（3 级留存策略）、怎么防篡改（权限隔离/专用存储/哈希校验）。等保 2.0 通用要求对安全审计的核心导向是"覆盖所有用户、记录重要安全事件、日志不可删除篡改"。通用基线：审计日志在线留存 90 天以上、归档 1 年起、核心业务 3 年。政企项目验收前，按本文字段清单自查一遍。

企业内控与等保（网络安全等级保护）测评中，审计日志是必查项：谁在什么时候动了什么数据，必须说得清楚。低代码平台降低了应用搭建门槛，也让"谁负责审计"变得模糊——本文帮平台管理员把这个责任落到字段和流程上。

记什么：4W1H 字段清单

一条合格的审计日志要能回答 5 个问题：

两个常被遗漏的字段：变更前后值（Before/After）——只记"修改了"而不记改了什么，审计等于没做；失败操作——登录失败、越权尝试往往比成功操作更有安全价值，必须同样记录。

等保 2.0 与内控的通用要求

从通用合规视角看，审计日志需要满足四个方向的要求（具体等级与条款以测评机构现场要求为准）：

1. 覆盖范围：审计覆盖到每个用户与重要安全事件，不能存在"日志盲区"账号。
2. 记录内容：日期时间、用户、事件类型、事件结果等关键信息完整。
3. 日志保护：日志受到保护，定期备份，避免被非授权删除、修改。
4. 留存时限：满足监管对留存周期的下限要求（行业内常见做法为不少于 6 个月）。

企业内控通常在此之上叠加业务要求：敏感数据访问留痕、财务相关操作双人复核留证、离职账号操作可追溯。设计时把监管要求与企业内控合并成一张事件清单，一次实现。医疗行业的患者数据访问留痕是这套要求的典型叠加场景，具体清单见医疗机构低代码方案。

防篡改：3 种方案对比

日志能被改，审计就失去公信力。三种防护方案按成本递增：

最低配也应做到第一种：数据库层面给应用账号回收日志表的写后权限，这一条多数团队当天就能落地。自托管部署（如使用猫拽低代码这类开源平台）在这里有天然优势——日志落在自己的数据库与文件系统里，留存周期、脱敏规则、外发策略都可以按企业内控自行定制，不受平台云端的默认策略限制。

留存周期与查询设计

3 级留存策略：在线库保留 90 天（支撑日常查询，控制单表体积）；超期归档到低成本存储保留 1 年起；涉及财务与核心业务的按内控要求保留 3 年。归档要有索引清单，能按时间与对象找回。金融行业的留存要求更严，账户、支付与交易链路的多重审计设计可参考金融应用开发的合规与审计要点。

查询侧设计三个能力：按"人+时间段"查（回答某人近期做过什么）；按"对象+操作类型"查（回答这条数据被谁动过）；按"异常特征"查（如导出类操作汇总报表）。审计日志的价值在查询效率——存了查不出来的日志，等于没存。

FAQs

Q1：所有操作都要记审计日志吗？

A：按风险分级记录即可：登录登出、数据增删改、导出下载、权限变更、配置修改五类必记；纯浏览类操作按数据敏感度选择性记录（敏感数据查看要记）。全量记录会让日志体积与查询成本失控。

Q2：审计日志会不会拖慢系统性能？

A：异步写入可基本消除影响：业务线程只把日志投递到内存队列，由独立线程批量落库。注意队列要有降级策略——队列满时宁可落本地文件也不丢弃，事后补录。

Q3：等保测评时审计部分主要查什么？

A：常见核查点：能否演示日志记录与查询、日志是否覆盖测试期间的关键操作、日志有无防删除措施、留存时长是否达标。提前按本文的 4W1H 字段与留存要求自查并留存演练记录，通过难度会显著降低。

延伸阅读

• 低代码应用安全加固清单：鉴权、防注入与审计——审计是安全加固清单的最后一环。
• 用户权限系统设计——权限体系与审计日志是内控的两大支柱。
• 低代码应用的数据备份与恢复策略——日志归档与数据备份可统一规划。