24.5 证据、审计与合规

“日志里应该有”不是证据策略。

一份可用于运营决策的证据至少要回答：

what fact
from which source
about which exact target
collected by which identity/tool
at what time
under which authority
with which integrity check
used for which decision
retained where and for how long
disclosed to whom
deleted how

同时还要回答：

what must never enter this evidence

数据库 evidence 很容易包含 credential、SQL bind value、tenant data、backup 内容和人员身份。收集越多，不等于治理越好。

24.5.1 配置、变更、访问和恢复证据

日志、审计、证据和合规不是同义词

一个系统可以日志很多但证据不足：

log:
  ALTER ROLE completed

missing:
  requester
  independent approver
  exact reviewed artifact
  previous state
  intended target
  new-session verification
  existing-session decision
  secret handling

反过来，保存一份结构化的 secret-free manifest 可能比复制整个日志目录更适合 日常 change evidence。

配置证据：声明、渲染、运行事实

Pigsty 管理的 PostgreSQL 配置有三层：

declared
  inventory / policy source

rendered
  generated config, HBA, service definition

observed
  pg_settings / pg_hba_file_rules / listener / service state

只保存 inventory 不能证明部署生效；只保存 SHOW 不能证明变更来源和评审。

配置 evidence：

service/environment/cluster
source revision and hash
sanitized inventory projection
rendered artifact hash
live target identity
observed setting + source + pending_restart
drift and accepted exception
collector/tool version
captured_at UTC

需要特别区分：

• 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：

intent
  request / desired state / user reason

authority
  requester / approver / executor / time / role

artifact
  exact SQL/config/script hash

preflight
  target / topology / budget / capacity / stop lines

execution
  phases / timestamps / tool outcome

observation
  SLI / component facts / unknown outcomes

verification
  postconditions

decision
  accept / reject / exception / rollback / roll-forward

命令历史不能替代这个链：

• shell history 可编辑；
• shared account 无法归因；
• command line 可能泄露 secret；
• 它不记录独立批准；
• 它不证明 target；
• 它不证明结果。

访问证据：身份链而不是密码

第 23 章区分：

workforce/workload identity
  -> login role
      -> effective role
          -> object permission
              -> RLS context

访问 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：

old version v17
new version v18
new auth pass
old new-session auth rejected
existing sessions handled by decision CHG-...
final role LOGIN=false

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 至少有：

source identity
backup identity
repository identity
target time/name/LSN
required WAL coverage
restore destination and isolation
start-in-recovery
target reached
promotion decision
system identifier relation
application marker/invariant checks
network/listener boundary
postmaster stopped
timings and their interpretation

第 21 章正式摘要：

run id       run_20260729T201040Z_961665aa
named PITR   accepted-with-exceptions
production   pending

本章只引用其 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

事件证据：

first signal
declared severity
user/data impact
decision log
commands and target
topology/config changes
unknown outcome reconciliation
communications
recovery verification
follow-up

时间线要区分：

event time
observed time
recorded time

避免事后把“后来知道的根因”写成当时已知事实。

六类 evidence policy

本章定义：

这些数字只是教学政策，用于验证每类都有正数、访问和删除合同。真实保留期必须 经过法律、监管、隐私、调查和成本评审，不能照抄。

24.5.2 保留、不可抵赖与隐私边界

chain of custody

证据链：

collect
  source / target / collector / UTC / tool version

preserve
  immutable or object-locked original where required

manifest
  canonical file list + SHA-256

derive
  redacted review copy, original retained separately

access
  role-based and audited

hold/export
  authority and recipient recorded

delete
  policy-driven and audited

“文件还在”不能证明它没被改。

hash 证明什么

SHA-256 可以证明：

current bytes match the bytes whose digest was recorded

不能单独证明：

• 谁采集；
• 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：

person authenticates with durable workforce identity
  -> obtains time-bounded privileged session
      -> executes under unique session/change id
          -> command and target recorded
              -> approval and result linked

仍要考虑：

• 身份被盗；
• 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。

最小必要收集

问四次：

purpose
  这个字段证明哪项控制？

scope
  能否用 aggregate/fingerprint 替代原值？

access
  谁真正需要？

retention
  目的结束后何时删除？

例子：

evidence store 不是 backup repository

backup 本身包含业务数据，访问和保留应按数据分类；治理 evidence 只需记录：

