Rilevare gli URL dannosi con Web Risk

Prima di iniziare

Configura l'autenticazione e abilita l'API Web Risk

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.

  3. To initialize the gcloud CLI, run the following command: 

    gcloud init

  4. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Enable the Web Risk API: 

    gcloud services enable webrisk.googleapis.com
  7. Install the Google Cloud CLI.

  8. To initialize the gcloud CLI, run the following command: 

    gcloud init

  9. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  10. Make sure that billing is enabled for your Google Cloud project.

  11. Enable the Web Risk API: 

    gcloud services enable webrisk.googleapis.com

Utilizzo delle API

Quando utilizzi le API Web Risk, assicurati di conoscere il contratto di livello del servizio e i limiti di utilizzo di Web Risk.

Per iniziare a utilizzare Web Risk, consulta questi argomenti:

Quale API è adatta a me? Ricerca o aggiornamento?

Web Risk fornisce due API diverse con cui puoi eseguire l'integrazione. Queste API sono l'API Lookup e l'API Update. Entrambe queste API forniscono le stesse informazioni. In altre parole, se un URL è stato identificato come dannoso. La più semplice da utilizzare è l'API Lookup. Utilizzando l'API Lookup, esegui una query su Web Risk per ogni URL che vuoi controllare.

L'API Update è più complessa, ma ha alcune proprietà interessanti. Con l'API Update, gestirai un database locale. Questo database può essere controllato per verificare se un URL è dannoso. Questo database funge da filtro Bloom. In altre parole, possono esserci falsi positivi (un URL viene identificato come dannoso, ma non lo è), ma non dovrebbero esserci falsi negativi (un URL viene identificato come non dannoso, ma lo è). Per questo motivo, i server di Web Risk vengono contattati raramente e solo per confermare le corrispondenze e distinguere i falsi positivi. Nella maggior parte dei casi, quando controlli un URL utilizzando l'API Update, non dovrai contattare i server Web Risk. Dovresti contattare i server Web Risk solo quando aggiorni il database locale e quando confermi che un URL è dannoso.

In sintesi, utilizza l'API Lookup se vuoi eseguire la configurazione in modo facile e veloce. Utilizza l'API Update se hai bisogno di un controllo degli URL con latenza inferiore.

Scegliere le funzionalità del client giuste

Se hai scelto di utilizzare l'API Update, potresti non dover implementare l'intera specifica. Alcune funzionalità sono state progettate per client ampiamente distribuiti (come i browser web) e sono sovraottimizzazioni in molti casi aziendali.

Alcune funzionalità possono essere ignorate per semplificare l'integrazione.

Di seguito sono riportate le soluzioni di integrazione di Web Risk in ordine di complessità

  1. Utilizzare l'API LookUp
  2. Client API di aggiornamento di base
  3. Aggiorna il client API utilizzando le differenze
  4. Aggiorna il client API utilizzando le differenze compresse RICE

Utilizzo dell'API Lookup

L'utilizzo dell'API Lookup ha la complessità più bassa. Ogni volta che è presente un URL potenzialmente sconveniente, chiama semplicemente l'API Lookup con l'URL per visualizzare un verdetto. La canonicalizzazione e la formattazione dell'URL vengono gestite dal server Web Risk. Questa soluzione dovrebbe essere valida per la maggior parte dei clienti, a meno che la latenza media non superi i requisiti.

Client API di aggiornamento di base

L'API Update richiede la complessità aggiuntiva della gestione di un database locale e di URL canonici prima delle query.

In una tipica integrazione del client con Web Risk, un client applicherà le differenze del database per rimanere aggiornato. L'implementazione corretta della logica di applicazione delle differenze può richiedere del tempo, pertanto nei casi più semplici consigliamo ai clienti di ignorare le differenze e di richiedere un nuovo database completo da Web Risk ogni ciclo. Questo database verrà ancora memorizzato in memoria per eseguire query efficienti. Per richiedere un ripristino completo del database, lascia vuoto il campo versionToken nella richiesta threatLists.computeDiff. Questa soluzione dovrebbe essere valida per i client, a meno che la larghezza di banda o la latenza della sincronizzazione del database non superino i requisiti.

Utilizzare l'API Update e richiedere aggiornamenti delle differenze

Questa soluzione presenta la complessità aggiuntiva dell'applicazione della logica di differenza al database locale. Per ulteriori informazioni, consulta Differenze del database. L'utilizzo delle differenze riduce la larghezza di banda a scapito della complessità, rispetto alla richiesta di un nuovo database ogni ciclo. Un aggiornamento completo del database potrebbe essere nell'ordine di alcuni megabyte. Questa soluzione dovrebbe essere sufficiente per la maggior parte dei clienti aziendali.

Utilizza l'API Update e richiedi aggiornamenti delle differenze codificate RICE

Questa soluzione è l'integrazione del cliente più efficiente possibile. La codifica RICE comprime le dimensioni dei file DIFF e riduce ulteriormente la larghezza di banda di aggiornamento. Questa soluzione è prevista per essere utilizzata dai clienti con limitazioni di larghezza di banda più stringenti. Un esempio in cui questo potrebbe essere pertinente è se le query relative ai rischi web sono integrate in un'app per smartphone. Gli utenti di un'app di questo tipo apprezzerebbero sicuramente una soluzione con una larghezza di banda inferiore se avessero bisogno di aggiornare il database tramite i dati dello smartphone. Per ulteriori informazioni, vedi Compressione.