Panoramica della gestione dei bot di Google Cloud Armor

Google Cloud Armor e reCAPTCHA forniscono strumenti per aiutarti a valutare e intervenire sulle richieste in arrivo che potrebbero provenire da clienti 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, consulta la panoramica dell'integrazione di Google Cloud Armor e reCAPTCHA.

La gestione dei bot di Google Cloud Armor include le seguenti funzionalità integrate.

  • Verifica manuale (pagina di verifica 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 farlo. Per ulteriori informazioni, consulta Implementare un test reCAPTCHA.
    • Puoi consentire solo agli utenti finali che superano la verifica manuale reCAPTCHA di reindirizzarli per la valutazione reCAPTCHA.

  • Applicare 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 provenga da un bot. Puoi scrivere regole dei criteri di sicurezza per valutare efiltrare 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 azioni reCAPTCHA e token di sessione reCAPTCHA.
    • Devi configurare una regola delle norme di sicurezza che valuti i token reCAPTCHA.
    • Per impedire 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.
  • Decora richiesta
    • 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 le funzionalità di gestione dei bot di Google Cloud Armor per ridurre il rischio di bot e controllare l'accesso da client automatici.

Utilizza una verifica manuale per distinguere gli utenti legittimi dai 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 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 offre loro un modo per dimostrare di essere persone reali. 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 automatico:

Esempio di reindirizzamento a reCAPTCHA.
Esempio di reindirizzamento a reCAPTCHA (fai clic per ingrandire).

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 grantire l'accesso al bot, puoi configurare una regola del criterio di sicurezza con l'espressione di corrispondenza avanzata request.path.matches("/login.html") e un'azione redirect di tipo GOOGLE_RECAPTCHA. L'esperienza utente end-to-end è la seguente:

  1. Un utente finale visita il tuo sito per la prima volta.
  2. Google Cloud Armor valuta la richiesta e decide di reindirizzarla a reCAPTCHA.
  3. reCAPTCHA risponde con una pagina HTML con il codice JavaScript di reCAPTCHA incorporato.
  4. Quando la risposta viene visualizzata, il codice JavaScript incorporato viene eseguito per valutare l'utente e, se necessario, vengono presentate verifiche manuali.
    • Se l'utente supera la valutazione, reCAPTCHA emette un cookie di esenzione, che viene allegato automaticamente dal browser a ogni richiesta successiva allo stesso sito fino alla scadenza del cookie.
    • In caso contrario, reCAPTCHA non emette un cookie di esenzione.

In questo esempio, solo Maya supera il test reCAPTCHA e riceve un cookie di esenzione, ottenendo l'accesso al tuo sito.

Quando utilizzi le verifiche manuali, ti consigliamo di creare la tua chiave di sito reCAPTCHA WAF e associarla al criterio di sicurezza. In questo modo puoi visualizzare le metriche reCAPTCHA associate alla chiave del sito e addestrare un modello di sicurezza specifico per la chiave del 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 una chiave di sito gestita da Google durante la valutazione. Non puoi visualizzare le metriche di reCAPTCHA associate alle chiavi sito che non possiedi, incluse le chiavi sito gestite da Google.

Applicare test reCAPTCHA

Quando un token reCAPTCHA è associato a una richiesta in arrivo, 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 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, incluso un punteggio che rappresenta il rischio associato all'utente. Inoltre, contengono informazioni sulla chiave reCAPTCHA utilizzata al momento della generazione del 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 in merito. Per ulteriori informazioni, consulta il confronto dei casi d'uso di reCAPTCHA.

Dopo aver stabilito il tipo di token che vuoi utilizzare, implementa reCAPTCHA in modo che il token venga allegato a una richiesta. Per informazioni sull'implementazione dei token in reCAPTCHA, consulta le seguenti pagine:

Infine, utilizza il linguaggio delle regole di Google Cloud Armor per configurare le regole dei criteri di sicurezza per valutare i token reCAPTCHA allegati alla 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 una convalida aggiuntiva 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 problemi di reCAPTCHA.

La figura seguente mostra il flusso di applicazione del token reCAPTCHA.

Flusso di applicazione forzata del token reCAPTCHA.
Flusso di applicazione del token reCAPTCHA (fai clic per ingrandire).

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 delle richieste alla tua applicazione. Questa opzione ti consente di taggare le richieste sospette per un'elaborazione a valle alternativa, ad esempio la pubblicazione di una honeypot, o per analisi e monitoraggio aggiuntivi. 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 valore o un'intestazione personalizzata con lo stesso nome di una delle intestazioni personalizzate per il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni classico, il valore dell'intestazione viene sovrascritto dal bilanciatore del carico. Per saperne di più, consulta Creare 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 dell'intestazione viene sovrascritto dal valore definito dall'utente fornito alla regola 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 o reindirizzare 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 di 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 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
Session-token HTTP-COOKIE recaptcha-ca-t

Puoi limitare le richieste o bandire 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 della 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 è 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 per test reCAPTCHA.
Applica verifiche manuali.
Applica le verifiche manuali (fai clic per ingrandire).

In secondo luogo, supponiamo che tu utilizzi solo token di azione o token di sessione sul tuo sito. Ad esempio, puoi utilizzare gli action token per proteggere le azioni degli utenti di alto profilo, come /login.html. Per farlo, esegui azioni in base al punteggio del token di azione come segue:

  • Regola 1: quando il punteggio dell'action-token è superiore a una soglia predefinita (ad es. 0.8), consenti la richiesta se il numero di utilizzi dell'action-token è inferiore alla soglia definita.
  • Regola 2: rifiuta la richiesta.
Applica la valutazione del token di azione reCAPTCHA.
Applica la valutazione del token di azione reCAPTCHA (fai clic per visualizzare ingrandito).

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. Inoltre, vuoi dare all'utente una seconda possibilità risolvendo le sfide se il punteggio non è sufficientemente 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 es. 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 un'altra soglia predefinita (ad esempio 0.5), reindirizza la richiesta per test reCAPTCHA, a meno che non sia associato alla richiesta un cookie di esenzione valido e il numero di utilizzi del cookie di esenzione sia inferiore alla soglia definita.
  • Regola 4: rifiuta la richiesta.
Applica la valutazione del token di azione reCAPTCHA con verifiche manuali.
Applica la valutazione del token di azione reCAPTCHA con verifiche manuali (fai clic per visualizzare ingrandito).

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 di 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 gli action token, consigliamo di utilizzare una soglia bassa (ad es. 1) e un intervallo di tempo elevato (ad es. 30 minuti), poiché gli action token sono validi per 30 minuti. Ti consigliamo di ricavare la soglia in base alle statistiche sul traffico.

Passaggi successivi