合规与审计：证据是执行的副产品
SchemaBridge Team · 2026-01-24 · Compliance, SOC2, GDPR, Security
借助有记录的执行历史，让 SOC2 证据收集和 GDPR 删除更轻松，同时准确说明它不保证什么。
合规税：审计为何拖慢你的脚步
如果你经历过 SOC2、ISO27001 或 HIPAA 审计，就会明白其中的痛苦。审计师问道：“请出示证据，证明每一个用户离职注销请求都在 24 小时内得到处理。”
在传统系统中，这会引发一场手忙脚乱的寻宝游戏。
- 你翻查邮件日志。
- 你在 Splunk 里 grep 某条 “Deleted User” 消息。
- 你给 JIRA 工单截图。
- 你在电子表格里交叉比对时间戳。
这种手工收集证据的工作可能耗掉数周的工程时间。这就是合规税。它把你最优秀的人才从功能开发中拉走。更糟的是，这些证据往往只是间接证据。你能证明某个脚本运行过，但你能证明它究竟触碰了哪些数据吗？
审计跟踪：证据是执行的副产品
在 SchemaBridge，我们认为证据应当是执行的副产品，而不是一项单独的工作。引擎在运行时写入审计跟踪：执行的启动、重放和运维人员解决，工作流、顶点和边的变更，部署，配置与保留期变更，权限与角色变更，以及审批决定。
审计跟踪能提供什么
- 有记录的状态转换：运行状态本身保存在 PostgreSQL 中，并随运行推进而更新；与此同时，每一次状态转换都会追加到执行追踪中，因此事后可以回答“我们是怎么走到这一步的”。审计跟踪记录的是运行的启动以及运维人员对它的操作，而不是每一次转换。
- 可追溯性：对于任何一次运行，你都可以查看每个步骤记录下来的输入和输出（在你的保留期内）。请注意区别：SchemaBridge 中的 Replay 会以一次新的执行重新运行工作流，包括其副作用；它不是只读的历史回放。
- 可查询的历史：审计跟踪可以通过 API 按工作区和按工作流查询，并存放在独立于业务数据库的专用列式存储中（位于内部审计服务之后的 ClickHouse）。
它不是什么
在保证范围上，请对审计师准确表述。审计跟踪在应用层面是仅追加的，但不具备防篡改可验证性：没有哈希链或签名，并且审计写入是尽力而为（best-effort）的，因此写入失败不会表现为可检测的缺口。如果你需要 WORM 级别的证据，请将审计跟踪导出到由你自己控制的一次写入存储中。
GDPR 与“被遗忘权”
在任何保存历史的系统中，最棘手的挑战之一就是“被遗忘权”（GDPR 第 17 条）。如果你保存了历史，又该如何删除用户的 PII（个人身份信息）？
删除与保留
SchemaBridge 通过删除路径和保留期来应对这一问题。
1. 删除：删除一个工作区会执行一条专用的删除路径，其背后是一个义务台账：在不可逆删除之前记录，并在删除之后验证；另有一条独立路径用于删除单个用户的数据。
2. 自动清理：保留期按工作区设置（或继承自你的套餐）。过期的执行记录、追踪和载荷会被自动删除。
3. 凭据掩码：形似凭据的字段（API 密钥、机密、令牌）在运行日志中会被掩码为 。PII 掩码不是*自动的，因此最好的防御是不要让个人数据流经不需要它的步骤。
自动化 SOC2 证据收集
你可以使用 SchemaBridge 工作流来自动化审计本身的一部分。
“审计机器人”
与其手工收集截图，不如创建一个专门的“证据收集”工作流，按 cron 计划在每周一运行。
1. 扫描：查询 GitHub API，列出上周合并的所有 PR。
2. 验证：检查每个 PR 是否都有 code owner 给出的 “Approved” 评审。
3. 快照：生成一份合规状态的 JSON 快照。
4. 归档：将快照写入审计师可以读取的存储（通过你控制的 HTTP 端点——最好是一次写入存储）。
审计师到来时，你只需把他们引向归档，而不是一堆截图，审计准备时间也会相应缩短。
{
"week": "2026-W03",
"mergedPullRequests": 42,
"withCodeOwnerApproval": 42,
"exceptions": []
}示例场景：受监管环境中的患者入院登记
设想一家虚构的 HealthTech 初创公司，需要自动化处理患者入院登记表。
挑战
他们需要证明：
1. 只有获得授权的员工才能修改或运行入院登记工作流。
2. 对工作流的每一次变更和每一次运行结果都有记录。
3. 数据从未暴露给第三方日志工具（Splunk/Datadog）。
做法
1. 基于角色的访问：工作区角色（admin、writer、reader）和权限范围限制了谁可以编辑、部署和运行该工作流，并且每一次角色变更都会进入审计跟踪。
2. 有记录的运行：每次入院登记运行的启动以及运维人员的解决操作都在审计跟踪中，完整的状态历史保存在运行历史里，每个步骤的载荷可以在平台内查看，而不是打印到 stdout。
3. 仍需他们自行承担的缺口：SchemaBridge 不记录谁查看过某个载荷，没有 HIPAA 专用角色，也未持有 HIPAA 认证。按查看记录的访问日志以及监管方面的文书工作，仍然是他们自己的责任。
可能的收益
这样的配置会让审计中变更管理和运行历史相关的部分轻松得多，同时也坦诚说明了平台未覆盖的部分。
对比：传统日志 vs. SchemaBridge 审计跟踪
| 特性 | Syslog / Splunk | 数据库审计表 | SchemaBridge 审计跟踪 |
| :--- | :--- | :--- | :--- |
| 不可变性 | 低（可被删除） | 中（DBA 可修改） | 中到高（应用层仅追加；由运营方控制的存储） |
| 上下文 | 单行 | 行变更 | 工作流与执行上下文 |
| 凭据处理 | 手工掩码 | 列加密 | 运行日志中掩码凭据字段 |
| 保留 | 有限（成本高） | 有限（性能） | 按工作区 / 按套餐设置保留期 |
合规架构专家检查清单
1. 不要记录 PII：注意你打印到 stdout 的内容，以及在步骤之间传递的内容。不要把个人数据放进不需要它的载荷。
2. 自动化证据：手工去做，就一定会出错。把审计脚本化。
3. 职责分离：编写工作流的人不应该是持有管理员密钥的人。
4. 测试删除：定期运行“模拟 GDPR 请求”，验证你的删除与保留路径是否真正有效。
5. 了解平台的局限：向每一家供应商（包括我们）问清楚究竟记录了什么、保留多久，以及是否具备防篡改可验证性。把答案写进你的控制描述中。
结论：信任即 API
合规关乎的不是文书工作，而是信任。以有记录、可查询的历史为基础构建系统，并准确说明这段历史保证什么、不保证什么，你就能从“相信我，我是个好工程师”转变为“证据在这里”。
本文属于 Building the Bridge 系列。另请参阅：集成的未来。