審核和不變日誌

審核和不變日誌

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加密」
• 「秘密管理」
• 「密鑰管理和旋轉」
• "；請求的簽字和核實"；