滲透測試與弱點掃描 (Penetration Testing and Vulnerability Scans)

GCP 安全性測試簡介

在雲端環境中，安全性是一項共同責任。雖然 Google 負責基礎設施的安全，但你必須負責應用程式和資料的安全。安全性測試 (Security Testing) 是主動尋找雲端環境弱點的實踐。這包括弱點掃描 (Vulnerability Scanning)（自動化探索）和滲透測試 (Penetration Testing)（模擬手動攻擊）。

對於 GCP Professional Cloud Architect 來說，目標是將安全性測試整合到軟體開發生命週期 (SDLC) 中，確保在弱點被利用之前就被發現。

白話文解釋安全性測試 (Security Testing)

比喻 1 — 居家保全系統

弱點掃描就像有一個自動化機器人每天晚上在你的房子周圍走動，檢查是否有門窗沒鎖。它速度很快且覆蓋面廣。滲透測試則像是僱用一名專業鎖匠，嘗試真正地「闖入」你的房子。他們會尋找巧妙的方法來繞過機器人可能忽略的鎖。

比喻 2 — 體格檢查與壓力測試

弱點掃描就像是例行體檢。醫生檢查你的血壓、心率和基本健康指標（標準弱點）。滲透測試則像是心臟壓力測試。醫生讓你跑跑步機，觀察你的心臟在極端壓力下的表現，以發現隱藏的弱點。

比喻 3 — 城堡圍牆

你可以建造世界上最厚的圍牆，但如果後門開著，城堡就不安全。弱點掃描確保門是關著的。滲透測試則檢查是否有人可以挖地道穿過圍牆，或者使用你沒看到的梯子爬過圍牆。

GCP 上的關鍵安全性測試工具

1. Security Command Center (SCC)

SCC 是 Google Cloud 的集中化安全性管理和風險平台。

• 弱點管理： 自動掃描常見的錯誤配置（例如：公開的儲存桶、開放的防火牆連接埠）和軟體弱點。
• 事件威脅偵測 (Event Threat Detection)： 監控日誌以尋找活動攻擊的跡象（例如：暴力破解、惡意軟體）。

2. Cloud Security Scanner

一種專門用於對 App Engine、GKE 和 Compute Engine 應用程式進行 Web 安全性掃描 (DAST) 的工具。

• 掃描項目： XSS、明文密碼、過時的程式庫和混合內容。
• 注意： 它僅掃描公開的 URL 或在 VPC 內可連達的 URL。

3. Container Analysis

作為 CI/CD 流水線的一部分，自動掃描 Artifact Registry 中的容器映像檔，以尋找已知的弱點和漏洞 (CVEs)。

規劃滲透測試

Google Cloud 允許你在不預先通知的情況下對自己的資源進行滲透測試，但你必須遵守某些規則：

• 不影響他人： 你不能攻擊 Google 的基礎設施或其他客戶的資源。
• 法律合規： 你必須遵守 Cloud 資料處理補充條款 (CDPA) 和其他服務條款。
• 第三方掃描器： 如果使用第三方工具（如 Burp Suite 或 Nessus），請確保它們配置為僅針對你特定的專案 ID 和 IP 地址。

授權測試交戰規則 (Rules of Engagement, RoE)

在對 GCP 資源進行任何滲透測試之前，架構師必須簽署一份 Rules of Engagement 文件，讓法務、安全與平台團隊就測試範圍達成共識。RoE 是防止測試被誤判為真實攻擊、進而觸發自動化事件回應的關鍵文件。

RoE 必備條款（GCP 情境）

• 以專案 ID 與 CIDR 圈定範圍： 列出明確在範圍內的 projects/<id> 與外部/內部 IP 範圍。範圍之外（含 Shared VPC host project，除非明確納入）皆禁止測試。
• 測試時段： 定義 UTC 起訖時段。時段之外，從測試者來源 IP 發出的流量會被視為惡意流量，可能觸發 Cloud Armor 自動封鎖或 Event Threat Detection 偵測結果。
• 來源 IP 白名單： 記錄測試者的來源 IP，讓 SOC 能關聯掃描器流量。部分團隊會在測試時段把這些 IP 加入 Cloud Armor edge-security policy 白名單，避免誤報。
• 資料處理規則： 規範測試者可否帶走樣本資料、含 PII 的截圖或 Secret Manager 內容。正式環境資料通常需要遮罩或以合成資料取代。
• 緊急停止聯絡人： 指定一位 Google Cloud 管理員，可透過 gcloud projects remove-iam-policy-binding 立即撤銷測試者 IAM 權限。

