資料最小化：只收集需要的欄位

資料最小化的工程落地是「每個收集的欄位都要能回答：這個欄位用來做什麼決策？」。如果一個欄位只是「可能有用」但沒有明確的消費場景，就不應該收集。

正面表列 vs 負面排除

正面表列（allowlist）是列出「收集哪些欄位」— 只收集清單上的欄位，其他全部不收。

負面排除（denylist）是列出「不收集哪些欄位」— 預設收集所有欄位，排除清單上的。

GDPR 的精神更接近正面表列 — 每個收集行為需要有正當理由（lawful basis）。工程上的實作方式是：事件 schema 定義哪些欄位是允許的，不在 schema 中的欄位在 collector 端丟棄。

SDK 端的最小化

SDK 端的最小化更主動 — 在事件產生時就只包含必要的欄位，而非送到 collector 再過濾。

設計 SDK 的 event API 時，不提供「送任意 key-value」的 free-form API，而是提供結構化的 API：

1// free-form（難以控制收集了什麼）
2monitor.event('login', data: {'email': email, 'ip': ip, 'device': device, ...})
3
4// 結構化（schema 控制收集範圍）
5monitor.event('login', loginMethod: 'biometric', success: true)

結構化 API 的參數在 SDK 設計時就決定了收集範圍，code review 時可以檢查「為什麼這個 event 需要這個參數」。

目的限制：收集的資料只用於聲明的目的

目的限制要求資料只用於收集時聲明的目的。監控系統收集事件的目的通常是 debug 和效能監控 — 如果之後要用同一份資料做行為分析或廣告投放，需要額外的法律基礎（通常是使用者同意）。

工程落地

目的限制在工程上的實作是「不同目的的資料分開儲存、分開授權」。

Debug 用的 error 事件和行為分析用的 event 事件存在不同的儲存位置（不同的 JSONL 檔案或不同的資料庫 table）。Debug 用途的 access 不需要使用者同意（legitimate interest）；行為分析用途的 access 需要使用者同意。

分開儲存讓「使用者撤回行為分析同意」的工程操作變簡單 — 刪除行為分析的儲存，不影響 debug 儲存。

儲存限制：不保留超過必要期間的資料

儲存限制要求資料只保留達成目的所需的最短期間。監控資料的合理保留期間依用途不同：

自動清理

Collector 的儲存清理應該自動化 — 手動清理依賴人記得執行，最終會被遺忘。

JSONL 儲存用「一天一檔」的命名（events-2026-06-19.jsonl），清理腳本每天刪除超過保留期限的檔案。Cron job 或 systemd timer 定期執行。

下一步路由

• 去識別化技術 → 去識別化策略
• 監控資料洩漏的威脅分析 → 監控資料洩漏的 threat model
• Collector 的儲存設計 → 模組四 Collector 設計

服務定位

CloudHSM 的核心定位是 把 cryptographic root of trust 放回客戶手上 — 適合金融、政府、醫療這類有資料主權、FIPS 140-2 Level 3、PCI HSM、HIPAA 合規壓力的場景。跟 AWS KMS 比、KMS 也滿足 FIPS 140-2 Level 3、但 HSM cluster 是 AWS 多租戶共用、key material 由 AWS-controlled HSM 持有、控制面 API 也是 AWS。CloudHSM 把 HSM cluster 物理隔離給單一客戶、PKCS#11 / JCE / OpenSSL Dynamic Engine 直接打 HSM、AWS 在資料平面 沒有讀 key 的能力。

跟 自管 on-prem HSM（SafeNet / Thales 自架）比、CloudHSM 把硬體採購、機房、network、firmware patch 交還 AWS、客戶只管 key custody 跟 Crypto User policy；代價是不能完全脫離 AWS region。跟 Vault auto-unseal 整合場景中、CloudHSM 是 Vault master key 的 root custodian — Vault unseal key 用 CloudHSM 加密、CloudHSM 出事整個 Vault cluster 沒法 unseal、所以可用性設計（cross-AZ cluster、cross-region backup）很關鍵。多數一般 web app / SaaS 用 KMS 即可、不需要 CloudHSM 的物理隔離。

本章目標

讀完本頁、讀者能判斷：

1. 何時需要 CloudHSM 的 dedicated 模型、何時 AWS KMS 已足夠
2. CloudHSM cluster 的最低安全 / 可用性需求（cross-AZ、Crypto Officer 分離、Quorum、backup）
3. Crypto User credential 出事的降級路徑（AWS 不能幫忙、靠 backup + Quorum）
4. 跟 KMS Custom Key Store / Vault auto-unseal 整合的取捨

最短判讀路徑

判斷 CloudHSM deployment 是否健康、最少看四件事：

• Cluster 拓樸：production cluster 是否至少 2 個 HSM instance 跨 AZ、cluster 內自動 replicate、單一 AZ 故障時 key 是否仍可用
• Crypto User 管理：Crypto Officer（CO）跟 Crypto User（CU）是否分離、CO password 是否走 break-glass 保管、CU credential 是否走 short-lived 取得 + audit
• Quorum-based policy：高敏 operation（建 CU、改 policy、key export wrapped）是否設 M-of-N approval、避免單一 admin compromise 後 silent abuse
• Backup 治理：automatic 24h backup 跟 manual backup 是否都開、cross-region backup 是否走 explicit copy、restore 流程是否定期演練

