頻率限制簡介

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

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

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

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

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

  1. 節流：您可以對個別用戶端設定使用者設定的門檻，強制限制每個用戶端或所有用戶端的最高要求數。
  2. 以速率為準的禁止：您可以根據用戶端，對符合規則的要求設定速率限制，如果用戶端超過使用者設定的門檻，則會暫時禁止這些用戶端一段時間。

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

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

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

找出頻率限制的用戶端

Google Cloud Armor 會使用下列鍵類型彙整要求並強制執行速率限制，藉此識別個別用戶端以進行速率限制：

  • ALL：所有要求符合規則比對條件的用戶端，都會使用同一個金鑰。
  • IP：每個用戶端來源 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。詳情請參閱規則語言參考資料。

您可以單獨使用上述金鑰，也可以根據最多三個金鑰的組合套用速率限制。您可以使用多個 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 個要求，系統就會限制用戶端約 20% 的流量，直到允許的要求量達到或低於設定的門檻為止。

如果用戶端的流量速率小於或等於 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 會對該用戶端超過 2,000 個要求門檻的流量套用 exceed_action，直到 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 項要求 (分別為 rate_limit_threshold_count 和 interval_sec 的 500 和 60)。如要選取其他門檻，建議按照下列步驟調整參數：

  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 動作可讓您在使用者指定的時限內，禁止所有超過限制次數過多的用戶端。舉例來說，如果用戶在一分鐘內超過限制 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 使用速率限制，請參閱機器人管理總覽。

後續步驟