Google PCD: 身分、驗證與應用程式安全 — 學習指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

屬於 Google Professional Cloud Developer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

授權、API 與邊界安全

應用程式授權
- 角色型檢查：簡單、快速，但較粗略。屬性型存取控制 (ABAC) 則使用使用者屬性、資源屬性與情境 (時間、裝置狀態) 來進行更精細的決策。
- 將政策評估集中化，或使用 sidecar/OPA；在微服務之間一致地傳遞身分與租戶宣告。
- 多租戶模式
  - 將 tenant_id 嵌入驗證權杖中，並在每個資料存取路徑強制執行；使用資料列層級篩選或為每個租戶使用獨立的資料集，以達到嚴格隔離。
  - 若法規要求隔離，可考慮為每個租戶使用專屬的服務帳戶或 KMS 金鑰。
- 失效模式
  - 因缺少租戶檢查而導致不安全的直接物件參考 (IDOR)。各服務間的授權邏輯分歧，造成執行不一致。
安全的 API 設計
- 驗證並正規化所有輸入；拒絕過大的酬載。強制使用強型別的內容類型。對檔案上傳進行威脅建模；對大型物件使用簽署的 URL。
- 速率限制與配額：使用 Cloud Armor 的速率限制或 Apigee 來緩解濫用與 429 錯誤。在用戶端實作帶有 jitter 的指數退避。
- CORS
  - 回傳最小範圍的 Access-Control-Allow-*；在有憑證的請求上避免使用萬用字元來源。預檢快取可減少延遲。
- CSRF 防禦
  - 優先選擇無狀態的 API，並在 Authorization 標頭中使用 bearer token。對於基於 cookie 的會話，請使用 SameSite=strict 或 lax、安全 cookie，以及 CSRF 權杖 (double-submit 或 synchronizer)。
- 範例 (Cloud Armor 規則)：
  - gcloud compute security-policies rules create 1000 –security-policy web-policy –expression “request.path.matches(’/api/’)” –action rate_based_ban –rate-limit-threshold-count 100 –rate-limit-threshold-interval-sec 60
- 失效模式
  - 單純基於 IP 的限制可被 IPv6 或代理伺服器繞過。過於寬鬆的 CORS 設定會導致權杖洩漏。缺少 CSRF 權杖與 cookie 搭配使用，會讓會話騎劫 (session riding) 成為可能。
網路控制與資料邊界
- 使用階層式防火牆政策與 VPC 防火牆規則；當服務位於 HTTP(S) Load Balancing 後方時，允許來自 Google Front Ends 的健康狀態檢查。
- 範例：
  - gcloud compute firewall-rules create allow-lb –network prod –allow tcp:80,tcp:443 –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
- Cloud Armor 提供 WAF、機器人防禦以及地理/IP 限制；調整規則並檢視誤報 (false positives)。
- Private service access 提供與 Google 代管服務 (例如 Cloud SQL、Memorystore) 的私有 IP 連線；避免公開的出口流量與 IP 允許清單。
- VPC Service Controls 透過在支援的服務周圍建立邊界來降低資料外洩風險；可與 Access Context Manager 結合，以加入裝置/位置的情境脈絡。
- 失效模式
  - 設定錯誤的邊界會阻擋 CI/CD 或中斷服務對服務的呼叫。缺少 PSA 配置會導致無法附加私有 IP。過於嚴格的 WAF 規則可能引發可用性事件。

供應鏈安全、記錄與應變

軟體供應鏈安全
- 將產物儲存在 Artifact Registry；強制執行漏洞掃描。當發現高/嚴重等級的 CVEs 時，建置應失敗，並追蹤政策例外情況。
- 鎖定依賴項目與基礎映像檔的版本；避免使用「latest」標籤。產生並驗證 SBOMs。使用 Binary Authorization 要求在部署前必須使用已簽署的映像檔。
- 使用 Cosign 簽署映像檔並記錄來源證明；採納符合 SLSA 規範的建置實務。為 CI 使用 Workload Identity Federation 以消除 JSON 金鑰。
- 故障模式
  - 未鎖定版本的依賴項目會拉取到有漏洞的版本。跳過來源證明會讓映像檔可能被竄改。在 CI 日誌中儲存 registry 憑證或服務帳戶金鑰會洩漏密鑰。
安全記錄與監控
- 為關鍵專案與服務啟用「管理員活動」與「資料存取」稽核日誌。將日誌路由到一個存取受限的專用專案。
- 針對驗證失敗、權限拒絕及政策評估錯誤建立 Cloud Logging 指標；透過 Cloud Monitoring 發出警報。
- 範例（自訂計數器指標概念）：計算 /api/* 路徑的 401/403 錯誤率，並在偏離基準線時發出警報。
- 威脅分類與修復
  - 使用 Security Command Center 匯總發現項目；為關鍵情境（金鑰外洩、暴力破解、異常的 IAM 變更）建立應變劇本。
  - 自動化常見的修復措施（撤銷權杖、停用金鑰、輪替密鑰、隔離服務帳戶）。
- 具備隱私意識的設計
  - 最小化 PII（個人可識別資訊）；盡可能將其權杖化。從日誌中遮蓋敏感值；使用 Cloud DLP 進行分類。套用最短保留期與區域性儲存政策。
- 故障模式
  - 停用「資料存取」日誌會使偵測資料外洩變得不可能。高基數標籤會導致成本暴增。在日誌中記錄密鑰會造成持久性的曝險。

實務問題情境

Acme Retail 公司在 Cloud Run 上建置一個多租戶分析入口網站，包含一個 React 前端、一個 Python API，以及每個租戶專屬的 BigQuery 資料集。需求包括為員工和客戶提供 SSO、租戶隔離、密鑰與金鑰管理、私有資料庫存取、WAF 與速率限制，以及一個不使用長期有效金鑰的強健 CI/CD 態勢。

方法：

建立身分並遵循最低權限原則

為每個微服務（api-sa、ingest-sa）建立一個專屬的 Google 服務帳戶。在專案或資料集層級授予最低權限角色（例如，在租戶資料集上授予 roles/bigquery.dataEditor）。
理由：每個服務使用獨立的 SA 可限定爆炸半徑並簡化輪替；範圍狹窄的角色可減少橫向移動的風險。

為 CI/CD 使用 Workload Identity Federation

設定 GitHub Actions OIDC，透過 roles/iam.workloadIdentityUser 和 roles/iam.serviceAccountTokenCreator 來模擬 deployer-sa。使用模擬權杖部署到 Cloud Run。
理由：從 CI 中移除 JSON 金鑰；短期有效的憑證可降低被竊風險。

前端與使用者驗證

在 Cloud Run 服務前方的 HTTPS 負載平衡器上設定 IAP。整合 Google 作為員工的 IdP，並透過聯邦機制整合客戶的 IdP。使用「IAP-secured Web App User」角色將存取權限限制於授權的群組。
理由：為瀏覽器應用程式提供集中式驗證；服務中不需包含驗證邏輯；支援 SSO。