運營審計日誌

（部分： 業務和管理）

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切片和行車記錄-並且您將擁有可靠的信任，安全和合規性基礎。