頻率限制簡介

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

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

• 避免任何特定用戶端耗盡應用程式資源。
• 保護應用程式執行個體，避免發生客戶端要求頻率的異常和無法預測的尖峰。

此外，如果資源受到少數用戶端的大量流量影響，您可以防止其他用戶端受到少數用戶端的大量流量尖峰影響，讓資源能夠盡可能處理大量要求。

Google Cloud Armor 有兩種以費率為準的規則：

1. 節流：您可以將個別用戶端的節流設為使用者設定的門檻，藉此強制執行每個用戶端或所有用戶端的最大要求限制。
2. 以頻率為依據的禁止：您可以針對符合規則的要求設定頻率限制，並在用戶設定的一段時間內，暫時禁止這些用戶端。

如果您設定的規則含有以頻率為依據的禁止動作，就無法在日後將其變更為節流動作。不過，如果您設定的規則含有節流動作，日後可以將其變更為以頻率為準的封鎖動作。詳情請參閱「根據多個鍵限制頻率」。

Google Cloud Armor 會將頻率限制門檻套用至每個相關聯的後端。舉例來說，如果您有兩個後端服務，並且設定的速率限制規則門檻為每分鐘 1,000 個要求，則在 Google Cloud Armor 套用規則動作之前，每個後端服務每分鐘可以收到 1,000 個要求。

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

找出要進行頻率限制的用戶端

Google Cloud Armor 會使用下列索引鍵類型匯總要求並強制執行頻率限制，藉此識別個別用於頻率限制的用戶端：

• ALL：針對要求符合規則比對條件的所有用戶端，提供單一索引鍵。
• 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 Network Load Balancer 中使用此鍵類型，則鍵類型預設為 ALL。
• HTTP_PATH：HTTP 要求的網址路徑。鍵值會截斷至前 128 個位元組。
• SNI：HTTPS 要求 TLS 工作階段中的伺服器名稱指示。鍵值會截斷至前 128 個位元組。在 HTTP 工作階段中，金鑰類型預設為「ALL」。
• REGION_CODE：發出要求的國家/地區。
• TLS_JA3_FINGERPRINT：如果用戶端使用 HTTPS、HTTP/2 或 HTTP/3 進行連線，則為 JA3 TLS/SSL 指紋。如果無法使用，則金鑰類型預設為 ALL。如要進一步瞭解 JA3，請參閱規則語言參考資料。
• USER_IP：來源用戶端的 IP 位址，包含在 userIpRequestHeaders 下設定的標頭中，值則由上游 Proxy 填入。如果沒有 userIpRequestHeaders 設定，或無法從中解析 IP 位址，則索引鍵類型預設為 IP。詳情請參閱規則語言參考資料。

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

選擇以頻率為依據的停權和節流頻率限制規則

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

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

最適合的規則取決於您的具體需求和所處理的流量類型。舉例來說，如果您遭受 DDoS 攻擊，基於頻率的封鎖機制可能更適合快速封鎖惡意流量。另一方面，如果您遇到合法流量突然激增的情況，節流可能會是更好的做法，可在維持服務可用性的同時避免超載。

流量節流

規則中的 throttle 動作可讓您強制執行個別用戶端要求門檻，以保護後端服務。這項規則會強制設下閾值，限制符合規則中相符條件的每個用戶端的流量。系統會將閾值設為指定時間間隔內的指定要求數量。

舉例來說，您可以將要求門檻設為 1,200 秒 (20 分鐘) 內的 2,000 個要求。如果用戶端在任何 1,200 秒的時間範圍內傳送 2,500 個要求，用戶端流量會受到限制，直到允許的要求量達到或低於設定的門檻為止。