四件事任一缺失、就是 CloudHSM deployment 待補項目 — 跟 secret management 的 evidence 邊界同類。

日常操作與決策形狀

Cluster + HSM Instance 拓樸：CloudHSM 的部署單位是 cluster、cluster 內可以有 1-N 個 HSM instance。production 場景至少 2 個 HSM instance 跨 AZ、cluster 自動把 key material replicate 在所有 instance 上、單一 AZ 失效不影響 cryptographic operation。跨 region 不自動 replicate — 跨 region DR 要靠 backup copy。

Crypto Officer (CO) vs Crypto User (CU)：CO 是 cluster 管理員、能建 / 刪 CU、設 policy、做 backup；CU 是真的做 cryptographic operation 的 identity（encrypt / decrypt / sign / verify）。production 必須分離 — CO credential 走 break-glass 保管、CU credential 給 application 使用、application compromise 只影響 CU 邊界、不能改 CO policy。

Quorum-based policy（M-of-N approval）：CloudHSM 支援把高敏操作（建 CU、改 policy、key export wrapped）綁定 M-of-N CO approval。例如 3-of-5 quorum、單一 CO 即使 credential 外洩也不能單獨建後門 CU、必須拿到另外 2 個 CO 的 signed token。對應 Storm-0558 signing key chain 啟示：高價值 key custodian 的 admin operation 不該是 單人單 token、必須有第二人簽核才能改變信任根。

Backup 治理：CloudHSM 每 24 小時自動 backup 整個 cluster state（含 key material）、backup 是 AWS-managed encrypted blob、AWS 自己也不能解密、restore 必須在 CloudHSM cluster context 內進行。可手動 backup、可 copy 到其他 region 做 DR。Backup retention 預設 90 天、可延長。Backup 不是 export — 不能把 key material 從 HSM 拿出來看 plaintext。

Key Replication 跨 region：CloudHSM cluster 綁定單一 AWS region、跨 region 走 backup → copy → restore 流程、不是 active replication。設計 DR 時要算 RTO：restore 一個 cluster 從 backup 大約小時級、不適合 hot failover、應該 primary region 跑、DR region 備好空 cluster + backup copy。

PKCS#11 / JCE / OpenSSL Dynamic Engine 整合：application 不用 AWS SDK 講 CloudHSM、而是透過 標準 cryptographic API library（PKCS#11 for C/C++、JCE Provider for Java、OpenSSL Dynamic Engine 走 TLS termination）。好處是 application code 用業界標準介面、未來換 HSM 廠也只需要換 library。代價是 client SDK 要裝在 application host、CU credential 要 deploy 到 host、host security baseline 變成 cryptographic boundary 的一部分。

跟 KMS Custom Key Store 整合：KMS Custom Key Store 把 KMS Key 的 backing material 放在 CloudHSM、API 仍透過 KMS（kms:Encrypt / kms:Decrypt）、application code 不需要改。這是 KMS 易用 + HSM dedicated 雙重：保留 KMS 的 IAM policy / key rotation / audit log（CloudTrail）、又得到 single-tenant HSM 的合規屬性。代價是 CloudHSM 失效時、Custom Key Store backing 的 KMS Key 全部不可用、需要監控 cluster health。

核心取捨表

選 CloudHSM 的核心訴求：合規明文要求 dedicated HSM（PCI HSM、某些國家資料主權法規）、或 trust model 上不接受 AWS 持 key。多數 AWS-heavy workload 用 KMS 即可、加 CloudHSM 反而引入 Crypto User credential 的單點失誤（丟了 = key 永久遺失）。需要 KMS API 但又要 dedicated HSM、走 Custom Key Store 是折衷路徑。

進階主題

Quorum Auth 設計：production 把 Quorum threshold 設為 3-of-5 或 2-of-3、五位 CO 由不同部門 / 不同地理位置持有、避免單一辦公室 / 單一網路同時被攻陷。Quorum token 有 TTL、單次 operation 用完就失效、防止 replay。建議 quarterly 演練：模擬一個 CO 不在、用剩餘 quorum 完成 emergency operation、驗證流程在事故時跑得通。

KMS Custom Key Store 整合決策：用 Custom Key Store 的關鍵問題是 availability blast radius — KMS Key 出事影響範圍是 使用該 Key 的 AWS service（S3、EBS、RDS encryption）、Custom Key Store backing 失效會讓這些 service 同步斷。設計時做 分層 key strategy：mass volume 的 S3 / EBS 用 AWS-managed KMS Key、高合規敏感的 database / secret 才用 Custom Key Store backing 的 KMS Key、降低單一 cluster 失效的影響面。

Cross-Region Backup：DR 要把 backup copy 到第二個 region、走 CopyBackupToRegion API、restore 時建空 cluster + 套 backup。整個 RTO 通常數小時、不適合熱備、設計上是 容忍小時級 outage 換到 BCDR 環境、不是 秒級 failover。對應 Azure AD Identity Control Plane 2021 對照啟示：身份 / 加密控制面的單點 outage 影響整個 platform、availability 的 topology 設計跟 confidentiality 同等重要。

