运营审计日志

（部分： 业务和管理）

1）任命和原则

审计日志是有关谁，在哪里，何时以及为什么这样做的主要真相来源，并能够证明记录的不变性和真实性。

• 完整性：涵盖人员，服务和外部合作伙伴的行为。
• 不可变性：记录无法在没有可见痕迹的情况下重写/删除。
• 归因：动作与主体，角色，上下文和人工制品有关。
• 可重复性：可以在报告/争议中复制事件。
• PII最小化：只需要戴口罩和令牌。

2）覆盖范围

自定义操作：输入/SSO/MFA、角色/限制更改、PII操作。
特权操作：JIT/PAM会议，断玻璃，管理控制台。
财务：价格表/税收/FX出版物,付款/付款,代管,注销/退款。
配置/发行版：ficheflagi，图形迁移，丢弃/回滚，密钥/证书。
整合：webhooks，签名，收据，idempotency密钥。
数据：读取/导出PII,创建/删除工件,更改策略。

3）架构与不可变性

具有身份验证，配额和电路验证的Ingest网关。
WORM存储（immutable buckets/append-only）：版本,Retention Lock, Legal Hold。
加密微调：对于关键事件，"receipt_hash"和DSSE签名形成。
Merkle链：定期构建切片（checkpoint）,发布根哈希。
Custody of custody：跟踪工件的移动（谁获得了访问权限、时间、依据）。
时间同步：NTP/PTP，标记"event_time"和"ingest_time"，调整"skew"。

4）事件图（参考）

audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human    service    partner, roles[], mfa?, device_posture?
},
action: CREATE    READ    UPDATE    DELETE    EXECUTE    PUBLISH    APPROVE    ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass    fail, justification?, ticket_ref?,
result: success    deny    error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none    aggregated    tokenized    sensitive,
retention_class, labels[]
}

另外：对于金融-"fx_version/tax_rule_version/pricelist_version"；webhooks是"webhook_id"，"idempotency_key"。

5）数据模型和区域

热门（快速）：7-30天,快速查询/行车记录仪。
Warm （OLAP）： 6-24个月,分析/搜索。
冷藏（存档/WORM）：长达7-10岁（通过监管）。
复仇类："operational"，"financial"，"security"，"legal_hold"。
策略验证：所有事件均标有"policy_version"；策略更改是一个单独的审计事件。

6）负担得起和隐私

RBAC/ABAC/ReBAC：角色/tenant/区域/案例（案例）可见性。
PII伪装：标识符标记，主要输出仅通过批准的乔巴。
禁止直接删除：仅"tombstone"+Legal Hold；带有单独期刊的"donews"。
审计本身：谁看过/卸载了逻辑-也是这样。

7）质量,一致性,双打

数据合同：严格的电路和输入上的lambda验证。

Idempotency＆dedup： "（event_id，制作人）"；«seen-cache» + KV.

时间校正：后期事件的水印（水标）。
完整性控制：比较源计数器和最严格的度量。

8） Dashbords和查询

操作：特权行动，SoD违规行为，JIT权利提升，访问PII。
财务：FX/Tax/PriceList出版，quote↔checkout差异，关键签名。
整合：webhook收据，lag，retrai，dubly。
版本/configs：谁/何时启用/回滚，事件链接。
搜索脚本："trace_id"，"主题"。id`, `target.id'，时间/区域/tenant，"policy_version"。
导出：应要求提供带收据（签名清单）的批量卸载。

9） API和webhooks

"POST/audit/ingest"-接受事件（身份验证、限制、电路）。
"GET/audit/search"-过滤器、分页、结果限制。
'GET/audit/trace/{trace_id}-链条上的一系列事件。
"POST/audit/receipt/verify"-收据验证/DSSE。

Вебхуки: `SoDViolation`, `PrivilegedSession`, `PIIAccess`, `PolicyChanged`, `FinancialArtifactPublished`.

10）SLO/审计质量指标

Ingest Availability: ≥ 99.95%.

Freshness（时机）：Lag ≤ 30与p95。
Completeness: ≥ 99.5％的消息来源将数据发送到窗口。

Correctness： 校验和差异≤ 0。1%.

Tamper-evidence： 100%的时间段通过Merkle根/签名认证。
PII Hygiene： 100%的敏感类事件带有面具/令牌。

11）花花公子和事件

怀疑更换记录：立即检查Merkle根，DSSE收据对账，访问隔离，法律保留。
PII泄漏：查找受影响的事件/出口、访问审核、DPO/监管机构及时通知。
违反SoD：操作障碍，临时撤职，调查和政策调整。
Ingest故障：缓冲、降级模式、恢复后继、重复数据控制。

12）法律摘录和合规性

司法管辖区：财务/税收-5-10年；安全-政策；个人数据-最低要求期限。
法律保护：在监管机构的桉件/请求中冻结处置。
报告工件：时期索引，根哈希，签名列表，源清单。
不可逆性：密码处理，独立计时（内部TSA）。

13） iGaming/fintech特点

付款/付款：完全跟踪授权，清算，拒绝，充电包；与银行收据相匹配。
RTP/限值：配置文件发布、RTP观察到的更改和限值决策-带有签名和版本。
附属机构：仅接受签名文物，进行变换，异议/代管。
价格表/税单/FX：每个订单中的人工制品版本；回扣-带收据。

14) RACI

15）风险和反模式

可编辑的逻辑没有痕迹→法律上的不支持。
没有时间同步→未连接的时间线。
影子出口没有收据→泄漏/争议。
逻辑中的秘密→妥协。
与SLO/事件无关 →"数据墓地"没有好处。

16）实施支票

• 确定覆盖范围和policy_version。
• 部署具有身份验证、方案和配额的ingest。
• 启用WORM、Merkle切片、DSSE签名、TSA。
• 按类和Legal Hold配置戒律。
• 引入RBAC/ABAC/ReBAC和日志访问审核。
• 构建dashbords：特权，PII，财务，发行版/配音。
• 包括花花公子：tamper，PII泄漏，ingest故障，SoD违规。
• 在测试套件上试用继电器和dedup。
• 建立带有收据和请求登记册的出口。
• 每季度审核质量指标（freshness/completeness/tamper）。

17) FAQ

可以将所有内容存储在常规DB中吗?

对于快速操作-是的,但关键日志必须在WORM/append-only中复制,并带有签名和Merkle剪辑。

是否需要对每个数据读数进行拼写?

PII/财务阅读-强制性；其余的是政策和成本。

如何证明不变性？
根哈希，DSSE签名，独立的TSA和可复制的验证程序。

如何处理"删除权"（GDPR）?

删除处理系统中的主要产品；在审核日志中-在没有恢复PII的情况下存储令牌/哈希,并在需要时保持合法保留。

摘要：审核日志不是"S3中的日志"，而是具有明确策略，不变的存储，受控访问以及对争议/监管检查的准备的可加密证明的操作历史。根据合同建造最出色的产品，签署关键事件，支持Merkle切片和行车记录-并且您将拥有可靠的信任，安全和合规性基础。