审核和不变日志

审核和不变日志

1）为什么需要它

审计的目的是以可证明的完整性记录"谁，哪里，何时和为什么"，以保持安全，调查，财务报告和合规性。
不可变日志是一种格式和存储，其中事件仅通过添加（仅附录）编写，并且无法通过加密工具和存储策略进行后续更改/删除。

2）威胁模式和控制目标

• 内部人员故意编辑/删除事件。
• 更改时间/源（replay/backdating）。
• "安静"关闭节点上的拼写。
• 在事故/迁移中丢失日志的一部分。
• PII收费过多，隐私不和谐。

1.完整性：经修改/删除保护证明。

2.完整性：关闭关键流（控制平面、数据平面、可用性、金钱）。

3.时间精度：可播放的同步时间。

4.可用性：在SLO中读取和搜索。

5.隐私：最低PII，令牌/加密，使用合法性。

3）分类学和事件优先级

• 控制平面：身份验证/授权、配置更改、密钥操作（KMS）、秘密管理、策略更改。
• 数据平面：访问对象/记录/支票/付款；读/创建/删除。
• Admin和DevOps：SSH/控制台，CI/CD，基础设施/IaC更改，权利升级。
• 杂货：交易，计费，客户运营。
• 系统/网络：内核/代理人/代理人/资产负债表、经纪人、DB。
• 安全性：IDS/IPS/EDR，WAF，抗DDoS，抗氟化物，DLP。

对于每个类别，我们提交以下内容：关键性，方案，强制性字段，保留期，不变性要求。

4）必填字段和格式

相关标识符是：'trace_id'，'span_id'，'request_id'，'actor_id'（用户/服务），'tenant_id'，'resource_id'。
A&A上下文：操作时验证方式、角色/策略。
时间：RFC3339/UTC，毫秒/纳秒；同步源。
动作和结果：操作类型、目标、状态、受影响的对象数量。
完整性：本地HMAC记录，序号（序号），hash-prev。
电路：具有稳定模型的JSON（例如，与通用事件词典兼容）。

禁止：秘密，钥匙，代币，完整PAN，密码，私人钥匙。PII-仅在需要时使用，带有伪装/令牌化功能。

5）时间与同步

时间来源：至少两个独立来源（NTP/PTP）+位移监测。
关键时间签名：使用可信时间标记服务（TSA） 或内部时间sealing服务进行事件包。
规则：没有本地时区，只有UTC；构造和偏移/时间质量。

6） Logo Stream体系结构

代理商→缓冲区→运输→兰丁→哈希链/签名→寒冷/存档→搜索索引。

节点收集：带有磁盘缓冲区的轻型代理（daemonset/sidecar）（后压）。
运输：安全通道（TLS/mTLS），有保证的交付（on-least-once），idempotent-ingest。
Landing zone：以"原始"视图（按日期/tenant/类型分期）提供的对象存储。
索引：用于在线查询的搜索/分析引擎（热层）。
归档（WORM）：带有保留策略和法律保留的不变垃圾箱/磁带。
Anchor/Seal：偶尔的"zapaika"哈希链包（见下文）。

7）密码不可变性

7.1哈希链（仅限附录）

每个条目都包含："hash_curr=H（记录）"，先前条目中的"hash_prev"，"seq"。任何编辑都会打破链条。

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7.2签名包和时间印章

每N 秒/MB形成一个块：所有"hash_curr"的Merkle根。
我们用审计键（在KMS/HSM中持续存储）签名块。
我们添加TSA时间戳并发布"块目录"（Transparency Log）。
可选：定期将根哈希锚定到外部可证明空间（例如，独立日志或公共不可变存储）。

7.3审计密钥管理

签名键-在KMS/HSM中，按计划轮换，多因素访问，用于导出的双控制。
召回钥匙→新的信任分支；旧签名仍可验证。

8）存储策略和WORM

WORM/immutability：包括不变容器/垃圾箱，以及针对P0/P1类的Retention和Legal Hold策略。
转化：包括在内；删除-仅通过延迟程序（禁止即时购买）。
Retentia：热（7-30天），温暖（3-6个月），冷/存档（1-7年或更长-取决于监管机构/合同）。
多租户性：每个租户的单独名称/帐户空间/加密密钥；期刊访问报告。