測試前檢查清單

1. 對 Persistent Disk 與 Cloud SQL 執行快照，破壞性測試後可回復。
2. 將所有測試資源打上 pen-test=true 等標籤，方便在 Cloud Logging 過濾日誌。
3. 通知 on-call SRE 輪值人員；若測試流量會超過 1 Gbps，部分組織會另行通知 Google Support（避免被誤判為 DDoS）。
4. 與法務確認 CDPA 與客戶合約允許此次測試。

Web Security Scanner（免費層級）

Web Security Scanner 是 GCP 原生的 DAST 工具，前身為 Cloud Security Scanner。它是 web app 弱點掃描中成本最低的入門選項，包含在 Security Command Center Standard 層級中。

可掃描範圍

• 架在 App Engine、Compute Engine 或 GKE 上的公開 URL
• 位於 VPC 內、可被掃描器工作池連達的內部 URL（透過 Custom scans）
• 透過 Google 帳號、非 Google 帳號或自訂登入流程的已驗證區域

可偵測的弱點類型

• 跨網站指令碼 (XSS) — 反射型與儲存型
• 混合內容 (Mixed content)（HTTPS 頁面載入 HTTP 資源）
• 過時函式庫 (Outdated libraries) 含已知 CVE（jQuery、AngularJS 等）
• 明文密碼表單 透過 HTTP 傳輸
• 不安全的 Cookie 缺少 Secure 或 HttpOnly 旗標
• Flash injection（傳統）

掃描模式

• Managed scans（Premium 層級）— 每週自動發現並掃描公開的 App Engine 應用，無需設定。
• Custom scans — 自行指定起始 URL、認證、黑名單樣式、User-Agent。適合在正式部署前掃描 staging 環境。

考試常考的限制

• 無法測試 僅有 API 的後端（沒有 UI 可爬）— 改用第三方 DAST 或 SAST。
• 不會執行 破壞性測試，例如會改動資料的 SQL injection。
• 不支援 已驗證 GraphQL mutation。
• 有速率限制；建議搭配 Cloud Armor rate-limiting 規則，避免掃描器流量自己觸發 WAF。

第三方 DAST：Burp Suite 與 OWASP ZAP

當 Web Security Scanner 深度不足時，架構師會引入 Burp Suite Professional 或 OWASP ZAP。兩者皆可對 GCP 工作負載運行，但必須謹慎設定以符合 RoE。

部署模式

• 從測試者筆電： 最快速。公開 IP 須列入 Cloud Armor 白名單。適合外部攻擊面測試。
• 從 VPC 內的 GCE 跳板機： 測試內部負載平衡器、INTERNAL ingress 的 Cloud Run、或私有 IP 的 GKE Service 時必要。在測試者 subnet 開一台強化過的 e2-standard-4 VM，安裝 Burp/ZAP，透過 IAP TCP tunneling（gcloud compute start-iap-tunnel）連入。
• 從 Cloud Build 做 CI/CD DAST： 在 Cloud Build step 使用官方 ZAP image，於每次部署時對 staging URL 做 baseline scan。發現 High 等級即讓 build 失敗。

必要設定

• Target scope 鎖定自家網域/IP，避免誤打到其他租戶。
• 節流： 限制併發請求，避免被自家 Cloud Armor rate-based ban。
• 認證錄製： 使用 Burp session handling rules，先透過 Identity Platform 或 IAP 登入再 fuzz。
• 結果匯出： 將 JSON 結果推到 Cloud Storage bucket，再透過 SCC API 以 custom findings 匯入 Security Command Center。

Container Threat Detection (CTD)

Container Threat Detection 是 Security Command Center Premium 提供的服務，於執行階段監控 GKE 節點行為，補足 Container Analysis 的映像檔掃描。

偵測訊號

• Added Binary Executed — 執行了原始 image 內沒有的新 binary（典型 post-exploit 指標）。
• Added Library Loaded — 載入了 image 內沒有的 shared library。
• Reverse Shell — 行程將 stdin/stdout 重導向遠端 socket。
• Suspicious Shell Activity — 針對 crypto-miner 與已知攻擊工具的啟發式規則。
• Execution: Added Malicious Binary — hash 比對命中已知威脅情報來源。