當用戶端的流量率低於或等於 rate_limit_threshold_count 時，要求會遵循 conform_action，而這通常是 allow 動作。系統會透過安全性政策允許要求，並允許要求到達目的地。如果用戶端的流量速率超過指定的 rate_limit_threshold_count，Google 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 時，Google Cloud Armor 會套用已設定的 exceed_action。exceed_action 的可能值如下：
  • deny(status)：系統會拒絕要求，並傳回指定的錯誤代碼 (有效值為 403、404、429 和 502)。建議您使用 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 個要求，Google Cloud Armor 會將 exceed_action 套用至超過 2,000 個要求門檻的用戶端流量，直到 1,200 秒的完整時間過後，以及您設定的額外秒數 (做為禁止期間) 過後為止。舉例來說，如果禁止期間設為 3600，則在閾值間隔結束後，用戶端的流量將遭到禁止，時間長達 3,600 秒 (一小時)。

當用戶端的要求頻率低於頻率限制門檻時，系統會立即允許要求繼續傳送至後端服務。當用戶端的流量率超過指定的 rate_limit_threshold_count 時，Google 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 時，Google Cloud Armor 會套用已設定的 exceed_action。exceed_action 的可能值如下：
  • deny(status)：要求遭到拒絕，並傳回指定的錯誤代碼。錯誤代碼的有效值為 403、404、429 和 502。建議您使用回應碼 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：這是在指定時間間隔內，每個用戶端允許的請求數量，超過此數量後，Google Cloud Armor 就會禁止請求。如果指定了這個值，當超過 rate_limit_threshold_count 的請求數量也超過這個 ban_threshold_count 時，系統就會禁止使用已設定的 ban_duration_sec 金鑰。
  • ban_threshold_interval_sec：ban_threshold_count 時間間隔的秒數。這個值必須為 10、30、60、120、180、240、300、600、900、1200、1800、2700 或 3600 秒。
• ban_duration_sec：這是在 interval_sec 時間到期後，用戶端遭到封鎖的額外秒數。值必須為 60、120、180、240、300、600、900、1200、1800、2700 或 3600 秒。

預設的頻率限制安全性政策

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

1. 啟用 Cloud Logging，並查詢 Google Cloud Armor 防護後端服務在一天或更長時間內，每個 IP 位址和每分鐘的最大要求數量。

   舉例來說，假設您認為收到的 99% 網路流量不應受到速率限制規則的影響。在這種情況下，建議您將速率限制閾值設為 Cloud Logging 資料所產生分布資料中，每分鐘每個 IP 位址的最大要求數量的第 99 百分位數。

2. 如果您仍發現預設頻率限制規則阻擋合法流量，請考慮採取下列額外步驟：

   1. 啟用快取功能 (Cloud CDN 或 Media CDN)。
   2. 增加節流時間間隔 (每隔幾分鐘收到要求，而不是每隔 60 秒)。
   3. 您可以禁止用戶端，進一步降低初始攻擊的影響。您可以透過 Google Cloud Armor rate_based_ban 動作執行這項操作，方法是禁止在使用者指定的時間範圍內，超過限制次數的所有用戶端。舉例來說，如果客戶在 1 分鐘內超過限制 10 次，系統就會禁止他們使用服務 15 分鐘。

門檻強制執行

系統會在您部署 HTTP(S) 後端服務的每個 Google Cloud 地區，獨立執行節流和費率限制的設定門檻。舉例來說，如果您的服務部署在兩個地區，兩個地區的每個鍵都會設有設定的門檻，因此後端服務可能會遇到跨地區匯總流量量是設定門檻兩倍的情況。如果設定的閾值為 5,000 個要求，後端服務可能會從一個區域收到 5,000 個要求，從第二個區域收到 5,000 個要求。

不過，對於主要類型的 IP 位址，我們可以合理假設來自相同用戶端 IP 位址的流量會導向最接近後端部署地區的區域。在這種情況下，無論部署的區域為何，都可以在後端服務層級強制執行頻率限制。

請注意，強制執行的費率限制僅為概略值，與設定的門檻相比，可能不夠精確。此外，在少數情況下，由於內部路由行為，限制速率可能會在您部署的區域以外的更多區域中實施，進而影響準確度。基於上述原因，我們建議您僅在濫用情況發生時，或為了維持應用程式和服務的可用性，才使用頻率限制，而非用於強制執行嚴格的配額或授權規定。

記錄

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

自訂錯誤回應

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

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

與 reCAPTCHA 整合

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

後續步驟

• 設定頻率限制