跟 Vault auto-unseal 整合：Vault auto-unseal 可用 CloudHSM 作 master key custodian、走 PKCS#11 plugin、Vault unseal 時呼叫 CloudHSM Unwrap master key。比起 AWS KMS auto-unseal 多一層 dedicated HSM 保證、適合監管特別嚴的場景。代價是 CloudHSM cluster 失效 → Vault 不能 unseal → 下游所有 secret 拿不到、要設計 break-glass 流程。

合規憑證：CloudHSM 同時持有 FIPS 140-2 Level 3、PCI HSM、Common Criteria EAL4+ 多個認證、可作金融 PIN block 處理、payment 業者的 HSM 上鏈、政府機敏資料加密的 直接合規承諾、不需要客戶端再做 HSM 認證 audit。

排錯與失敗快速判讀

• Crypto User credential 丟失：CU password 全公司只有一份、保管人離職 → AWS 不能 reset、key material 永久不可用 — CU credential 要走 password manager + 多人持有、CO 有能力 revoke 舊 CU 建新 CU
• Cluster 只有單一 HSM instance：成本省了、單一 instance 故障 cluster 整個失效 — production 強制至少 2 個 instance、跨 AZ
• Backup 沒測過 restore：每天 automatic backup 跑、從未 restore 演練、DR 真要用時發現流程不通 — quarterly 演練 restore 到測試 cluster、驗證 key material 可用
• Custom Key Store 沒監控 CloudHSM health：CloudHSM cluster degraded 時、KMS Custom Key Store 跟著失效、application 看到 KMS 5xx — CloudWatch metric 監 HsmsActive / HsmTemperature、cluster health degrade 立即 alert
• PKCS#11 library 版本漂移：application host 的 client SDK 版本跟 cluster firmware 不相容、cryptographic operation 失敗 — version compatibility matrix 進 deployment pipeline、firmware upgrade 前先測 staging
• Quorum CO 全部同地點：5 個 CO 全在同一個辦公室、辦公室斷網 = quorum 不能組 — CO 跨 region / 跨組織分散
• Audit log 沒接 SIEM：CloudHSM activity 透過 CloudTrail + cluster audit log、沒接 SIEM 就無 forensic — CloudTrail 跟 cluster audit 都 push 到 SIEM（見 7.13 偵測覆蓋率與訊號治理）

何時改走其他服務

不在本頁內的主題

• CloudHSM 完整 PKCS#11 / JCE API reference
• CloudHSM Classic（舊版、已 EOL）的差異
• 每種合規法規（PCI HSM、HIPAA、FedRAMP）的逐條對應
• CloudHSM CLI 跟 cloudhsm_mgmt_util 詳細指令
• 應用層使用 HSM-bound key 做 TLS termination 的 nginx / Apache 配置細節

案例回寫

CloudHSM 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.5 傳輸信任與憑證生命週期（HSM 為 CA / signing key 的 FIPS-grade root custodian）、7.13 偵測覆蓋率與訊號治理
• 平行：AWS KMS、Google Cloud KMS、Azure Key Vault
• 整合：HashiCorp Vault（CloudHSM 作為 Vault auto-unseal master key custodian）
• 整合：KMS Custom Key Store（KMS API + CloudHSM backing 雙重）
• 跨模組：8 事故處理 vendor 清單（HSM 失效如何 routing 進 IR 流程）
• 官方：AWS CloudHSM Documentation

本章目標

讀完本章後、你應該能：

1. 對照 OWASP LLM Top 10（LLM01-LLM10）跟自己工作流的具體風險。
2. 看到 enterprise security audit 報告用 OWASP 編號、能 map 到模組六章節找對應 control。
3. 知道哪些 OWASP 項目模組六完整覆蓋、哪些只覆蓋部分、哪些屬其他模組或 backend/07。

OWASP LLM Top 10 2025

OWASP（Open Worldwide Application Security Project）的 LLM 應用安全清單、2025 更新版：

事實查核註：OWASP 列表會定期更新（2023 → 2025、未來會有新版）、引用前以 OWASP LLM Top 10 當前版為準。

詳細 mapping

LLM01 Prompt Injection

OWASP 範圍：使用者輸入 / 外部資料 / RAG retrieved content 中藏指令、影響模型行為。包含 direct injection（user 自己注）跟 indirect injection（內容裡有人塞）。

模組六對應：

• 主章節：6.3 IDE 場景的 prompt injection
• 覆蓋：間接注入（codebase / 第三方依賴 / issue / 剪貼簿 / web fetch）、本地 LLM 跟雲端 LLM 的抵抗能力差異、IDE 場景的具體入口
• 不在 M6 範圍：production agent 場景的 prompt injection 後果（資料外洩 / 誤觸 tool）見 backend/07 LLM agent prompt injection

個人 dev 場景的最低 control：RAG exclude .env / secrets、tool use 加 confirm（見 6.2）、agent loop 設 max steps、untrusted 來源內容明確標記

LLM02 Sensitive Information Disclosure

OWASP 範圍：模型輸出洩漏訓練資料、system prompt、PII、商業機密、API key。

模組六對應：

