合規框架與稽核設計

合規工作從解讀要求開始

「我們要符合 GDPR，所以資料全部放歐洲」聽起來很果斷，卻可能把法律、契約和技術混在一起。架構師不應自行替法規下法律結論，而是和法務、資安、資料 owner 共同把要求拆成：

• Scope：哪些系統、資料、使用者和供應商在範圍內？
• Control objective：要降低什麼風險，或證明什麼責任？
• Implementation：用 IAM、加密、日誌、流程或其他控制完成。
• Evidence：稽核時拿什麼證明控制在指定期間有效？
• Owner：誰監看、誰核准例外、誰定期複查？

Google Cloud 的 compliance certification 能協助供應商評估，但不會讓部署在上面的應用自動合規。Shared responsibility 的重點，就是把 Google 負責的證據與客戶自己的控制證據接起來。

Cloud Audit Logs：先分清楚四種類型

Google Cloud 提供四類 audit logs：

• Admin Activity：修改 resource configuration 或 metadata 的管理操作。
• Data Access：讀取 configuration、metadata 或 user-provided data，以及資料寫入操作。
• System Event：Google system 對 resource 執行的管理動作。
• Policy Denied：請求因 security policy 被拒絕。

Admin Activity 和 System Event 不能停用，會進 _Required log bucket；Data Access 多數服務要明確啟用，但有 service-specific exceptions；Policy Denied 與 Data Access 通常進 _Default 或依 routing 設定處理。要知道誰讀過 BigQuery table，不能只查 Admin Activity，應確認該服務的 Data Access audit logging 行為。

Retention 看 bucket，不只看 log type

目前 _Required bucket 預設保留 400 天且不可調整；_Default 和 user-defined buckets 一般預設 30 天，project 中的 bucket 可依支援範圍調整 retention。正式設計應查 Cloud Logging retention，再依法律、契約、調查需求和成本決定。

不要看到某框架就自行填「一定保留七年」。應由合規 owner 定義 retention schedule，並說明不同 log 的保存目的、legal hold（遇到訴訟或調查時暫停刪除）、刪除與存取權限。

flowchart TD
  E["Google Cloud operation／event"] --> T{"Audit log type"}
  T -->|"Resource／metadata 管理變更"| A["Admin Activity"]
  T -->|"資料或 configuration 讀寫"| D["Data Access<br/>多數服務需明確啟用"]
  T -->|"Google system 管理動作"| S["System Event"]
  T -->|"Security policy 拒絕"| P["Policy Denied"]
  A --> R["_Required bucket<br/>固定 retention 規則"]
  S --> R
  D --> B["_Default／user-defined bucket<br/>依 service 與 routing 設定"]
  P --> B
  R --> K["Aggregated sink／查詢／evidence"]
  B --> K
  O["Compliance owner<br/>定義 retention、legal hold、access"] --> K

集中式 logging 要處理完整性和可用性

常見架構是在 organization 或 folder 建 aggregated sink，把子層 logs 路由到專用 logging project。目的不只是方便查詢，也是在 workload administrator 與 audit evidence 之間建立職責分離。

可以依用途選 destination：

• Log bucket：Logs Explorer、Log Analytics、field-level access 和可調 retention。
• BigQuery：長期 SQL 分析、稽核報表或跨資料集關聯。
• Cloud Storage：歸檔與外部處理，查詢便利性較低。
• Pub/Sub：送往 SIEM（集中分析資安事件的平台）或即時處理 pipeline。

設計時要確認：

• Aggregated sink 是否真的包含 children，filter 有沒有漏掉重要 log。
• Sink writer identity 是否有 destination permission。
• 路由只影響建立後的新 log，歷史資料是否需要另外保存。
• 日誌中是否含 PII／secret，viewer 與 private log access 如何分離。
• Log volume、ingestion failure、exclusion 和 destination quota 是否有監控。
• Retention lock 一旦鎖定就難以縮短，是否經過 legal 與 data governance 核准。

