Cloud Armor 最佳做法

本頁提供最佳做法，協助您最佳化及調整 Google Cloud Armor 部署作業。

Cloud Armor 會與全域外部應用程式負載平衡器、傳統版應用程式負載平衡器或外部 Proxy 網路負載平衡器一併部署。部署 Cloud Armor 時，請將安全性政策附加至要保護的負載平衡器後端服務。安全政策由您決定的預先設定和自訂規則組成。

如要設定 Cloud Armor 政策，讓政策自動套用至貴機構的所有專案，並允許個別專案新增專屬規則，請參閱使用自訂限制管理 Cloud Armor 的指南。這種做法可讓您集中管理整個機構的安全政策，同時維持個別專案需求的彈性。

建立安全性政策和規則

下列各節提供新安全政策和規則的最佳做法與建議。

提供規則說明

使用規則說明提供額外背景資訊，說明建立各項規則的原因和規則的預期功能。「說明」欄位最多只能輸入 64 個字元，因此參照設定管理資料庫或其他存放區，是擷取內容最有效率的方式。

考慮優先順序間距

首次設定規則時，請為每個規則優先順序值保留至少 10 的間隔。舉例來說，安全性政策中的前兩條規則可能分別具有 20 和 30 的優先順序。這樣一來，您就能在需要時插入更多規則。此外，建議您將類似規則分組，並在各組之間保留較大的間隔。

使用預覽模式

安全政策規則 (包括 Open Web Application Security Project (OWASP) 簽章) 可能會對應用程式造成無法預測的影響。使用預覽模式評估導入規則是否會對實際工作環境流量造成負面影響。

啟用 JSON 剖析

如果應用程式會在 POST 要求的內文中傳送 JSON 內容，請務必啟用 JSON 剖析功能。如果未啟用 JSON 剖析功能，Cloud Armor 就不會剖析 POST 主體的 JSON 內容，以套用預先設定的 WAF 規則，結果可能會產生雜訊和誤判。詳情請參閱 JSON 剖析。

測試邏輯

當規則的相符條件評估結果為 true 時，就會觸發規則。舉例來說，如果要求區域碼為 AU，相符條件 origin.region_code == 'AU' 的評估結果就會為 true。如果優先順序較高的規則評估結果為 true，系統就會忽略優先順序較低規則中的動作。在下列範例中，假設您要建立安全性政策，封鎖 AU 區域的使用者，但 IP 位址範圍 10.10.10.0/24 內的流量除外。請參考下列安全性政策，其中包含兩項規則：

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2

在本範例中，Rule1 允許來自 IP 位址範圍 10.10.10.0/24 的流量。由於 Rule1 是優先順序較高的規則，因此系統會先允許這類流量，再根據 Rule2 評估流量，也就是說，Cloud Armor 不會根據 Rule2 (或任何其他剩餘規則) 評估流量。

建立 Cloud Armor 政策時，請測試規則的邏輯，確保達到預期行為。為此，我們建議您產生合成流量，瞭解哪些規則會封鎖流量，並確認結果是否與規則設計決策一致。如果不確定要求在系統中的流向，請使用預覽模式查看符合要求的規則。

找出掃描器的來源 IP 位址

安全掃描器可位於 Google 內部或外部。如要對應用程式進行外部評估，且不套用任何篩選條件，您可以在根據任何其他規則評估應用程式之前，明確允許根據 IP 位址 (或其他權杖) 傳送流量。

在安全性政策中分組及排序規則

您的應用程式可能服務不同的客戶子集。在下列範例中，您想拒絕來自特定地理區域或 IP 範圍的流量，因此在政策中設定第一條規則來拒絕這類流量。此外，您也想明確允許部分流量進入應用程式，但不要經過安全性政策處理。以這個範例來說，我們建議採用下列規則優先順序結構 (從最高優先順序到最低優先順序)：

  1. 明確拒絕規則 (ASN、區域、IP 範圍)
  2. 信任的明確允許規則 (掃描器、信任的系統 - 使用時務必極度謹慎)
  3. 安全性規則 (OWASP、自訂規則)
  4. 明確允許規則 (ASN、標頭值是否存在、IP 範圍)
  5. 預設拒絕規則

設定頻率限制門檻

