24.5 证据、审计与合规
“日志里应该有”不是证据策略。
一份可用于运营决策的证据至少要回答：
同时还要回答：
数据库 evidence 很容易包含 credential、SQL bind value、tenant data、backup 内容和人员身份。收集越多，不等于治理越好。
24.5.1 配置、变更、访问和恢复证据
日志、审计、证据和合规不是同义词
| 对象 | 主要用途 | 例子 |
|---|---|---|
| operational log | 调试运行行为 | PostgreSQL error/log line |
| audit record | 记录受关注主体动作 | role/DDL/object access |
| evidence | 支撑一个具体结论 | target+hash+result manifest |
| compliance assessment | 将证据映射到外部控制 | control tested/effective/gap |
一个系统可以日志很多但证据不足：
反过来，保存一份结构化的 secret-free manifest 可能比复制整个日志目录更适合 日常 change evidence。
配置证据：声明、渲染、运行事实
Pigsty 管理的 PostgreSQL 配置有三层：
只保存 inventory 不能证明部署生效；只保存 SHOW 不能证明变更来源和评审。
配置 evidence：
需要特别区分：
- desired value；
- current effective value；
- reload-pending；
- restart-pending；
- session override；
- role/database override。
PostgreSQL pg_settings 的 source、sourcefile、pending_restart 等字段有助于
解释运行值，但路径和配置内容仍需按敏感性处理。官方视图见
pg_settings。
变更证据：意图、授权、执行、结果
完整 change evidence：
命令历史不能替代这个链：
- shell history 可编辑；
- shared account 无法归因；
- command line 可能泄露 secret；
- 它不记录独立批准；
- 它不证明 target；
- 它不证明结果。
访问证据：身份链而不是密码
第 23 章区分：
访问 evidence 可以保存：
- durable identity id；
- authentication mechanism/result；
- login/effective role；
- membership option；
- target object/action；
- approval；
- SQLSTATE；
- session id/correlation；
- start/end/revoke；
- policy version。
不能保存：
- cleartext password；
- SCRAM verifier；
- private key；
- session token；
- credential-bearing URI；
- raw PgBouncer userlist；
- 无必要的 SQL parameter。
credential rotation evidence 保存 secret version id，而不是 secret value：
ordinary PostgreSQL logs 的边界
PostgreSQL logging 可以记录：
- connection/disconnection；
- statement duration；
- SQLSTATE 和错误；
- DDL/statement；
- prefix 中的 user/database/application/session；
- lock、checkpoint、autovacuum 等运行事件。
配置见 Error Reporting and Logging。
但普通日志不是自动完整 audit：
- 采样和阈值会省略事件；
- statement 与 bind value 记录受参数影响；
- superuser/host admin 可能改配置；
- owner/role 语义需要额外关联；
- log storage、access、integrity、retention 仍需治理；
- 记录过多参数会泄露数据。
pgAudit 可以提供更结构化的 session/object audit，但仍需安装、preload、配置、 容量和审查。官方项目见 pgaudit/pgaudit。它也不能替代 change request、业务授权和 evidence chain。
恢复证据：从 backup 到 application
恢复 evidence 至少有：
第 21 章正式摘要：
本章只引用其 run id 与 SHA-256，不复制 private raw bundle，也不把单次沙箱 timing 升格为生产 RTO。
SLO 和告警证据
SLO decision 需要：
- policy version；
- numerator/denominator；
- query/recording rule hash；
- evaluation window；
- exclusion records；
- missing-data intervals；
- budget state；
- release/change markers；
- alert firing/resolved；
- route delivery 和 acknowledgement；
- owner decision。
只有 dashboard screenshot 不够：
- 时间范围可能隐藏；
- query 可能后来改变；
- series 可能 missing；
- panel 可手工选择过滤；
- screenshot 不能复算。
可以保留 screenshot 作为沟通附件，但 canonical evidence 应能机器重算。
incident evidence
事件证据：
时间线要区分：
避免事后把“后来知道的根因”写成当时已知事实。
六类 evidence policy
本章定义：
| 类别 | 教学保留 | 分类 |
|---|---|---|
| configuration | 400 d | internal |
| change | 400 d | confidential-operational |
| access | 400 d | confidential-security |
| recovery | 400 d | confidential-operational |
| SLO/alert | 400 d | internal |
| incident | 730 d | confidential-incident |
这些数字只是教学政策，用于验证每类都有正数、访问和删除合同。真实保留期必须 经过法律、监管、隐私、调查和成本评审，不能照抄。
24.5.2 保留、不可抵赖与隐私边界
chain of custody
证据链：
“文件还在”不能证明它没被改。
hash 证明什么
SHA-256 可以证明：
不能单独证明：
- 谁采集；
- source 真实；
- 采集前没有被篡改；
- timestamp 可信；
- manifest 没被一起替换；
- 结论正确。
增强方式：
- signed manifest；
- append-only/object lock store；
- independent timestamp；
- durable collector identity；
- separation of duties；
- multiple source correlation；
- access and deletion audit。
不要把“有 hash”写成绝对不可抵赖。
不可抵赖依赖个人身份
shared postgres 或 root account 最多证明“某个拥有共享 credential 的人”。
要提高 accountability：
仍要考虑：
- 身份被盗；
- host compromise；
- log admin；
- 时钟；
- collusion；
- privacy。
所以工程上更准确的说法是“提高归因与篡改检测能力”，而不是宣称数学意义上的 绝对不可抵赖。
UTC、时钟与顺序
多节点 PostgreSQL/Pigsty 证据需要：
- UTC timestamp；
- NTP status；
- monotonic duration；
- event sequence/correlation；
- clock uncertainty。
wall clock 可调整，耗时应使用 monotonic clock。跨系统排序若只靠毫秒 timestamp 可能出错，应用事件应有 correlation/idempotency token。
最小必要收集
问四次：
例子：
| 原始材料 | 更安全替代 |
|---|---|
| password | secret version id |
| certificate private key | public certificate fingerprint |
| full SQL values | normalized fingerprint + SQLSTATE |
| customer row | count + synthetic marker |
| full connection URI | host/db/user + redacted auth |
| raw system identifier everywhere | relation matches/differs，必要时私密保存 |
evidence store 不是 backup repository
backup 本身包含业务数据，访问和保留应按数据分类；治理 evidence 只需记录：
不要把 backup archive 复制到工单附件。
legal hold 与 scheduled deletion
正常生命周期：
事件/诉讼 hold：
hold 不能变成永久保存所有数据的借口；解除后恢复原 retention decision。
redaction 要保留原始与派生关系
安全流程：
直接覆盖 original 会破坏调查能力；把 original 给所有 reviewer 又扩大泄露面。
日志参数与隐私
PostgreSQL 的 statement/parameter logging 可以帮助诊断，也能记录：
- password reset SQL；
- token；
- email/phone；
- tenant data；
- health/financial data；
- application secret。
第 23 章沙箱观察到普通非错误 statement logging 可能保留完整 bind parameter， 且 pgAudit 未安装/preload。这个 gap 在治理层必须：
- 有 owner；
- 有整改或接受期限；
- 限制日志访问；
- 评审 retention；
- 避免在 SQL 中传 secret；
- 对敏感语句/值设计脱敏；
- 不谎称“审计完整”。
合规是外部控制映射
NIST、ISO、行业或地区监管可以要求：
- change control；
- dual authorization；
- audit generation/review；
- retention；
- least privilege；
- incident evidence；
- recovery testing。
本章合同可以成为控制 evidence，但不能自行宣布：
正式 assessment 还需要：
- applicable scope；
- control owner；
- external requirement version；
- test procedure；
- evidence period/sample；
- deficiency；
- compensating control；
- assessor decision。
本章参考 NIST SP 800-53 Rev. 5.1 的 change/audit 思路，不把它当通用认证印章。
24.5.3 用自动检查减少人工表格
自动化检查不变量
最有价值的自动化不是生成更多空表格，而是拒绝错误状态。
本章 validator 检查：
交叉引用比格式更重要
JSON 能 parse 不代表治理一致：
这类关系很难靠人工逐页检查，适合 CI。
对抗性验证证明 validator 不是摆设
positive fixture 全通过仍可能说明检查从未真正失败。每条关键 policy 要有 negative case：
本章二十个 mutation 全部必须产生至少一个 failure。若一个 mutation 被接受， validator 即失败。
hash binding
正式 evidence 保存：
这样以后修改合同再验证旧 evidence，会因 source hash drift 失败。不能拿新版 规则解释旧运行而不声明差异。
live gate 与历史证据分开
本章正式运行做两件事：
它没有重跑：
- failover；
- restore；
- pool mutation；
- credential/RLS drill。
因此结论：
这是 evidence freshness 的重要边界。
secret scanner
review 扫描 private evidence：
- SCRAM verifier signature；
- PEM private key；
- clear password JSON field；
- credential-bearing PostgreSQL URI。
scanner 不能发现所有 secret，也会有误报/漏报。还需要：
- source schema allowlist；
- credential input 与 output 分离；
- mode
0600； - no shell args；
- redacted projection；
- 人工 review；
- secret manager policy。
mode 与位置
正式 evidence directory：
- 新建且为空；
umask 077；- 文件 group/world 不可读；
- 不进入 repository；
- private inventory 不复制、不 hash；
- repository 只保存 secret-free summary。
本章的 governance-run.json 只保留摘要、run id、计数和 source/upstream hash。
自动化不能决定什么
validator 能发现：
它不能决定：
- 99.9% 是否符合真实用户；
- 250 ms 是否合理；
- 400 天是否符合法律；
- 哪个人有组织授权；
- 一次 data mismatch 的客户影响；
- 是否应该恢复到某个时间点；
- 一个 exception 是否值得接受。
这些需要真实 owner 与 authority。自动化的价值是让他们在同一组可信事实上 决策。
将手工表格转换为规则
手工问题：
更强的机器合同：
不是所有内容都能计数，但能机器判定的部分不应只靠勾选。
CI 分层
把所有检查塞进夜间报表会错过执行门槛。
本章正式结果
公开摘要见
governance-run.json，正式原始 evidence 位于
私密临时目录，不进入仓库。
Evidence review 清单
- 结论要证明什么？
- source、target、collector、time、tool 是否明确？
- desired/rendered/observed 是否分开？
- requester/approver/executor 是否可归因？
- artifact 是否按 hash 绑定？
- command success 与 postcondition 是否分开？
- access evidence 是否不含 credential？
- recovery evidence 是否包含 application verification？
- SLO numerator/denominator/query/exclusion 是否可复算？
- missing intervals 是否保留？
- original 与 redacted copy 是否可追溯？
- retention 是否有目的、访问、hold 和删除？
- hash 是否被错误宣传为绝对 authenticity？
- shared account 是否破坏归因？
- raw SQL/bind/customer rows 是否最小化？
- negative cases 是否真的失败？
- 历史 evidence 的 freshness 是否明确？
- compliance 结论是否由适用的正式评估给出？
下一节把服务卡、SLO、告警、SOP 和 evidence 串成一个完整的 pg36_shop
治理实验。
上一节：观察与告警契约 · 返回本章目录 · 下一节：实战：把 pg36_shop 纳入服务治理 ·
查看全书目录 · 查看索引中心