Rileva URL dannosi con Web Risk

Prima di iniziare

Configura l'autenticazione e abilita l'API Web Risk

  1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
  2. Installa Google Cloud CLI.
  3. Per initialize gcloud CLI, esegui questo comando:

    gcloud init
  4. Crea o seleziona un progetto Google Cloud.

    • Crea un progetto Google Cloud:

      gcloud projects create PROJECT_ID

      Sostituisci PROJECT_ID con un nome per il progetto Google Cloud che stai creando.

    • Seleziona il progetto Google Cloud che hai creato:

      gcloud config set project PROJECT_ID

      Sostituisci PROJECT_ID con il nome del tuo progetto Google Cloud.

  5. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  6. Attiva l'API Web Risk.

    gcloud services enable webrisk.googleapis.com
  7. Installa Google Cloud CLI.
  8. Per initialize gcloud CLI, esegui questo comando:

    gcloud init
  9. Crea o seleziona un progetto Google Cloud.

    • Crea un progetto Google Cloud:

      gcloud projects create PROJECT_ID

      Sostituisci PROJECT_ID con un nome per il progetto Google Cloud che stai creando.

    • Seleziona il progetto Google Cloud che hai creato:

      gcloud config set project PROJECT_ID

      Sostituisci PROJECT_ID con il nome del tuo progetto Google Cloud.

  10. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  11. Attiva l'API Web Risk.

    gcloud services enable webrisk.googleapis.com

Utilizzo delle API

Quando utilizzi le API Web Risk, assicurati di conoscere l'accordo sul livello del servizio e i limiti di utilizzo di Web Risk.

Per iniziare a utilizzare Web Risk, vedi questi argomenti:

Qual è l'API più adatta alle mie esigenze? Eseguire ricerche o aggiornare?

Web Risk fornisce due diverse API con cui è possibile l'integrazione. Queste API sono l'API Lookup e l'API Update. Entrambe queste API forniscono le stesse informazioni. Ciò significa che 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 presenta alcune proprietà desiderabili. Utilizzando l'API Update, gestirai un database locale. È possibile controllare questo database per verificare se un URL è dannoso. Questo database funge da filtro di fioritura. In altre parole, potrebbero esserci falsi positivi (un URL è identificato come dannoso ma non lo è), ma non dovrebbero esserci falsi negativi (un URL è identificato come non dannoso, ma lo è). Per questo motivo, i server 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 devi contattare i server Web Risk. Devi contattare i server Web Risk soltanto quando aggiorni il database locale e quando confermi che un URL è dannoso.

Per riassumere, utilizza l'API Lookup se vuoi una configurazione rapida e semplice. Utilizza l'API Update se hai bisogno di controllare gli URL con una latenza inferiore.

Scegliere le funzioni giuste per i clienti

Se hai scelto di utilizzare l'API Update, potrebbe non essere necessario implementare l'intera specifica. Alcune funzionalità progettate per client ampiamente distribuiti (come i browser web) sono eccessivamente ottimizzate in molti casi aziendali.

Alcune funzionalità potrebbero essere ignorate per facilitare l'integrazione.

Ecco le soluzioni di integrazione di Web Risk in ordine di complessità

  1. Utilizzare l'API LookUp
  2. Client API Basic Update
  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à minore. Ogni volta che viene rilevato un URL potenzialmente sospetto, è sufficiente chiamare l'API Lookup con l'URL per visualizzare un esito. La canonicalizzazione e formattazione dell'URL sono gestite dal server Web Risk. Questa soluzione dovrebbe essere valida per la maggior parte dei client, a meno che la latenza media non superi i requisiti.

Client API Basic Update

L'API Update richiede l'ulteriore complessità di gestione di un database locale e degli URL canonici prima delle query.

In una tipica integrazione client con Web Risk, un client applica le differenze del database per rimanere aggiornato. L'implementazione corretta della logica dell'applicazione per le differenze potrebbe richiedere del tempo, quindi nei casi più semplici consigliamo ai client di ignorare le differenze e di richiedere un nuovo database completo da Web Risk a ogni ciclo. Questo database verrà comunque archiviato in memoria per eseguire query in modo efficiente. La richiesta di reimpostazione completa del database viene eseguita lasciando vuoto il campo versionToken nella richiesta threatLists.computeDiff. Questa soluzione deve essere valida per i client, a meno che la latenza di sincronizzazione della larghezza di banda o del database non superi i requisiti.

Utilizza l'API Update e richiedi gli aggiornamenti delle differenze

Questa soluzione presenta la complessità aggiuntiva derivante dall'applicazione della logica di diff al database locale. Per ulteriori informazioni, consulta Differenze database. L'uso delle differenze riduce la larghezza di banda a scapito della complessità, rispetto alla richiesta di un nuovo database a ogni ciclo. L'aggiornamento completo del database può richiedere alcuni megabyte. Questa soluzione dovrebbe essere sufficiente per la maggior parte dei client aziendali.

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

Questa soluzione offre l'integrazione più efficiente possibile dei clienti. La codifica RICE comprime le dimensioni DIFF e riduce ulteriormente la larghezza di banda di aggiornamento. Questa soluzione è pensata per essere utilizzata dai clienti con la maggiore larghezza di banda limitata. Un esempio in cui ciò può essere pertinente è il caso in cui le query Web Risk sono integrate in un'app per telefono. Gli utenti di questa app apprezzerebbero sicuramente una soluzione con larghezza di banda inferiore se avessero bisogno di aggiornare il database tramite i dati telefonici. Per ulteriori informazioni, consulta la sezione Compressione.