• 主章節：6.4 跨雲端 / 本地的資料邊界
• 覆蓋：跨雲端 prompt 邊界、第三方 plugin 偷送 prompt、API key 不放在前端 JS
• 補充章節：4.16 靜態 / serverless RAG 資安 的 API key 暴露段、user query 隱私段
• 不在 M6 範圍：企業合規（GDPR / HIPAA / SOC 2）的逐條檢核屬 backend/07

個人 dev 場景的最低 control：本地敏感任務不送雲端、雲端 model 明確標記、API key 從環境變數讀

LLM03 Supply Chain

OWASP 範圍：模型權重、訓練資料、tokenizer、dependency 套件、MCP server 等的供應鏈風險。

模組六對應：

• 主章節：6.0 模型供應鏈與信任邊界
• 覆蓋：GGUF / HuggingFace / Ollama registry 信任、量化版本污染、權重完整性、MCP server 信任
• 補充：4.16 靜態 RAG 資安 的 client-side LLM 模型 CDN 信任段
• 不在 M6 範圍：production 模型 release / SBOM / artifact provenance 屬 backend/07 supply chain

個人 dev 場景的最低 control：選主流作者 / 量化者、下載後 hash 比對、MCP server 跑 sandbox

LLM04 Data and Model Poisoning

OWASP 範圍：訓練資料被植入惡意樣本、fine-tune 資料污染、模型行為後門。

模組六對應：部分覆蓋

• 覆蓋：6.0 模型供應鏈 的「量化版本污染」段、選主流作者的 framing
• 不在 M6 範圍：自己 train base model 或 large-scale fine-tune 的資料治理屬研究 / production team 範圍、見 3.4 訓練流程 概念 + 1.x hands-on local-fine-tune 的小規模 fine-tune 注意事項

個人 dev 場景的最低 control：個人 dev 多用既有模型、threat model 不涵蓋自訓 base、用主流作者降低 poisoning 風險

LLM05 Improper Output Handling

OWASP 範圍：把 LLM 輸出直接餵給下游系統（執行、render、SQL query）、若 LLM 輸出含惡意內容、下游 XSS / SQLi / RCE。

模組六對應：

• 主章節：6.2 tool use 與 MCP server 的權限模型
• 覆蓋：tool 副作用範圍 spectrum、可逆性、confirm 機制
• 補充原理：4.3 tool use 副作用範圍設計
• 不在 M6 範圍：web app 場景的 output sanitization、CSP、render escape 屬一般 web 安全 + backend/07

個人 dev 場景的最低 control：副作用類 tool 加 confirm、shell 命令前 review、git track + diff

LLM06 Excessive Agency

OWASP 範圍：Agent 工具權限過大、副作用範圍超出需求、agent loop 太自主沒人類審查。

模組六對應：

• 主章節：6.2 tool use 權限 + 4.4 Agent 跟人類審查協作
• 覆蓋：sandbox / 白名單 / 副作用可逆性、agent 人類審查 spectrum、coding agent 的 permission boundary（hands-on）
• 補充：4.17 coding agent harness 的 permission boundary 設計

個人 dev 場景的最低 control：副作用 tool 加 confirm、agent max steps、production-level tool 不放在 dev agent 可達範圍

LLM07 System Prompt Leakage

OWASP 範圍：使用者透過 prompt engineering 誘導 LLM 露出 system prompt 內容、暴露商業邏輯 / 提示工程 know-how。

模組六對應：部分

• 覆蓋：4.17 coding agent harness 的 scaffold 設計提到 system prompt 是核心元件、但沒專門講 leakage
• 不在 M6 範圍：sysprompt leak 主要是 production 商業祕密議題、屬 backend/07 / 各 vendor docs

個人 dev 場景的最低 control：不要把 secret（API key、internal info）寫在 system prompt、敏感邏輯放後端而非 prompt

LLM08 Vector and Embedding Weaknesses

OWASP 範圍：Vector DB 被污染、embedding model 被攻擊、retrieval pipeline 被注入毒文件、跨租戶 vector 污染。

模組六對應：部分

• 覆蓋：4.16 靜態 RAG 資安 的「第三方 SaaS 信任」段、跨租戶 isolation 議題
• 補充原理：4.1 RAG 原理 的失敗模式、4.12 embedding model 內部
• 不在 M6 範圍：production multi-tenant vector DB 屬 backend/07 多租戶 isolation

個人 dev 場景的最低 control：RAG ingestion 加 PII / secret filter、vector DB 選 search-only key、不混跨 user vector

LLM09 Misinformation

OWASP 範圍：LLM hallucination 被當真實、使用者過度信任輸出做 critical 決定。

模組六對應：跨章節

• 概念基礎：hallucination 卡
• 評估方法：4.14 benchmarking + 4.21 LLM-as-judge
• 應用層緩解：4.1 RAG（給 LLM 外掛真實知識）、4.4 agent 的人類審查 spectrum
• 不在 M6 範圍：M6 預設 dev 自己驗證輸出、不專章寫

個人 dev 場景的最低 control：critical 任務人類 review、複雜推理用 reasoning model、code 生成必跑 test

LLM10 Unbounded Consumption

OWASP 範圍：Resource exhaustion（context / token / GPU memory 燒爆）、cost runaway（API quota 被偷用 / agent 無限 loop 燒錢）。

