Google Cloud Armor e reCAPTCHA Enterprise forniscono strumenti per aiutarti a valutare le richieste in arrivo provenienti da client automatici e ad agire di conseguenza.
reCAPTCHA Enterprise utilizza tecniche avanzate di analisi del rischio per distinguere gli utenti umani e i client automatici. reCAPTCHA Enterprise valuta l'utente in base alla configurazione delle chiavi del sito reCAPTCHA WAF. Quindi, invia un token criptato con attributi che rappresentano il rischio associato. Google Cloud Armor cripta questo token in linea, senza una richiesta/risposta aggiuntiva al servizio reCAPTCHA Enterprise. In base agli attributi dei token, Google Cloud Armor consente di consentire, negare, limitare la frequenza o reindirizzare le richieste in entrata. Per ulteriori informazioni, consulta la panoramica sull'integrazione di Google Cloud Armor e reCAPTCHA Enterprise.
La gestione dei bot di Google Cloud Armor include le seguenti funzionalità integrate.
- Sfida manuale (pagina della verifica reCAPTCHA)
- Puoi consentire solo agli utenti finali che superano la verifica manuale di reCAPTCHA Enterprise reindirizzando gli utenti finali alla valutazione di reCAPTCHA Enterprise.
- Ti consigliamo di creare la tua chiave di sito WAF reCAPTCHA e di associarla al tuo criterio di sicurezza. Per maggiori informazioni, consulta la pagina Implementare una verifica reCAPTCHA.
- Devi configurare una regola del criterio di sicurezza per reindirizzare una richiesta di valutazione di reCAPTCHA Enterprise.
- Applica la valutazione senza problemi di reCAPTCHA Enterprise
- Puoi intraprendere diverse azioni sulle richieste in entrata basate sulla valutazione di reCAPTCHA Enterprise del rischio che la richiesta provenga da un bot. Puoi scrivere regole di criteri di sicurezza per valutare e filtrare il traffico in base al punteggio del token e ad altri attributi del token.
- La valutazione dei criteri di sicurezza di Google Cloud Armor avviene al livello della rete di Google, quindi i tuoi backend non sono coinvolti nella decifrazione del token.
- Prima di implementare reCAPTCHA Enterprise, devi scegliere se utilizzare i token di azione o i token di sessione reCAPTCHA Enterprise, quindi creare la tua chiave di sito WAF reCAPTCHA. Per ulteriori informazioni, consulta Implementare i token di azione reCAPTCHA e Implementare i token di sessione reCAPTCHA.
- Devi configurare una regola del criterio di sicurezza che valuti i token reCAPTCHA Enterprise.
La gestione dei bot di Google Cloud Armor include anche le seguenti funzionalità.
- Reindirizzamento (302)
- Puoi reindirizzare le richieste all'URL alternativo configurato configurando Google Cloud Armor per fornire una risposta HTTP 302 al client.
- Decora richiesta
- Puoi inserire intestazioni personalizzate nelle richieste e valori statici in tali intestazioni, prima di eseguire il proxy delle richieste nei tuoi backend.
Casi d'uso
Questa sezione descrive come utilizzare le funzionalità di gestione dei bot di Google Cloud Armor per ridurre i rischi di bot e controllare l'accesso dai client automatici.
Utilizzare una verifica manuale per distinguere tra utenti legittimi e clienti automatici
Puoi reindirizzare una richiesta a reCAPTCHA Enterprise per valutare il client finale e pubblicare le sfide manuali, se necessario, senza alcuna implementazione aggiuntiva di reCAPTCHA Enterprise. Quando gli utenti umani condividono la stessa firma (ad esempio percorsi URL o altre firme L7) di un bot o un sistema illecito, questa azione fornisce loro un modo per dimostrare che sono persone. Solo gli utenti che superano il test possono ottenere l'accesso al tuo servizio.
Il seguente diagramma mostra in che modo una sfida manuale distingue se una richiesta proviene da un cliente umano o automatico:
Supponiamo che un utente Maya e un bot stiano navigando nella pagina di accesso
(/login.html) sul tuo sito. Per consentire l'accesso a Maya senza concedere l'accesso al bot, puoi configurare una regola del criterio di sicurezza con l'espressione di corrispondenza avanzata request.path.matches("/login.html"), con un'azione redirect di tipo GOOGLE_RECAPTCHA. L'esperienza end-to-end
degli utenti è la seguente:
- Un utente finale visita il tuo sito per la prima volta.
- Google Cloud Armor valuta la richiesta e determina di reindirizzarla a reCAPTCHA Enterprise.
- reCAPTCHA Enterprise risponde con una pagina HTML con il codice JavaScript Enterprise JavaScript incorporato.
- Una volta eseguito il rendering della risposta, il codice JavaScript incorporato viene eseguito per valutare l'utente e, se necessario, pubblica le verifiche manuali.
- Se l'utente supera il test, reCAPTCHA Enterprise emette un cookie di esenzione, che viene collegato automaticamente dal browser a ciascuna delle successive richieste allo stesso sito fino alla scadenza del cookie.
- In caso contrario, reCAPTCHA Enterprise non emette un cookie di esenzione.
In questo esempio, solo Maya supera il test reCAPTCHA Enterprise e riceve un cookie di esenzione, ottenendo l'accesso al tuo sito.
Quando utilizzi le verifiche manuali, ti consigliamo di creare una tua chiave di sito WAF reCAPTCHA e di associarla ai criteri di sicurezza. Ciò consente di visualizzare le metriche reCAPTCHA Enterprise associate alla chiave del sito e addestrare un modello di sicurezza specifico della chiave del sito. Per ulteriori informazioni, consulta la sezione Creare una chiave di verifica del sito WAF reCAPTCHA.
Se non crei e associ una chiave di sito, reCAPTCHA Enterprise utilizza una chiave di sito gestita da Google durante la valutazione. Non puoi visualizzare le metriche reCAPTCHA associate alle chiavi di sito che non sono di tua proprietà, incluse le chiavi del sito gestite da Google.
Applica la valutazione reCAPTCHA Enterprise
Quando è presente un token reCAPTCHA Enterprise collegato a una richiesta in entrata, Google Cloud Armor valuta la richiesta e applica l'azione configurata in base ai singoli attributi nel token.
Token reCAPTCHA Enterprise
reCAPTCHA Enterprise emette due tipi di token: token azione e token sessione. Entrambi i tipi di token restituiscono un punteggio per ogni richiesta in base alle interazioni con il sito. Entrambi i tipi di token contengono attributi, tra cui un punteggio che rappresenta il rischio associato all'utente.
Prima di configurare le regole relative ai criteri di sicurezza, devi decidere se utilizzare i token di azione, i token di sessione o entrambi. Consigliamo di leggere la documentazione di reCAPTCHA Enterprise per informare la tua decisione. Per ulteriori informazioni, consulta il confronto dei casi d'uso di reCAPTCHA Enterprise.
Dopo aver determinato il tipo di token che vuoi utilizzare, devi implementare reCAPTCHA Enterprise per il collegamento a una richiesta. Per informazioni sull'implementazione dei token in reCAPTCHA Enterprise, vedi Implementare i token di azione reCAPTCHA Enterprise e I token di sessione di reCAPTCHA Enterprise.
Infine, utilizza il linguaggio delle regole di Google Cloud Armor per configurare regole di criteri di sicurezza per valutare i token reCAPTCHA Enterprise associati alla richiesta.
La figura seguente illustra il flusso di applicazione dei token reCAPTCHA Enterprise.
Reindirizzamento (risposta 302)
Puoi utilizzare un'azione di reindirizzamento basata su URL per reindirizzare esternamente le richieste a un endpoint diverso. Fornisci una destinazione di reindirizzamento sotto forma di URL e Google Cloud Armor reindirizza la richiesta pubblicando una risposta HTTP 302 al client.
Decora richiesta
Google Cloud Armor può inserire intestazioni di richiesta personalizzate con valori statici definiti dall'utente prima di eseguire il proxy delle richieste alla tua applicazione. Questa opzione consente di codificare le richieste sospette per l'elaborazione alternativa a valle, come la pubblicazione di un miele o per ulteriori analisi e monitoraggio. Tieni presente che questo parametro dell'azione deve essere aggiunto a un'azione allow esistente.
Intestazioni personalizzate
Se hai configurato Google Cloud Armor per inserire un'intestazione o un valore personalizzato con lo stesso nome di intestazione per un bilanciatore del carico HTTP(S) esterno globale o un bilanciatore del carico HTTP(S) esterno globale (classico), il valore dell'intestazione viene sovrascritto dal bilanciatore del carico. Per ulteriori informazioni, consulta la pagina sulla creazione di intestazioni personalizzate nei servizi di backend.
Inoltre, se scegli un nome di intestazione già esistente nella richiesta, incluse le intestazioni HTTP standard, il valore originale in tale intestazione viene sovrascritto dal valore definito dall'utente fornito alla regola Google Cloud Armor.
Integrazione con limitazione di frequenza
Le regole di limitazione della frequenza di Google Cloud Armor sono compatibili con le funzionalità di gestione dei bot. Ad esempio, puoi reindirizzare una richiesta di valutazione reCAPTCHA Enterprise o reindirizzare a un URL diverso quando il numero di richieste supera la soglia configurata. Inoltre, puoi identificare i client per la limitazione di frequenza in base ai cookie o ai token di esenzione reCAPTCHA Enterprise, per limitare le richieste o escludere i client che riutilizzano o utilizzano in modo illecito lo stesso cookie o token a una velocità superiore alla soglia configurata dall'utente.
Limitazione di frequenza dei cookie o dei token di esenzione reCAPTCHA Enterprise
Per motivi di sicurezza, ti consigliamo di configurare le regole di limitazione della frequenza per impedire l'abuso del token tramite più utilizzi per ogni token di azione, token della sessione o esenzione reCAPTCHA univoco. La tabella seguente illustra come identificare un cookie o token di esenzione reCAPTCHA Enterprise come la chiave in una regola di limitazione della frequenza.
| Risorsa | enforce_on_key |
enforce_on_key_name |
|---|---|---|
| Cookie di esenzione | HTTP-COOKIE |
recaptcha-ca-e |
| Token azione | HTTP-HEADER |
X-Recaptcha-Token |
| Token di sessione | HTTP-COOKIE |
recaptcha-ca-t |
Puoi limitare le richieste o escludere i client che dipendono dallo stesso cookie o token di esenzione e che superano la soglia configurata. Per ulteriori informazioni sui parametri di limitazione di frequenza, consulta Applicare la limitazione di frequenza.
Esempi di limitazione di frequenza
Innanzitutto, supponiamo che vengano utilizzate verifiche manuali solo su URL selezionati
(/login.html, ad esempio) sul tuo sito. A questo scopo, configura
le regole relative ai criteri di sicurezza nel seguente modo:
- Regola 1: se alla richiesta è allegato un cookie di esenzione valido e il numero di utilizzi del cookie di esenzione è inferiore alla soglia definita, consenti la richiesta.
- Regola 2: reindirizza la richiesta di valutazione di reCAPTCHA Enterprise.
In secondo luogo, supponiamo che sul tuo sito utilizzi solo token di azione e/o token di sessione.
Ad esempio, puoi utilizzare i token delle azioni per proteggere le azioni degli utenti di alto profilo, come /login.html. Per farlo, esegui le azioni in base al punteggio del token azione:
- Regola 1: quando il punteggio del token azione è superiore a una soglia predefinita (ad esempio
0.8), consenti la richiesta se il numero di utilizzi del token azione è inferiore alla soglia definita. - Regola 2: rifiuta la richiesta.
Puoi configurare regole di criteri di sicurezza simili per applicare la valutazione del token di sessione reCAPTCHA Enterprise.
In terzo luogo, supponi di combinare i token di azione o i token di sessione con le verifiche manuali
su URL selezionati (come /login.html) sul tuo sito e di voler eseguire azioni
basate sul punteggio del token delle azioni. Vuoi dare all'utente una seconda opportunità risolvendo le sfide se il punteggio non è sufficiente. A questo scopo,
configura le regole dei criteri di sicurezza come segue:
- Regola 1: quando il punteggio del token azione è superiore a una soglia predefinita (ad esempio
0.8), consenti la richiesta se il numero di utilizzi del token azione è inferiore alla soglia definita. - Regole 2 e 3: quando il punteggio del token azione è superiore a una soglia predefinita diversa (ad esempio
0.5), reindirizza la richiesta di valutazione reCAPTCHA Enterprise a meno che non sia associato un cookie di esenzione valido e che il numero di utilizzi del cookie di esenzione sia inferiore alla soglia definita. - Regola 4: rifiuta la richiesta.
Puoi configurare regole di criteri di sicurezza simili per applicare la valutazione dei token di sessione reCAPTCHA Enterprise con sfide manuali.
Se non configuri le regole di limitazione della frequenza come indicato in precedenza, Google Cloud Armor non impone limiti al numero di utilizzi per ogni cookie di esenzione reCAPTCHA, token azione e token sessione. Per i token di azione, consigliamo di utilizzare una soglia bassa (ad esempio 1) e un intervallo di tempo elevato (30 minuti ad esempio, poiché i token di azione sono validi per 30 minuti). Ti consigliamo di ricavare la soglia in base alle statistiche sul traffico.
Limitazioni
- La gestione dei bot di Google Cloud Armor non supporta il bilanciatore del carico HTTP(S) esterno globale. Per configurare la gestione dei bot con un bilanciatore del carico HTTP(S), utilizza il bilanciatore del carico HTTP(S) esterno globale (classico). Per ulteriori informazioni, consulta la Panoramica del bilanciatore del carico HTTP(S) esterno: modalità di funzionamento.
Passaggi successivi
- Configurare i criteri di sicurezza
- Visualizza il riferimento relativo al linguaggio delle regole
- Visualizza i log
- Risolvere i problemi