Google Cloud Armor 和 reCAPTCHA 提供工具，可協助您評估並處理可能來自自動化用戶端的傳入要求。
reCAPTCHA 採用進階風險分析技術，區分人類使用者和自動化用戶端。reCAPTCHA 會根據 reCAPTCHA WAF 網站金鑰的設定評估使用者。接著，系統會發出加密權杖，其中包含代表相關風險的屬性。Google Cloud Armor 會在線上解密此符記，不必向 reCAPTCHA 服務提出額外要求或回應。Google Cloud Armor 可根據權杖屬性，允許、拒絕、限制頻率或重新導向傳入的要求。如需更多資訊，請參閱 Google Cloud Armor 和 reCAPTCHA 整合總覽。
Google Cloud Armor 的機器人管理功能包含下列整合功能。
手動驗證 (reCAPTCHA 驗證頁面)
- 您必須設定安全性政策規則，才能重新導向 reCAPTCHA 評估要求。
- 您可以自行建立 reCAPTCHA WAF 網站金鑰，並將其與安全性政策建立關聯。我們強烈建議您這麼做。 詳情請參閱「導入 reCAPTCHA 驗證問題」。
- 您可以將使用者重新導向至 reCAPTCHA 評估，只允許通過 reCAPTCHA 手動驗證的使用者。
強制執行 reCAPTCHA 無摩擦評估
- 您可以根據 reCAPTCHA 對要求來自機器人的風險評估，對傳入的要求採取不同的行動。您可以撰寫安全性政策規則，根據符記分數和其他符記屬性評估及篩選流量。
- 您必須實作 reCAPTCHA 動作符記、工作階段符記，或兩者皆實作。網站、iOS 和 Android 應用程式支援 reCAPTCHA 動作符記。網站僅支援 reCAPTCHA 工作階段符記。如要進一步瞭解 reCAPTCHA 符記，請參閱 reCAPTCHA 動作符記和 reCAPTCHA 工作階段符記。
- 您必須設定可評估 reCAPTCHA 符記的安全性政策規則。
- 為避免權杖遭竊，建議您將 WAF 專用的 reCAPTCHA 金鑰與安全性政策規則建立關聯。
Google Cloud Armor 機器人管理功能還包含下列功能。
- 重新導向 (302)
- 您可以將要求重新導向至已設定的替代網址，方法是將 Google Cloud Armor 設為向用戶端提供 HTTP 302 回應。
- 裝飾要求
- 您可以在將要求轉送至後端之前，在要求中插入自訂標頭，並在這些標頭中插入靜態值。
用途
本節將說明如何使用 Google Cloud Armor 機器人管理功能，降低機器人風險並控管自動化用戶端的存取權。
使用手動驗證功能，區分合法使用者和自動化客戶
您可以將要求重新導向至 reCAPTCHA，以便評估終端用戶端，並視需要提供手動驗證問題，而無需額外導入 reCAPTCHA。如果人類使用者與機器人或濫用系統共用相同的簽章 (例如網址路徑或其他 L7 簽章)，這項動作可讓他們證明自己是人類。只有通過評估的使用者才能存取您的服務。
下圖顯示手動挑戰如何判斷要求來自人類還是自動化用戶端：
假設使用者 Maya 和機器人同時瀏覽網站上的登入頁面 (/login.html)。如要允許 Maya 存取權，但不授予對方對聊天機器人的存取權，您可以使用進階比對運算式 request.path.matches("/login.html") 設定安全政策規則，並搭配 redirect 動作 (類型為 GOOGLE_RECAPTCHA)。端對端使用者體驗如下：
- 使用者首次造訪網站。
- Google Cloud Armor 會評估要求，並決定將其重新導向至 reCAPTCHA。
- reCAPTCHA 會回應 HTML 網頁，其中嵌入 reCAPTCHA JavaScript。
- 在回應算繪時，內嵌的 JavaScript 會執行，以便評估使用者，並視需要提供手動驗證。
- 如果使用者通過評估，reCAPTCHA 就會發出豁免 Cookie，瀏覽器會自動將此 Cookie 附加至對同一網站提出的後續要求，直到 Cookie 到期為止。
- 否則，reCAPTCHA 不會發出豁免 Cookie。
在本例中，只有 Maya 通過 reCAPTCHA 評估，並收到豁免 Cookie，因此可以存取您的網站。
使用手動驗證時，建議您自行建立 reCAPTCHA WAF 網站金鑰，並將其與安全性政策建立關聯。這可讓您查看與網站金鑰相關聯的 reCAPTCHA 指標，並訓練專屬於網站金鑰的安全性模型。如需更多資訊，請參閱「建立 reCAPTCHA WAF 挑戰網站金鑰」。
如果您沒有建立及關聯網站金鑰，ReCAPTCHA 會在評估期間使用 Google 管理的網站金鑰。您無法查看與您不具擁有權的網站金鑰相關聯的 reCAPTCHA 指標，包括 Google 管理的網站金鑰。
強制執行 reCAPTCHA 評估
如果傳入要求附加 reCAPTCHA 權杖，Google Cloud Armor 會評估要求，並根據權杖中的個別屬性套用已設定的動作。Google Cloud Armor 安全性政策評估作業會在 Google 網路邊緣執行，因此您的後端不會參與解密權杖的作業。
reCAPTCHA 權杖
reCAPTCHA 會發出兩種符記：動作符記和工作階段符記。這兩種權杖都會根據與網站或應用程式的互動，為每個要求傳回分數。兩種權杖都包含屬性，包括代表與使用者相關風險的分數。這些權杖也會包含您在產生權杖時使用的 reCAPTCHA 金鑰相關資訊。
設定安全性政策規則前，您必須決定是否要使用動作符記、工作階段符記，或兩者皆用。建議您詳閱 reCAPTCHA 說明文件，以便做出決定。如需更多資訊，請參閱 reCAPTCHA 用途比較。
確定要使用的權杖類型後，您就可以實作 reCAPTCHA，讓權杖附加至要求。如要瞭解如何在 reCAPTCHA 中導入符記，請參閱下列頁面：
- 網頁應用程式
- 行動應用程式
最後，請使用 Google Cloud Armor 規則語言設定安全性政策規則，評估與要求附加的 reCAPTCHA 權杖。為避免權杖遭竊，我們強烈建議您將 reCAPTCHA 金鑰與安全政策規則建立關聯。將 reCAPTCHA 金鑰與安全政策規則建立關聯後，Google Cloud Armor 會比較權杖中的 reCAPTCHA 金鑰，以及與規則相關聯的 reCAPTCHA 金鑰，藉此對權杖執行額外驗證。Google Cloud Armor 會將含有不明 reCAPTCHA 金鑰的權杖視為無效。詳情請參閱強制執行 reCAPTCHA 無摩擦評估功能。
下圖說明 reCAPTCHA 權杖強制執行流程。
重新導向 (302 回應)
您可以使用以網址為基礎的重新導向動作，將外部要求重新導向至不同的端點。您以網址的形式提供重新導向目標，Google Cloud Armor 就會向用戶端提供 HTTP 302 回應，藉此重新導向要求。
裝飾要求
Google Cloud Armor 可在將要求轉送至應用程式之前，插入含有靜態使用者定義值的自訂要求標頭。這個選項可讓您標記可疑要求，以便進行其他下游處理作業，例如提供蜜罐，或進行額外分析和監控。請注意，此動作參數必須新增至現有的 allow 動作。
自訂標頭
如果您已設定 Google Cloud Armor，以便插入自訂標頭或值，且標頭名稱與全域外部應用程式負載平衡器或傳統版應用程式負載平衡器的其中一個自訂標頭相同，則負載平衡器會覆寫標頭值。詳情請參閱「在後端服務中建立自訂標頭」。
此外，如果您選擇的標頭名稱已存在於要求中 (包括標準 HTTP 標頭)，則該標頭中的原始值會被提供給 Google Cloud Armor 規則的使用者定義值覆寫。
整合頻率限制
Google Cloud Armor 頻率限制規則與機器人管理功能相容。舉例來說，您可以將 reCAPTCHA 評估要求重新導向，或是在要求次數超過設定的門檻時，將要求重新導向至其他網址。此外，您可以根據 reCAPTCHA 豁免 Cookie 或權杖，識別用於限制頻率的用戶端，以便限制要求，或禁止用戶端重複使用或濫用相同的 Cookie 或權杖，頻率超過使用者設定的閾值。
限制 reCAPTCHA 豁免 Cookie 或權杖的頻率
為了確保安全性，建議您設定速率限制規則，以防範有人濫用權杖，例如透過重複使用每個 reCAPTCHA 動作權杖、工作階段權杖或豁免 Cookie。下表說明如何在速率限制規則中將 reCAPTCHA 豁免 Cookie 或權杖視為鍵。
| 資源 | enforce_on_key |
enforce_on_key_name |
|---|---|---|
| 豁免 Cookie | HTTP-COOKIE |
recaptcha-ca-e |
| 動作符記 | HTTP-HEADER |
X-Recaptcha-Token |
| 工作階段符記 | HTTP-COOKIE |
recaptcha-ca-t |
您可以限制要求或禁止依賴相同豁免 cookie 或權杖，且超過所設定門檻的用戶端。如要進一步瞭解頻率限制參數，請參閱「套用頻率限制」。
頻率限制範例
首先，假設您只在網站上的特定網址 (例如 /login.html) 使用手動驗證。如要達成這項目標，請按照下列方式設定安全政策規則：
- 規則 1：如果要求附加有效的豁免 Cookie，且豁免 Cookie 的使用次數低於您定義的門檻，請允許要求。
- 規則 2：重新導向 reCAPTCHA 評估要求。
其次，假設您只在網站上使用動作符記或工作階段符記。舉例來說，您可以使用動作符記來保護重要使用者動作，例如 /login.html。如要執行這項操作，請根據 action-token 的分數採取行動，如下所示：
- 規則 1：如果 action-token 的得分高於預先定義的門檻 (例如
0.8)，且 action-token 的使用次數低於您定義的門檻，系統就會允許要求。 - 規則 2：拒絕要求。
您可以設定類似的安全性政策規則，強制執行 reCAPTCHA 工作階段符記評估。
第三，假設您在網站上選取的網址 (例如 /login.html) 中，將動作符記或工作階段符記與人工驗證結合，並想根據動作符記的得分採取行動。如果分數不夠理想，您想給使用者第二次機會，讓他們解決挑戰。如要這麼做，請按照下列方式設定安全性政策規則：
- 規則 1：如果 action-token 的得分高於預先定義的門檻 (例如
0.8)，且 action-token 的使用次數低於您定義的門檻，系統就會允許要求。 - 規則 2 和 3：如果 action-token 的分數高於其他預先定義的門檻 (例如
0.5)，請重新導向 reCAPTCHA 評估作業的要求，除非要求中附加了有效的豁免 Cookie，且豁免 Cookie 的使用次數低於您定義的門檻。 - 規則 4：拒絕要求。
您可以設定類似的安全性政策規則，透過手動驗證機制強制執行 reCAPTCHA 工作階段權杖評估。
如果您未調整速率限制規則，Google Cloud Armor 就不會對每個 reCAPTCHA 豁免 Cookie、動作權杖和會話權杖的使用次數設限。針對動作符記，建議您使用低門檻 (例如 1) 和長時間間隔 (例如 30 分鐘，因為動作符記的有效期限為 30 分鐘)。建議您根據流量統計資料來設定門檻。