頻率限制是一項實用且彈性的功能，可防止濫用行為，並減輕大量威脅，例如憑證填塞或第 7 層 DDoS 攻擊。首次部署速率限制時，請務必選擇適合應用程式的門檻。建議您先以預覽模式強制執行。分析及瞭解流量設定檔後，即可調整速率限制參數。此外，請務必考量您為速率限制規則指派的優先順序。在根據速率限制規則評估流量之前，優先順序較高的規則可能會明確允許或拒絕流量。

規則調整

網頁應用程式可能會允許看似攻擊的要求，也可能允許 (甚至要求) 使用者傳送符合預先設定 WAF 規則中簽章的要求。請務必先根據應用程式驗證 Cloud Armor 規則，並解決可能與應用程式無關的任何發現，再停用正式版應用程式的預覽模式，以升級規則。以下各節將說明調整預先設定 WAF 規則的最佳做法和建議。

選擇預先設定的 WAF 規則敏感程度

導入任何預先設定的 WAF 規則時，您可以根據安全性需求和時間表，選擇適當的敏感度層級。對於大多數必須符合貴機構安全規定的應用程式，建議您從敏感度等級 1 開始。為敏感度 1 設定的規則會使用高保真簽章，並減少規則可能產生的雜訊。如果簽章的敏感度較高，可能會偵測並防範更多攻擊，但部分受保護的應用程式可能會因此產生干擾。不過，如果工作負載有更嚴格的安全要求，可能需要最高敏感度等級。在這些用途中，可能會有大量干擾或無關的發現，您必須先使用微調功能解決這些問題，才能將安全政策投入實際工作環境。

啟用詳細記錄功能

如要進一步瞭解哪些要求屬性和酬載會觸發特定 WAF 規則，請啟用詳細記錄。詳細記錄會提供觸發特定規則的要求詳細資料，包括要求中違規部分的程式碼片段，有助於排解問題及調整 Cloud Armor。由於詳細記錄功能可能會將使用者要求內容記錄在 Cloud Logging 中，因此記錄檔中可能會累積使用者 PII。因此，我們不建議長時間啟用詳細記錄功能，並執行實際工作環境工作負載。

使用穩定或 Canary 規則

Cloud Armor 預先設定的 WAF 規則分為兩種類型：穩定版和 Canary 版。當現有 OWASP 核心規則集 (CRS) 新增規則時，我們會先將規則發布至 Canary 規則建構版本，然後自動發布至穩定版規則建構版本。建議您在測試環境中部署 Canary 規則，以便查看環境中任何變更和新增項目的影響。您可以在「調整 Cloud Armor WAF 規則」頁面查看規則名稱，確認 Canary 版本是否與穩定版本同步。

記錄和監控

以下各節提供設定記錄和監控功能的最佳做法和建議。

選擇 Cloud Logging 取樣率

Cloud Armor 的單次要求記錄會使用全域外部應用程式負載平衡器或傳統版應用程式負載平衡器的記錄基礎架構。因此，Cloud Armor 記錄的產生作業會受到負載平衡器上設定的記錄取樣率影響。建議您在積極調整及導入 Cloud Armor 時，將取樣率設為 1。完成 Cloud Armor 的調整和實作後，建議您保持開啟完整要求記錄功能；不過，您可能偏好降低取樣率。全域外部應用程式負載平衡器和傳統版應用程式負載平衡器預設都不會啟用記錄，因此請務必手動啟用記錄功能。

使用 Cloud Monitoring 資訊主頁

清楚瞭解 Cloud Armor 設定中發生的情況至關重要。為簡化這個程序，您可以改用安全性資訊主頁。此外，您也可以直接從 Logging 將 Cloud Armor 記錄匯出至自己的平台。

一般管理

以下內容提供設定 Cloud Armor 的其他最佳做法和建議。

設定身分與存取權管理存取權控管

請遵循一般 Trusted Cloud IAM 最佳做法，確保適當人員擁有 Cloud Armor 的存取權。您必須具備 Compute 安全性管理員角色，才能設定、修改、更新及刪除 Cloud Armor 安全性政策。此外，如要將 Cloud Armor 安全性政策附加至後端服務，您必須具備 Compute Network Admin 角色或 compute.backendServices.setSecurityPolicy 權限。

盡量減少政策數量

Cloud Armor 政策可在多個後端服務中重複使用。建議您使用一組可重複使用的安全性政策。

使用 Terraform

為確保設定可輕鬆復原，並在各專案中重現，建議使用 Terraform。Cloud Armor 已全面整合 Terraform，可支援正式發布的功能。