運作方式

每個 Container-Optimized OS (COS) 節點上會跑一個 kernel-level instrumentation。事件串流到 SCC，以 THREAT finding 形式呈現。無需 sidecar，也沒有 per-pod 設定負擔。

啟用方式

1. 使用 Container-Optimized OS 節點映像（GKE Autopilot 與大多數 Standard cluster 預設值）。Ubuntu image 不支援 CTD。
2. 啟用 GKE Security Posture 儀表板。
3. 在 SCC 上於組織或專案層級啟用 Container Threat Detection 服務。

CTD 不涵蓋的範圍

• Cloud Run 工作負載 — 沒有 runtime 可視性；改靠 Cloud Logging 與 image scanning。
• GKE on-prem / Google Cloud 以外的 Anthos cluster — 改用 GKE Enterprise 安全功能。
• 部署前的 image 弱點 — 那是 Container Analysis 的職責。

Container Analysis 弱點掃描

Container Analysis 持續掃描 Artifact Registry（與舊版 Container Registry）中的容器映像，找出已知 CVE。它是 GCP 上 shift-left CVE 管控的核心服務。

兩種掃描模式

• On-push scanning — 每個新推送的 image 掃描一次，結果快取。
• Continuous scanning — 過去 30 天內被 pull 過的 image，會在上游資料庫出現新 CVE 時重新掃描。這就是發布後才出現的 CVE 仍能被你抓到的原因。

OS 與語言支援

• OS 套件： Debian、Ubuntu、Alpine、CentOS、RHEL。
• 語言套件： Go、Java (Maven)、Python (PyPI)、Node.js (npm)。支援度持續擴大 — 考前確認最新文件。

與 Binary Authorization 整合

這是考試最常出的模式：Container Analysis 結果餵給 Binary Authorization attestor。GKE admission controller 拒絕部署任何沒有「no critical CVE」attestation 的 image。這是 GCP 認可的「production 不放有弱點 image」實作 — 比週期性掃描強得多。

值得背的 gcloud 指令

• gcloud artifacts docker images list --show-occurrences — 列出掃描結果。
• gcloud artifacts docker images describe <image> --show-package-vulnerability — 深入某 image。
• gcloud container binauthz attestations create ... — 通過掃描後對 image 簽章。

OSS Vulnerabilities Database (OSV) 與 OSV-Scanner

Google 維護的 OSV (Open Source Vulnerabilities) 資料庫位於 osv.dev，是一個跨語言、分散式的開源套件弱點資訊來源。Container Analysis 內部會吃 OSV 資料，但架構師也常直接使用。

OSV 的價值

• 單一 schema、多生態系： npm、PyPI、Go、Maven、crates.io、RubyGems、NuGet、Linux 發行版、Android、OSS-Fuzz。
• 精確版本範圍： 弱點對應到實際受影響的 commit / version，避開 CVE-only 資料庫常見的誤報。
• 公開 API： 免費、免認證 — 可依套件名稱、生態系、commit hash 查詢。

OSV-Scanner CLI

osv-scanner Go binary 可掃 lockfile（package-lock.json、Pipfile.lock、go.sum 等）、SBOM（SPDX、CycloneDX）或容器映像，並回報 OSV 命中：

osv-scanner --lockfile=package-lock.json
osv-scanner --sbom=app.spdx.json
osv-scanner -r ./repo

在 CI/CD 中的位置

• 在 Cloud Build 中與 docker build 同時跑 osv-scanner，遇到 HIGH/CRITICAL 即讓 build 失敗。
• 用 Cloud Scheduler + Cloud Run job 每週重新掃描 production manifest，把差異推到 Pub/Sub 觸發工單。
• SBOM 流程：build 時產生 SPDX SBOM，存到 Cloud Storage，再以獨立排程掃 SBOM，不必重新 build。

OSV vs Container Analysis

• OSV-Scanner = lockfile / SBOM 驅動，可在任何環境跑，免費、開源。
• Container Analysis = registry 驅動，受管，整合 Binary Authorization，超過免費額度後按 image 計費。

兩者並用：OSV 把源碼端守住，Container Analysis 把 registry / runtime 守住。

合規掃描器對應 (PCI DSS、HIPAA、NIST)

