审计日志记录操作人时间

本文目录导读：

1. 核心原则：服务器端权威
2. 常见企业级实现方案
3. 常见“坑”与最佳实践
4. 总结表

针对“审计日志记录操作人时间”的需求，这通常指的是在数据系统中记录“谁在什么时间做了什么操作”。

为了确保审计日志的准确性（防篡改）和合规性，在设计和实现时，不能简单地依赖客户端时间或前端传入的操作人信息,以下是核心的设计原则和最佳实践：

核心原则：服务器端权威

• 操作人（Who）： 必须从认证系统（如 Session、Token、JWT）中解析，绝对不能从前端请求参数（如 JSON Body 或 URL 参数）中读取，否则，恶意用户或 BUG 可以伪造操作人。
• 时间（When）： 必须使用数据库服务器或应用服务器的时间,绝对不能依赖客户端提交的时间戳。
• 操作（What）： 记录具体的请求、方法、参数（注意脱敏）、资源 ID 和结果。

常见企业级实现方案

根据你的技术栈,以下是主流的实现方式：

数据库层面（适用于单体或传统应用，最常见）

利用数据库的触发器或内置机制,自动在业务表上记录日志。

• 实现： 在每个需要审计的表上创建 created_at， updated_at 字段，并额外增加 created_by， updated_by 字段。
• 记录时间： 使用数据库函数，如 NOW() 或 GETDATE()。
• 记录操作人： 应用层在执行业务 SQL 前，通过 SET @current_user = 'admin' 该类的方式将当前用户传入数据库会话（Session），触发器或 ON UPDATE 机制读取该变量。
• 优点： 强一致性,无法绕过应用直接修改数据库。
• 缺点： 难以记录“查看”操作，修改 schema 较复杂。

-- 示例：使用 PostgreSQL 的触发器或 MySQL 的触发器
CREATE TRIGGER audit_user_changes
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
    -- 记录当前用户（需要从会话变量获取）
    SET NEW.updated_by = @current_user;
    SET NEW.updated_at = NOW();
    -- 同时写入专门的审计日志表（可选）
    INSERT INTO audit_logs(table_name, row_id, operation, old_value, new_value, operator, time)
    VALUES('users', OLD.id, 'UPDATE', OLD.*, NEW.*, @current_user, NOW());
END;

AOP / 注解 / Middleware 层面（适用于 Spring, .NET, Nest.js, Django, Rails）

通过切面编程或中间件,拦截所有请求或指定方法调用。

• 实现：
  • Spring:
    • @Around 注解 + SecurityContextHolder.getContext().getAuthentication() 获取用户名。
    • System.currentTimeMillis() 记录开始和结束时间。
  • Python:
    • Django 的 Signal + request.user。
    • Flask 的 @app.after_request 装饰器 + flask_login.current_user。
  • Node.js:
    • Express 中间件（Middleware）：在 req 对象中读取 req.user，记录 new Date().toISOString()。
• 优点： 统一管理，与业务代码解耦,可随意开启关闭。
• 缺点： 可能会影响性能（高频使用慎用）,难以追踪复杂的内部方法调用。

// Node.js (Express 中间件示例)
const auditLogger = (req, res, next) => {
    const originalEnd = res.end;
    res.end = function (...args) {
        const auditData = {
            userId: req.user?.id || 'anonymous', // 从 token/session 解析
            username: req.user?.username,
            ip: req.ip,
            method: req.method,
            url: req.originalUrl,
            statusCode: res.statusCode,
            timestamp: new Date().toISOString(), // 服务器时间
            requestBody: JSON.stringify(req.body).substring(0, 500), // 截断敏感数据
        };
        // 异步写入审计日志（如写入文件、DB、消息队列）
        writeAuditLog(auditData).catch(console.error);
        originalEnd.apply(res, args);
    };
    next();
};

事件溯源 / CDC（Change Data Capture） 架构（适用于微服务，数据量大）

利用专门的中间件或工具（如 Debezium, Apache Kafka）捕获数据库变更。

• 实现：
  • 应用正常写业务库。
  • 后台工具监听数据库的 Binlog (MySQL) 或 WAL (PostgreSQL)。
  • 捕获变更事件，并附加上下文信息（通过应用发来的 Header 或 Metadata）。
• 优点： 对业务代码零侵入，性能极高,完全异步。
• 缺点： 架构复杂，引入了 Kafka 等组件,运维成本高。

特定数据库功能（如 PostgreSQL 审计扩展）

• pgAudit: 专业的 PostgreSQL 审计日志扩展，可以配置记录 DDL、DML、SELECT 等,时间由数据库保证。

常见“坑”与最佳实践

1. 时间时区问题（极重要）：

   • 做法： 所有审计日志的“时间”必须统一记录为 UTC，或者使用 BIGINT 类型的 Unix 时间戳（毫秒）。
   • 原因： 不同服务器的系统时间、时区设置可能不同，统一存储 UTC 和时区偏移量,在前端展示时再转换为用户本地时间。
   • 避免： 存储 '2023-10-05 14:30:00' 这种无时区信息的字符串。

2. 操作人来源（绝不能信前端）：

   • 错误做法： request.body.operator。
   • 正确做法： request.user.id 或 SecurityContextHolder.getContext().getAuthentication().getName()。

3. 数据脱敏（安全）：

   • 记录参数时，需要对密码、Token、身份证号、信用卡号进行脱敏（如 ****1234）或彻底排除,否则审计日志本身会成为巨大安全隐患。

4. 异步与性能：

   • 审计日志不应阻塞主业务流程，如果统计日志表很大，考虑异步写（丢进消息队列，如 RabbitMQ, Kafka）或分表（按月份/ID hash 分表）。

5. 时间粒度：

   • 如果需要精确到毫秒级（用于分析操作顺序），建议增加 start_time 和 end_time，仅记录一个 created_at 可能不够用。

总结表

如果你的团队正在开发新项目，推荐方案：

• 简单项目： 使用数据库的 updated_by/created_at + 应用层的 AOP/Middleware。
• 复杂项目/微服务： 使用 异步消息队列 + CDC 工具,实现高吞吐的审计日志。