backup label
repository identity
size/count aggregate
coverage
integrity result
restore result

不要把 backup archive 复制到工单附件。

legal hold 与 scheduled deletion

正常生命周期：

created -> retained -> expired -> reviewed -> deleted -> deletion recorded

事件/诉讼 hold：

hold authority
scope
start
reason
access
release authority

hold 不能变成永久保存所有数据的借口；解除后恢复原 retention decision。

redaction 要保留原始与派生关系

安全流程：

original private evidence
  hash A
  restricted access

redacted review copy
  hash B
  derived_from A
  redaction tool/version/rules

直接覆盖 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，但不能自行宣布：

compliant
certified
meets every jurisdiction

正式 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 检查：

service card
  exact owner functions
  dependencies and failure semantics
  six health layers
  production=false

SLO
  target in (0,1)
  event/time budget arithmetic
  planned maintenance included
  missing=unknown
  correctness/recovery controls

alerts
  objective references
  owner/runbook/action/verification
  symptom/cause/capacity separation
  multiwindow burn set
  actionless candidate rejected

SOP/change
  four capabilities
  precondition/stop/verify/rollback/evidence
  L2/L3 identity separation
  break-glass boundary

evidence
  six categories
  no secrets
  hash/access/retention

交叉引用比格式更重要

JSON 能 parse 不代表治理一致：

SLO objective id
  must exist in observation contract
  must be referenced by alerts

SOP reference run id
  must match retained upstream artifact

upstream production gate
  must remain pending

source hash
  must match exact validator and policy bytes

这类关系很难靠人工逐页检查，适合 CI。

对抗性验证证明 validator 不是摆设

positive fixture 全通过仍可能说明检查从未真正失败。每条关键 policy 要有 negative case：

change target to production
delete platform owner
set SLO target to 1
set missing to healthy
accept actionless page
make capacity a page
remove restore verification
allow one identity to self-approve
allow break-glass to skip evidence
permit secret values
invent upstream run id

本章二十个 mutation 全部必须产生至少一个 failure。若一个 mutation 被接受， validator 即失败。

hash binding

正式 evidence 保存：

source_sha256
  service-card.json
  slo-policy.json
  observation-contract.json
  ...
  validate.py
  review.py
  task.sh

upstream_references
  path
  schema
  run_id
  sha256
  production_gate

这样以后修改合同再验证旧 evidence，会因 source hash drift 失败。不能拿新版 规则解释旧运行而不声明差异。

live gate 与历史证据分开

本章正式运行做两件事：

current:
  rerun chapter-19 read-only deployment gate

historical:
  bind retained ch20–ch23 run summaries by hash

它没有重跑：

• failover；
• restore；
• pool mutation；
• credential/RLS drill。

因此结论：

current baseline        rechecked
historical references   identity-bound
historical freshness    not automatically renewed
production proof        no

这是 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 能发现：

target is 1.0
owner missing
hash mismatched
secret field allowed

它不能决定：

• 99.9% 是否符合真实用户；
• 250 ms 是否合理；
• 400 天是否符合法律；
• 哪个人有组织授权；
• 一次 data mismatch 的客户影响；
• 是否应该恢复到某个时间点；
• 一个 exception 是否值得接受。

这些需要真实 owner 与 authority。自动化的价值是让他们在同一组可信事实上 决策。

将手工表格转换为规则

手工问题：

请确认有回退方案： [x]

更强的机器合同：

rollback_or_roll_forward nonempty
stop_conditions >= 3
verification >= 3
artifact hash exists
approver != executor
preflight age <= policy

不是所有内容都能计数，但能机器判定的部分不应只靠勾选。

CI 分层

PR time
  parse/schema/cross-reference/math/negative cases

pre-deploy
  target/hash/authority/budget/preflight

during deploy
  stop lines + service/component observation

post-deploy
  verification + evidence manifest

scheduled
  owner/route expiry
  restore evidence age
  notification canary
  exception expiry

把所有检查塞进夜间报表会错过执行门槛。

本章正式结果

run id             34909737-527a-460c-927c-d9d71c93aa13
mode               read-only
source artifacts   8 core + scripts/policies
objectives         5
accepted alerts    7
SOPs               4
negative cases     20 rejected
upstream hashes    4
ch19 live gate     accepted-with-exceptions
secret material    absent
production gate    pending

公开摘要见 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 纳入服务治理 · 查看全书目录 · 查看索引中心