Panoramica della gestione dei bot di Google Cloud Armor

Google Cloud Armor e reCAPTCHA forniscono strumenti che consentono di 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 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 alcuna richiesta o risposta aggiuntiva al servizio reCAPTCHA. 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.

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 eseguire questa operazione. Per maggiori informazioni, consulta Implementare una verifica reCAPTCHA.
    • Puoi consentire solo agli utenti finali che superano la verifica manuale di reCAPTCHA reindirizzando gli utenti finali per la valutazione reCAPTCHA.

  • Applica la valutazione senza problemi di reCAPTCHA

    • Puoi eseguire diverse azioni sulle richieste in entrata in base alla valutazione di reCAPTCHA del rischio che la richiesta provenga da un bot. Puoi scrivere regole del criterio 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 e di sessione reCAPTCHA o entrambi. I token di azione reCAPTCHA sono supportati su 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 le pagine relative ai token di azione reCAPTCHA e ai token di sessione reCAPTCHA.
    • Devi configurare una regola del criterio di sicurezza che valuti i token reCAPTCHA.
    • Per prevenire 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 da inviare una risposta HTTP 302 al client.
  • Richiesta Decora
    • Puoi inserire intestazioni personalizzate nelle richieste e valori statici al loro interno, 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 mitigare il rischio dei bot e controllare l'accesso da client automatizzati.

Utilizzare una verifica manuale per distinguere tra utenti legittimi e client automatici

Puoi reindirizzare una richiesta a reCAPTCHA per valutare il client finale e, se necessario, eseguire verifiche manuali, senza ulteriori implementazioni 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 consente loro di dimostrare di essere umani. Solo gli utenti che superano il test possono accedere al tuo servizio.

Il seguente diagramma mostra come una verifica manuale consente di distinguere se una richiesta proviene da un client umano o da un client automatico:

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

Supponiamo che un utente Maya e un bot stiano esplorando la pagina di accesso (/login.html) del tuo sito contemporaneamente. 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:

  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 JavaScript JavaScript incorporato.
  4. 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 il test, reCAPTCHA emette un cookie di esenzione, che viene automaticamente allegato dal browser a ciascuna delle 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, ottenendo l'accesso al tuo sito.

Se utilizzi le verifiche manuali, ti consigliamo di creare la tua chiave di sito WAF reCAPTCHA 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 la chiave di sito per la verifica di 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 possiedi, incluse le chiavi del sito gestite da Google.

Applica test reCAPTCHA

Se a una richiesta in entrata è associato un token reCAPTCHA, 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 sito o l'app. Entrambi i tipi di token contengono attributi, incluso un punteggio che rappresenta il rischio associato all'utente. Contengono inoltre informazioni sulla chiave reCAPTCHA che hai utilizzato al momento della generazione del token.

Prima di configurare le regole del criterio di sicurezza, devi decidere se utilizzare token di azione, di sessione o entrambi. Ti consigliamo di leggere la documentazione di reCAPTCHA per prendere una decisione informata. Per ulteriori informazioni, consulta il confronto dei casi d'uso di reCAPTCHA.

Dopo aver determinato il tipo di token da utilizzare, implementi il reCAPTCHA per collegare il token 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 al fine di valutare i token reCAPTCHA collegati alla richiesta. Per prevenire il furto dei token, ti consigliamo vivamente di associare le chiavi reCAPTCHA 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 del token con le chiavi reCAPTCHA associate alla regola. Google Cloud Armor considera non valido un token con una chiave reCAPTCHA sconosciuta. Per maggiori informazioni, consulta Applicare la valutazione senza problemi di reCAPTCHA.

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

Flusso di applicazione forzata dei token reCAPTCHA.
Flusso di applicazione forzata 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. Tu fornisci una destinazione di reindirizzamento sotto forma di URL e Google Cloud Armor reindirizza la richiesta fornendo una risposta HTTP 302 al client.

Richiesta Decora

Google Cloud Armor può inserire intestazioni delle richieste personalizzate con valori statici definiti dall'utente prima di eseguirne il proxy per l'applicazione. Questa opzione ti consente di taggare le richieste sospette per l'elaborazione downstream alternativa, come la pubblicazione di un vaso di miele, o per analisi e monitoraggio aggiuntive. 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 personalizzato con lo stesso nome di intestazione di una delle intestazioni personalizzate per l'Application Load Balancer esterno globale o l'Application Load Balancer classico, il valore dell'intestazione viene sovrascritto dal bilanciatore del carico. Per maggiori informazioni, consulta Creazione di 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 viene sostituito 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 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, 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.

Cookie o token di esenzione reCAPTCHA per la limitazione di frequenza

Per motivi di sicurezza, ti consigliamo di configurare le regole di limitazione di frequenza per impedire l'uso illecito dei token tramite più utilizzi per token di azione, sessione o cookie di esenzione univoci di reCAPTCHA. 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
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 limitazioni di frequenza

Innanzitutto, supponiamo di utilizzare le verifiche manuali solo sugli URL selezionati (ad esempio /login.html) del tuo sito. A questo scopo, 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 di test reCAPTCHA.
Imponi le verifiche manuali.
Applica verifiche manuali (fai clic per ingrandire).

Secondo, supponiamo di utilizzare sul tuo sito 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 tale scopo, esegui le azioni in base al 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.
Applica la valutazione del token di azione reCAPTCHA.
Applica la valutazione del token di azione reCAPTCHA (fai clic per ingrandire).

Puoi configurare regole del criterio di sicurezza simili per applicare la valutazione del token di sessione reCAPTCHA.

In terzo luogo, supponi di combinare token di azione o token di sessione con verifiche manuali su URL selezionati (ad esempio /login.html) del 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 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 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 ingrandire).

Puoi configurare regole del criterio 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 alcun limite al numero di utilizzi per ogni cookie, token di azione e token di sessione di esenzione reCAPTCHA. 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 ricavare la soglia in base alle statistiche sul traffico.

Passaggi successivi