用户隐私日志：最小化与审计数据访问记录

2025-01-01 API调用 getUserInfo 返回 {phone:"13800138000",...}

✅ 最小化记录（只保留操作上下文和资源引用）：

2025-01-01T10:00:00Z AUDIT actor=user_123 action=PHONE_LOOKUP resource=user_456 result=success trace_id=abc-123

常用审计字段建议：
- `timestamp`：精确到毫秒的记录时间
- `actor_type`：操作主体类型（user/admin/system）
- `actor_id`：操作者的唯一标识（非真实姓名）
- `action`：标准化动作（如 READ、WRITE、DELETE、EXPORT）
- `resource_type`：被访问的数据类型（如 USER_PROFILE、PAYMENT_INFO）
- `resource_id`：受影响数据项的唯一标识
- `origin`：请求来源（IP、内部服务名）
- `session_id / trace_id`：用于串联整个调用链
- `reason`：若是人工触发的敏感操作，需记录审批工单或业务原因代码

### 2.3 实时阻断与告警
当检测到日志中**将输出敏感原始值**时，应在代码层或日志管道层直接阻断，用占位符（如 `[REDACTED]`）替换，并触发告警。这能杜绝“不小心用console.log打出了用户密码”的事故。

## 3. 构建可审计的数据访问记录

### 3.1 基于拦截器的统一审计层
不要在每个业务方法中手工嵌入日志代码。推荐在数据访问层构建统一的拦截器（AOP思想）：

- **数据库层**：对ORM的数据查询、更新、删除操作进行拦截；
- **API网关层**：对所有外部请求生成验签和访问记录；
- **内部服务间调用**：利用中间件或RPC过滤器记录跨服务数据流转。

无论你使用何种技术栈，模式都是：**请求进入 → 提取上下文 → 判断资源类型 → 过滤敏感字段 → 写入审计事件**。

### 3.2 敏感操作的强制留痕
对于后台管理员查看用户私密数据、客服代操作、数据导出等高风险行为，必须实现**强制审计且日志不可被操作者自身删除或修改**。可以考虑以下设计：

- 将审计日志输出到**仅追加（append-only）**的存储，如经过权限隔离的日志文件、专用的数据库表；
- 对日志行计算签名或哈希链，实现防篡改校验；
- 敏感操作与审批工作流打通，日志中附带`approval_id`。

### 3.3 日志本身的访问控制与加密
审计日志也是敏感数据。措施包括：

- 对存储中的日志文件进行**透明加密**（如服务器端加密）；
- 使用基于角色的最小权限控制日志读取接口，且读取动作本身再次生成审计事件（实现“审计的审计”）；
- 定期自动归档到不可变存储（如对象存储的合规模式）。

## 4. 实战演练：设计一个最小化审计日志格式

假设有一个客服系统，需要记录客服代表查看用户联系方式的场景。设计日志格式如下：

```json
{
  "eventTime": "2025-03-15T08:12:11.123Z",
  "decision": "ALLOW",
  "subject": {
    "type": "AGENT",
    "id": "agent_9925",
    "sessionId": "sess_abcd"
  },
  "action": "PRIVATE_DATA_VIEW",
  "resource": {
    "type": "USER_CONTACT",
    "ownerId": "user_12345",
    "fields": ["email", "phone"]
  },
  "context": {
    "ticketId": "TKT-9001",
    "reasonCode": "customer_verify"
  },
  "traceId": "trace-x9f2"
}