Cloud Armor 的最佳做法

您可以最佳化及調整 Google Cloud Armor 部署項目，保護服務免受阻斷攻擊 (DoS) 和網路攻擊。本文說明最佳做法，協助您強化應用程式的資安態勢、提升效能，並運用 Google 的全球基礎架構和安全系統，更有效率地防範威脅。

Cloud Armor 與 Google Cloud 負載平衡器整合。部署 Cloud Armor 時，您會建立由預先設定和自訂規則組成的安全性政策。接著，將這些政策附加至負載平衡器的後端服務，協助保護後端服務。

如要瞭解如何集中管理整個組織的 Cloud Armor 政策，並允許專案專屬規則，請參閱「使用自訂限制管理 Cloud Armor」。

建立安全性政策和規則

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

提供規則說明

您可以使用規則說明，進一步說明建立每項規則的原因和預期功能。description 欄位長度上限為 64 個字元，因此參照設定管理資料庫或其他存放區，是擷取背景資訊最有效率的方式。

考量優先順序間距

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

使用預覽模式

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

啟用 Google Cloud Armor Adaptive Protection

啟用 Adaptive Protection，為應用程式提供額外防護。Adaptive Protection 會監控流量，並視需要為安全性政策建議新規則。此外，建議您制定警告政策，確保適當人員能收到潛在攻擊的警示。Adaptive Protection 最適合用於防範大量攻擊。非巨流量攻擊可能不會觸發 Adaptive Protection。

啟用 JSON 剖析

如果應用程式在要求主體中傳送 JSON 內容，請務必啟用 JSON 剖析功能。如未啟用 JSON 剖析功能，Cloud Armor 就不會剖析預先設定 WAF 規則的要求主體 JSON 內容，結果可能會產生雜訊和偽陽性。詳情請參閱「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 (或任何其他剩餘規則) 評估這類流量。

如要在單一規則中達到類似的例外狀況，可以使用邏輯運算子結合比對條件。請注意，這種做法與雙規則範例的不同之處，在於後續規則的評估方式。舉例來說，下列運算式使用單一規則，拒絕 AU 流量，除非流量來自特定 IP 範圍 10.10.10.0/24：

expr: origin.region_code == 'AU' && !inIpRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1

只有在區域為 AU 且 IP 位址「不在」10.10.10.0/24 範圍內時，這項條件才會評估為 true (並觸發拒絕動作)。

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

找出掃描器的用戶端 IP 位址

安全性掃描器可以位於 Google 內部或外部。如要對應用程式進行外部和未經篩選的評估，可以明確允許以 IP 位址 (或其他權杖) 為依據的流量，再根據其他規則進行評估。

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

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

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

使用 reCAPTCHA 管理機器人

Cloud Armor 整合 Google 的 reCAPTCHA，可在網頁應用程式防火牆 (WAF) 層偵測機器人。在這項整合中，reCAPTCHA 會產生 reCAPTCHA 權杖，Cloud Armor 則會執行權杖評估程序，而非 reCAPTCHA。這麼做可以減少來源負載，進而降低成本，並將安全性控制項移至比後端更靠近使用者的位置。詳情請參閱漫遊器管理總覽。

設定頻率限制門檻

頻率限制是一項靈活且實用的功能，可協助防範濫用行為，並減輕大量威脅，例如憑證填充或第 7 層 (L7) 分散式阻斷服務 (DDoS) 攻擊。首次部署頻率限制時，請務必選擇適合應用程式的門檻。建議您先在預先發布版模式中強制執行。分析並瞭解流量設定檔後，即可調整頻率限制參數。此外，請務必考量您指派給頻率限制規則的優先順序。在系統根據頻率限制規則評估流量之前，優先順序較高的規則可能會明確允許或拒絕流量。

規則調整

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

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

