Google Cloud Armor e reCAPTCHA forniscono strumenti per aiutarti a valutare le richieste in entrata che potrebbero provenire da client automatici e intervenire di conseguenza.
reCAPTCHA utilizza tecniche avanzate di analisi del rischio per distinguere tra utenti umani e client automatici. reCAPTCHA valuta l'utente in base alla configurazione delle chiavi sito WAF reCAPTCHA. Quindi emette un token criptato con attributi che rappresentano il rischio associato. Google Cloud Armor decifra questo token in linea, senza una richiesta o risposta aggiuntiva al servizio reCAPTCHA. In base agli attributi dei token, Google Cloud Armor consente di consentire, negare, limitare la frequenza o reindirizzare le richieste in entrata. Per maggiori informazioni, consulta la panoramica dell'integrazione di Google Cloud Armor e reCAPTCHA.
La gestione dei bot di Google Cloud Armor include le seguenti funzionalità integrate.
Test manuale (pagina di test reCAPTCHA)
- Devi configurare una regola del criterio di sicurezza per reindirizzare una richiesta di test reCAPTCHA.
- Puoi creare la tua chiave di sito reCAPTCHA WAF e associarla al tuo criterio di sicurezza. Ti consigliamo vivamente di eseguire questa operazione. Per ulteriori informazioni, consulta Implementare una verifica reCAPTCHA.
- Puoi autorizzare solo gli utenti finali che superano la verifica manuale reCAPTCHA reindirizzando gli utenti finali per la valutazione di reCAPTCHA.
Applica la valutazione senza problemi di reCAPTCHA
- Puoi intraprendere diverse azioni sulle richieste in arrivo in base alla valutazione di reCAPTCHA del rischio che la richiesta abbia origine da un bot. Puoi scrivere regole del criterio di sicurezza per valutare e filtrare il traffico in base al punteggio e ad altri attributi dei token.
- Devi implementare i token di azione reCAPTCHA, quelli di sessione o entrambi. I token di azione reCAPTCHA sono supportati sulle applicazioni in esecuzione su siti web, iOS e Android. I token di sessione reCAPTCHA sono supportati solo sui siti web. Per ulteriori informazioni sui token reCAPTCHA, vedi token di azione reCAPTCHA e token di sessione reCAPTCHA.
- Devi configurare una regola del criterio di sicurezza che valuti i token reCAPTCHA.
- Per evitare il furto di token, ti consigliamo di associare le tue chiavi reCAPTCHA per WAF alla regola del criterio di sicurezza.
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 in modo che fornisca una risposta HTTP 302 al client.
- Decora richiesta
- Puoi inserire intestazioni personalizzate nelle richieste e valori statici al loro interno prima di eseguire il proxy delle richieste ai tuoi backend.
Casi d'uso
Questa sezione descrive come utilizzare le funzionalità di gestione dei bot di Google Cloud Armor per ridurre i rischi correlati ai bot e controllare l'accesso da client automatizzati.
Utilizza una verifica manuale per distinguere tra utenti legittimi e client automatizzati
Puoi reindirizzare una richiesta a reCAPTCHA per valutare il client finale e, se necessario, gestire verifiche manuali, senza alcuna ulteriore implementazione di reCAPTCHA. Quando gli utenti umani condividono la stessa firma (ad esempio i percorsi degli URL o altre firme L7) di un bot o di un sistema illecito, questa azione consente loro di dimostrare di essere umani. Solo gli utenti che superano il test possono accedere al tuo servizio.
Il seguente diagramma mostra in che modo una verifica manuale distingue se una richiesta proviene da un cliente umano o da un client automatizzato:
Supponiamo che un utente Maya e un bot stiano esplorando la 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 utente end-to-end
è 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.
- reCAPTCHA risponde con una pagina HTML con il codice JavaScript reCAPTCHA incorporato.
- Quando viene visualizzata la risposta, il codice JavaScript incorporato viene eseguito per valutare l'utente e, se necessario, propone verifiche manuali.
- Se l'utente supera il test, reCAPTCHA emette un cookie di esenzione che viene associato automaticamente dal browser a ciascuna delle successive richieste allo stesso sito fino alla scadenza del cookie.
- In caso contrario, reCAPTCHA non emetterà un cookie di esenzione.
In questo esempio, solo Maya supera test reCAPTCHA e riceve un cookie di esenzione, che consente di accedere al tuo sito.
Quando utilizzi le verifiche manuali, ti consigliamo di creare una tua chiave di sito WAF reCAPTCHA e associarla al criterio di sicurezza. In questo modo puoi visualizzare le metriche reCAPTCHA associate alla chiave di sito e addestrare un modello di sicurezza specifico per la chiave di sito. Per ulteriori informazioni, consulta Creare una chiave di sito di verifica reCAPTCHA WAF.
Se non crei e non associ una chiave di sito, reCAPTCHA utilizza una chiave di sito gestita da Google durante la valutazione. Non puoi visualizzare le metriche reCAPTCHA associate a chiavi di sito che non sono di tua proprietà, incluse le chiavi di sito gestite da Google.
Applica test reCAPTCHA
Quando un token reCAPTCHA è collegato a una richiesta in entrata, Google Cloud Armor valuta la richiesta e applica l'azione configurata in base ai singoli attributi nel token. La valutazione dei criteri di sicurezza di Google Cloud Armor avviene sul perimetro della rete Google, quindi i tuoi backend non sono coinvolti nella decifrazione del token.
Token reCAPTCHA
reCAPTCHA emette due tipi di token: token di azione e token di sessione. Entrambi i tipi di token restituiscono un punteggio per ogni richiesta in base alle interazioni con il tuo sito o la tua app. Entrambi i tipi di token contengono attributi, tra cui un punteggio che rappresenta il rischio associato all'utente. Contengono anche informazioni sulla chiave reCAPTCHA utilizzata al momento della generazione del token.
Prima di configurare le regole del criterio di sicurezza, devi decidere se utilizzare token di azione, token di sessione o entrambi. Ti consigliamo di leggere la documentazione di reCAPTCHA per prendere una decisione consapevole. Per ulteriori informazioni, consulta il confronto dei casi d'uso di reCAPTCHA.
Dopo aver determinato il tipo di token che vuoi utilizzare, devi implementare il reCAPTCHA per il token da associare a una richiesta. Per informazioni sull'implementazione dei token in reCAPTCHA, vedi le pagine seguenti:
- Applicazioni web
- App mobile
Infine, utilizza il linguaggio delle regole di Google Cloud Armor per configurare le regole dei criteri di sicurezza per valutare i token reCAPTCHA associati alla richiesta. Per evitare il furto di token, ti consigliamo vivamente di associare le tue chiavi reCAPTCHA alle regole del tuo criterio di sicurezza. Quando associ le chiavi reCAPTCHA a una regola del criterio di sicurezza, Google Cloud Armor esegue un'ulteriore convalida del token confrontando la chiave reCAPTCHA nel token con le chiavi reCAPTCHA associate alla regola. Google Cloud Armor considera un token con una chiave reCAPTCHA sconosciuta come non valido. Per maggiori informazioni, consulta Applicare la valutazione senza attriti di reCAPTCHA.
La figura seguente illustra il flusso di applicazione del token reCAPTCHA.
Reindirizzamento (risposta 302)
Puoi utilizzare un'azione di reindirizzamento basata su URL per reindirizzare esternamente le richieste a un endpoint diverso. Tu fornisci una destinazione di reindirizzamento sotto forma di URL e Google Cloud Armor reindirizza la richiesta fornendo una risposta HTTP 302 al client.
Decora richiesta
Google Cloud Armor può inserire intestazioni delle richieste personalizzate con valori statici definiti dall'utente prima di eseguire il proxy delle richieste alla tua applicazione. Questa opzione consente di taggare le richieste sospette per elaborazioni downstream alternative, come la pubblicazione di vasetti di miele, o per ulteriori analisi e monitoraggio. Tieni presente che questo parametro di azione deve essere aggiunto a un'azione allow esistente.
Intestazioni personalizzate
Se hai configurato Google Cloud Armor per inserire un'intestazione o un valore personalizzati con lo stesso nome di intestazione di una delle intestazioni personalizzate dell'Application Load Balancer esterno globale o dell'Application Load Balancer classico, il valore dell'intestazione viene sovrascritto dal bilanciatore del carico. Per maggiori informazioni, consulta la pagina relativa alla 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 nell'intestazione viene sovrascritto dal valore definito dall'utente fornito alla regola di Google Cloud Armor.
Integrazione con la limitazione di frequenza
Le regole di limitazione di frequenza di Google Cloud Armor sono compatibili con le funzionalità di gestione dei bot. Ad esempio, puoi reindirizzare una richiesta per la valutazione reCAPTCHA o a un URL diverso quando il numero di richieste supera la soglia configurata. Inoltre, puoi identificare i client per la limitazione di frequenza basata su cookie o token di esenzione reCAPTCHA 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
Per motivi di sicurezza, ti consigliamo di configurare regole di limitazione di frequenza per prevenire l'abuso di token tramite più utilizzi per token di azione reCAPTCHA univoco, token di sessione o cookie di esenzione. La seguente tabella illustra come identificare un cookie o un token di esenzione reCAPTCHA come chiave in una regola di limitazione di frequenza.
| Risorsa | enforce_on_key |
enforce_on_key_name |
|---|---|---|
| Cookie di esenzione | HTTP-COOKIE |
recaptcha-ca-e |
| Token di 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 saperne di più sui parametri per la limitazione di frequenza, consulta Applicare la limitazione di frequenza.
Esempi di limitazione di frequenza
Innanzitutto, supponi di utilizzare le verifiche manuali solo su URL selezionati (ad es. /login.html) del tuo sito. A questo scopo, configura le regole dei criteri di sicurezza come segue:
- Regola 1: se alla richiesta è associato 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 test reCAPTCHA.
In secondo luogo, supponi di utilizzare solo token di azione o di sessione sul tuo sito.
Ad esempio, potresti utilizzare i token di azione per proteggere azioni degli utenti di alto profilo, come /login.html. Per farlo, esegui azioni basate sul punteggio del
token di azione come segue:
- Regola 1: quando il punteggio del token di azione è superiore a una soglia predefinita (ad esempio
0.8), consenti la richiesta se il numero di utilizzi del token di azione è inferiore alla soglia definita. - Regola 2: rifiuta la richiesta.
Puoi configurare regole dei criteri di sicurezza simili per applicare la valutazione del token di sessione reCAPTCHA.
In terzo luogo, supponi di combinare token di azione o di sessione con verifiche manuali su URL selezionati (come /login.html) sul tuo sito e di voler eseguire azioni in base al punteggio del token di azione. e dare all'utente una seconda possibilità,
risolvendo delle sfide se il punteggio non è abbastanza soddisfacente. Per farlo, configura le regole del criterio di sicurezza come segue:
- Regola 1: quando il punteggio del token di azione è superiore a una soglia predefinita (ad esempio
0.8), consenti la richiesta se il numero di utilizzi del token di azione è inferiore alla soglia definita. - Regole 2 e 3: quando il punteggio del token di azione è superiore a una soglia predefinita diversa (ad esempio
0.5), reindirizza la richiesta di test reCAPTCHA, a meno che alla richiesta non sia associato un cookie di esenzione valido e il numero di utilizzi del cookie di esenzione non sia inferiore alla soglia definita. - Regola 4: rifiuta la richiesta.
Puoi configurare regole dei criteri di sicurezza simili per applicare la valutazione del token di sessione reCAPTCHA con verifiche manuali.
Se non ottimizzi le regole di limitazione di frequenza, Google Cloud Armor
non impone limiti al numero di utilizzi per ogni cookie di esenzione reCAPTCHA,
token di azione e token di sessione. Per i token di azione, consigliamo di utilizzare una soglia bassa (ad esempio 1) e un intervallo di tempo elevato (ad es. 30 minuti, poiché i token di azione sono validi per 30 minuti). Ti consigliamo di calcolare la soglia
in base alle statistiche sul traffico.
Passaggi successivi
- Configurare la gestione dei bot
- Visualizza il riferimento al linguaggio delle regole
- Visualizza i log
- Risoluzione dei problemi