頻率限制簡介

Google Cloud Armor 提供多項功能，可協助保護 Google Cloud 應用程式，防範各種第 3 層和第 7 層攻擊。以頻率為基礎的規則可協助您保護應用程式，避免受到會導致執行個體超載及迫使正當使用者無法存取資源的大量要求。

頻率限制可執行下列操作：

  • 避免任何特定用戶端耗盡應用程式資源。
  • 保護應用程式執行個體，避免用戶端要求頻率出現不穩定且無法預測的尖峰。

此外，當資源收到來自少數用戶端的大量流量時，您可以防止其他用戶端受到這些流量高峰的影響，讓資源盡可能處理更多要求。

Cloud Armor 提供兩種以速率為準的規則：

  • Throttle。您可以將個別用戶端限制在使用者設定的門檻，藉此強制執行每個用戶端或所有用戶端的要求上限。
  • 根據頻率封鎖。您可以根據每個用戶端，對符合規則的要求設定頻率限制，如果用戶端超過使用者設定的門檻，則可暫時禁止這些用戶端存取一段時間。

如果規則設定為根據速率禁止動作，之後就無法變更為節流動作。不過，如果您設定的規則動作為節流，之後可以改為根據頻率封鎖。詳情請參閱「將節流規則變更為以頻率為依據的禁止規則」。

Cloud Armor 會對每個相關聯的後端套用頻率限制門檻。舉例來說，如果您有兩項後端服務，並設定每分鐘 1,000 項要求的速率限制規則，則每項後端服務每分鐘可接收 1,000 項要求，Cloud Armor 才會套用規則動作。

您可以使用預覽模式並檢查要求記錄，預覽安全性政策中頻率限制規則的效果。

Cloud Armor 頻率限制和服務頻率限制

Cloud Armor 頻率限制和服務頻率限制是不同的頻率限制策略：

  • Cloud Armor 頻率限制：在網路邊緣的負載平衡器上強制執行。使用 Cloud Armor 頻率限制，防範不受信任用戶端的分散式阻斷攻擊 (DDoS)。
  • 服務頻率限制：這項限制會在內部應用程式負載平衡器和 Secure Web Proxy 上強制執行。使用服務頻率限制，管理可信任但可能行為不當的用戶端，並盡可能提高最重要流量的服務可用性。

詳情請參閱「服務速率限制總覽」。

識別用戶端以設定頻率限制

Cloud Armor 會使用下列金鑰類型匯總要求並強制執行頻率限制，藉此識別個別用戶端，以便限制頻率：

  • 全部：針對符合規則比對條件的所有要求，使用單一金鑰。
  • IP：每個用戶端 IP 位址的專屬金鑰，其要求符合規則比對條件。
  • HTTP_HEADER：每個已設定名稱的專屬 HTTP 標頭值，都有一個專屬鍵。金鑰值會截斷為標頭值的前 128 個位元組。如果沒有這類標頭，或您嘗試將這類金鑰類型用於外部 Proxy 網路負載平衡器，金鑰類型預設為 ALL。
  • XFF_IP：每個原始用戶端 IP 位址的專屬金鑰，也就是 X-Forwarded-For HTTP 標頭中指定 IP 清單的第一個 IP 位址。如果沒有這類標頭、值不是有效的 IP 位址，或您嘗試將這個金鑰類型與外部 Proxy 網路負載平衡器搭配使用，金鑰類型會預設為 IP 位址。
  • HTTP_COOKIE：每個 HTTP Cookie 值的專屬金鑰，其名稱已設定。鍵值會截斷為 Cookie 值的前 128 個位元組。如果沒有這類 Cookie，或您嘗試將這個金鑰類型與外部 Proxy 網路負載平衡器搭配使用，金鑰類型會預設為 ALL。
  • HTTP_PATH：HTTP 要求的網址路徑。鍵值會截斷為前 128 個位元組。
  • SNI：HTTPS 要求的 TLS 工作階段中的伺服器名稱指示。 金鑰值會截斷為前 128 個位元組。在 HTTP 工作階段中，金鑰類型預設為 ALL。
  • REGION_CODE：要求來源的國家/地區。
  • TLS_JA4_FINGERPRINT：如果用戶端使用 HTTPS、HTTP/2 或 HTTP/3 連線，則為 JA4 TLS/SSL 指紋。如未提供，金鑰類型預設為 ALL。如要進一步瞭解 JA4，請參閱規則語言參考資料。
  • TLS_JA3_FINGERPRINT：如果用戶端使用 HTTPS、HTTP/2 或 HTTP/3 連線，則為 JA3 TLS/SSL 指紋。如未提供，金鑰類型預設為 ALL。
  • USER_IP：來源用戶端的 IP 位址，包含在 userIpRequestHeaders 下設定的標頭中，且其值由上游 Proxy 填入。如果沒有 userIpRequestHeaders 設定，或無法從中解析 IP 位址，金鑰類型會預設為 IP。詳情請參閱規則語言參考資料。
  • ASN：原始用戶端的自治系統編號。如果 ASN 無法使用，金鑰類型會預設為 ALL。