模組六對應：部分

• 覆蓋：4.16 靜態 RAG 資安 的「rate limit / abuse」段、靜態前端被 scrape 後燒 LLM quota 的情境
• 補充：4.18 prompt caching（Prompt Cache、cost 控制）、4.4 agent 的 termination（max steps / cost cap）、4.17 coding agent harness 的 budget management
• 不在 M6 範圍：production rate limiting / DDoS 防護屬 backend/07 entrypoint protection

個人 dev 場景的最低 control：agent 設 max_steps / max_cost、API key 不放前端 JS、用 edge function 加 rate limit

速查表

按 OWASP 編號排序、給定 OWASP 項目可快速找對應 control 章節：

跟 backend/07 的分工再述

模組六是「個人 dev 視角」、跟 backend 模組七 資安 是分工關係（6.5 routing-to-production-security 有詳細）：

OWASP LLM Top 10 是兩邊共用詞彙、不限本地或 production。

何時過時 / 何時不過時

不會過時的部分：

• OWASP LLM Top 10 作為企業合規溝通共同詞彙的地位
• 本章 mapping 表的 framing（每個 OWASP 項對應模組六哪章 / 部分覆蓋 / 跨模組）
• 模組六跟 backend/07 的分工

會變的部分：

• OWASP 清單本身（2023 → 2025 → 未來新版、項目可能調整）
• 具體 vendor security audit 的範本（不同 vendor / industry 不同）
• 跟其他 framework（NIST AI RMF、ISO/IEC 42001）的對照

下一步

本章是模組六最後一章。production 多租戶服務化資安見 backend 模組七。

本文是 GCP Cloud Operations 的 vendor deep article，深化 overview「Cloud Logging 結構化 logs」跟「BigQuery 匯出長期儲存」段。初次接觸 GCP 觀測的讀者建議先讀 GCP Cloud Operations 服務頁。

問題情境

Cloud Logging 對 GCP 服務是預設開啟的 — GKE、Cloud Run、Cloud Functions 的 stdout/stderr 自動進 Cloud Logging，工程師不需要配置就能查。問題出在後續階段：log 量成長後的成本控制（GCP 的 ingestion 計費讓高 volume 服務成本快速累積）、合規需求要求特定 log 保留特定時間（healthcare / fintech 的 7 年留存）、organization-level 的 log 聚合與存取控制（多 project 集中 audit）、以及 PII 在 log 中的遮罩與加密。理解 Cloud Logging 的 router / sink 架構跟 retention bucket 才能從「預設全收」走向「可治理的 log pipeline」。

核心概念

Log Router 與 Sink

Cloud Logging 的資料流是 log entry → log router → sink → destination。每一筆 log 進入 Cloud Logging 後，log router 根據 inclusion filter 跟 exclusion filter 決定這筆 log 送到哪些 destination。

Sink 是 log router 的輸出端點。每個 GCP project 預設有兩個 sink：_Required（admin activity audit log、system event，不可關閉）和 _Default（其他所有 log、送到 _Default log bucket、可修改 filter）。工程師可以建立自訂 sink，把符合條件的 log 送到 BigQuery、Cloud Storage、Pub/Sub 或 Splunk。

Exclusion filter 在 log router 層攔截 — 被排除的 log 不會寫入任何 sink destination，也不計入 ingestion 計費。這是成本控制的第一道防線。

Inclusion filter 在 sink 層生效 — 只有符合 filter 的 log 會送到該 sink 的 destination。

路由順序很重要：exclusion filter 先執行（全域攔截），然後 _Required sink 攔走必留 log，然後 _Default sink 跟自訂 sink 各自的 inclusion filter 平行執行。一筆 log 可以同時送到多個 sink。

Retention 與 Log Bucket

Cloud Logging 的儲存單位是 log bucket。每個 project 預設有兩個 bucket：

• _Required bucket：admin activity audit log 跟 system event，保留 400 天，不可刪除或修改 retention
• _Default bucket：其他所有 log，預設保留 30 天，可調整為 1-3650 天

自訂 log bucket 可以設定不同 retention 期。常見用法：把 application log 留 30 天、把 audit log 留 7 年（送到自訂 bucket 或 BigQuery）。

Cloud Logging 的 ingestion 計費跟 storage 計費是分開的。前 50 GiB/month per billing account 的 ingestion 免費；超過後按 ingestion volume 計費。_Required log 的 ingestion 免費。Storage 在 _Default bucket 的前 0.5 GiB 免費，自訂 bucket 按用量計費。

成本治理判讀：高 volume 服務（例如 GKE 的 container stdout）的成本主要來自 ingestion，而非 storage。Exclusion filter 攔掉不需要的 log 是最直接的降成本方式。

查詢語言

Cloud Logging 的查詢語言用在 Logs Explorer 跟 gcloud CLI：

1resource.type="k8s_container"
2resource.labels.cluster_name="prod-us-central1"
3severity>=ERROR
4jsonPayload.order_id="ord-12345"
5timestamp>="2026-06-22T00:00:00Z"

語法特點：field path 用 . 分隔、支援 comparison operators（= / != / > / >= / < / <=）、支援 boolean（AND / OR / NOT）、支援 regex（=~ / !~）。

