Rileva URL dannosi con Web Risk
Prima di iniziare
Creare un progetto Google Cloud. Scopri come creare un progetto Google Cloud.
Make sure that billing is enabled for your Google Cloud project.
Configura l'autenticazione e abilita l'API Web Risk
- 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.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
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.
-
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Web Risk API:
gcloud services enable webrisk.googleapis.com
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
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.
-
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Web Risk API:
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à
- Utilizzare l'API LookUp
- Client API Basic Update
- Aggiorna il client API utilizzando le differenze
- 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.