合規工作從解讀要求開始
「我們要符合 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、刪除與存取權限。
集中式 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 都能刪，稽核文件寫得再漂亮也沒有用。
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。
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。至少要分開問：
- Storage：primary data、replica、backup 和 log 存在哪裡？
- Processing：job、query 和 temporary data 在哪裡處理？
- Access：哪些地區或人員能提供支援、管理和讀取？
- 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 和資料匯出流程一起驗證。
建立 evidence matrix
每一個 control objective 都應對應 evidence，而不是只截一張 Console 圖：
| Control objective | 實作 | 可查證 evidence | Owner／頻率 |
|---|---|---|---|
| Production IAM 變更可追蹤 | Admin Activity logs + 集中 sink | 每月 IAM change query、sink health | Security，每月 |
| 敏感資料讀取可追蹤 | Data Access logs | 指定 dataset 的 read events、抽樣複核 | Data owner，每季 |
| 資源只建於允許區域 | Org Policy + deployment policy | Policy definition、violation logs、asset inventory | Platform，持續 |
| Google personnel access 可見 | Access Transparency | Access reason、resource、approval linkage | Compliance，每月 |
| 日誌不被一般管理員修改 | 專用 logging project + IAM | Effective IAM、retention／lock config | Security，每季 |
Evidence 也需要測試。例如刻意做一個會被 policy 拒絕的 request，確認 log 真的進到中央 destination，而且值班人員找得到。
情境練習：受監管的醫療 SaaS
假設產品會處理美國病患的 PHI：
- 和法務確認 BAA，並只使用 BAA 涵蓋且符合架構需求的 services。
- 由 compliance owner 建立 control matrix，不把 HIPAA 簡化成「CMEK + 美國 region」。
- 盤點 PHI data flow、backup、support tools、analytics 和 subprocessors。
- 評估合適的 Assured Workloads control package，確認每個 service 支援，而不是假設整個 folder 裡什麼都能用。
- 啟用需要的 Data Access logs，建立 aggregated sink 到受控 logging project。
- 依正式 retention policy 設定 log bucket／archive，分離 log writer、viewer 和 config admin。
- 若需要控制 Google personnel access，確認 Access Transparency／Approval 的 supported services 和 emergency behavior。
- 每季抽樣測 IAM change、PHI read、policy denial、log routing 和 access approval evidence。
這樣稽核時交付的是「要求、控制、證據、測試結果和例外」，不是一串產品名稱。
本課檢查清單
- 合規要求要由法務／合規 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
下一步
下一課會把身分、裝置、應用、網路和資料控制串成零信任架構，並練習怎麼避免新的旁路與單點失效。
