Google Cloud Armor e reCAPTCHA forniscono strumenti per aiutarti a valutare e intervenire sulle richieste in arrivo che potrebbero provenire da client automatici.
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 di sito WAF di reCAPTCHA. Emette quindi un token criptato con attributi che rappresentano il rischio associato. Google Cloud Armor decifra questo token in linea, senza una richiesta o una risposta aggiuntiva al servizio reCAPTCHA. In base agli attributi del token, Google Cloud Armor ti consente di consentire, negare, limitare la frequenza o reindirizzare le richieste in entrata. Per ulteriori informazioni, vedi il Panoramica dell'integrazione di Google Cloud Armor e reCAPTCHA.
La gestione dei bot di Google Cloud Armor include quanto segue le funzionalità di machine learning.
Verifica manuale (pagina di verifica reCAPTCHA)
- Devi configurare una regola del criterio di sicurezza per reindirizzare una richiesta per Test reCAPTCHA.
- Puoi creare la tua chiave di sito reCAPTCHA WAF e associarla al tuo criterio di sicurezza. Ti consigliamo vivamente di farlo. Per ulteriori informazioni, consulta Implementare un test reCAPTCHA.
- Puoi autorizzare solo gli utenti finali che superano il reCAPTCHA verifica manuale tramite il reindirizzamento degli utenti finali per reCAPTCHA la valutazione.
Applica la valutazione senza problemi di reCAPTCHA
- Puoi intraprendere azioni diverse sulle richieste in arrivo in base Valutazione di reCAPTCHA del rischio che la richiesta proviene da un bot. Puoi scrivere regole dei criteri di sicurezza per valutare e filtrare il traffico in base al punteggio del token e ad altri attributi del token.
- Devi implementare i token di azione o i token di sessione reCAPTCHA o entrambi. I token di azione reCAPTCHA sono supportati nelle applicazioni che funzionano su siti web, iOS e Android. I token di sessione reCAPTCHA sono supportati solo sui siti web. Per ulteriori informazioni sui token reCAPTCHA, consulta token di azione reCAPTCHA e token di sessione reCAPTCHA.
- Devi configurare una regola del criterio di sicurezza che valuti di reCAPTCHA.
- Per evitare il furto di token, ti consigliamo di associare le tue chiavi reCAPTCHA 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 da inviare una risposta HTTP 302 al client.
- Richiesta di decorazione
- Puoi inserire intestazioni personalizzate nelle richieste e valori statici in queste intestazioni prima di eseguire il proxy di una richiesta ai tuoi backend.
Casi d'uso
Questa sezione descrive come utilizzare la gestione dei bot di Google Cloud Armor per mitigare il rischio di bot e controllare l'accesso da parte dei client automatizzati.
Utilizzare una verifica manuale per distinguere tra utenti legittimi e client automatici
Puoi reindirizzare una richiesta a reCAPTCHA per valutare il cliente finale e, se necessario, presentare verifiche manuali, senza alcuna implementazione aggiuntiva di reCAPTCHA. Quando utenti umani condividono lo stesso (ad es. percorsi URL o altre firme L7) come bot o sistema, questa azione offre loro un modo per dimostrare di essere umani. Solo gli utenti che superano la valutazione 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 automatizzato:
Supponiamo che un utente Maya e un bot stiano entrambi visitando la pagina di accesso
(/login.html) sul tuo sito. Per consentire l'accesso a Maya senza
per consentire 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
è il seguente:
- Un utente finale visita il tuo sito per la prima volta.
- Google Cloud Armor valuta la richiesta e determina reindirizzarlo a reCAPTCHA.
- reCAPTCHA risponde con una pagina HTML con il codice JavaScript di reCAPTCHA incorporato.
- Quando viene visualizzata la risposta, viene eseguito il codice JavaScript incorporato per valutare l'utente,
e gestisce le verifiche manuali,
se necessario.
- Se l'utente supera il test, reCAPTCHA emette un cookie di esenzione, che viene automaticamente collegato dal browser a ogni richieste successive allo stesso sito fino alla scadenza del cookie.
- In caso contrario, reCAPTCHA non emette un cookie di esenzione.
In questo esempio, solo Maya supera test reCAPTCHA e riceve un cookie di esenzione e ottiene l'accesso al tuo sito.
Quando utilizzi le verifiche manuali, ti consigliamo di crearne di personalizzate Chiave di sito reCAPTCHA WAF e associarla al criterio di sicurezza. Questo ti consente di visualizzare le metriche reCAPTCHA associate al chiave di sito e addestra un modello di sicurezza specifico per la chiave di sito. Per ulteriori informazioni, consulta Creare una chiave di sito per le sfide reCAPTCHA WAF.
Se non crei e associ una chiave di sito, reCAPTCHA utilizza a una chiave di sito gestita da Google durante la valutazione. Non puoi visualizzare le metriche reCAPTCHA associate a chiavi di sito che non possiedi, incluso il sito gestito da Google chiave.
Applica test reCAPTCHA
Se a una richiesta in entrata è collegato un token reCAPTCHA, Google Cloud Armor valuta la richiesta e applica l'azione configurata in base ai singoli attributi del token. La valutazione dei criteri di sicurezza di Google Cloud Armor avviene sul perimetro della rete di Google, pertanto i tuoi backend non sono coinvolti nella decifrazione del token.
Token reCAPTCHA
reCAPTCHA emette due tipi di token: token di azione e 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, incluso un punteggio che rappresenta il rischio associato all'utente. Inoltre, Contenere informazioni sulla chiave reCAPTCHA utilizzata quando è stato generato il token.
Prima di configurare le regole dei criteri di sicurezza, devi decidere se utilizzare i token di azione, i token di sessione o entrambi. Ti consigliamo di leggere la documentazione di reCAPTCHA per prendere una decisione informata. Per maggiori informazioni informazioni, consulta confronto tra i casi d'uso di reCAPTCHA.
Dopo aver determinato il tipo di token da utilizzare, implementa reCAPTCHA per il token da collegare con un richiesta. Per informazioni sull'implementazione dei token in reCAPTCHA, consulta le seguenti pagine:
- Applicazioni web
- App mobile
Infine, utilizza il linguaggio delle regole di Google Cloud Armor per configurare la sicurezza regole sui criteri per valutare i token reCAPTCHA collegati con la richiesta. Per evitare il furto di token, ti consigliamo vivamente di associare le tue chiavi reCAPTCHA alle regole delle norme 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 rispetto alle chiavi reCAPTCHA associate a la regola. Google Cloud Armor considera non valido un token con una chiave reCAPTCHA sconosciuta. Per ulteriori informazioni, consulta Applicare la valutazione senza problemi di reCAPTCHA.
La figura seguente mostra 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. Fornisci un target di reindirizzamento sotto forma di URL e Google Cloud Armor reindirizza la richiesta inviando una risposta HTTP 302 al client.
Richiesta di decorazione
Google Cloud Armor può inserire intestazioni delle richieste personalizzate con valori statici definiti dall'utente prima di eseguire il proxy della richiesta
richieste alla tua applicazione. Questa opzione ti consente di taggare elementi sospetti.
richieste di elaborazioni downstream alternative, come servire un vaso di miele o per
per ulteriori analisi e monitoraggio. Tieni presente che questa 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 di una delle intestazioni personalizzate per l'Application Load Balancer esterno globale o il bilanciatore del carico delle applicazioni classico, il valore dell'intestazione sovrascritto dal bilanciatore del carico. Per saperne di più, consulta Creare intestazioni personalizzate nei servizi di backend.
Inoltre, se scegli un nome di intestazione che esiste già nella richiesta, incluse le intestazioni HTTP standard, il valore originale nell'intestazione 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 la gestione dei bot le funzionalità di machine learning. Ad esempio, puoi reindirizzare una richiesta per reCAPTCHA la valutazione o il reindirizzamento 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 cookie o ai token di esenzione reCAPTCHA, per limitare le richieste o bandire i client che riutilizzano o abusano dello stesso cookie o token a una frequenza superiore alla soglia configurata dall'utente.
Cookie o token di esenzione dal limite di frequenza reCAPTCHA
Per motivi di sicurezza, ti consigliamo di configurare regole di limitazione della frequenza per impedire l'uso improprio dei token tramite più utilizzi per token di azione reCAPTCHA, token di sessione o cookie di esenzione univoci. La tabella seguente illustra come puoi Identificare un cookie o un token di esenzione reCAPTCHA come chiave in un una regola di limitazione di frequenza.
| Risorsa | enforce_on_key |
enforce_on_key_name |
|---|---|---|
| Cookie di esenzione | HTTP-COOKIE |
recaptcha-ca-e |
| Action-token | HTTP-HEADER |
X-Recaptcha-Token |
| Session-token | HTTP-COOKIE |
recaptcha-ca-t |
Puoi limitare le richieste o escludere i client che dipendono dalla stessa esenzione cookie o token, che superano la soglia configurata. Per ulteriori informazioni sui parametri di limitazione di frequenza, consulta Applica una limitazione di frequenza.
Esempi di limitazione di frequenza
Innanzitutto, supponiamo che tu utilizzi le verifiche manuali solo su URL selezionati (ad esempio /login.html) sul tuo sito. Per farlo, configura le regole del criterio di sicurezza come segue:
- Regola 1: se alla richiesta è collegato un cookie di esenzione valido e il numero di utilizzi del cookie di esenzione è inferiore alla soglia definita, consentire la richiesta.
- Regola 2: reindirizza la richiesta per la valutazione reCAPTCHA.
Secondo, supponiamo di utilizzare sul tuo sito solo token di azione o di sessione.
Ad esempio, potresti usare i token di azione per proteggere le azioni degli utenti di alto profilo,
come /login.html. Per farlo, esegui azioni in base al punteggio dell'attributo
action-token come segue:
- Regola 1: quando il punteggio dell'action-token è superiore a una soglia predefinita (ad esempio
0.8), consenti la richiesta se il numero di utilizzi dell'action-token è 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 reCAPCHA.
Terzo, supponiamo che tu combini token di azioni o token di sessione con verifiche manuali su URL selezionati (ad esempio /login.html) sul tuo sito e che tu voglia intraprendere azioni in base al punteggio del token di azioni. E vuoi concedere all'utente un secondo
e la possibilità di risolvere le sfide se il punteggio non è abbastanza soddisfacente. Per farlo,
configura le regole del criterio di sicurezza come segue:
- Regola 1: quando il punteggio dell'action-token è superiore a una soglia predefinita (ad esempio
0.8), consenti la richiesta se il numero di utilizzi dell'action-token è inferiore alla soglia definita. - Regole 2 e 3: quando il punteggio del token di azione è superiore a quello di un altro valore predefinito
di soglia (
0.5, ad esempio), reindirizza la richiesta per test reCAPTCHA a meno che non esista un cookie di esenzione valido associato alla richiesta e il numero di usi del cookie di esenzione è sotto la soglia definita. - Regola 4: rifiuta la richiesta.
Puoi configurare regole dei criteri di sicurezza simili per applicare la valutazione del token di sessione reCAPCHA con verifiche manuali.
Se non configuri le regole di limitazione della frequenza, Google Cloud Armor
non impone alcun limite al numero di utilizzi per ogni cookie di esenzione reCAPTCHA,
token di azione e token di sessione. Per i token di azione, consigliamo di usare un
soglia (1, ad esempio) e un intervallo di tempo elevato (ad esempio 30 minuti,
poiché i token di azione sono validi per 30 minuti). Ti consigliamo di ricavare 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
- Risolvere i problemi