日誌若沒進 destination、查不到或任何專案 owner 都能刪，稽核文件寫得再漂亮也沒有用。

flowchart LR
  O["Organization／Folder"] --> S["Aggregated sink<br/>include children＋filter"]
  P1["Workload Project A"] --> S
  P2["Workload Project B"] --> S
  S --> W["Sink writer identity<br/>具 destination write permission"]
  W --> L["專用 Logging project<br/>職責分離"]
  L --> B["Log bucket<br/>搜尋與 retention"]
  L --> Q["BigQuery<br/>稽核分析"]
  L --> G["Cloud Storage<br/>archive"]
  L --> U["Pub/Sub<br/>SIEM／stream processing"]
  M["Route health<br/>volume、exclusion、quota、failure"] -. "監控" .-> S
  M -. "監控" .-> L
  A["Audit viewer／config admin<br/>分離 IAM"] --> L

Access Transparency 與 Access Approval

Cloud Audit Logs 主要記錄客戶 organization 中 principals 的操作；Access Transparency 記錄 Google personnel 對 customer data 的受管存取，包含 resource、action、time、reason 和 accessor 相關資訊。

Access Approval 則讓支援的 Google personnel access 先經客戶核准。核准後仍需符合 Google 內部的 privileged access control，並可在 Access Transparency log 中關聯 approval request。

兩者都要注意 supported services、subscription／eligibility 和 exclusions。嚴格 emergency criteria 下可能出現 auto-approved access，但仍留下記錄；Access Transparency 對某些服務和存取也有已知限制。不能把「已啟用」寫成「任何 Google 存取都絕不可能未經人工核准」。應依 supported services 和 Access Approval exclusions 建立實際 control statement。

sequenceDiagram
  autonumber
  participant G as Google personnel
  participant A as Access Approval
  participant P as Google privileged access controls
  participant R as Customer resource
  participant T as Access Transparency
  G->>A: 對支援服務提出 access request
  alt 需要且支援 customer approval
    A-->>A: 通知 customer approver
    A-->>G: Approved／denied／expired
  else Exclusion 或符合嚴格 emergency criteria
    A-->>G: 依支援行為處理並保留狀態
  end
  G->>P: 通過 Google 內部 privileged access control
  P->>R: 執行受管 access
  R-->>T: 記錄 resource、action、time、reason、accessor
  A-->>T: 關聯 approval request／狀態
  T-->>A: 提供 customer audit evidence

Assured Workloads 是 control package，不是合規按鈕

Assured Workloads 會在 folder 套用並監看 regional、regulatory 或 sovereign control package，可能包含 resource location、personnel access、key management、service usage 和 violation monitoring。

採用前要確認：

• 目標 control package 目前支援哪些 products 和 regions。
• Free／Premium tier、support 與 personnel control 的條件。
• 現有 projects／resources 如何遷移，哪些不符合 control package。
• Workload updates 如何 review 與套用。
• Violation 由誰處理，例外由誰核准。

Control package 協助實作一組 baseline controls，仍不會替你的 application、資料處理流程和人員作業完成所有合規責任。詳情以 Assured Workloads control packages 為準，避免在課程裡背一張很快過期的框架清單。

資料位置要拆成四個問題

Data residency 不只是 resource 建在哪個 region。至少要分開問：

1. Storage：primary data、replica、backup 和 log 存在哪裡？
2. Processing：job、query 和 temporary data 在哪裡處理？
3. Access：哪些地區或人員能提供支援、管理和讀取？
4. Transfer：資料能否跨 boundary，經過哪些第三方與 subprocessors（供應商再委託處理資料的下游廠商）？

constraints/gcp.resourceLocations 可以限制支援資源建立的位置，但有幾個重要界線：

• 只對支援的 services／resource types 生效。
• 一般不會把既有 resource 自動搬走，也不是完整的 retroactive control。
• global、multi-region 和 value group 的涵蓋範圍要看服務定義。
• 它限制 resource location，不等於限制 network path、support personnel location 或所有 metadata。

