中小型團隊適用的 GCP 安全強化檢查清單

常見的 GCP 威脅途徑

大多數雲端安全事件都始於責任歸屬或設定上的小缺口。請搶在攻擊者之前找出這些途徑。

• 權限過大的使用者、服務帳戶或工作負載身分，可能讓一組遭竊的憑證演變成橫跨多個專案的廣泛存取權。
• 暴露在外的管理端點、偵錯通訊埠或過於寬鬆的防火牆規則，可能繞過為一般應用程式流量設計的所有控管措施。
• 公開的儲存空間值區或範圍過大的已簽署網址，可能在應用程式沒有明顯遭入侵跡象的情況下洩漏客戶資料。
• 當舊的映像檔、被遺忘的命名空間、未使用的服務帳戶和無人負責的資源仍可部署時，閒置的工作負載會造成長期風險。
• 稽核證據缺漏或保留期過短，會難以判斷是誰變更了政策、存取從何時開始，以及哪些資料遭到存取。
• 未經測試的備份只是一種期望。還原失敗、保留不完整以及無法存取的加密金鑰，都可能讓一次安全事件變成永久性的損失。

身分與存取權

將身分視為主要的控制層。每個人員、自動化程序和工作負載都應擁有各自獨立、用途受限的身分。

明確界定資源邊界

使用機構和資料夾設置防護機制，並將開發、預備和正式環境分隔到不同專案或更嚴格的信任邊界中。在實際可行的最高層級套用機構政策、限制服務使用，並避免在不相關的產品之間共用正式環境專案。

在最小範圍內授予最低限度的角色

優先使用預先定義角色或自訂角色，而非範圍廣泛的基本角色；將角色授予群組和工作負載身分，並在可透過資源名稱或標記縮小存取範圍時使用 IAM 條件。審查未使用的權限，並移除只應透過緊急存取 (break-glass) 程序取得的常設正式環境存取權。

移除長期有效的憑證

使用 Workload Identity Federation for GKE，讓 Pod 不必匯出服務帳戶金鑰就能取得短期有效的憑證。盡可能透過機構政策禁止建立和上傳金鑰、清查所有剩餘的金鑰，並在 Cloud Audit Logs 出現高風險的 IAM 變更時發出警示。

網路和邊緣

假設某個應用程式缺陷終究會從網路上被觸及，並限制該缺陷能存取的範圍。

預設拒絕，只新增明確指定的途徑

採用最低權限的 VPC 防火牆規則，並以 Kubernetes NetworkPolicies 管控 Pod 流量。將各環境分隔到不同的網路、記錄每一條輸入途徑，並移除允許大範圍位址存取管理通訊埠或所有通訊協定的寬鬆偵錯規則。

讓節點和控制層保持私人

停用 GKE 節點的外部 IP 位址。優先使用以 DNS 為基礎的私人控制層端點；若無法避免使用 IP 端點，請以授權網路加以限制。為工作負載提供刻意規劃的輸出途徑，而非廣泛的網際網路存取權。

只發布刻意規劃的公開服務

透過經過審查的閘道或負載平衡器公開應用程式，而不是透過意外暴露的 Pod 或節點位址。以代管憑證終止 TLS、限制輸入主機和路徑、套用要求限制和頻率限制，並將管理介面置於身分感知存取控管之後。

資料與密鑰

保護靜態、傳輸中和使用中的資料，然後證明您能夠還原這些資料。資料探索也是控管的一環。

防止意外的公開存取

在 Cloud Storage 上強制執行禁止公開存取和統一值區層級存取權。依機密程度將值區分類、限制物件和金鑰的存取權、為高價值資料啟用記錄功能，並在風險或法規遵循模型有所要求時使用客戶自行管理的加密金鑰。

不要將密鑰放進映像檔和原始碼

將憑證儲存在 Secret Manager 中，並只向特定的工作負載身分授予特定密鑰版本的存取權。有計畫地輪替密鑰，避免將其複製到 Git 或容器映像檔中，也不要將一般的 Kubernetes Secrets 視為完整的防護邊界。

測試復原，而不只是建立備份

