Rilevamento di URL dannosi con Web Risk

Rilevamento di URL dannosi con Web Risk

Prima di iniziare

Configurare l'autenticazione e abilitare 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 inizializzare l'interfaccia a riga di comando gcloud, esegui il comando seguente:

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

    • Crea un progetto Google Cloud:

      gcloud projects create PROJECT_ID
    • Seleziona il progetto Google Cloud che hai creato:

      gcloud config set project PROJECT_ID
  5. Verifica che la fatturazione sia attivata per il tuo progetto Google Cloud. Scopri come verificare se la fatturazione è abilitata per un progetto.

  6. Attiva l'API Web Risk.

    gcloud services enable webrisk.googleapis.com
  7. Installa Google Cloud CLI.
  8. Per inizializzare l'interfaccia a riga di comando gcloud, esegui il comando seguente:

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

    • Crea un progetto Google Cloud:

      gcloud projects create PROJECT_ID
    • Seleziona il progetto Google Cloud che hai creato:

      gcloud config set project PROJECT_ID
  10. Verifica che la fatturazione sia attivata per il tuo progetto Google Cloud. Scopri come verificare se la fatturazione è abilitata per un progetto.

  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, consulta questi argomenti:

Qual è l'API giusta per me? Cercare o aggiornare?

Web Risk fornisce due diverse API che puoi integrare. Si tratta dell'API Search e dell'API Update. Entrambe queste API forniscono le stesse informazioni. Questo significa che un URL è stato identificato come dannoso. L'API Search è il più semplice da utilizzare. Con l'API lookup, eseguirai query su Web Risk per ogni URL che vuoi controllare.

L'API Update è più complessa, ma ha alcune proprietà desiderabili. Utilizzando l'API Update, manterrai un database locale. Questo database può essere controllato per verificare se un URL è dannoso. Questo database funge da filtro fiorito. In altre parole, possono esistere falsi positivi (un URL è identificato come dannoso ma non lo è), ma non devono esserci falsi negativi (un URL è identificato come non dannoso, ma lo è). Per questo motivo, i server Web Risk vengono contattati raramente e vengono contattati solo per confermare le corrispondenze e disambiguare i falsi positivi. Nella maggior parte dei casi, quando si controlla un URL usando l'API Update non è necessario contattare i server Web Risk. Dovresti contattare i server Web Risk solo quando aggiorni il database locale e quando confermi un URL dannoso.

In breve, utilizza l'API lookup se vuoi eseguire la configurazione in modo rapido e semplice. Utilizza l'API Update se hai bisogno di un controllo degli URL a latenza più bassa.

Scelta delle funzionalità giuste per il client

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

Alcune funzionalità potrebbero essere ignorate per un'integrazione più semplice.

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

  1. Usare 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 Search è il più complesso possibile. Ogni volta che c'è un URL potenzialmente sospetto, basta chiamare l'API lookup con l'URL per vedere un verdetto. La canonizzazione e la formattazione dell'URL vengono gestite dal server Web Risk. Questa soluzione deve essere valida per la maggior parte dei client, 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 client con Web Risk, un client applicherà le differenze di database per rimanere aggiornato. La logica dell'applicazione diff può richiedere del tempo per l'implementazione corretta, quindi nei casi più semplici consigliamo ai client di ignorare le differenze e richiedere un database completamente nuovo da Web Risk ogni ciclo. Questo database sarà comunque archiviato in memoria per eseguire query in modo efficiente. Per richiedere la reimpostazione completa del database, lascia vuoto il campo versionToken nella richiesta threatLists.computeDiff. Questa soluzione deve essere valida per i client, a meno che la larghezza di banda o la latenza di sincronizzazione del database non superi i requisiti.

Utilizzare l'API Update e richiedere gli aggiornamenti delle differenze

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

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

Questa soluzione è l'integrazione del client più efficiente possibile. La codifica RICE comprime le dimensioni DIFF e riduce ulteriormente la larghezza di banda dell'aggiornamento. Questa soluzione è destinata a essere utilizzata dalla maggior parte dei clienti con larghezza di banda limitata. Un esempio potrebbe essere pertinente se le query Web Risk sono integrate in un'applicazione telefonica. Gli utenti di tale applicazione apprezzerebbero sicuramente una soluzione con larghezza di banda inferiore se avessero bisogno di aggiornare il database tramite i dati del telefono. Per ulteriori informazioni, consulta l'articolo Compressione.