跟 KQL（Elastic）或 LogQL（Loki）相比，Cloud Logging 查詢語言更接近 structured filter 而非 full-text search。Full-text 搜尋要用 textPayload: 或 jsonPayload: prefix。進階分析（aggregation、time bucketing、join）需要匯出到 BigQuery 後用 SQL 做。

配置 step-by-step

Organization-level log 聚合

多 project 環境下，集中 log 的標準做法是在 organization 或 folder level 建立 aggregated sink：

1gcloud logging sinks create org-audit-sink \
2  bigquery.googleapis.com/projects/central-audit/datasets/org_audit_logs \
3  --organization=123456789 \
4  --include-children \
5  --log-filter='logName:"cloudaudit.googleapis.com"'

--include-children 讓 organization 下所有 project、folder 的符合 log 都送到同一個 BigQuery dataset。Sink 的 service account 需要 destination 的寫入權限（BigQuery Data Editor）。

適用場景：SOC 團隊需要跨 project 的 audit log 查詢、compliance team 需要集中的 data access log 存檔、security team 需要異常 IAM 變更的全域偵測。

Data Access Audit Logs 啟用

GCP 的 audit log 分三類：

• Admin Activity：對資源的管理操作（建立 / 刪除 / 修改 IAM）。預設開啟、不可關閉、不計費。
• Data Access：對資源的讀取操作（BigQuery query、GCS read、Cloud SQL connect）。預設關閉（除 BigQuery）、需手動啟用、計費。
• System Event：GCP 系統自動操作。預設開啟、不可關閉、不計費。

Data Access audit log 的啟用是 per-service、per-project（或 org level）。啟用後 log 量會大幅增加 — 一個高 QPS 的 Cloud SQL 服務可能每秒產生數百筆 data access log。成本跟 volume 判讀要先做。

建議做法：先對 security-sensitive 服務啟用（IAM / KMS / Cloud SQL / GCS），其他服務按需啟用。用 exclusion filter 精細控制 — 例如只保留 ADMIN_READ 跟 DATA_WRITE、排除 DATA_READ（read 量通常遠大於 write）。

VPC Flow Logs 與 DNS Logs 的觀測用途

VPC Flow Logs 記錄每一筆通過 VPC 的網路流量元資料（src/dst IP、port、protocol、bytes、packets）。啟用方式是 per-subnet 設定、支援 sampling rate（100% / 50% / 10%）。

DNS Logs 記錄 VPC 內的 DNS 查詢（query name、response code、source VM）。啟用方式是 per-VPC 或 per-policy 設定。

觀測用途：

• 異常流量偵測：VPC Flow Logs 送到 BigQuery 後用 SQL 找出異常流量模式（大量對外連線、非預期 port、跨 region 資料傳輸）
• 網路效能分析：量測 inter-service latency、跨 AZ 流量比例
• 安全稽核：DNS Logs 偵測 DNS tunneling 或 C2 callback

成本注意：VPC Flow Logs 在高流量服務上的 ingestion 量非常大。100% sampling + 高 QPS 服務可能每天產生 TB 級 log。建議用 sampling rate 控制、或只對 security-sensitive subnet 啟用 100%。

自建 vs managed pipeline 的取捨

Cloudflare 觀測案例展示了自建觀測 pipeline 的理由 — 全球 300+ edge locations、每秒數十億 request 的規模下，SaaS 觀測平台的帳單不合理，自建 pipeline 的 compute 成本反而更低。

但多數團隊的結論是反過來的。GCP 環境下，Cloud Logging 的 managed pipeline（log entry → router → sink → BigQuery / Cloud Storage）幾乎不需要維運人力。自建等價的 pipeline（Fluent Bit → Kafka → Elasticsearch / BigQuery）需要維運 Kafka cluster、Elasticsearch cluster、Fluent Bit DaemonSet 的升級與監控。

判斷分水嶺的兩個維度：

1-10 TB/day 的灰色地帶取決於查詢模式 — 如果 Logs Insights 能滿足 90% 的查詢、BigQuery 能處理剩下 10% 的分析，不需要自建。如果團隊需要 Kibana dashboard、Elasticsearch alerting、或跨 cloud 的統一 log backend，自建可能更合理。

Healthcare 分層 retention 在 GCP 的實現

Healthcare 案例的核心需求是分層 retention — 不同 log 類型有不同的法規留存要求（data access audit log 要 6 年+、application operational log 要 90 天、debug log 要 7 天）。

在 GCP 上用三層架構實現：

Hot 層（Cloud Logging custom bucket）：application log 保留 90 天、audit log 保留 1 年。設定 custom log bucket + retention。優點是 Logs Explorer 直接可查、延遲低。

Warm 層（BigQuery）：audit log sink 到 BigQuery dataset，BigQuery 的 partition expiration 設 2 年。需要分析跟 correlation 時用 SQL 查。成本低於 Cloud Logging storage。

Cold 層（Cloud Storage + Object Lifecycle）：BigQuery 的 scheduled export 或直接 Cloud Logging sink 到 GCS bucket。Object lifecycle rule 把 90 天以上的 object 轉 Nearline / Coldline / Archive class。最終刪除設定在 7 年。