滲透測試結果最終要餵給合規稽核。Security Command Center Premium 內建 Compliance reports，把 SCC 結果對應到具體控制框架，稽核員可直接看到覆蓋率，不必逐一手動 mapping。

SCC 預先對應的框架

• PCI DSS v3.2.1 與 v4.0 — 卡片資料流經 GCP 時必備。
• HIPAA / HITECH — 保護健康資訊；需搭配簽過的 BAA。
• NIST 800-53 moderate 與 high baseline。
• NIST CSF。
• ISO 27001:2013。
• CIS GCP Foundations Benchmark v1.x / v2.x。

對應運作方式

SCC 每個 detector（例如 PUBLIC_BUCKET_ACL、MFA_NOT_ENFORCED、OPEN_FIREWALL）都帶有 metadata 標註其滿足的合規控制。在組織層匯出 compliance report，可得到覆蓋率報表，例如：「PCI DSS 1.2.1 — 50 個 in-scope 專案中 47 個通過、3 個失敗」。

對應滲透測試報告

實務做法：

1. 測試者以 OWASP Risk Rating 或 CVSS v3.1 格式產出 finding。
2. 在報告中加一欄，將每個 finding 對應到控制 ID（PCI DSS 6.5.1、HIPAA 164.312(e)(1) 等）。
3. 透過 SCC API 將報告以 custom findings 匯入 SCC，合規儀表板就能同時呈現自動掃描與滲透測試結果。
4. 稽核期間直接匯出單一儀表板檢視。

這能解決經典問題：滲透測試 PDF 躺在 SharePoint、SCC 卻顯示「全綠」，組織看似合規實際並非如此。

CIS Benchmark for Google Cloud

CIS Google Cloud Platform Foundation Benchmark 是事實上的基準配置稽核，列出 IAM、logging、networking、KMS、Compute、Storage、GKE 等約 70 項控制。

範例控制

• 1.1 — 組織管理員需使用公司登入憑證（不可用 @gmail.com）。
• 1.4 — 每個 service account 只能使用 GCP 管理的金鑰。
• 3.6 — SSH 不可從網際網路開放（不可 0.0.0.0/0 對 port 22）。
• 5.1 — Cloud Storage bucket 不可匿名或公開存取。
• 6.2.x — Cloud SQL 須使用 TLS 並啟用備份。
• 7.x — BigQuery dataset ACL。

自動化評估選項

• Security Command Center Premium — CIS Benchmark 是內建 compliance report，免額外設定。
• Cloud Asset Inventory + Policy Analyzer — 撰寫 Organization Policy constraint 預防 CIS 違規（例如 constraints/compute.requireOsLogin）。
• Forseti（舊版）或 Cloud Custodian（開源）— 適用 SCC Premium 之前的組織，或想用 declarative rule 的團隊。
• Open Policy Agent (OPA) 在 CI/CD — apply 前先用 OPA 檢查 Terraform plan 是否符合 CIS。

CIS Benchmark for GKE

另有一份 CIS GKE Benchmark 涵蓋 Kubernetes 專屬項目：PSP/PSS、RBAC、network policy、audit log 目的地、控制平面端點曝露等。SCC 的 GKE Security Posture 儀表板會對每個 cluster 自動檢查大多數 CIS GKE 項目。

執行頻率

至少每月跑一次完整 CIS 掃描；SCC 實際上是持續檢查，但建議每月做一次快照供安全審查會議使用。

GKE Security Posture 儀表板

GKE Security Posture 儀表板是 Cloud Console 中 cluster 安全性的單一窗口，集中呈現多種掃描器的結果。

呈現項目

• Workload configuration audits — 標記以 root 執行的 pod、缺少 resource limit、hostPath mount、privileged container 等，對應 CIS GKE Benchmark 與 Pod Security Standards（Baseline / Restricted）。
• Vulnerability scanning — 來自 Container Analysis 持續掃描的執行中工作負載語言套件 CVE。
• Misconfiguration severity — Critical、High、Medium、Low。
• Cluster 層級檢查 — 控制平面端點曝露、RBAC、audit log 目的地。

啟用方式

Autopilot cluster 預設開啟 posture。Standard cluster：

gcloud container clusters update CLUSTER_NAME \
    --location=REGION \
    --security-posture=standard \
    --workload-vulnerability-scanning=standard

