Google Cloud Armor e reCAPTCHA Enterprise forniscono strumenti che consentono di valutare e intervenire sulle richieste in arrivo che potrebbero provenire da client automatici.
reCAPTCHA Enterprise utilizza tecniche avanzate di analisi del rischio per distinguere utenti umani e client automatici. reCAPTCHA Enterprise valuta l'utente in base alla configurazione delle chiavi di sito reCAPTCHA WAF. 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 Enterprise. In base agli attributi del token, Google Cloud Armor consente di consentire, negare, limitare la frequenza o reindirizzare le richieste in entrata. Per ulteriori informazioni, consulta la panoramica dell'integrazione di Google Cloud Armor e reCAPTCHA Enterprise.
La gestione dei bot di Google Cloud Armor include le seguenti funzionalità integrate.
Verifica manuale (pagina di test reCAPTCHA)
- Devi configurare una regola del criterio di sicurezza per reindirizzare una richiesta di valutazione reCAPTCHA Enterprise.
- Puoi creare la tua chiave di sito reCAPTCHA Enterprise per il WAF e associarla al tuo criterio di sicurezza. Ti consigliamo vivamente di farlo. Per ulteriori informazioni, consulta Implementare una verifica reCAPTCHA.
- Puoi autorizzare solo gli utenti finali che superano la verifica manuale di reCAPTCHA Enterprise reindirizzando gli utenti finali per la valutazione di reCAPTCHA Enterprise.
Applica la valutazione senza attriti di reCAPTCHA Enterprise
- Puoi intraprendere diverse azioni sulle richieste in arrivo in base alla valutazione di reCAPTCHA Enterprise del rischio che la richiesta abbia origine da un bot. Puoi scrivere regole dei criteri di sicurezza per valutare e filtrare il traffico in base al punteggio e ad altri attributi dei token.
- Devi implementare i token di azione e di sessione di reCAPTCHA Enterprise 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, consulta i token di azione reCAPTCHA e i token di sessione reCAPTCHA.
- Devi configurare una regola del criterio di sicurezza che valuti i token reCAPTCHA Enterprise.
- Per impedire il furto di token, ti consigliamo di associare le tue chiavi reCAPTCHA Enterprise per il 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 inviare le richieste tramite proxy ai backend.
Casi d'uso
Questa sezione descrive come utilizzare le funzionalità di gestione dei bot di Google Cloud Armor per mitigare i rischi legati ai bot e per controllare l'accesso da client automatizzati.
Utilizza una verifica manuale per distinguere tra utenti legittimi e clienti automatici
Puoi reindirizzare una richiesta a reCAPTCHA Enterprise per valutare il client finale e, se necessario, gestire verifiche manuali, 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 di un sistema illecito, questa azione consente loro di dimostrare di essere umani. Solo gli utenti che superano il test possono accedere al servizio.
Il seguente diagramma mostra in che modo una verifica manuale distingue se una richiesta proviene da un utente umano o da un client automatizzato:
Supponiamo che un utente Maya e un bot stiano esplorando la pagina di accesso (/login.html) del 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 Enterprise.
- reCAPTCHA Enterprise risponde con una pagina HTML con il JavaScript di reCAPTCHA Enterprise incorporato.
- Quando viene visualizzata la risposta, il codice JavaScript incorporato viene eseguito per valutare l'utente e, se necessario, esegue verifiche manuali.
- Se l'utente supera la valutazione, reCAPTCHA Enterprise emette un cookie di esenzione, che viene collegato automaticamente dal browser a ciascuna richiesta successiva allo stesso sito fino alla scadenza del cookie.
- In caso contrario, reCAPTCHA Enterprise non emetterà un cookie di esenzione.
In questo esempio, solo Maya supera la valutazione di reCAPTCHA Enterprise e riceve un cookie di esenzione, che consente di accedere al tuo sito.
Quando utilizzi le verifiche manuali, ti consigliamo di creare la tua chiave di sito WAF reCAPTCHA e di associarla al criterio di sicurezza. In questo modo puoi visualizzare le metriche reCAPTCHA Enterprise 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 per la verifica reCAPTCHA WAF.
Se non crei e non 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 a chiavi del sito che non sono di tua proprietà, incluse le chiavi del sito gestite da Google.
Applica la valutazione di reCAPTCHA Enterprise
Quando a una richiesta in entrata è associato un token reCAPTCHA Enterprise, 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 di reCAPTCHA Enterprise
reCAPTCHA Enterprise 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 inoltre informazioni sulla chiave reCAPTCHA Enterprise che hai utilizzato quando è stato generato il token.
Prima di configurare le regole dei criteri di sicurezza, devi decidere se utilizzare token-azione, token di sessione o entrambi. Ti consigliamo di leggere la documentazione di reCAPTCHA Enterprise per prendere una decisione. Per ulteriori informazioni, consulta il confronto dei casi d'uso di reCAPTCHA Enterprise.
Dopo aver determinato il tipo di token da utilizzare, devi implementare reCAPTCHA Enterprise per collegare il token a una richiesta. Per informazioni sull'implementazione dei token in reCAPTCHA Enterprise, consulta le seguenti pagine:
- 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 Enterprise associati alla richiesta. Per evitare il furto di token, ti consigliamo vivamente di associare le tue chiavi reCAPTCHA Enterprise alle regole dei criteri di sicurezza. Quando associ le chiavi reCAPTCHA a una regola del criterio di sicurezza, Google Cloud Armor esegue un'ulteriore convalida sul token confrontando la chiave reCAPTCHA nel token con le chiavi reCAPTCHA associate alla regola. Google Cloud Armor considera non valido un token con una chiave reCAPTCHA sconosciuta. Per ulteriori informazioni, consulta Applicare la valutazione senza attriti di reCAPTCHA Enterprise.
La figura seguente mostra il flusso di applicazione dei token di reCAPTCHA Enterprise.
Reindirizzamento (risposta 302)
Puoi utilizzare un'azione di reindirizzamento basata su URL per reindirizzare esternamente le richieste a un endpoint diverso. Devi fornire 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 inviare le richieste alla tua applicazione tramite proxy. Questa opzione ti consente di taggare le richieste sospette per elaborazioni downstream alternative, come la pubblicazione di un vaso 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 l'inserimento di un'intestazione o un valore personalizzati con lo stesso nome di intestazione di una delle intestazioni personalizzate per l'Application Load Balancer esterno globale o per l'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 di valutazione reCAPTCHA Enterprise o a un URL diverso quando il numero di richieste supera la soglia configurata. Inoltre, puoi identificare i client per la limitazione della frequenza in base ai token o ai cookie 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: cookie o token di esenzione da reCAPTCHA Enterprise
Per motivi di sicurezza, ti consigliamo di configurare regole di limitazione di frequenza per evitare l'uso illecito di token di azione, token di sessione o cookie di esenzione univoci per ogni token di azione reCAPTCHA. La seguente tabella illustra come identificare un cookie o un token di esenzione di reCAPTCHA Enterprise 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 per determinati URL (ad esempio /login.html) del tuo sito. Per farlo, configura le regole dei criteri di sicurezza come segue:
- 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 vengano utilizzati solo token di azione o di sessione.
Ad esempio, potresti utilizzare i token di azione per proteggere le azioni degli utenti di alto profilo, come /login.html. A questo scopo, 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 di criteri di sicurezza simili per applicare la valutazione del token di sessione reCAPTCHA Enterprise.
Terzo, supponi di combinare token di azione o token 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. Inoltre, vuoi dare all'utente una seconda possibilità
risolvendo le sfide se il punteggio non è abbastanza soddisfacente. Per farlo, configura le regole dei criteri 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 diversa soglia predefinita (ad esempio
0.5), reindirizza la richiesta di valutazione reCAPTCHA Enterprise, a meno che alla richiesta non sia associato un cookie di esenzione valido e il numero di utilizzi del cookie di esenzione 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 Enterprise con verifiche manuali.
Se non ottimizzi le regole di limitazione di frequenza, Google Cloud Armor
non impone limiti al numero di utilizzi per ciascun cookie di esenzione reCAPTCHA,
token di azione e token sessione. Per i token di azione, consigliamo di utilizzare una soglia bassa (ad esempio 1) e un intervallo di tempo elevato (ad esempio 30 minuti, poiché i token di azione sono validi per 30 minuti). Ti consigliamo di calcolare questa soglia
in base alle statistiche sul traffico.
Passaggi successivi
- Configurare la gestione dei bot
- Visualizza il riferimento per il linguaggio delle regole
- Visualizza i log
- Risolvere i problemi