三層各自的 access control 要獨立設定 — cold 層的 GCS bucket 只有 compliance team 有讀取權限，application team 看不到。CMEK 在三層都啟用（Cloud Logging custom bucket 的 CMEK + BigQuery dataset 的 CMEK + GCS bucket 的 CMEK），金鑰由安全團隊集中管理。

PII 治理與 CMEK

Cloud Logging 中的 PII 治理有三層：

第一層：不寫入。Application 端在 log 之前就遮罩 PII（email → ***@***.com、credit card → last 4 digits）。這是最有效的方式，因為一旦寫入 Cloud Logging，即使後續刪除 log entry，在 deletion 前可能已經被 sink 匯出到 BigQuery / GCS。

第二層：log 層過濾。用 exclusion filter 把含 PII 的 log field 排除（例如排除特定 jsonPayload field）。限制是 Cloud Logging 的 exclusion filter 只能排除整筆 log entry，不能 redact 單一 field。需要 field-level redaction 的話，在 OTel Collector 或 Fluentd 層做 processor 處理、再送到 Cloud Logging。

第三層：加密。Cloud Logging 預設用 Google-managed encryption。需要自管金鑰的場景（HIPAA / PCI-DSS / 金融監管）用 CMEK（Customer-Managed Encryption Keys）。CMEK 設定在 log bucket 層 — 自訂 log bucket 可以指定 Cloud KMS key。_Default bucket 也可以啟用 CMEK（需要把 _Default bucket 的 region 從 global 改成特定 region）。

存取控制：Cloud Logging 的 IAM role 分 roles/logging.viewer（讀 log）、roles/logging.privateLogViewer（讀含 data access 的 log）、roles/logging.admin（管理 sink / bucket / filter）。Audit log 的存取用 roles/logging.privateLogViewer、不是一般的 roles/logging.viewer。對應 稽核追蹤與責任邊界 的 GCP 實作。

故障演練與邊界

Exclusion filter 設太寬，重要 log 被丟掉

觸發條件：為了降成本建立 exclusion filter，但 filter expression 太寬泛（例如排除整個 severity=INFO），連帶排除了 business-critical 的 info-level log。

表現：事故時查不到關鍵 log、audit 證據鏈斷裂。因為 exclusion filter 在 ingestion 前執行，被排除的 log 無法回補。

預防：exclusion filter 建立後先用 gcloud logging read 驗證哪些 log 會被排除。用 Logs Explorer 的 preview 功能確認 filter 不會命中關鍵 log。對 audit log 和 security log 不設 exclusion filter。

BigQuery sink 匯出成本失控

觸發條件：org-level aggregated sink 把所有 log 送到 BigQuery，沒有 inclusion filter 限制。

表現：BigQuery storage 跟 streaming insert 成本暴增。一個中型 GKE cluster 每天可能產生 100+ GB 的 container log，全部送 BigQuery 的月成本可能超過 Cloud Logging 本身。

修復：在 sink 加 inclusion filter（只送 audit log 或 error-level log 到 BigQuery）。高 volume 的 application log 送 Cloud Storage（成本更低），需要查詢時用 BigQuery external table 做 federated query。

Log entry size 超過限制

觸發條件：application log 寫入超過 256 KB 的單筆 log entry（Cloud Logging 的 per-entry 上限）。

表現：超過限制的 log entry 被截斷或拒絕寫入。

修復：application 端控制 log entry size — 大型 payload（request body / response body / stack trace）做 truncation 後再 log。需要完整內容的場景，把 payload 寫到 GCS、log 中只留 GCS URI。

容量與成本

成本最佳化優先序：

1. Exclusion filter：攔掉不需要的 log、最直接
2. 降 log level：application 端把 verbose debug log 關掉
3. Sampling：高 QPS 服務的 request log 做 sampling（在 application 端或 OTel Collector 層）
4. BigQuery sink filter：只送需要長期分析的 log 到 BigQuery
5. Cloud Storage sink：高 volume + 低查詢頻率的 log 送 GCS、按需用 BigQuery external table 查

整合與下一步

• GCP Cloud Operations 服務頁：overview 與日常操作
• Cloud Monitoring Metrics Model 與 MQL：同 vendor 的 metrics 面
• 4.12 Audit Log 邊界與 PII 治理：跨 vendor 的 audit log 治理策略
• 4.C1 Fintech audit evidence：審計證據鏈的案例回寫
• 4.C3 Healthcare retention：長期保留的合規設計
• 07 security 模組：data access audit log 的安全面

本章寫作邊界

本章聚焦 production LLM 服務的 log / cache / context 中的 PII 治理特殊性。個人 dev 場景的隱私資料流見 0.7 隱私資料流；通用資料保護見 7.4；資料居住地與刪除證據鏈見 7.8。

本章 threat scope

In-scope：prompt log 累積的 PII、response log 中模型 hallucinate 出的 PII、context cache 跟 KV cache 中的殘留、跨地區資料居住地對應、log 保留期限與刪除證據。

Out-of-scope（路由到他章）:

• 通用資料保護與 masking → 7.4 data-protection-and-masking-governance
• 資料居住地與刪除證據鏈 → 7.8 data-residency-deletion-and-evidence-chain
• 通用 audit log → 通用 audit-log knowledge-card
• multi-tenant log 隔離 → llm-multi-tenant-isolation
• 偵測訊號 → llm-as-service-detection-coverage