您可以單獨使用上述金鑰，也可以根據最多三個金鑰的組合套用頻率限制。您可以使用多個 HTTP-HEADER 或 HTTP-COOKIE 鍵，但其他類型的鍵只能使用一個。詳情請參閱「根據多個金鑰設定速率限制」。

選擇依據頻率禁止和節流頻率限制規則

Cloud Armor rate-based ban 和 throttle 頻率限制規則處理流量超出設定門檻的方式不同。

  • rate_based_ban：如果要求率超過定義的門檻，Cloud Armor 會在指定期間內，封鎖來自這些要求來源或目標的所有後續要求。
  • throttle：不封鎖所有流量，而是將要求速率限制在定義的上限。節流可讓部分流量通過，但會控制速率，避免過載。

最適合的規則取決於您的具體需求和處理的流量類型。舉例來說，如果遭受 DDoS 攻擊，依據頻率禁止存取可能更適合快速封鎖惡意流量。或者，如果合法流量突然激增，建議您選擇調節，在維持服務可用性的同時，避免系統超載。

限制流量

規則中的 throttle 動作可讓您強制執行每個用戶端的要求門檻，保護後端服務。這項規則會強制執行門檻，限制來自每個用戶端的流量，前提是這些用戶端符合規則中的比對條件。門檻設定為指定時間間隔內的要求數量。

舉例來說，您可以將要求門檻設為 1,200 秒 (20 分鐘) 內 2,000 個要求。如果用戶端在任何 1,200 秒內傳送 2,500 項要求，系統會對用戶端約 20% 的流量進行節流，直到允許的要求量等於或低於設定的門檻。

當用戶端的流量速率低於或等於 rate_limit_threshold_count時，要求會遵循conform_action，這項動作一律為 allow。要求通過安全性政策，可抵達目的地。當用戶端的流量速率超過指定的 rate_limit_threshold_count 時，Cloud Armor 會對超過限制的要求套用 exceed_action (可以是 deny 或 redirect)，直到門檻間隔結束。

您可以設定下列參數來控制動作：

  • rate_limit_threshold_count：指定時間間隔內，每個用戶端可有的要求量。最小值為 1，最大值為 1,000,000。
    • interval_sec：時間間隔的秒數。值必須為 10、30、60、120、180、240、300、600、900、1200、1800、2700 或 3600 秒。
  • exceed_action：當要求超過 rate_limit_threshold_count 時，Cloud Armor 會套用設定的 exceed_action。exceed_action 的可能值如下：
    • deny(status)：系統會拒絕要求，並傳回指定的狀態碼。有效值為 403 Forbidden、404 Page Not Found、429 Too Many Requests 和 502 Bad Gateway。建議使用 429 Too Many Requests 狀態碼。
    • redirect：根據 exceed_redirect_options 參數，要求會重新導向至 reCAPTCHA 評估或其他網址。
  • exceed_redirect_options：當 exceed_action 為 redirect 時，請使用這個參數指定重新導向動作：
    • type：重新導向動作的類型，可為 GOOGLE_RECAPTCHA 或 EXTERNAL_302。
    • target：重新導向動作的目標網址。僅適用於 type 為 EXTERNAL_302 時。
  • conform_action：要求數量低於 rate_limit_threshold_count 時執行的動作。這項操作一律是 allow 操作。

根據要求比率禁止用戶端

