本文將說明 Google Cloud 服務和防範策略，協助您防禦OWASP Top 10:2025 中列出的應用程式層級攻擊。Open Web Application Security (OWASP) Foundation 建立的 OWASP Top 10:2025 列出軟體開發生命週期 (SDLC) 的前 10 大安全風險。雖然沒有任何服務能保證完全防範這些風險，但如果您的架構適合使用這些服務，就能打造強大的多層式安全解決方案。
Google 基礎架構的設計宗旨是協助您建構、部署及運作服務，並提供強大的安全控管機制。實體和作業安全、靜態資料加密和傳輸中資料加密，以及許多其他基礎架構防護措施，都由 Google 管理。將應用程式部署至 Google Cloud即可享有這些優勢，但您可能需要採取額外措施，協助保護應用程式免於特定攻擊。
法規遵循矩陣
下表列出的 Google Cloud 服務可協助防範 OWASP Top 10:2025 識別出的前 10 大安全性風險：
Google Cloud 服務
下列各節說明核心Google Cloud 服務的 OWASP Top 10 最佳做法。
Access Approval 和資料存取透明化控管機制
資料存取透明化控管機制和 Access Approval 可驗證雲端服務供應商的存取權。透過資料存取透明化控管機制，您可以記錄 Google 員工每次存取的原因。當支援您服務的 Google 人員提出存取要求，您可利用 Access Approval 予以核准或拒絕。
適用於 A09：安全性記錄和警示失敗。
請參閱下列最佳做法：
- 自動化存取核准程序。如要這麼做，請設定存取權核准，將傳入的存取權核准要求中繼資料傳送至 Pub/Sub 主題。 建立 Pub/Sub 訂閱項目，將 JSON 酬載推送至自訂 Webhook 端點 (例如已驗證的 Cloud Run 服務、Cloud Run 函式或企業 API 閘道) 進行處理。
- 將資料存取透明化控管機制記錄視為重要的安全性遙測資料。在 Monitoring 中建立記錄指標和快訊政策，如果 Google 人員在沒有相應的有效支援單的情況下存取敏感資源，就向您的安全營運中心 (SecOps) 發出警示。
- 直接將資料存取透明化控管機制記錄檔匯出至 Google SecOps 或集中式企業 SIEM。
- 建立法規遵循政策，定期稽核記錄串流，並確認
auto_approved緊急存取事件與記錄在案的重大事件相關。 - 如要進行加密控制，請使用金鑰存取依據，強制系統以程式輔助方式要求金鑰解密核准。
Access Context Manager
Access Context Manager 是情境感知存取權引擎，Google CloudAccess Context Manager 可讓您為 IAP、VPC Service Controls 和 IAM 定義屬性式存取層級 (例如用戶端 IP 位址範圍、裝置資安態勢和地理位置)。
適用於下列項目：
- A01：存取控管失效
- A02：安全性設定錯誤
- A07：驗證失敗
請參閱下列 A01：存取權控管失效最佳做法：
- 為貴機構的存取權政策建立可重複使用的分層安全等級。建立基本存取層級，測試標準屬性。如要設定複雜的多重條件，請部署自訂存取層級，評估進階裝置狀態和第三方端點信號。
- 使用 Endpoint Verification 或 Chrome Enterprise 基本版，強制執行裝置層級的限制，例如全磁碟加密、啟用螢幕鎖定，以及使用核准的作業系統版本。
- 如要使用 VPC Service Controls 保護高價值資料存放區，請在 VPC Service Controls 傳入規則中新增存取層級。如果服務帳戶金鑰外洩，攻擊者無法僅使用該金鑰，從未經授權的公開 IP 位址或不受信任的機器查詢 BigQuery 或 Cloud Storage。
- 如要將零信任防護機制擴充到網頁應用程式和 VM 管理通道，請直接將存取層級附加至受 IAP 保護的資源。
請參閱下列 A02：安全性設定錯誤的最佳做法：
- 導入與特定資料夾綁定的範圍存取政策，將本機政策管理權委派給個別專案團隊，並將他們的變更與組織其他部分隔離。
- 為避免孤立的 Ingress 規則成為無聲的後門，請定期檢查並移除已停用的 IP 範圍、過期的合作夥伴子網路和過時的裝置屬性。
請參閱下列 A07：驗證失敗的最佳做法：
- 使用使用者存取繫結設定嚴格的工作階段時間上限。設定重新驗證政策，要求使用者提供
SECURITY_KEY(FIDO2 或 WebAuthn)。如要對高風險環境套用更嚴格的限制，請設定scopedAccessSettings，覆寫敏感應用程式的預設工作階段時間長度。
Agent Gateway 和代理身分
Agent Gateway 和 Agent Identity 可為 AI 代理和代理工作流程提供專屬的網路政策執行、身分生命週期管理，以及密碼編譯驗證。
適用於下列項目：
- A01：存取控管失效
- A07：驗證失敗
請參閱下列 A01：存取權控管失效最佳做法：
- 在多代理系統、外部 MCP 工具或自主管道的環境中，請使用 Agent Gateway 做為專屬網路和政策執行點，協助減輕代理存取控制失敗的問題。
- 為代理程式身分設定精細的授權政策，限制工具存取權和資料擷取權，只允許代理程式存取特定工作流程所需的資源。
請參閱下列 A07：驗證失敗的最佳做法：
- 如要驗證自主代理程式和工具整合，而不必嵌入靜態 API 金鑰或密碼，請為每個代理程式產生並指派代理程式身分。
- 設定代理程式身分，以核發 X.509 憑證做為代理程式的憑證。這些憑證有助於防止權杖遭竊，因此如果存取權杖遭到攔截，該權杖就無法在其他環境中使用。
Apigee
Apigee 提供集中式閘道層級機制，使用 API 代理強制執行密碼編譯標準、驗證已簽署的酬載，以及加密傳輸中和靜態的應用程式資料。Apigee 可做為 API 流量的反向 Proxy 閘道，執行邊界和結構檢查，協助驗證酬載。Apigee 提供內建的 API 驗證、OAuth 和 JSON Web Token (JWT) 驗證政策，可建立嚴格的身分界線。Apigee 提供多種方式，可執行記錄、監控、錯誤處理和稽核記錄。
適用於下列項目：
- A01：存取控管失效
- A04：密碼編譯失敗
- A05：注入
- A06：不安全的設計
- A07：驗證失敗
- A09：安全性記錄和警示失敗
請參閱下列 A01：存取權控管失效最佳做法：
使用 API Proxy 完成下列操作：
攔截要求，防止攻擊者透過操控 API 要求路徑中的 ID 變數，存取其他使用者的記錄。
禁止標準用戶端執行受限制的管理員方法或高權限作業。
在 API 管理層，使用加密鍵值對應、Secret Manager 或 Kubernetes Secrets (僅限混合式部署)，強制執行存取控制、驗證和密鑰儲存。
使用 OAuth 政策和 JWT 權杖驗證簽名。將敏感端點和動作對應至高權限的細微 OAuth 範圍 (例如
delete:account或write:billing)。使用OAuthV2政策在 API 進入點驗證這些範圍，並向任何沒有正確權限的用戶端傳回 HTTP403 Forbidden狀態碼。啟用 Advanced API Security，分析流量中的異常行為模式，並開始執行安全性動作。
請參閱下列 A04：密碼學失敗的最佳做法：
- 在應用程式中加密敏感資料，並在流量抵達後端應用程式前，強制執行嚴格的加密驗證。使用 Cloud KMS，透過客戶自行管理的加密金鑰 (CMEK) 設定 Apigee 環境。
- 使用單向和雙向 TLS 在通訊協定層級加密機密資訊。如果是伺服器對伺服器或高風險的商務整合，請在 Apigee Ingress 閘道設定相互傳輸層安全標準 (mTLS)。
- 使用
VerifyJWT和VerifyJWS政策，要求傳入的權杖必須具有有效的加密簽章，才能處理要求。使用標準 OAuth 技術，並考慮實作 HMAC、酬載雜湊、狀態或隨機值驗證，以及用於程式碼交換的金鑰證明 (PKCE)，以加密方式強化每個要求。 - 遮蓋機密資料，以便在使用 Apigee 偵錯工具時，加密及隱藏資料。
請參閱下列 A05：注入的最佳做法：
- 部署 Apigee 威脅防護政策，在閘道層清理輸入參數，並封鎖 SQL、NoSQL 和指令注入攻擊：
請參閱下列 A06：不安全設計的最佳做法：
- 使用
OASValidation政策，根據 OpenAPI 規範驗證傳入的要求或回應訊息。 - 實作
SpikeArrest政策和Quota政策，減輕流量尖峰和後端過載問題。 - 使用錯誤處理規則攔截後端錯誤 (例如資料庫當機)，並將其重新編寫為一般 HTTP 回應。
請參閱下列 A07：驗證失敗的最佳做法：
- 為面向開發人員的 API 實作 API 金鑰驗證，讓 Apigee 檢查用戶端應用程式的 API 金鑰是否存在、是否有效，以及是否有權存取所要求的 API 資源。
- 為防範工作階段符記遭竊和重送攻擊，請導入「證明擁有權 (DPoP)」。DPoP 會將權杖繫結至傳送者的公開金鑰，以防範權杖重送。
- 結合
SpikeArrest速率限制和 reCAPTCHA Enterprise 整合，防範自動暴力攻擊權杖產生和登入端點。
請參閱下列 A09：安全性記錄和警示失敗的最佳做法：
- 將結構化 API 交易中繼資料非同步串流至記錄或第三方 SIEM。將
MessageLogging政策附加至PostClientFlow，該政策會在回應傳送至用戶端後執行。 - 集中管理平台稽核記錄，追蹤 API Proxy、憑證和部署環境的修改內容。為避免未經授權的 Proxy 修改作業遭到忽略，請將 Apigee 與 Cloud 稽核記錄 整合。詳情請參閱「Apigee 稽核記錄」和「Apigee API 管理稽核記錄」。
- 在「監控」中設定 Advanced API Security 快訊，以便在發生自動化網頁擷取活動、憑證濫用和安全性分數下降等情況時，通知 SecOps 團隊。
- 在記錄訊息範本中，將使用者提供的變數包裝在
escapeJSON()函式中，即可清除這些變數。 - 如果將記錄中繼資料串流至外部 SIEM，請設定
MessageLogging政策，透過 TLS (TCP 通訊埠6514) 使用 Syslog 加密傳輸中的資料。
Artifact Registry 和 Artifact Analysis
Artifact Registry 可讓貴機構集中管理容器映像檔和語言套件。Artifact Analysis 提供整合式安全漏洞掃描、軟體物料清單 (SBOM) 產生功能，以及 Artifact Registry 中儲存構件的中繼資料儲存空間。
適用於下列項目：
- A03：軟體供應鏈故障
- A08：軟體或資料完整性失敗
請參閱下列 A03：軟體供應鏈故障最佳做法：
- 設定清除政策，在預先定義的保留期限過後，刪除未標記版本、未加上標記或過時的候選版本映像檔，即可減少受攻擊面，並防止部署有安全漏洞的舊版映像檔。
- 設定虛擬存放區，並使用上游存放區優先順序，將內部構件存放區的優先順序設為高於公開登錄檔，防範依附元件混淆攻擊。
- 強制執行不可變更的圖片代碼，或嚴格依據密碼編譯摘要 (
sha256:...) 部署，防止代碼突變攻擊。
請參閱下列 A08：軟體或資料完整性失敗的最佳做法：
- 在 Artifact Analysis 中啟用自動掃描安全漏洞和 SBOM 生成功能，在部署前偵測重大 CVE。
- 整合 Artifact Analysis 中繼資料與二進位授權認證，禁止部署未達安全門檻的映像檔。
Assured OSS
Assured OSS 可讓您將 Google 驗證及使用的 OSS 套件，整合至自家開發人員工作流程。
適用於下列項目：
- A03：軟體供應鏈故障
- A08：軟體或資料完整性失敗
請參閱下列 A03：軟體供應鏈故障最佳做法：
- 設定遠端存放區，將上游指向 Assured OSS。
- 確認建構作業中的開放原始碼程式庫含有有效的 Google 簽章，以及可驗證的 SLSA 建構出處記錄。在 Cloud Build 中設定品質門檻，在編譯應用程式二進位檔前驗證這些認證。
- 在 Cloud Workstations 基礎映像檔中，將套件管理員 (例如
pip.conf、settings.xml或build.gradle) 設定為僅指向內部 Assured OSS 存放區。 - 使用 Assured OSS 產生的中繼資料，判斷開放原始碼套件中新揭露的 CVE 是否可在特定部署環境中遭到利用。
請參閱下列 A08：軟體或資料完整性失敗的最佳做法：
- 在 Artifact Registry 中設定虛擬上游存放區，強制執行 Google 驗證的加密簽章，確保建構管道中的套件完整性。
- 使用 Assured OSS 進階級 (Security Command Center Premium 的一部分) 自動佈建存放區、存取精選的 JavaScript (npm) 套件，以及取得套件中繼資料和安全漏洞通知的存取權。
二進位授權
二進位授權會驗證容器的完整性，確保只會部署受信任的容器映像檔。您可以根據認證是否存在，建立政策來允許或拒絕部署作業。二進位授權會在叢集層級套用政策，因此您可以為不同環境設定不同政策。
適用於下列項目：
- A03：軟體供應鏈故障
- A08：軟體或資料完整性失敗
請參閱下列 A03：軟體供應鏈故障最佳做法：
- 設定部署管道，透過容器映像檔的專屬不可變更 SHA-256 加密摘要 (例如
@sha256) 參照及強制執行容器映像檔。 - 在 GKE 叢集上部署 Binary Authorization Continuous Validation，根據平台政策監控現有 Pod，並在執行中的容器不再符合規定時，在 Logging 中產生快訊。
請參閱下列 A08：軟體或資料完整性失敗的最佳做法：
- 在 Cloud Build 或 GitHub Actions 管道中，強制執行自動產生驗證。建立漸進式認證規定，讓圖片在接近製作階段時，通過連續驗證閘道。
- 如遇嚴重程度較高的正式版群組事件，請啟用急用權限緊急部署。針對「緊急情況存取」稽核記錄事件設定 Monitoring 警告政策，在發生准入程序略過事件時通知 SecOps 團隊。
CA 服務和 Certificate Manager
憑證授權單位服務 (CA 服務) 可簡化私人憑證授權單位 (CA) 的部署與管理作業。Certificate Manager 可集中佈建、更新及管理 Cloud Load Balancing 和 Cloud CDN 的 TLS 憑證。
適用於 A04：密碼編譯失敗。
請參閱下列最佳做法：
- 使用 CA Service 自動核發及管理私人憑證的生命週期。部署由 Cloud HSM 支援的根 CA 和中繼 CA，保護私密金鑰，並使用憑證範本強制執行加密政策 (例如最短金鑰長度和允許的擴充金鑰用途)。
- 啟用 Cloud 稽核記錄，監控高風險管理事件 (例如撤銷 CA、更新政策，或憑證要求突然暴增)。將快訊傳送至 Google SecOps，偵測潛在的內部威脅或遭入侵的 CI/CD 管道。
- 設定 Certificate Manager，使用與 DNS 授權配對的 Google 管理憑證。Certificate Manager 會驗證網域擁有權、核發 X.509 憑證，並在到期前 30 天處理續約事宜。
- 將憑證對應附加至目標 HTTPS Proxy，即可啟用動態憑證選取和憑證輪替功能，不必重新啟動 Proxy 或重新設定負載平衡器。
- 如果是內部微服務或混合式負載平衡，請設定憑證對應，直接從私人 CA 服務 CA 集區核發私人憑證。
- 設定憑證對應，將傳入的伺服器名稱指示 (SNI) 要求與特定憑證相符。
Cloud Asset Inventory
Cloud Asset Inventory 可讓您監控 Google Cloud 上的基礎架構，找出孤立或未經授權的 IT 基礎架構。
適用於 A02：安全性設定錯誤。
請參閱下列最佳做法：
- 設定通知，在有非預期的執行中資源時收到快訊，這些資源可能安全性不足或使用舊版軟體。
- 使用 IAM 政策分析器找出設定錯誤的存取控制項，例如具有
allUsers權限的公開儲存空間值區、權限過高的服務帳戶角色，或孤立的身分。 - 將資產快照匯出至 BigQuery，以便稽核一段時間內的基礎架構設定，並在多專案環境中維護基準法規遵循記錄。
Cloud Armor
Cloud Armor 是自動調整式網頁應用程式防火牆 (WAF)，可部署在網路邊緣，協助防範 DDoS 攻擊，並封鎖 SQLi 或 XSS 注入式酬載。 Google Cloud Cloud Armor 包含預先設定的 WAF 規則，可防範 OWASP 前 10 大安全漏洞、限制驗證端點的攻擊面，以及封鎖遭盜用的憑證。
適用於下列項目：
- A01：存取控管失效
- A05：注入
- A07：驗證失敗
- A08：軟體或資料完整性失敗
- A10：異常狀況處理不當
請參閱下列 A01：存取權控管失效最佳做法：
- 套用預先設定的 WAF 規則，例如
evaluatePreconfiguredWaf('lfi-stable')，阻擋本機檔案包含和路徑遍歷攻擊。 - 如要強制執行地理位置存取權控管 (也稱為地理圍欄)，請設定安全政策規則，根據傳入流量的來源國家/地區代碼 (使用
origin.region_code屬性)，比對流量。 - 使用威脅情報動態饋給封鎖已知的惡意 IP 位址。
- 編寫相符規則，限制外部存取敏感網址 (例如
/admin、/login或/config)。 - 在負載平衡器上啟用 Cloud Armor 路徑正規化，強制 Cloud Armor 解碼並標準化傳入的網址，再評估安全性政策。
請參閱下列 A05：注入的最佳做法：
- 在網路邊緣偵測並封鎖 SQL 注入 (
sqli-v422-stable)、跨網站指令碼攻擊 (xss-v422-stable)、PHP 指令注入 (php-v422-stable) 和 Java 注入 (java-v422-stable)。 - 將預先設定的網路應用程式防火牆規則調整為不同的敏感程度，以解決誤判問題，再將規則設為主動拒絕流量。
- 啟用預先設定的遠端程式碼執行 (RCE) 規則 (
rce-v422-stable) 和遠端檔案包含 (RFI) 規則 (rfi-v422-stable)，偵測其他複雜的指令注入手法。 - 如要防範針對 SQL 或 PHP 以外的注入式攻擊，請建立自訂規則。如果要求路徑或查詢中含有特定關鍵字或通訊協定中的逸出模式，您可以使用自訂規則封鎖要求。
請參閱下列 A07：驗證失敗的最佳做法：
- 限制存取權，只允許授權的 IP 位址或國家/地區存取驗證和管理端點。
- 啟用
evaluatePreconfiguredWaf可攔截並封鎖要求，避免工作階段狀態漏洞和工作階段遭竊。 - 使用
securityPolicies.patchRuleAPI，在網路邊緣封鎖查詢字串或標頭中含有遭入侵參數的所有傳入要求。
請參閱下列 A08：軟體或資料完整性失敗的最佳做法：
將接受來自不受信任來源的高風險序列化物件的端點，限制為一組受信任的 IP 位址，並使用類似下列的拒絕規則：
request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')部署自訂規則，檢查要求主體關鍵字是否有特定語言的執行模式和不安全的還原序列化簽章。
請參閱下列 A10 最佳做法：異常狀況處理不當：
- 在安全性政策中啟用 Google Cloud Armor Adaptive Protection，建立正常流量模式的基準、設定第 7 層異常狀況的快訊，以及使用攻擊簽章產生目標 WAF 規則。
- 在重要端點 (例如
/login、/checkout或搜尋 API) 上設定 Cloud Armor 速率限制規則。速率限制規則會根據每個用戶端 IP 或 HTTP 標頭節流要求 (例如限制用戶端每分鐘 100 項要求)，並傳回 HTTP429 Too Many Requests狀態碼。 - 在 Cloud Armor 安全性政策中，將優先順序最低的預設規則設為
Deny(狀態碼：403或404)。
Cloud Build 和 Cloud Deploy
Cloud Build 和 Cloud Deploy 提供整合式安全持續整合和持續推送軟體更新 (CI/CD) 管道，可在Google Cloud上運作。Cloud Build 會建構構件，並提供可驗證的 SLSA provenance和加密認證，而 Cloud Deploy 則會管理 GKE 和 Cloud Run 的漸進式推出、目標核准和自動驗證。
適用於下列項目：
- A03：軟體供應鏈故障
- A08：軟體或資料完整性失敗
請參閱下列 A03：軟體供應鏈故障最佳做法：
- 在
cloudbuild.yaml檔案中設定requestedVerifyOption: VERIFIED，要求可驗證的出處。 - 部署與私人虛擬私有雲網路對等互連的 Cloud Build 私人集區，用於建構機密企業專案。
- 設定建構觸發程序，在專用的使用者代管服務帳戶下執行。只為這些服務帳戶授予必要的最低 IAM 允許權限，例如 Artifact Registry 寫入者 (
roles/artifactregistry.writer) 和記錄寫入者 (roles/logging.logWriter)。 - 針對以測試或正式環境為目標的 Cloud Build 觸發條件，要求手動核准。
- 將持續整合建構工具 (例如 Cloud Build、GitHub Actions 或 GitLab) 限制為 Cloud Deploy Releaser (
roles/clouddeploy.releaser) 角色，這樣建構管道就只能建立版本。 - 如要手動核准，請在預先發布和正式發布目標中，使用
requireApproval: true設定發布管道資訊清單 (delivery-pipeline.yaml)。 - 使用目標專屬服務帳戶設定執行環境 (例如，一個服務帳戶的權限僅限於暫存命名空間，另一個服務帳戶則用於正式環境，並經過稽核)。
- 部署自訂掛鉤，在推出生命週期期間執行頻外安全聲明。使用部署前掛鉤驗證目標叢集是否符合法規遵循基準，並使用部署後掛鉤對即時容器端點啟動自動安全漏洞掃描。
請參閱下列 A08：軟體或資料完整性失敗的最佳做法：
- 將 Cloud Build 與 Cloud KMS 和 Artifact Analysis 整合，在單元測試和靜態分析測試順利完成時，建立及簽署密碼編譯認證。
- 在
cloudbuild.yaml的建構工具步驟中，使用不可變動的加密 SHA-256 摘要 (例如golang@sha256:...)。 - 將建構設定儲存在受分支保護規則保護的版本控管存放區 (例如強制對提取要求進行雙人審查)。使用使用者代管的服務帳戶，將觸發條件修改權限限制在授權平台管理員。
- 在目標階段中，宣傳相同的預先轉譯部署資訊清單和不可變更的容器映像檔摘要，且不允許 CI 管道在測試和正式環境之間變更資訊清單。
- 在
skaffold.yaml資訊清單中定義自動化部署驗證工作。在 Pod 部署完畢後，Cloud Deploy 會執行這些驗證容器，以執行動態健康狀態檢查、整合測試和 API 合約斷言。 - 使用初期測試部署策略。如果 Skaffold 驗證測試失敗，或監控功能在 Canary 階段偵測到異常狀況門檻，Cloud Deploy 會停止推出作業，並將流量回溯至最後已知的良好發布版本。
- 設定 GKE 叢集和 Cloud Run，強制執行二進位授權政策。當 Cloud Deploy 套用資訊清單時，目標准入控制器會以密碼編譯方式驗證容器映像檔摘要，並拒絕不受信任的構件。
Cloud Identity 和 Titan 安全金鑰
Cloud Identity 可集中管理 Google Cloud 和 Google Workspace 的身分、憑證生命週期和存取權。 Google CloudTitan 安全金鑰是防範網路釣魚的硬體式安全裝置，採用以 FIDO2 或 WebAuthn 標準為基礎的公開金鑰密碼編譯技術。
適用於 A07：驗證失敗。
請參閱下列最佳做法：
- 為防範中間人 (PITM) 網路釣魚攻擊，請設定兩步驟驗證 (2SV)，並將允許的方法設為「僅限安全金鑰」 (FIDO2、WebAuthn 或 Titan 安全金鑰)。
- 設定以 SAML 2.0 或 OIDC 為基礎的單一登入 (SSO) 服務，並搭配自動佈建功能，與公司識別資訊提供者整合。
- 將Google Cloud 工作階段長度政策 設為較低的最大門檻，強制使用者定期重新驗證。
- 將 Titan 安全金鑰註冊為密碼金鑰，啟用免密碼驗證，大幅降低暴力破解和憑證遭盜用的風險。
- 在 Cloud Identity 中強制執行安全金鑰政策，為專案擁有者、帳單管理員和 SecOps 團隊等具備特殊權限的身分，規定必須使用 Titan 安全金鑰進行雙重驗證。為高風險使用者申請加入進階保護計畫。
Cloud KMS
Cloud KMS 可管理相容 Google Cloud 服務和您自有應用程式的對稱與非對稱加密編譯金鑰。您可以產生、使用、輪替及銷毀對稱式加密、非對稱式簽署、非對稱式加密和 MAC 簽署的加密編譯金鑰。
適用於 A04：密碼編譯失敗。
請參閱下列最佳做法：
- 使用 Cloud KMS Autokey 自動佈建及指派金鑰。使用 Autokey 時，您不需要事先佈建金鑰環、金鑰和服務帳戶。而是會在建立資源時，視需要產生金鑰和金鑰環。
- 在將機密酬載傳送至儲存空間值區或資料庫之前，請先使用 Cloud KMS 金鑰加密。您可以使用 Cloud KMS API 或用戶端程式庫，透過 Cloud KMS 金鑰進行用戶端加密。
- 驗證端對端資料完整性：在傳輸期間驗證檢查碼。
- 對於嚴格的法規遵循和監管工作負載，請使用 Cloud HSM 儲存及執行密碼編譯作業。Cloud HSM 會將金鑰儲存在通過 FIPS 140-3 第 3 級驗證的硬體安全性模組中。
- 在設定的時間範圍內設定自動金鑰輪替排程 (例如每 90 天)。
Cloud Load Balancing
Cloud Load Balancing 是完全分散式的軟體定義型代管服務，可將使用者流量分配到多個後端執行個體和區域。
適用於下列項目：
- A04：密碼編譯失敗
- A10：異常狀況處理不當
請參閱下列 A04：密碼學失敗的最佳做法：
- 設定自訂 SSL 政策並指派給負載平衡器的前端，將交涉作業限制為 TLS 1.3 或安全的 TLS 1.2 設定檔，並停用不安全的加密套件。
請參閱下列 A10 最佳做法：異常狀況處理不當：
- 使用自訂錯誤回應頁面設定外部應用程式負載平衡器，攔截後端失敗代碼，並提供標準化 HTML 或 JSON 錯誤回應。
- 部署具備跨區域容錯移轉功能的多區域後端服務，以便在發生服務中斷或未處理的系統當機時，將流量重新導向至次要區域。
Google Cloud Observability (Logging、Monitoring 和 Error Reporting)
Google Cloud Observability 提供全堆疊記錄管理功能 (Logging)、指標和警報功能 (Monitoring)，以及即時應用程式當機追蹤功能 (Error Reporting)。
適用於下列項目：
- A09：安全性記錄和警示失敗
- A10：異常狀況處理不當
請參閱下列 A09：安全性記錄和警示失敗的最佳做法：
- 針對儲存機密資料的高價值資料存放區 (例如 Cloud Storage、BigQuery 和 Spanner) 啟用資料存取記錄。您可以使用資料存取記錄，稽核機密資料的每項讀取、寫入和查詢事件。
- 對自訂記錄 bucket 強制執行bucket 鎖定和保留政策，防止攻擊者或未經授權的管理員刪除記錄來掩蓋行蹤。
- 使用匯總接收器，將記錄檔項目彙整並轉送至單一中央存放區，供 SecOps 團隊使用。設定攔截匯總接收器，避免在多個位置儲存大量記錄檔，例如資料存取記錄。
- 針對遭入侵的重大指標 (例如「權限遭拒」IAM 錯誤、意外建立的 API 金鑰，或防火牆設定突然變更)，設定以記錄為準的警報政策。
- 在 Logs Explorer 或 Monitoring 中部署以記錄為基礎的快訊政策。指定確切的篩選器，鎖定高嚴重程度的事件，例如未經授權的 IAM 政策修改或 KMS 金鑰撤銷，以便在系統擷取相符的記錄項目時產生事件通知。
- 在 Logging 中建立記錄型計數器指標，將相符的記錄項目轉換為時間序列資料。接著在 Monitoring 中建立指標型警告政策，當比率超過特定門檻時 (例如五分鐘內登入嘗試失敗次數超過 50 次)，就會啟動事件。
- 設定以記錄為準的快訊政策，監控對 Cloud Logging API 的管理呼叫，並在記錄匯出接收器遭到意外修改或 bucket 遭到刪除時發出快訊。
- 使用清楚的文件範本設定通知管道。包括Logs Explorer 查詢的直接深層連結、值班工程師的標準作業程序 (SOP)，以及明確的修復步驟，有助於迅速防堵事件。
請參閱下列 A10 最佳做法：異常狀況處理不當：
- 直接將 Error Reporting SDK 整合到應用程式程式碼中，或設定 Logging 剖析結構化 JSON 例外狀況格式。
- 設定 Error Reporting 通知管道或 Monitoring 快訊政策，在出現新的例外狀況類別時通知 SecOps 團隊。
Cloud NGFW
Cloud NGFW 是代管防火牆服務，可對南北向和東西向流量進行有狀態檢查，並提供第 7 層應用程式控制功能。
適用於下列項目：
- A01：存取控管失效
- A05：注入
請參閱下列 A01：存取權控管失效最佳做法：
- 使用全域網路防火牆政策和 IAM 控管的資源標記，強制執行網路微區隔，隔離後端應用程式層，並限制子網路之間的東向通訊。
- 在防火牆規則中使用 Google 維護的威脅情報清單，封鎖來自已知惡意攻擊者、C2 伺服器和遭入侵殭屍網路的連入連線。
請參閱下列 A05：注入的最佳做法：
- 設定入侵偵測和防護服務，並使用安全設定檔群組拒絕符合 SQL 注入、OS 指令注入和遠端程式碼執行漏洞簽章的威脅。
- 設定 Cloud NGFW TLS 檢查，解密傳入和傳出的 HTTPS 流量、對純文字酬載套用 IPS 插入簽章檢查，並在傳送至後端前重新加密工作階段。
- 在後端資料庫和 Compute 子網路上，強制執行以 FQDN 為依據的輸出防火牆規則。將傳出連線限制為已核准的預先定義外部網域，有助於防止易受攻擊的應用程式建立未經授權的反向 Shell。
- 在威脅防範設定檔中啟用防火牆規則記錄，並將這些記錄檔傳送至 Google SecOps，將遭封鎖的網路注入簽章與主機層級遙測資料建立關聯，找出需要優先修補的目標工作負載。
Cloud Workstations
Cloud Workstations 提供 Google Cloud 代管開發環境，內建安全防護機制和自訂功能。
適用於下列項目：
- A03：軟體供應鏈故障
- A04：密碼編譯失敗
請參閱下列 A03：軟體供應鏈故障最佳做法：
- 建立儲存在 Artifact Registry 中的自訂基礎容器映像檔，預先安裝安全工具、可信任的開發人員擴充功能和核准的語言執行階段。
- 部署工作站叢集，並使用私有 IP 傳入和傳出流量，以及在 VPC Service Controls 範圍內。
- 設定 Cloud Workstations，透過 IAP 轉送工作階段流量。要求開發人員使用企業憑證進行驗證，並啟用多重驗證 (MFA)，同時強制執行最低權限角色 (例如 Cloud Workstations 使用者 (
roles/workstations.user))。 - 設定工作站設定時，請將逾時限制設為較低的值 (例如閒置兩小時後自動停止)。工作站重新啟動時，Cloud Workstations 會提取最新修補安全漏洞的容器映像檔，讓開發人員在乾淨的環境中工作。
請參閱下列 A04：密碼學失敗的最佳做法：
- 設定工作站設定，使用 CMEK 加密附加的永久磁碟。
CodeMender
CodeMender 是專門的自主 AI 工程代理，CodeMender 可以修補新發現的安全漏洞，並重寫現有的舊版程式碼，解決現有的安全漏洞。您可以在 Gemini Enterprise Agent Platform 中安裝及設定 CodeMender。
適用於下列項目：
- A03：軟體供應鏈故障
- A05：注入
- A06：不安全的設計
請參閱下列 A03：軟體供應鏈故障最佳做法：
- 將 CodeMender CLI 整合至本機開發人員工作區和 CI/CD 管道，掃描目標模組、驗證可利用性，並在提交程式碼前找出安全弱點。
- 將軟體組成分析 (SCA) 和依附元件安全漏洞報告匯入 CodeMender，執行概念性驗證攻擊驗證，並在開發人員審查前篩除誤判。
請參閱下列 A05：注入的最佳做法：
- 在獨立的本機沙箱中執行自動修補程式產生作業，改寫有安全漏洞的邏輯 (例如清除輸入內容)。建立提取要求前，請先確認單元測試通過，且 PoC 不再可供利用。
請參閱下列 A06：不安全設計的最佳做法：
- 使用 CodeMender 的疊代修補引擎重構舊版或不安全的架構程式碼邏輯，並提供明確的程式碼限制，在應用程式模組中強制執行安全設計模式。
- 對 CodeMender 生成的提取要求和差異維持人工審查，確認建議的變更符合安全程式設計指南。
機密運算
機密運算 可在處理資料時加密記憶體中的資料，藉此保護使用中的資料。機密運算使用硬體式受信任的執行環境 (TEE)，確保您的機密資料和加密金鑰無法由 Hypervisor、主機作業系統或基礎架構管理員存取。
適用於 A04：密碼編譯失敗。
請參閱下列最佳做法：
- 針對高度機密的工作負載 (例如個人識別資訊、財務記錄或專屬 AI 模型權重)，請使用機密 VM 或機密 Google Kubernetes Engine 節點。
- 如果多個機構必須匯集機密資料進行分析或 AI 訓練 (但不得向彼此公開原始資料)，請使用 Confidential Space 強制執行加密認證和資料隔離。
Firebase (Firebase 驗證、Firebase App Check 和 Firebase 安全性規則)
Firebase 提供以開發人員為中心的安全性控制項，涵蓋身分識別、用戶端驗證和資料庫存取權。Firebase 驗證負責處理使用者身分和工作階段管理作業，App Check 則會驗證用戶端應用程式的完整性，而 Firebase 安全性規則會對 Firestore 和 Cloud Storage 強制執行以屬性為基礎的存取權控制和結構定義驗證。
適用於下列項目：
- A01：存取控管失效
- A05：注入
- A07：驗證失敗
- A08：軟體或資料完整性失敗
請參閱下列 A01：存取權控管失效最佳做法：
- 在 Firebase 安全性規則中，將讀取和寫入作業的範圍限定為已通過驗證的使用者 ID。請勿使用寬鬆的預設規則，例如
allow read, write: if true;。 - 對於管理員角色，請使用 Firebase Admin SDK 在使用者的 ID 權杖上設定自訂聲明，並在安全性規則中驗證這些聲明，而不是允許用戶端設定檔寫入。
- 在 Firebase 安全性規則中強制執行 App Check，在資料庫層級封鎖未經驗證或偽造的用戶端存取要求。
請參閱下列 A05：注入的最佳做法：
- 在安全規則中強制執行結構化酬載驗證，方法是檢查傳入的文件欄位型別、字串長度和物件大小，在資料庫擷取資料前，拒絕格式錯誤或惡意的寫入酬載。
請參閱下列 A07：驗證失敗的最佳做法：
- 升級至提供 Identity Platform 的 Firebase 驗證，即可啟用企業防護功能，例如使用 TOTP 的多重驗證和封鎖功能。
- 使用 Firebase Admin SDK 在後端驗證 Firebase ID 權杖，再授予敏感應用程式資料的存取權。
- 使用偵錯供應商，為開發人員和 CI/CD 管道在暫存環境中產生臨時的範圍偵錯權杖。
請參閱下列 A08：軟體或資料完整性失敗的最佳做法：
- 強制執行採用專屬硬體的證明供應商，以驗證用戶端完整性。設定 App Check，使用 Android Play Integrity 和 Apple App Attest。
- 在 Cloud Run 和 Kubernetes Engine API 後端部署 App Check 權杖驗證中介軟體，拒絕來自遭盜用 API 金鑰、自動化指令碼或模擬環境的要求。
Fraud Defense
Fraud Defense 是一體式平台，可防範詐欺和濫用行為，包括保護網站的機器人、帳戶和交易。reCAPTCHA 是 Fraud Defense 的一部分，會評估存取嘗試的風險等級，藉此篩除機器人和其他形式的自動化及大量流量。
適用於 A07：驗證失敗。
請參閱下列最佳做法：
- 將 reCAPTCHA 與現有的 WAF (例如 Google Cloud Armor) 整合，在要求抵達驗證端點前，發出自動驗證或封鎖高風險的機器人流量。
- 在登入、密碼重設和工作階段續約端點保護帳戶。根據使用者登入速度和裝置指紋，取得帳戶入侵 (ATO) 風險分數。
- 在傳送外送簡訊前評估電話號碼風險設定檔，防範註冊和雙重驗證表單中的簡訊費用詐欺。
- 如要減少誤判情形，並訓練網站專屬的風險評估模型，請定期註解及傳送交易意見回饋。
- 在使用者登入和帳戶建立流程中檢查密碼，偵測提交的憑證是否出現在網路上第三方資料侵害資料庫中。
Google SecOps
Google Security Operations 是一個安全營運平台，整合了安全遙測分析 (SIEM)、自動化安全性調度管理和應變 (SOAR)，以及第一線的 Mandiant 威脅情報。
適用於下列項目：
- A02：安全性設定錯誤
- A09：安全性記錄和警示失敗
請參閱下列 A02：安全性設定錯誤的最佳做法：
- 將 Security Command Center 發現項目擷取至 Google SecOps，即可將靜態設定錯誤發現項目 (例如
PUBLIC_BUCKET_ACL或CMEK_DISABLED) 與即時網路和防火牆遙測資料合併。 - 建構自動化 SOAR 應變應對手冊，執行防堵行動。
- 使用 Gemini 加速分類錯誤設定，並取得錯誤設定資產、附加 IAM 角色和補救措施指南的綜合摘要。
請參閱下列 A09：安全性記錄和警示失敗的最佳做法：
- 將記錄遙測資料正規化為統合式資料模型 (UDM)，即可快速進行標準化的多雲端搜尋和關聯，不必耗費資源剖析原始記錄。
- 編寫 YARA-L 2.0 偵測規則，監控高風險的設定變更，例如停用 OS 登入、刪除記錄接收器，或修改 VPC Service Controls 範圍。
- 使用 Applied Threat Intelligence 策劃的偵測，根據 Mandiant 威脅情報資料評估事件資料。
- 使用 Gemini in Google SecOps，根據自然語言說明生成 YARA-L 偵測規則，並將複雜的多階段事件時間軸歸納為事件摘要，供主管參考。
Identity-Aware Proxy
IAP 會為透過 HTTPS 存取的應用程式和管理 TCP 連線建立中央授權層。IAP 會先驗證使用者身分和背景資訊，再授予 Cloud Run、App Engine、Compute Engine、GKE 和地端部署資源的存取權。
適用於下列項目：
- A01：存取控管失效
- A07：驗證失敗
請參閱下列 A01：存取權控管失效最佳做法：
- 根據使用者身分、群組成員資格和要求情境，對網頁應用程式、VM、 Google Cloud API 和 Google Workspace 應用程式強制執行精細的存取控制管理。
- 與 Agent Gateway 整合，為代理身分強制執行存取控管。
- 使用 IAP TCP 轉送功能，建立連往後端執行個體的加密 HTTPS 通道，並移除面向網際網路的 SSH (通訊埠
22) 和 RDP (通訊埠3389) 端點。
請參閱下列 A07：驗證失敗的最佳做法：
- 透過 IAP，使用 IAM 或 Cloud Identity 中佈建的身分，驗證存取管理介面和網頁應用程式的使用者。
- 在應用程式層的
x-goog-iap-jwt-assertion標頭中，驗證已簽署的 JWT 聲明。根據 Google 的公開金鑰驗證簽章，並確認對象 (aud) 聲明與後端服務 ID 相符。 - 為防止攻擊者規避 IAP 驗證，請設定 Cloud Run 輸入設定，只允許內部和 Cloud Load Balancing 流量，並封鎖對後端容器網址的直接公開存取權。如果是 VM 或 GKE 節點，請設定 VPC 防火牆規則，只接受來自負載平衡器 IP 範圍的輸入流量。
Identity and Access Management
Identity and Access Management (IAM) 可讓您管理 Google Cloud中服務和資源的精細存取權。IAM 包含下列功能：
- Privileged Access Manager：管理敏感 Google Cloud 資源的隨選暫時性權限提升
- Workload Identity Federation可讓工作負載使用聯合身分存取 Google Cloud 資源。
- 員工身分聯盟：可讓使用者透過聯盟身分存取資源。 Google Cloud
適用於下列項目：
- A01：存取控管失效
- A07：驗證失敗
請參閱下列 A01：存取權控管失效最佳做法：
- 使用預先定義的角色或自訂角色 (而非基本角色)，將權限限制在特定資源或使用者需求。
- 限制權限，只授予「服務帳戶使用者」(
roles/iam.serviceAccountUser) 和「服務帳戶憑證建立者」(roles/iam.serviceAccountTokenCreator) 角色。 - 使用 IAM 建議工具分析貴機構的有效使用記錄，並移除權限過高的帳戶。
- 在角色繫結中撰寫 IAM 條件，加入情境感知授權，並依據日期、時間或來源 IP 位址限制存取權。
- 部署主體存取邊界 (PAB) 政策，定義一組主體可存取的組織、資料夾或專案。如果攻擊者竊取有效工作階段，或服務帳戶意外獲得廣泛的 IAM 角色，當指定資源超出身分識別的指定邊界時，PAB 就會封鎖存取權。
- 在機構或資料夾層級附加 IAM 拒絕政策，封鎖高風險權限 (例如
iam.serviceAccountKeys.create或resourcemanager.projects.delete)。 - 設定 IAM 拒絕規則時，請在
exceptionPrincipals清單中宣告專屬的緊急存取安全群組。在拒絕條件中使用資源標記 (例如resource.matchTag('env', 'prod'))，封鎖對正式環境資源的破壞性動作，同時允許開發人員在開發沙箱專案中靈活運作。
請參閱下列 Privileged Access Manager 適用的 A07：驗證失敗最佳做法：
- 將重要管理員角色 (例如擁有者 (
roles/owner)、機構管理員 (roles/resourcemanager.organizationAdmin) 和安全管理員 (roles/iam.securityAdmin)) 從靜態 IAM 繫結轉換為 Privileged Access Manager 權限。設定這些權利，要求使用者在獲得提升權限前提供作業理由。 - 在正式環境中，設定 Privileged Access Manager 授權政策時，請指定強制核准者，例如中央 SecOps 群組或團隊主管。
- 在 Privileged Access Manager 授權中，將時間長度上限設為最短的實際作業時間 (例如，標準維護作業為兩小時，急用權限動作為 30 分鐘)。計時器到期後， Google Cloud 移除暫時性 IAM 角色繫結。
- 使用非授權 IAM 資源 (例如
google_project_iam_member或google_folder_iam_member，而非google_project_iam_policy或google_project_iam_binding) 管理 Terraform 基礎架構。這樣做可避免覆寫 Terraform 管道，或在管理員積極補救事件時，取消同步處理暫時的 Privileged Access Manager 角色繫結。 - 在 Privileged Access Manager 上啟用 Cloud 稽核記錄，記錄授權動作和到期事件。將這些記錄檔擷取至 Google SecOps，即可針對可疑的權限提升模式發出快訊，例如在非上班時間提出多項權限提升要求，或從非預期的地理位置重複提出要求。
請參閱下列 A07：適用於員工身分聯盟的驗證失敗最佳做法：
- 使用 SAML 2.0 或 OpenID Connect (OIDC) 部署員工身分集區，將外部識別資訊提供者與Google Cloud建立聯盟。
- 在工作團隊身分集區中設定工作階段時間長度，限制聯盟使用者權杖的生命週期。
- 在員工身分識別資訊提供者上強制執行屬性條件，以防範多租戶 IdP 權杖偽造或跨機構模擬。
- 對應外部群組成員資格，將 IAM 角色指派給同盟群組主體集 (例如
principalSet://iam.googleapis.com/.../attribute.group/security-engineers)。
請參閱下列適用於 Workload Identity 聯盟的 A07：驗證失敗最佳做法：
- 為外部工作負載建立 workload identity pool 和提供者。使用短期 OIDC 權杖，並透過安全權杖服務動態交換，取得幾分鐘後就會過期的臨時存取權杖。
- 對工作負載身分識別提供者強制執行屬性條件，確保外部多租戶平台無法從未經授權的存放區或帳戶向集區進行驗證。
- 將 IAM 角色直接繫結至特定主體集，並依自訂對應屬性篩選。
- 設定工作負載存取權時，請直接在目標資源上，將 IAM 角色授予聯盟
principalSet://識別碼。 - 如要強制執行 Workload Identity 聯盟，請在貴機構設定
constraints/iam.disableServiceAccountKeyCreation限制。
Identity Platform
Identity Platform 是客戶身分與存取權管理 (CIAM) 平台，專為 Google Cloud 客戶而生。Identity Platform 透過 SDK 和 API 提供驗證功能，支援多種通訊協定。Identity Platform 支援多重驗證、與第三方驗證服務整合，以及可稽核的活動追蹤。
適用於 A07：驗證失敗。
請參閱下列最佳做法：
- 為所有使用者啟用MFA。 優先採用可防範網路釣魚的方法，例如 TOTP (驗證器應用程式) 或 WebAuthn (生物特徵辨識和安全金鑰)。
- 使用
beforeCreate和beforeSignIn觸發程序部署封鎖 Cloud Run 函式，在儲存使用者或核發權杖前執行自訂安全碼。您可以透過這項做法封鎖拋棄式電子郵件網域、限制 IP 位址，或強制執行電子郵件驗證。 - 整合 reCAPTCHA Enterprise，評估登入、註冊和重設密碼要求是否為機器人流量、憑證填充嘗試和自動化濫用行為。
- 設定密碼政策，強制規定密碼長度下限、要求使用特定複雜字元 (例如數字和符號)，以及禁止使用容易猜到的字元序列。
- 如果使用手機進行 MFA，請設定簡訊區域，並啟用 reCAPTCHA SMS Defense，將驗證訊息限制在目標使用者所在國家/地區的國家/地區代碼。
Mandiant AI 安全諮詢解決方案
Mandiant AI 資安諮詢解決方案可在開發生命週期早期，評估您提議的軟體架構、業務流程和雲端部署。在您編寫任何程式碼之前，Mandiant 顧問會將第一線威脅情報套用至系統設計，協助您找出隱藏的邏輯缺陷、缺少的信任邊界和架構風險。
適用於 A06：不安全的設計。
請參閱下列最佳做法：
- 在開發開始前，先與 Mandiant 顧問合作，完成架構研討會，並從一開始就實作安全控管機制。
- 與威脅模型專家合作，繪製應用程式的資料流程圖。定義機密資料跨越信任邊界的範圍，找出必須強制執行嚴格驗證、加密和驗證控管措施的位置。
- 在架構研討會期間，使用結構化威脅模型架構 (例如 STRIDE)。Mandiant 顧問可根據實際的利用可能性和業務影響，協助您優先處理發現的設計缺陷。
- 為代理工作流程和 LLM 部署作業建立安全的 AI 管理基準，在 AI 代理、MCP 伺服器和企業後端資料來源之間，定義明確的信任邊界。
Model Armor
Model Armor 的設計宗旨是篩選 LLM 提示詞、回覆和 MCP 工具呼叫。Model Armor 會檢查生成式 AI 酬載，協助偵測並阻擋提示詞注入、越獄嘗試、惡意網址、惡意內容和機密資料外洩。
適用於下列項目：
- A05：注入
- A10：異常狀況處理不當
請參閱下列 A05：注入的最佳做法：
- 使用 Apigee 整合或 Agent Gateway，在 API Gateway 層級部署 Model Armor 政策，在流量抵達推論引擎或工具執行階段前，篩除傳入的提示和傳出的模型回覆。
- 在組織或資料夾層級設定底限設定，建立強制執行的基本安全防護措施，個別專案團隊無法略過。
- 針對公開端點，使用經過調整的信賴度門檻 (例如
LOW_AND_ABOVE或MEDIUM_AND_ABOVE)，建立自訂的 Model Armor 範本，偵測提示詞注入和越獄攻擊。 - 在 Model Armor 範本中啟用惡意網址偵測和 PDF 與檔案掃描功能，根據 Google 的威脅情報資料庫檢查內嵌網址。在執行前，捨棄含有惡意軟體或網路釣魚向量的提示。
- 在 Model Armor 範本中啟用 Sensitive Data Protection，檢查模型輸出流量。設定自動去識別化或遮蓋功能，在回應離開邊界前，將偵測到的私密/機密資料替換為預留位置。
請參閱下列 A10 最佳做法：異常狀況處理不當：
- 請設定應用程式程式碼來攔截
MATCH_FOUND判決，並傳回一般回應，這樣系統就不會預設執行提示或顯示原始例外狀況追蹤記錄。 - 在應用程式程式碼中導入「故障關閉」(故障安全) 架構，在 Model Armor API 呼叫遇到網路逾時、速率限制或未處理的 HTTP 5xx 錯誤時，拒絕傳入的生成式 AI 提示。
組織政策
機構政策可讓您透過程式輔助，集中控管機構的 Google Cloud 資源。
適用於下列項目：
- A01：存取控管失效
- A02：安全性設定錯誤
- A04：密碼編譯失敗
請參閱下列 A01：存取權控管失效最佳做法：
- 強制執行
constraints/storage.publicAccessPrevention覆寫嘗試授予allUsers或allAuthenticatedUsers存取權的值區層級身分與存取權管理政策或 ACL。 - 套用
constraints/iam.allowedPolicyMemberDomains，將 IAM 政策繫結嚴格限制為已驗證的 Google Workspace 或 Cloud Identity 客戶 ID。 - 在正式環境資料夾中強制執行
constraints/iam.disableServiceAccountKeyCreation，防止使用者下載服務帳戶金鑰，並強制工程團隊採用 Workload Identity 聯盟等短期替代方案。 - 強制執行
constraints/iam.automaticIamGrantsForDefaultServiceAccounts，以免 Google Cloud 自動將寬鬆的編輯者 (roles/editor) 角色授予預設服務帳戶。 - 如要滿足預先定義限制未涵蓋的需求，請部署自訂限制，強制執行精細的資源設定。建議您限制 VM 建立作業，僅允許使用核准的機器系列、限制永久磁碟佈建大小，或強制執行特定網路防火牆標記設定。
請參閱下列 A02：安全性設定錯誤的最佳做法：
- 使用
constraints/compute.requireShieldedVm要求使用 Shielded VM，協助保護 VM 免於核心 Rootkit、Bootkit 和韌體竄改。 - 強制執行
constraints/compute.requireOsLogin要求 Linux 執行個體使用 OS 登入，直接將 SSH 存取權連結至使用者的 IAM 身分和兩步驟驗證。 - 強制執行
constraints/compute.disableSerialPortAccess，禁止跨專案的互動式序列主控台連線。 - 強制執行
constraints/compute.skipDefaultNetworkCreation，這樣就不會建立預設虛擬私有雲網路，團隊必須建立自訂虛擬私有雲，並使用專屬子網路和嚴格的防火牆政策。 - 強制執行
constraints/sql.restrictPublicIp，讓 Cloud SQL 執行個體只接收私人 RFC 1918 內部 IP 位址，並使用constraints/compute.vmExternalIpAccess限制 VM 上的公開 IPv4 位址。 - 套用
constraints/gcp.resourceLocations，將資源建立作業限制在授權 Google Cloud 區域。
請參閱下列 A04：密碼學失敗的最佳做法：
- 如要強制執行 CMEK，請在機構或頂層資料夾套用
constraints/gcp.restrictNonCmekServices，將政策類型設為Deny，並列出支援的 Google Cloud 服務。強制執行限制前，請先確認每個目標服務的服務代理人存在，且已獲授相關金鑰環的 Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) 角色。 - 強制執行
constraints/gcp.restrictCmekCryptoKeyProjects，將金鑰選取範圍限制在專屬的 Cloud KMS 專案。
Secret Manager
Secret Manager 可讓應用程式和管道根據 IAM 授予的權限，存取具名密鑰的值。啟用後，與 Secret Manager 的互動會建立稽核追蹤記錄，可用於協助鑑識和滿足法規遵循需求。
適用於下列項目：
- A04：密碼編譯失敗
- A07：驗證失敗
請參閱下列 A04：密碼學失敗的最佳做法：
- 使用 CMEK 加密高價值密鑰，控管、輪替或撤銷用來包裝密鑰酬載的主要加密金鑰。
- 使用資料完整性總和檢查碼，在新增和存取密鑰版本時，維護及驗證密鑰資料的完整性。
- 跨多個區域複製密鑰，確保高可用性，並在地理位置部署區域發生災難時復原。
請參閱下列 A07：驗證失敗的最佳做法：
- 從原始碼、
.env檔案和容器建構設定中移除 API 金鑰等機密值，並將憑證儲存在 Secret Manager。使用Google Cloud 用戶端程式庫、GKE Secret Store CSI 驅動程式或 Cloud Run 密鑰繫結，在執行階段擷取解密值。 - 直接將 IAM 政策繫結套用至特定個別密鑰，只授予微服務 Secret Manager 密鑰存取者 (
roles/secretmanager.secretAccessor) 角色，讓微服務只能存取所需的特定密鑰。 - 在 Secret Manager 中設定自動輪替時間表。輪替間隔開始時，Secret Manager 會將
SECRET_ROTATE通知發布至指定 Pub/Sub 主題。設定 Cloud Run functions 或 Cloud Run 服務，讀取通知、產生新的密鑰值、將新版本新增至 Secret Manager，並銷毀已停用的版本。 - 啟用 Secret Manager 的 Cloud 稽核記錄，追蹤密鑰版本建立、毀損和酬載存取事件。將這些記錄傳送至 Google SecOps，以便在發生可疑存取事件時收到警報，例如遭入侵的服務帳戶在標準作業時間以外存取密鑰，或嘗試讀取未獲核准的密鑰資源。
Security Command Center Premium
Security Command Center Premium 可協助您找出並解決 Google Cloud環境和網頁應用程式中的安全設定錯誤和執行階段威脅，包括識別和驗證失敗。Web Security Scanner 服務可監控應用程式安全漏洞，包括 XML 外部實體 (XXE) 安全漏洞，並進行掃描，涵蓋 OWASP Top 10 控制項。
適用於下列項目：
- A02：安全性設定錯誤
- A05：注入
- A07：驗證失敗
- A08：軟體或資料完整性失敗
請參閱下列 A02：安全性設定錯誤的最佳做法：
- 套用內建架構 (例如 CIS 基準或 NIST)，使用 Compliance Manager 根據法規安全架構和業界基準，評估雲端設定。
- 啟用 Cloud Infrastructure Entitlement Management，管理有權存取雲端部署資源的身分，並降低設定錯誤造成的潛在安全漏洞。
- 檢查並修正 Web Security Scanner 發現的問題，以修正設定錯誤的 HTTP 回應安全標頭、無效的 CORS 來源標頭，以及混合內容服務。
請參閱下列 A05：注入的最佳做法：
- 啟用服務： 啟用虛擬機器威脅偵測和 Container Threat Detection 等服務。這些服務會掃描管理程序記憶體和核心事件，找出惡意指令碼、反向 Shell 和惡意軟體安裝作業 (使用「新增的二進位檔已執行」和「新增的程式庫已載入」偵測器)。
- 設定 Web Security Scanner，監控執行中的應用程式是否有跨網站指令碼攻擊 (XSS) 和 SQL 注入 (SQLi) 缺陷。
- 將 Security Command Center 發現項目整合至 Google SecOps 或第三方 SIEM，自動分類及事件應變。
請參閱下列 A07：驗證失敗的最佳做法：
- 監控記錄串流，並使用「Brute Force: SSH」(暴力攻擊：SSH) 和「Persistence: IAM Anomalous Grant」(持續性：IAM 異常授權) 偵測器，防範以憑證為基礎的攻擊。
- 使用「使用多重驗證或無密碼驗證」、「對 API 金鑰設定應用程式限制」和「要求輪替 API 金鑰」雲端控制項，偵測 MFA 未使用情況並監控 API 金鑰使用情形。
- 如要修正「工作階段 ID 外洩」問題，請將網頁後端設定為將工作階段權杖儲存在含有
HttpOnly和Secure標記的 HTTP Cookie 中。
請參閱下列 A08：軟體或資料完整性失敗的最佳做法：
- 設定 Web Security Scanner，掃描網路端點是否有以簽章為依據的執行錯誤，並在應用程式執行易受攻擊的 Apache Struts 版本時，產生嚴重程度高的
STRUTS_INSECURE_DESERIALIZATION發現項目。 - 如要修正
STRUTS_INSECURE_DESERIALIZATION發現項目，請升級有安全漏洞的框架程式庫版本，或部署 Assured OSS 來提取 Google 驗證的替代項目。
Sensitive Data Protection
Sensitive Data Protection 可掃描儲存在 bucket、資料庫、生成式 AI 提示或串流應用程式酬載中的任何潛在機密資料，協助防止資訊外洩。如果系統偵測到不允許的資料，Sensitive Data Protection 可以標記或遮蓋這類資料。
適用於下列項目：
- A04：密碼編譯失敗
- A09：安全性記錄和警示失敗
請參閱下列 A04：密碼學失敗的最佳做法：
- 啟用機密資料探索功能，持續掃描儲存空間和資料庫資產、產生資料剖析檔，並為稽核報表產生指標。
- 使用格式保留加密、加密雜湊或以金鑰為準的代碼化方式，去識別化機密資料。
- 部署可重複使用的集中管理去識別化範本，在各開發團隊中強制執行一致的加密遮蓋和檢查政策。
- 分析提示酬載，防止機密公司資料或 PII 外洩至生成式 AI 訓練管道。
請參閱下列 A09：安全性記錄和警示失敗的最佳做法：
- 設定 Logging 接收器，將應用程式記錄傳送至 Pub/Sub 主題。附加使用 Sensitive Data Protection API 的 Cloud Run 訂閱者，掃描並去識別化記錄酬載，然後將乾淨的記錄寫入最終的 Logging 值區。
- 在 Logging 接收器中使用排除篩選器，只將高風險的非結構化記錄 (例如原始應用程式錯誤、使用者註冊酬載和交易記錄) 透過清除管道傳送。
VirusTotal
VirusTotal API 是一種威脅情報和檔案掃描平台，可分析可疑檔案、網址、網域和 IP 位址，偵測惡意軟體、木馬程式和惡意酬載。將 VirusTotal API 整合至檔案擷取管道，即可在應用程式系統處理檔案前，掃描不受信任的上傳內容。
適用於下列項目：
- A08：軟體或資料完整性失敗
- A05：注入
請參閱下列 A08：軟體或資料完整性失敗的最佳做法：
- 部署自訂 YARA-X 簽章比對規則，掃描傳入的檔案結構，找出已知的惡意二進位和文字模式，偵測變種惡意軟體。
請參閱下列 A05：注入的最佳做法：
- 使用 VirusTotal Private Scanning 模組，即可掃描敏感上傳內容，且不會與第三方共用上傳的檔案。
- 在擷取程式碼中導入 API 頻率限制和例外狀況處理機制，以擷取 HTTP
429 Too Many Requests狀態碼。
VPC Service Controls
VPC Service Controls 可在 Google Cloud 資源周圍建立 perimeter，協助防範資料竊取和伺服器端偽造要求 (SSRF) 攻擊。除非輸入和輸出規則明確允許，否則 VPC Service Controls 會拒絕跨越 perimeter 邊界的 API 呼叫。
適用於下列項目：
- A01：存取控管失效
- A02：安全性設定錯誤
請參閱下列 A01：存取權控管失效最佳做法：
- 在服務邊界中納入重要服務 (例如 Cloud Storage、BigQuery、Spanner 和 Agent Platform)，將 API 存取權限制在授權的 VPC 網路和信任的身分。
- 在無伺服器資源上設定輸出邊界規則，防止未經授權的資料外洩，這類外洩事件通常是因輸出 API 呼叫外部非邊界目的地所致。
- 使用明確的輸入和輸出規則，限制跨界線和跨機構的 API 存取權，這些規則會指定核准的專案來源、目標 API 和呼叫端身分。
請參閱下列 A02：安全性設定錯誤的最佳做法：
- 將專案分組為專屬 perimeter，並依環境安全層級 (例如正式環境 perimeter) 整理。使用可透過虛擬私有雲存取的服務，限制可在 perimeter 內呼叫的內部 Google API。
- 透過虛擬私有雲網路，從無伺服器工作負載轉送輸出 API 要求。設定 Cloud Run 服務和 Cloud Run 函式，使用直連虛擬私有雲輸出流量或無伺服器 VPC 存取連接器，並將輸入流量嚴格設為僅限內部。
- 將 Access Context Manager 存取層級繫結至周邊的連入規則，評估公司 IP 子網路、已驗證的身分聲明和 Endpoint Verification 裝置健康狀態信號的組合。
- 維護預先核准的緊急事件應變「急用權限」管理程序，並針對任何非預期的邊界違規事件設定監控警告。
Wiz 服務
以下各節說明與Google Cloud整合的 Wiz 服務適用的 OWASP 前 10 大最佳做法。
Wiz Code
Wiz Code 可將雲端安全性延伸至開發人員工作流程和 CI/CD 管道。Wiz Code 會關聯程式碼到雲端的遙測資料、掃描基礎架構即程式碼 (IaC)、分析依附元件 (SCA)、偵測外洩的憑證，以及執行靜態應用程式安全測試 (SAST)。
適用於下列項目：
- A03：軟體供應鏈故障
- A05：注入
- A07：驗證失敗
請參閱下列 A03：軟體供應鏈故障最佳做法：
- 將 Wiz CLI 整合至 CI/CD 管道，如果提取要求將重大 CVE、外洩的密碼或嚴重的 IaC 設定錯誤導入受保護的分支，系統就會封鎖提取要求，防止合併。
- 為每個建構作業產生並匯出 SBOM，在 Wiz Cloud 中持續掌握供應鏈的能見度。
- 部署 Wiz Code IDE 擴充功能，即時提供開發人員意見回饋，在程式碼提交前找出有安全漏洞的套件、硬式編碼的 API 金鑰和語法錯誤。
- 在 CI/CD 管道中整合 Wiz Code 和 CodeMender，即可在偵測到有安全漏洞的第三方依附元件時，生成、測試及提交提取要求。
請參閱下列 A05：注入的最佳做法：
- 如果 SAST 掃描器偵測到未經適當清除的不受信任使用者輸入內容流入資料庫查詢或 OS 指令，則禁止合併提取要求。
- 將 Wiz Code 外掛程式整合至開發人員 IDE，在開發人員輸入不安全、串連 SQL 查詢或命令執行模式時，提供即時快訊。
- 當 Wiz Code 標示出注入漏洞時，請將資料流追蹤路徑傳送至 CodeMender，以草擬經過驗證的修復修補程式。
請參閱下列 A07：驗證失敗的最佳做法：
- 在開發人員 IDE、本機預先提交的 Hook 和 CI/CD 管道中，導入自動密碼掃描功能，以偵測外洩的憑證。
- 為防範憑證遭竊，請以動態短期權杖和身分繫結存取權 (例如 Workload Identity 聯盟或以 OIDC 為基礎的驗證)，取代靜態長期憑證。
- 實作自動化事件應變應對手冊，從程式碼、環境變數和建構記錄中移除偵測到的密碼。
Wiz Cloud
Wiz Cloud 會分析多雲端環境，找出安全設定錯誤、機密資料曝光和身分風險。Wiz Cloud 會使用 Wiz Security Graph 關聯基礎架構層的風險因素，突顯重大攻擊路徑。
適用於下列項目：
- A01：存取控管失效
- A02：安全性設定錯誤
- A04：密碼編譯失敗
- A06：不安全的設計
請參閱下列 A01：存取權控管失效最佳做法：
- 追蹤並標記 IAM 角色和政策中複雜的多躍點提權路徑，找出攻擊者可能橫向移動或提權的位置。
- 將使用者帳戶、服務帳戶和 AI 代理程式的有效存取權限，對應至重要資料存放區，並撤銷過度授權的權利。
- 將身分授權結果與編排平台整合，以即時 (JIT) 存取權取代永久管理員角色繫結。
- 監控及顯示資料移動情形，偵測正式環境 PII 何時複製或同步到不安全的暫存或開發環境。
請參閱下列 A02：安全性設定錯誤的最佳做法：
- 使用 Wiz Security Graph 將設定錯誤與多種攻擊因素相互關聯，評估雲端設定風險並決定處理的優先順序。
- 套用內建的法規遵循架構 (例如 OWASP 前 10 大、CIS 基準和 NIST)，根據業界標準評估雲端設定。
- 將 Wiz CLI 掃描器整合至 CI/CD 管道，以便在部署前檢查建構內容或修正 IaC 設定錯誤。
請參閱下列 A04：密碼學失敗的最佳做法：
- 請優先修正含有明文憑證、未經過雜湊處理的金鑰，或未經加密就儲存的機密資料的資料庫和儲存空間值區。
- 在 AI 訓練目錄、向量資料庫和 RAG 管線中執行 Wiz Cloud 資料探索，確認專屬資料和 PII 在 LLM 擷取前已遮蓋。
- 掃描環境找出未受管理的資料資產，並刪除多餘資料，盡可能縮小攻擊面。
請參閱下列 A06：不安全設計的最佳做法：
- 指示 Wiz Red Agent 分析邏輯架構介面，並模擬攻擊路徑，在部署至正式環境前找出不安全的設計瑕疵。
- 將 Wiz Red Agent 驗證的攻擊鏈脈絡資訊傳遞至 CodeMender，找出根本原因並產生經過測試的架構提取要求。
Wiz Defend
Wiz Defend 提供雲端偵測與回應 (CDR)、工作負載執行階段防護，以及 Kubernetes 准入安全防護。Wiz Defend 會監控控制層活動、偵測執行階段異常狀況、強制執行容器准入政策，以及觸發自動化遏止措施。
適用於下列項目：
- A08：軟體或資料完整性失敗
- A09：安全性記錄和警示失敗
請參閱下列 A08：軟體或資料完整性失敗的最佳做法：
- 設定 Wiz Defend 准入規則，檢查並拒絕嘗試以根層級權限執行容器、要求主機網路命名空間或啟用
privileged: true的 Kubernetes 部署資訊清單。 - 在正式環境中，使用
failurePolicy: Fail(fail-closed) 設定重要安全性許可網路掛鉤，在網路掛鉤無法連線時封鎖不受信任的容器。
請參閱下列 A09：安全性記錄和警示失敗的最佳做法：
- 使用記錄檔接收器將稽核記錄匯出 Google Cloud 至 Pub/Sub 主題，讓 Wiz Defend 擷取及分析控制層活動和工作負載事件。
- 在 GKE 叢集和高價值 Compute Engine VM 上部署 Wiz Runtime Sensor，偵測執行階段威脅、記憶體內攻擊和進行中的入侵活動。
- 自動執行防堵應對手冊，立即停用遭盜用的 IAM 服務帳戶，或隔離遭盜用的工作負載。
- 使用 Wiz Blue Agent 調查執行階段偵測結果，將即時程序遙測資料和身分背景資訊相互關聯，找出根本原因和受影響的資產。
維持 OWASP Top 10:2025 法規遵循狀態
Wiz 包含 OWASP Top 10 2025 法規遵循架構，可供您評估及監控安全狀態。OWASP Top 10 2025 法規遵循框架會將內建的 Wiz 政策對應至相關的 OWASP 風險類別，並在控制項不符規定時建立發現項目。您可以追蹤一段時間內的法規遵循分數。如有需要，您可以自訂 OWASP Top 10 2025 法規遵循架構，以符合業務需求。
後續步驟
如需其他最佳做法，請參閱安全性最佳做法目錄。