所以實作資料位置要求時，要把 Organization Policy、service-specific location、Assured Workloads、key location、support access 和資料匯出流程一起驗證。

flowchart TD
  R["正式 data location requirement"] --> S["Storage<br/>primary、replica、backup、log"]
  R --> P["Processing<br/>job、query、temporary data"]
  R --> A["Access<br/>support、admin、reader location"]
  R --> T["Transfer<br/>跨境、第三方、subprocessor"]
  S --> C["Service location＋resource location policy<br/>Assured Workloads／key location"]
  P --> C
  A --> C
  T --> C
  C --> V["Asset inventory、policy violations<br/>access logs、export evidence"]
  V --> Q{"四個面向都符合<br/>法務核准的 control statement？"}
  Q -->|"否"| G["補 control 或正式例外<br/>不自行改寫法律需求"]
  G --> C
  Q -->|"是"| E["持續監控與定期複查"]

建立 evidence matrix

每一個 control objective 都應對應 evidence，而不是只截一張 Console 圖：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Evidence 也需要測試。例如刻意做一個會被 policy 拒絕的 request，確認 log 真的進到中央 destination，而且值班人員找得到。

flowchart TB
  R["法律／契約／內部要求"] --> S["Scope<br/>system、data、user、supplier"]
  S --> O["Control objective<br/>要降低或證明什麼"]
  O --> I["Implementation<br/>IAM、policy、encryption、process"]
  I --> E["Evidence source<br/>query、config、<br/>approval、inventory"]
  E --> T["Control test<br/>negative request、<br/>sample、route failure"]
  T --> V{"期間內 evidence<br/>完整、可查且有效？"}
  V -->|"否"| G["Gap／exception<br/>owner、priority、<br/>due date"]
  G --> I
  V -->|"是"| A["Audit package<br/>retention＋owner＋<br/>review frequency"]
  A --> N["持續監控變更<br/>進入下一個 review period"]
  N --> T

情境練習：受監管的醫療 SaaS

假設產品會處理美國病患的 PHI（Protected Health Information），也就是能對應到特定病患的健康資料，在美國受 HIPAA 規範。雲端供應商要代你處理 PHI，得先簽 BAA（Business Associate Agreement）。這份合約寫明對方怎麼保護這些資料。

先別展開。花 5 分鐘列出你會做的步驟，並標出哪幾步不是架構師自己能決定的，再對照。

課後檢查

往下看重點之前，先試著回答這幾題；答不出來，括號裡是該回去重讀的那一節。

• 要查誰讀過某張 BigQuery table，為什麼只看 Admin Activity 不夠？（回〈Cloud Audit Logs：先分清楚四種類型〉）
• Access Transparency 和 Access Approval 各補上哪一段控制？為什麼不能寫成「Google 的存取一定先經過人工核准」？（回〈Access Transparency 與 Access Approval〉）
• 設了 resource location constraint，為什麼還不能說 data residency 做完了？（回〈資料位置要拆成四個問題〉）

本課重點

• 合規要求要由法務／合規 owner 解讀，架構師負責把 control objective 實作並產生 evidence。
• Audit Logs 有四類；Data Access 的預設與內容要按 service 確認。
• Retention 由 log bucket 與 policy 決定，不要從法規名稱猜固定年限。
• Aggregated sink 要驗證 include-children、filter、writer identity、destination 和失敗監控。
• Access Transparency 提供 Google personnel access 可見性；Access Approval 增加事前控制，但有支援範圍與例外。
• Assured Workloads 套用 control package，不會讓應用自動合規。
• Resource location constraint 不是完整的 data residency、processing 或 transfer 控制。

延伸閱讀

• Cloud Audit Logs overview
• Access Transparency overview
• Assured Workloads overview
• Restrict resource locations

下一步

下一課會把身分、裝置、應用、網路和資料控制串成零信任架構，並練習怎麼避免新的旁路與單點失效。