規則中的 rate_based_ban 動作可讓您強制執行每個用戶端的門檻，暫時禁止超過限制的用戶端，方法是針對用戶端在可設定的時間範圍內的所有要求，套用已設定的 exceed_action。門檻設定為指定時間間隔內的指定要求數量。只要流量符合指定的比對條件並超過設定的門檻，您就能在使用者設定的時間範圍內暫時禁止流量 ('ban_duration_sec')。

舉例來說，您可能會將要求門檻設為 1,200 秒 (20 分鐘) 內 2,000 個要求。如果用戶端在 1,200 秒內傳送 2,500 項要求，Cloud Armor 會對該用戶端超過 2,000 項要求門檻的流量套用 exceed_action，直到 1,200 秒結束，並持續您設定的禁止時間長度。舉例來說，如果將禁止時間長度設為 3600，系統會在門檻間隔結束後，禁止來自用戶端的流量 3,600 秒 (一小時)。

如果用戶端的要求比率低於頻率限制門檻，要求就能立即傳送至後端服務。如果用戶端的流量速率超過指定的 rate_limit_threshold_count，Cloud Armor 會在剩餘的門檻間隔和接下來的 ban_duration_sec 秒內，對來自該用戶端的所有傳入要求套用 exceed_action，無論是否超過門檻。

如果這樣設定，偶爾超出允許要求比率的新用戶端可能會遭到封鎖。為避免這種情況，並只禁止經常超出要求比率的用戶端，您可以選擇根據額外的 (最好是較長的) 閾值設定 (稱為 ban_threshold_count)，追蹤用戶端總要求數。在這種模式下，只有在要求比率超過設定的 ban_threshold_count 時，用戶端才會在設定的 ban_duration_sec 內遭到禁止。如果要求率未超過 ban_threshold_count，系統會持續將要求率限制在 rate_limit_threshold_count。為達到ban_threshold_count目的，系統會計算來自用戶端的總要求數，包括節流前所有傳入的要求。

這些參數可控制 rate_based_ban 規則的動作：

  • rate_limit_threshold_count：指定時間間隔內，每個用戶端可有的要求量。最小值為 1 個要求，最大值為 10,000 個要求。
    • interval_sec：時間間隔的秒數。值必須為 10、30、60、120、180、240、300、600、900、1200、1800、2700 或 3600 秒。
  • exceed_action：要求超過 rate_limit_threshold_count 時，Cloud Armor 會套用設定的 exceed_action。exceed_action 的可能值如下：
    • deny(status)：要求遭到拒絕，並傳回指定的狀態碼。有效值為 403 Forbidden、404 Page Not Found、429 Too Many Requests 和 502 Bad Gateway。建議使用狀態碼 429 Too Many Requests。
    • redirect：系統會根據 exceed_redirect_options 參數，將要求重新導向至 reCAPTCHA 評估或不同網址。
  • exceed_redirect_options：當 exceed_action 為 redirect 時，請使用這個參數指定重新導向動作：
    • type：重新導向動作的類型，可以是 GOOGLE_RECAPTCHA 或 EXTERNAL_302。
    • target：重新導向動作的目標網址。只有在 type 為 EXTERNAL_302 時，這個網址指定目標才適用。
  • conform_action：要求數量低於 rate_limit_threshold_count 時執行的動作。這項動作一律為 allow 動作。
  • ban_threshold_count：指定時間間隔內，每個用戶端可有的要求量，超過這個數量 Cloud Armor 就會禁止要求。如果指定，當超過 rate_limit_threshold_count 的要求數量也超過這個 ban_threshold_count 時，系統會在設定的 ban_duration_sec 內禁止使用該金鑰。
    • ban_threshold_interval_sec：ban_threshold_count 的時間間隔 (以秒為單位)。ban_threshold_interval_sec 值必須為 10、30、60、120、180、240、300、600、900、1200、1800、2700 或 3600 秒。
  • ban_duration_sec：interval_sec 時間到期後，用戶遭禁止存取的額外秒數。ban_duration_sec 值必須是 60、120、180、240、300、600、900、1200、1800、2700 或 3600 秒。

預設頻率限制安全性政策