導入任何預先設定的 WAF 規則時，您可以根據安全性需求和時間軸，選擇適當的敏感度等級。對於大多數必須符合貴組織安全性規定的應用程式，建議您從敏感度層級 1 開始。敏感度設為 1 的規則會使用高保真度簽章，並減少規則可能產生的雜訊。與較高敏感度相關聯的簽章可能會偵測並防範更多入侵嘗試，但代價是某些受保護的應用程式可能會出現雜訊。不過，如果工作負載有更嚴格的安全要求，則可能需要最高敏感度等級。在這些情況下，可能會出現大量雜訊或不相關的發現項目，您必須先進行調整，才能將安全性政策投入正式環境。

啟用詳細記錄功能

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

使用穩定版或 Canary 版規則

Cloud Armor 預先設定的 WAF 規則和代管規則，都提供穩定和初期測試版本。

  • 如果是預先設定的規則，OWASP 核心規則集 (CRS) 的更新會先發布至初期測試版本，然後再升級至穩定版。
  • 如果是代管規則，自動簽章更新會先發布至初期測試版本，然後升級至穩定版本 (或加速零時差規則)。

使用自動更新時，建議您將預先發布版模式中的初期測試規則設為較高優先順序，並將強制執行模式中的穩定規則設為較低優先順序。這種做法可讓您在規則變更影響正式環境流量前，先使用記錄檔預覽及驗證變更。如需設定操作說明，請參閱「使用初期測試預覽模式評估新規則」。

記錄和監控

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

使用 Security Command Center

Cloud Armor 會自動與 Security Command Center 整合。Cloud Armor 會將不同的發現項目匯出至 Security Command Center：

  • 允許的流量暴增
  • 拒絕率上升

請務必讓網站安全人員檢查這些發現項目。

選擇 Cloud Logging 取樣率

Cloud Armor 的每項要求記錄，都會使用全域外部應用程式負載平衡器或傳統版應用程式負載平衡器的記錄基礎架構。因此，Cloud Armor 記錄檔的生成作業會受到負載平衡器上設定的記錄檔取樣率影響。在主動調整及導入 Cloud Armor 時，建議將取樣率維持在 1。完成調整並導入 Cloud Armor 後，建議您保持啟用完整要求記錄功能，但您也可以選擇降低取樣率。全域外部應用程式負載平衡器和傳統版應用程式負載平衡器，預設都不會啟用記錄功能，因此請務必手動啟用。

注意：Adaptive Protection 記錄會顯示在 Google Cloud 控制台的network_security_policy資源下方，而非全域外部應用程式負載平衡器或傳統版應用程式負載平衡器下方。

使用 Cloud Monitoring 資訊主頁

清楚掌握 Cloud Armor 設定的運作情形至關重要。為簡化這項作業，您可以使用安全性資訊主頁。此外，您也可以直接從 Logging 將 Cloud Armor 記錄匯出至自己的平台。 如果您使用 Adaptive Protection，請務必為觸發的 Adaptive Protection 警告設定提報路徑。

一般管理

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

設定 Identity and Access Management 存取控管機制

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

盡量減少政策數量

Cloud Armor 政策可重複用於多項後端服務。建議您採用一組一致且可重複使用的安全性政策。

使用 Terraform

為確保設定可以復原，並在各專案中重現，建議您使用 Terraform。Cloud Armor 已針對正式發布版功能全面整合 Terraform。

透過 Google Kubernetes Engine 設定 Cloud Armor

如果您使用的是 Google Kubernetes Engine (GKE)，則必須透過 BackendConfig 參數設定 Cloud Armor 和其他輸入功能。建議您避免手動設定全域外部應用程式負載平衡器或傳統版應用程式負載平衡器，做為輸入點。如要進一步瞭解如何搭配 GKE 設定 Cloud Armor，請參閱「設定 Ingress 功能」。

設定 Cloud Armor 安全性政策後，您也可以使用 Kubernetes Gateway 搭配 GKE 啟用。請務必先建立 Cloud Armor 後端安全性政策，再於 GCPBackendPolicy 政策資源中參照該政策。如要啟用區域性閘道，則必須建立「區域性」Cloud Armor 後端安全性政策。