定義復原點目標 (RPO) 和復原時間目標 (RTO)，在正式環境的故障網域之外保留副本，並防止工作負載身分存取備份和加密金鑰。定期還原至隔離環境、驗證資料，並記錄所需時間和所有手動步驟。

GKE 安全強化

GKE 會保護代管的控制層，但叢集設定、命名空間、准入政策和工作負載仍須由您自行管理。

以命名空間作為隔離約定

將團隊和環境分隔到不同的命名空間或叢集，在其中繫結範圍精確的 Kubernetes RBAC 角色，並套用資源配額和 NetworkPolicies。避免為應用程式交付授予叢集範圍的寫入權限；當工作負載需要獨立身分時，為每個工作負載指派專屬的服務帳戶。

只准入您信任的映像檔和設定

強制執行 Restricted 層級的 Pod Security 標準或同等的 Policy Controller 規則。依不可變更的摘要部署映像檔、掃描安全漏洞、在需要確認來源出處時使用 Binary Authorization，並拒絕非預期的主機存取、權限提升和 cluster-admin 繫結。

移除不必要的容器權限

以非 root 使用者身分執行、捨棄 Linux capabilities、盡可能使用唯讀根檔案系統，並套用 RuntimeDefault seccomp 設定檔。非必要時不要掛接服務帳戶權杖；避免使用特權容器和主機命名空間、將節點服務帳戶的權限維持在最低限度，並使用 Shielded Nodes 和 Container-Optimized OS。

偵測與復原

控管措施總有失效的時候。請仰賴證據和演練過的行動，而不是相信沒有人會犯錯。

收集您需要的證據

將 Cloud Audit Logs 以及 GKE 系統記錄和工作負載記錄集中存放在同一個目的地，並設定符合調查需求的保留期限。針對機密資料選擇性啟用資料存取稽核記錄、限制記錄的存取權，並記錄對 IAM、防火牆、儲存空間和叢集設定的管理變更。

針對具有安全意義的變更發出警示

針對儲存空間公開暴露、範圍廣泛的防火牆或 IAM 變更、非預期的服務帳戶金鑰、准入遭拒、控制層暴露、反覆的驗證失敗、記錄功能遭停用、備份失敗，以及即將到期的憑證發出警示。將每則警示轉給對應的負責人，並附上確認或排除該警示的步驟。

演練應變流程

針對憑證外洩、資料遭公開、工作負載遭入侵，以及區域或專案遺失撰寫簡短的執行手冊，內容應涵蓋誰有權核准圍堵措施、如何撤銷存取權、如何保全證據，以及如何恢復服務。與實際使用這些執行手冊的人員一起進行測試。

依優先順序排列的 30、60、90 天檢查清單

如果您的基準尚不完整，請妥善安排工作順序：先減少暴露面，再讓後續的審查能夠重複進行。

第 1 到 30 天：封堵明顯的途徑

清查專案及其負責人、移除未使用和長期有效的憑證、確認稽核記錄功能、封鎖公開值區、審查範圍最廣的防火牆規則和 IAM 授權、找出正式環境備份的缺口，並修正所有無人負責的公開端點。為每一項發現指派負責人和到期日。

第 31 到 60 天：讓基準可重複套用

將網路、身分和工作負載設定移轉至經過審查的基礎架構即程式碼和 GitOps 交付流程。採用 Workload Identity、私人節點、受限的 Pod Security、可信任映像檔檢查、集中式記錄，以及針對最重要變更的警示。

第 61 到 90 天：驗證並持續維持

執行還原測試和事件桌上演練、審查特權存取權和例外的到期時間、重新掃描映像檔和相依套件、確認負責人能收到警示，並評估仍存在的缺口。在證據過時之前，將這些檢查納入定期審查週期。

請將這份檢查清單當作起點。Snow Tree 可以透過代管平台營運或針對性的諮詢服務，落實這套基準。

代管平台 · 諮詢服務

官方參考資料

當平台預設值或產品功能有所變動時，請以 Google 最新的指引作為技術上的權威依據。

• Google Cloud：強化 GKE 叢集安全性的最佳做法
• Google Cloud：GKE 安全性最佳做法