從本章到實作

• Mechanism：問題節點表 → knowledge-card。
• Delivery：交接路由 → 05-deployment-platform / 08-incident-response。

LLM 服務的 log 載體

LLM 服務累積的 log / cache 比一般 service 多幾類載體：

跟一般 service 的差異點：Prompt log / Response log 是新類別、它們含的不是 API meta-data、是使用者實際的「想法 / 內容」、隱私敏感度遠高於一般 API log。

分析模型

LLM log 治理依四個階段分析：

1. 累積階段：哪些載體會累積什麼內容、累積速率多大。
2. 儲存階段：儲存位置（DB / S3 / SIEM）、加密、訪問權。
3. 保留階段：保留期限、保留期內的訪問規則。
4. 刪除階段：刪除觸發條件、刪除證據鏈、合規對應。

判讀流程

判讀流程的責任是把「LLM 服務的 log」轉成「合規可審計的 log」。

1. 先盤點所有 log / cache 載體跟對應內容。
2. 再確認 PII 偵測 / masking 在累積階段是否生效。
3. 接著確認儲存跟訪問權跟一般資料保護一致。
4. 最後確認保留期限跟刪除證據鏈跟資料居住地對齊。

問題節點（案例觸發式）

常見風險邊界

風險邊界的責任是界定何時 LLM log 治理已進入高壓狀態。

• Prompt log 含未 mask 的 PII 時、代表 PII 治理在累積階段失效。
• KV cache / context cache 跨 tenant 共用時、代表 isolation 失效（亦見 llm-multi-tenant-isolation）。
• log 保留期限跟資料居住地政策不一致時、代表治理流程不收斂。
• 客戶刪除請求無法產生證據鏈時、代表合規對應失效。

LLM 場景的特殊判讀

LLM log 治理相對一般資料保護的特殊性：

1. Prompt 跟 Response 比 API log 隱私敏感度高一個量級：一般 API log 主要記 endpoint / status / latency、prompt log 記的是使用者實際「在問什麼」、Response log 是模型「在說什麼」。
2. 模型 hallucinate 的 PII 也是 PII：LLM 生成虛構的姓名 / 電話 / 地址、即使不對應真人、也屬於 PII 處理範圍、需要對應的 masking 跟保留政策。
3. KV cache 是非典型 log 載體：傳統 log 治理工具不掃 GPU memory / RAM cache、但這些 cache 可能跨 request / 跨 tenant 殘留 PII；需要 inference engine 配合做 cache 清理。
4. RAG context 是雙向載體：RAG 既把 corpus 注入 prompt（corpus 中的 PII 進 log）、也把 user query 注入 corpus（user query 變 future retrieval 的對象）；治理範圍要覆蓋雙向。
5. vendor 政策直接影響合規承諾：用雲端 LLM 時、vendor 的 log 保留政策（如 30 天 abuse log）直接限制自家對下游客戶能承諾的最短保留期、合約鏈要對齊。
6. abuse detection 跟 PII 治理的張力：abuse detection 需要 log prompt（看 abuse pattern）、PII 治理要求 minimize、兩者要在 mask 後 detection 跟全文 detection 中找平衡。

防禦設計的核心原則

1. 累積階段做 PII detection + masking：log 寫入前過 PII detector、敏感欄位 mask 或不 log。
2. 儲存階段加密 + 訪問權對齊 IAM：跟一般敏感資料一致。
3. 保留期限明確 + 自動刪除：用 policy-driven 自動 lifecycle、不依賴人工。
4. KV cache / context cache 跨 tenant 清理：inference engine 配合、tenant boundary 明確。
5. 刪除證據鏈：客戶刪除請求觸發時、產生 audit trail、能證明已刪除所有副本（包含 backup / log archive）。
6. vendor 政策對齊：用雲端 LLM 時、vendor 的條款拉進自家政策一致審視。

案例觸發參考

LLM log 治理的公開案例累積中、值得追蹤的方向：

• 大型 LLM vendor 的 log 政策變更引發的合規震盪
• 模型 hallucinate 出真人 PII 的訴訟案例
• KV cache 跨用戶洩漏的 incident 報告

LLM-specific 案例累積後會補入 red-team/cases/llm-log-pii/。一般資料保護案例見 7.4 data-protection-and-masking-governance 跟 7.8 data-residency-deletion-and-evidence-chain。

事實查核註：LLM log / PII 議題的具體 incident 跟法律判例累積還在早期、各 vendor 政策跟監管要求依時段快速變化、建議引用前以最新的監管文件（GDPR、CCPA、AI Act 等）跟 vendor 當前政策為準。

引用標準

引用版本與 cadence 規則見 security-citation-currency-and-precision。Last reviewed: 2026-05-12。

下一步路由

• 通用資料保護：7.4 data-protection-and-masking-governance
• 資料居住地與刪除：7.8 data-residency-deletion-and-evidence-chain
• 多租戶 isolation：llm-multi-tenant-isolation
• 偵測訊號：llm-as-service-detection-coverage
• 事件案例工作流：7.10 incident-case-to-control-workflow