在建立負載平衡器時設定預設安全政策時，預設門檻為每分鐘 500 個要求 (分別為 rate_limit_threshold_count 和 interval_sec 的 500 和 60)。如要選取其他門檻，建議您按照下列步驟調整參數：

  1. 啟用 Cloud Logging，並查詢 Cloud Armor 保護的後端服務，在一天或更長時間內，每個 IP 位址每分鐘收到的要求數量上限。

    舉例來說，假設您認為收到的網路流量有 99% 不會受到速率限制規則影響，在這種情況下，建議您將頻率限制門檻設為第 99 個百分位數，也就是 Cloud Logging 資料產生的分布中，每個 IP 位址每分鐘的要求數量上限。

  2. 如果發現預設頻率限制規則仍會封鎖合法流量，請考慮採取下列其他步驟：

    1. 啟用快取 (Cloud CDN 或 Media CDN)。
    2. 延長調節時間間隔 (每隔幾分鐘接收要求，而非每 60 秒)。
    3. 在第一波攻擊過後，您可以封鎖用戶端，進一步降低攻擊影響。Cloud Armor rate_based_ban 動作可讓您禁止在使用者指定的時間範圍內，超出限制次數過多的所有用戶端。舉例來說，如果用戶在一分鐘內超過限制 10 次，就會遭到封鎖 15 分鐘。

門檻強制執行

系統會根據您部署 HTTP(S) 後端服務的各個 Google Cloud 區域，分別強制執行設定的節流和依費率禁止閾值。舉例來說，如果服務部署在兩個區域，這兩個區域都會對每個金鑰套用設定的頻率限制門檻，因此後端服務可能會遇到跨區域匯總流量，達到設定門檻的兩倍。如果設定的門檻為 5,000 個要求，後端服務可能會從一個區域收到 5,000 個要求，並從第二個區域收到 5,000 個要求。

不過，如果是 IP 位址類型的金鑰，可以合理假設來自相同用戶端 IP 位址的流量，會導向最靠近後端部署區域的區域。在這種情況下，無論後端服務部署在哪些區域，都可以考慮在後端服務層級強制執行頻率限制。

請注意，強制執行的頻率限制為概略值，與設定的門檻相比，可能不完全準確。此外，在極少數情況下，由於內部轉送行為，系統可能會在您部署的區域以外的區域強制執行頻率限制，進而影響準確度。因此，建議您僅將頻率限制用於減少濫用行為，或維持應用程式和服務可用性，而非強制執行嚴格的配額或授權規定。

根據 REGION_CODE 限制頻率時，系統會考量要求來源區域，而不會考量後端服務中後端的區域，無論後端類型為何。後端包括執行個體群組、負載平衡器支援的任何類型網路端點群組 (NEG)，以及 Cloud Storage bucket。如要查看支援的後端，請參閱「安全性政策總覽」。

記錄

Cloud Logging 會在要求記錄中記錄安全性政策名稱、相符的速率限制規則優先順序、規則 ID、相關聯的動作和其他資訊。如要進一步瞭解記錄功能，請參閱「使用要求記錄功能」。

與 reCAPTCHA 整合

您可以對部分 reCAPTCHA 資源套用頻率限制，藉此減少權杖濫用情形，並限制權杖重複使用。這些資源包括動作權杖、工作階段符記和豁免 Cookie。如要進一步瞭解如何搭配使用頻率限制和 reCAPTCHA，請參閱機器人管理總覽。

自訂錯誤回應

您可以對 Cloud Armor 頻率限制套用自訂錯誤回應，包括 throttle 和 rate_based_ban 流量。系統強制執行這些限制時，會向使用者傳送自訂錯誤訊息。此外，使用全域外部應用程式負載平衡器時，您可以為負載平衡器或後端執行個體產生的特定 HTTP 狀態碼設定自訂錯誤回應。

如要進一步瞭解自訂錯誤回應，請參閱「自訂錯誤回應總覽」。如要設定自訂錯誤回應，請參閱「設定自訂錯誤回應」。

Cloud Armor 搭配 Cloud Service Mesh

您可以為服務網格設定內部服務安全政策，對每個用戶端強制執行全域伺服器端頻率限制，有助於公平分配服務的可用容量，並降低惡意或行為不當的用戶端造成服務過載的風險。您可以將安全性政策附加至 Cloud Service Mesh 端點政策，在伺服器端對傳入流量強制執行頻率限制。不過，如果您使用 TCP 流量轉送，就無法設定 Cloud Armor 安全性政策。如要進一步瞭解如何搭配使用 Cloud Armor 和 Cloud Service Mesh，請參閱「使用 Cloud Armor 設定頻率限制」。

後續步驟