standard（免費）涵蓋配置稽核與基礎語言套件 CVE。enterprise（付費）加入進階弱點掃描與額外 CIS 覆蓋。

與其他工具的連動

• 結果同時出現在 GKE → Security posture 分頁與 Security Command Center（顯示為 MISCONFIGURATION / VULNERABILITY finding）。
• 搭配 Binary Authorization 做預防控制、Container Threat Detection 做執行階段偵測 — 這三者組合即 GCP 原生 GKE CNAPP 等價物。

滲透測試的範圍內與範圍外 GCP 服務

Google 的 Customer Penetration Testing 政策允許測試 你擁有 的資源 — 但對「你的資源」與 Google 共用基礎設施的界線劃得很清楚。

明確在範圍內（可自由測試）

• 你專案中的 Compute Engine VM
• 你專案中的 GKE cluster 與工作負載
• 你部署的 Cloud Run 與 Cloud Functions 服務
• 你部署的 App Engine Standard 與 Flex app
• 你擁有、由 Cloud Load Balancing 對外的 web app
• 你擁有的 Cloud SQL 與 Spanner 執行個體（網路與認證攻擊面）
• 你擁有的 Dataflow、Dataproc、Composer 任務上跑的自訂程式碼

範圍外（絕對不可測試）

• Google 的控制平面 — *.googleapis.com 上的 API、IAM 端點、Cloud Console 本身。
• 其他租戶的資源 — 任何你不擁有的專案，即使你因錯誤配置而能公開存取也不行。
• Google 託管服務的內部 — BigQuery 的底層儲存、託管 Memorystore Redis 的內部節點、Cloud KMS 的 HSM。
• 底層實體基礎設施 — 資料中心網路、hypervisor、生產機隊。
• 針對 Google 員工的釣魚或社交工程。

DoS / 負載測試的特殊規定

Denial of service 測試屬特殊類別：

• 未經 Google Support 書面同意，不可對自家 GCP 資源進行真正的 DoS 測試 — 高流量會影響共用基礎設施。
• 在公告 service quota 與自家頻寬預算內，load test 是允許的。
• Cloud Armor 的 adaptive protection 只能在測試專案內以模擬流量測試，絕不可指向外部客戶使用的 production 端點。

通報 Google 平台弱點

若你在授權測試期間意外發現 Google 平台本身的弱點（例如 IAM bypass、控制平面 bug），不可 exploit。透過 Google Vulnerability Reward Program (VRP)（bughunters.google.com）通報。利用該弱點會違反 AUP，可能導致帳號被停權。

SAST vs. DAST

• SAST (靜態分析)： 在程式碼編譯之前分析原始碼。發現硬編碼的密鑰或不安全的編碼模式等問題（例如：GitHub Advanced Security、Snyk）。
• DAST (動態分析)： 分析運行中的應用程式。發現會話管理缺陷或注入弱點等問題（例如：Cloud Security Scanner）。

架構師洞察： 在 PCA 考試中，如果情境詢問如何「持續監控整個組織的安全性風險和錯誤配置」，答案是 Security Command Center (Standard 或 Premium 版本)。 ::

FAQ — GCP 安全性測試

Q1. 運行滲透測試需要 Google 的許可嗎？

不需要。對於大多數服務（GCE、GKE、App Engine），你可以隨時進行自己的安全性測試，而無需通知 Google。

Q2. Cloud Security Scanner 與 SCC 相同嗎？

Cloud Security Scanner 是 SCC 內的一個功能或偵測器。SCC 是更廣泛的平台，而 Security Scanner 專門針對 Web 應用程式的弱點。

Q3. 如何在我的 CI/CD 流水線中自動化安全性掃描？

使用 Cloud Build 觸發映像檔的 Container Analysis，並對程式碼運行 SAST 工具。你也可以在部署到預備環境 (Staging environment) 後觸發 Cloud Security Scanner 運行。

Q4. 什麼是「誤報 (False Positive)」？

誤報是指安全性工具回報了一個實際上並非風險的弱點。管理誤報是架構師的一項關鍵工作，以避免浪費安全性團隊的時間。

Q5. SCC 能發現我地端伺服器中的弱點嗎？

預設情況下，SCC 專注於 Google Cloud。但是，透過使用 Ops Agent 或將地端系統的日誌匯出到 Cloud Logging，SCC 可以分析混合雲環境中的特定事件和威脅。