9）私有化和最小化

根据必要性原则收集：我们不要再计算了。
敏感字段的标记/化名，标识符的盐哈希。
存储在共享对象存储中时，prodewser端字段（AEAD）加密。
删除权（如适用）：通过加密擦除字段/批次密钥而不破坏容器不可变性来实现（在设计时计划）。

10）审计本身的访问、角色和审计

拆分：生产商≠读者≠管理员。
仅从WORM读取；更改回避策略-通过单独的角色和批准程序。
所有阅读/导出操作都会记录在辅助日志中（元审核）。
Export for Respon/Compliance-使用哈希块目录和信任链进行加密。

11）可观察性和SLO

度量标准：注射率、到指数的差、丢失/重复的百分比、不同步时间的比例、签名/锚定错误、缓冲区填充。
SLO: ≥99.9％的事件≤ X秒传递到热索引；序列中有0个无法解释的"漏洞"；100％的块由时间签名和标记。
Alerts：无花果暂停>N分钟,无花果哈希上升,链条发散,签名/时间戳失败,时间偏移阈值。

12）测试和验证

红色/蓝色测试：尝试在不同阶段编辑/删除记录；检测验证。
溷沌：禁用主机上的座席、网络中断、缓冲区溢出、"时间替换"。
加密检查：定期验证链条，验证默克尔根和模具。
Forenzika：复制来自端到端日志的调查脚本。

13）操作和程序

Runbook"完整性检查"（按需和按计划）。
合法持有和临时批次"冻结"的程序。
保持信任链的发现和导出过程。
审核密钥轮换计划和对损害的反应（新的信任分支，块的笔签名，通知）。

14）迷你食谱

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• Control/Data plane P0：热30天→温暖6个月→存档7年（WORM）。
• DevOps：热14天→温暖3个月→存档1年。
• Security信号：热90天（用于调查），然后是1-3年。

15）经常出错

"徽标是没有模式的文本。"没有电路，就没有确定性的完整性和搜索。规范的JSON和固定字段是必需的。
没有相关性。缺乏"trace_id"破坏了调查。
本地时间。仅UTC和位移控制。
写入要更改的卷。没有WORM，任何不变性都是虚构的。
读数不合乎逻辑。读取敏感数据的重要性不亚于写入。
博客中的秘密。在发送前打开消毒剂，"红色列表"模式。
一把钥匙全部。签名和加密密钥是分开的，具有角色和轮换。

16）合规和监管

保留时间/不变性要求取决于域（财务，支付，电信等）。
可证明性：存在WORM/反应协议，链验证报告，日志访问日志，法律保留程序和导出。

17）支票单

出售前

• 已批准事件分类法和方桉（必填字段）。
• 已配置代理、缓冲区、安全传输、后压。
• 包括：哈希链、块签名、时间戳、透明日志。
• WORM/Retence存储库已启用；无法覆盖/删除测试。
• 敏感字段的掩蔽/标记化。
• 时间同步和位移监控。
• 在KMS/HSM中轮换计划和存储审计密钥。

运营活动

• 每周电路和块验证（+报告）。
• Alerta的电路断裂/签名错误/时间偏移。
• Red Team定期进行替换/删除测试。
• 定期复习和成本审查。

18) FAQ

问：DB级别的"仅加法"是否足够？
哦不需要加密保证（哈希链、块签名、时间戳）和WORM策略。

问： 如何处理数据删除权?

答：为字段/批次设计加密擦除（删除密钥），同时保持介质不可变性和日志的可证明性。

问： 是否需要单独的密钥来签名块?

是的。块签名密钥与存储加密密钥分离；存储在KMS/HSM中，并进行轮换和审核。

问：是否可以"锚定"公共空间？
答：可选。这将增强可验证性，并切断轮廓内的"历史重写"。

• "At Rest加密"
• "In Transit加密"
• "秘密管理"
• "密钥管理和旋转"
• "；请求的签字和核实"；