187 lines
13 KiB
Markdown
187 lines
13 KiB
Markdown
1|# 子系统 09 — 审计与通知中心 (`audit`) v1.0
|
||
2|
|
||
3|## 子系统概述
|
||
4|
|
||
5|| 维度 | 说明 |
|
||
6|| --- | --- |
|
||
7|| 代号 | `audit` |
|
||
8|| 核心职责 | 状态变更审计、敏感字段访问日志、多类型通知/告警 |
|
||
9|| 数据所有权 | `interaction_audit_logs`, `notification_records`, `manual_review_tasks` |
|
||
10|| 启动依赖 | 无硬依赖，完全独立 |
|
||
11|| 外部系统依赖 | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） |
|
||
12|
|
||
13|---
|
||
14|
|
||
15|## 1. 模块划分
|
||
16|
|
||
17|```
|
||
18|┌─────────────────────────────────────────────────────────────┐
|
||
19|│ audit 子系统 │
|
||
20|│ │
|
||
21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||
22|│ │ M1: 状态变更 │ │ M2: 敏感操作 │ │ M3: 通知分发 │ │
|
||
23|│ │ 审计 │ │ 审计 │ │ 引擎 │ │
|
||
24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
|
||
25|│ │ │ │ │
|
||
26|│ ▼ ▼ ▼ │
|
||
27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||
28|│ │ M4: 通知模板 │ │ M5: 人工复核 │ │ M6: 对外 API │ │
|
||
29|│ │ 管理 │ │ 任务 │ │ Gateway │ │
|
||
30|│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||
31|│ │
|
||
32|└─────────────────────────────────────────────────────────────┘
|
||
33|```
|
||
34|
|
||
35|| # | 模块 | 职责 |
|
||
36|| --- | --- | --- |
|
||
37|| M1 | 状态变更审计 | 记录所有业务对象的状态流转（对象ID/旧状态/新状态/操作人/时间/原因） |
|
||
38|| M2 | 敏感操作审计 | 敏感字段访问记录、数据导出记录、人工复核操作留痕 |
|
||
39|| M3 | 通知分发引擎 | 按通知类型路由到不同通道（系统内通知/IM/EDM/APP Push）；通知优先级管理 |
|
||
40|| M4 | 通知模板管理 | 各类通知的模板（额度预警/Listing 预警/超时提醒/审批通知/风险告警） |
|
||
41|| M5 | 人工复核任务 | 管理需要人工复核的任务（弱关联风险/额度预警池/异常评价），供风险/运营人员消费 |
|
||
42|| M6 | 对外 API Gateway | 接收所有子系统上报的审计事件和通知请求 |
|
||
43|
|
||
44|---
|
||
45|
|
||
46|## 2. 各模块内外说明
|
||
47|
|
||
48|### 2.1 M1: 状态变更审计
|
||
49|
|
||
50|| 维度 | 说明 |
|
||
51|| --- | --- |
|
||
52|| **对内** | 接收所有子系统的状态变更事件（fire-and-forget）；记录：对象类型（plan/ticket/risk_case/review…）、对象ID、旧状态、新状态、操作人、操作时间、操作原因；审计日志不可篡改（append-only）；支持按对象ID/操作人/时间范围检索 |
|
||
53|| **对外接口** | `POST /api/audit/event` — 上报审计事件 |
|
||
54|| **数据写入** | `interaction_audit_logs` |
|
||
55|| **典型事件** | 计划状态变更（草稿→审批→执行→完成）、工单分配/关闭、风险事件确认/排除、额度手动调整、审批决策 |
|
||
56|
|
||
57|### 2.2 M2: 敏感操作审计
|
||
58|
|
||
59|| 维度 | 说明 |
|
||
60|| --- | --- |
|
||
61|| **对内** | 三类敏感操作：①敏感字段访问（用户上下文卡中的涉密字段→记录访问人/时间/字段/上下文）②数据导出操作（导出人/时间/范围/原因/是否含敏感字段）③人工复核操作（决策人/决策内容/决策依据/时间） |
|
||
62|| **对外接口** | `POST /api/audit/sensitive-access` — 上报敏感访问 |
|
||
63|| **数据写入** | `interaction_audit_logs`（带 sensitivity 标记） |
|
||
64|
|
||
65|### 2.3 M3: 通知分发引擎
|
||
66|
|
||
67|| 维度 | 说明 |
|
||
68|| --- | --- |
|
||
69|| **对内** | 接收通知请求→按通知类型路由：①系统内通知（Web 前端轮询/WebSocket）②IM 通知（通过 outreach）③EDM 通知 ④APP Push；优先级管理（紧急 Listing 预警 > 超时提醒 > 额度预警）；通知去重（同一用户同一类型短时间内不重复发） |
|
||
70|| **对外接口** | `POST /api/notifications/send` — 发送通知 |
|
||
71|| **依赖** | outreach（IM/EDM/APP Push 通道） |
|
||
72|
|
||
73|### 2.4 M4: 通知模板管理
|
||
74|
|
||
75|| 维度 | 说明 |
|
||
76|| --- | --- |
|
||
77|| **对内** | 通知类型与模板：①额度预警（「真实人 X 的测评额度仅剩 1 次」）②紧急 Listing 预警（「ASIN X 评分接近 4.2，建议紧急催评」）③客服超时提醒（「工单 #123 已超时 N 小时未回复」）④审批通知（「计划 X 等待您的审批」）⑤规则风控提醒（「ASIN X 频控过高」）⑥风险告警（「用户 X 命中强关联风险」） |
|
||
78|| **对外接口** | 管理 API |
|
||
79|| **数据写入** | `notification_records` |
|
||
80|| **待确认** | 模板是否需要多语言（中文/英文/菲律宾语）？模板管理界面在 audit 内部还是独立？ |
|
||
81|
|
||
82|### 2.5 M5: 人工复核任务
|
||
83|
|
||
84|| 维度 | 说明 |
|
||
85|| --- | --- |
|
||
86|| **对内** | 统一管理需人工复核的任务：弱关联风险复核、额度预警池复核、异常评价复核、诈骗疑似复核；任务分配/认领/完成/超时 |
|
||
87|| **对外接口** | `POST /api/audit/review-task` — 创建复核任务；`GET /api/audit/review-tasks?assignee=` — 查询待复核任务 |
|
||
88|| **数据写入** | `manual_review_tasks` |
|
||
89|
|
||
90|---
|
||
91|
|
||
92|## 3. 对外 API 契约（草案）
|
||
93|
|
||
94|| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||
95|| --- | --- | --- | --- | --- |
|
||
96|| 上报审计事件 | `POST /api/audit/event` | `{object_type, object_id, old_status, new_status, operator, reason}` | `{event_id}` | 所有子系统（状态变更时调用） |
|
||
97|| 上报敏感访问 | `POST /api/audit/sensitive-access` | `{operator, field, context, accessed_at}` | `{event_id}` | identity（上下文卡访问） |
|
||
98|| 发送通知 | `POST /api/notifications/send` | `{recipient, type, template_id, params}` | `{notification_id}` | 所有子系统 |
|
||
99|| 创建复核任务 | `POST /api/audit/review-task` | `{task_type, target_id, priority, description}` | `{task_id}` | risk, quota |
|
||
100|
|
||
101|---
|
||
102|
|
||
103|## 4. 数据对象
|
||
104|
|
||
105|| 对象 | 核心字段 | 说明 |
|
||
106|| --- | --- | --- |
|
||
107|| `interaction_audit_logs` | log_id, object_type, object_id, old_status, new_status, operator, operation, reason, sensitivity_level, logged_at | 审计日志（append-only） |
|
||
108|| `notification_records` | notification_id, recipient, type, template_id, channel, sent_at, status(SENT/DELIVERED/READ/FAILED) | 通知记录 |
|
||
109|| `manual_review_tasks` | task_id, task_type, target_id, status(PENDING/ASSIGNED/IN_REVIEW/RESOLVED/TIMEOUT), assignee, priority, created_at, resolved_at | 人工复核任务 |
|
||
110|
|
||
111|---
|
||
112|
|
||
113|## 5. 业务澄清问题清单 — audit
|
||
114|
|
||
115|### 5.1 审计范围与保留（4 项）
|
||
116|
|
||
117|| # | 问题 | 优先级 |
|
||
118|| --- | --- | --- |
|
||
119|| A-01 | 审计日志的保留策略？（保留多久？1 年？永久？到期后归档还是删除？） | **P0** |
|
||
120|| A-02 | 审计日志的存储量预估？（日产生多少条？是否需要分库分表/冷热分离？） | P1 |
|
||
121|| A-03 | 审计日志是否需要支持导出/报表？（合规审计时需要导出给外部审计？） | P1 |
|
||
122|| A-04 | 「敏感字段」的定义范围？（订单号、收款信息、设备号——还有哪些？谁来确定完整清单？） | **P0** |
|
||
123|
|
||
124|### 5.2 通知策略（4 项）
|
||
125|
|
||
126|| # | 问题 | 优先级 |
|
||
127|| --- | --- | --- |
|
||
128|| A-05 | 通知发送通道的优先级？（紧急告警用什么通道？IM？系统内通知？邮件？） | P1 |
|
||
129|| A-06 | 通知去重规则？（同一用户同一类型通知 N 分钟内不重复发？） | P1 |
|
||
130|| A-07 | 通知是否需要用户偏好设置？（用户可以选择不接收某类通知？公告类通知是否强制发送？） | P2 |
|
||
131|| A-08 | 通知模板是否需要多语言支持？（中文/英文/菲律宾语？）模板由谁来维护？ | P2 |
|
||
132|
|
||
133|### 5.3 人工复核任务（2 项）
|
||
134|
|
||
135|| # | 问题 | 优先级 |
|
||
136|| --- | --- | --- |
|
||
137|| A-09 | 人工复核任务的时效要求？（不同任务类型 SLA？弱关联风险 N 小时内复核？额度预警池 N 分钟内复核？） | P1 |
|
||
138|| A-10 | 复核任务超时后的升级机制？（自动分配给上级？通知主管？） | P2 |
|
||
139|
|
||
140|### 5.4 与其他子系统的协作（2 项）
|
||
141|
|
||
142|| # | 问题 | 优先级 |
|
||
143|| --- | --- | --- |
|
||
144|| A-11 | 通知通道是否完全复用 outreach？（IM/EDM/APP Push）还是 audit 独立对接通知通道？（如果 outreach 不可用，audit 仍需要能发告警） | P1 |
|
||
145|| A-12 | 审计事件是同步上报还是异步？（同步→影响业务链路性能 / 异步→可能丢失事件） | P1 |
|
||
146|
|
||
### 5.5 合规与认证（3 项）
|
||
|
||
| # | 问题 | 优先级 |
|
||
| --- | --- | --- |
|
||
| A-13 | 系统是否需要通过合规认证？（SOC2 Type II / ISO 27001？）认证对审计日志的完整性、不可篡改性、保留期限有何具体要求？ | P1 |
|
||
| A-14 | 数据导出请求（DSR）——用户或监管机构要求导出所有个人数据时，系统如何响应？（需要哪些子系统的数据？导出格式？响应时限？） | P1 |
|
||
| A-15 | 审计日志是否需要对第三方审计开放？（外部审计师需要查看审计日志时——权限控制和数据脱敏？） | P2 |
|
||
|
||
### 5.6 日志保留与归档（3 项）
|
||
|
||
| # | 问题 | 优先级 |
|
||
| --- | --- | --- |
|
||
| A-16 | 审计日志的分级保留策略？（状态变更日志保留 X 年 / 敏感访问日志保留 Y 年 / 通知记录保留 Z 月？） | P1 |
|
||
| A-17 | 日志归档方案？（超过保留期的日志是删除还是归档到冷存储？归档后是否仍可检索？） | P2 |
|
||
| A-18 | 日志存储量预估？（日产生日志条数 × 保留天数 = 需要的存储空间——是否需要分库分表/分区？） | P2 |
|
||
|
||
### 5.7 敏感数据脱敏（3 项）
|
||
|
||
| # | 问题 | 优先级 |
|
||
| --- | --- | --- |
|
||
| A-19 | 审计日志中是否允许记录敏感字段的明文？（例如「谁在何时查看了用户 X 的收款信息」——收款信息是否脱敏存储？） | P1 |
|
||
| A-20 | 日志查询权限——谁可以查审计日志？（管理员？审计员？）是否需要限制只能查自己相关的日志？ | P1 |
|
||
| A-21 | 生产环境的日志是否可以包含 PII（个人可识别信息）？（邮箱/电话/地址——是否在写入日志时自动脱敏？） | P1 |
|
||
|
||
### 5.8 通知可靠性（3 项）
|
||
|
||
| # | 问题 | 优先级 |
|
||
| --- | --- | --- |
|
||
| A-22 | 通知的可靠性保证——紧急告警（如 Listing 评分暴跌）是否需要确保送达？（有送达确认机制吗？发送失败后重试？） | P1 |
|
||
| A-23 | 通知通道的优先级切换——IM 通知失败后是否自动切换到 EDM 或系统通知？ | P2 |
|
||
| A-24 | 通知的聚合/摘要——同一个用户短时间收到多条同类通知是否合并？（「您有 3 个待审批计划」而不是 3 条独立通知） | P2 |
|
||
|
||
### 5.9 实施层面（4 项）
|
||
|
||
| # | 问题 | 优先级 |
|
||
| --- | --- | --- |
|
||
| A-25 | 审计事件是同步写入还是异步写入？（同步→影响业务链路 RT / 异步→可能丢失事件——如何取舍？） | P1 |
|
||
| A-26 | 审计日志的查询性能——是否需要支持全文搜索？（按操作人/对象ID/时间范围检索是否需要在秒级返回？） | P2 |
|
||
| A-27 | 通知通道的可靠性——如果 audit 子系统本身宕机，其他子系统的通知请求是否丢失？（是否需要消息队列做缓冲？） | P1 |
|
||
| A-28 | audit 子系统是否需要独立的数据库？（与其他子系统共享数据库会在高峰期互相影响——是否独立部署数据库？） | P2 |
|