Rilevare URL dannosi con Web Risk

Prima di iniziare

Crea un Google Cloud progetto. Scopri come creare un Google Cloud progetto.
Verifica che la fatturazione sia abilitata per il tuo Google Cloud progetto.

Configurare l'autenticazione e abilitare l'API Web Risk

Accedi al tuo Google Cloud account. 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 senza costi per l'esecuzione, il test e il deployment dei workload.

Installa Google Cloud CLI.

Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.

Per inizializzare gcloud CLI, esegui questo comando:

gcloud init

Crea o seleziona un Google Cloud progetto.

Ruoli richiesti per selezionare o creare un progetto

Seleziona un progetto: la selezione di un progetto non richiede un ruolo IAM specifico. Puoi selezionare qualsiasi progetto su cui ti è stato concesso un ruolo.
Crea un progetto: per creare un progetto, devi disporre del ruolo Autore progetto (roles/resourcemanager.projectCreator), che contiene l' resourcemanager.projects.create autorizzazione. Scopri come concedere i ruoli.

Crea un Google Cloud progetto:
```
gcloud projects create PROJECT_ID
```
Sostituisci PROJECT_ID con un nome per il Google Cloud progetto che stai creando.
Seleziona il Google Cloud progetto che hai creato:
```
gcloud config set project PROJECT_ID
```
Sostituisci PROJECT_ID con il nome del Google Cloud progetto.

Verifica che la fatturazione sia abilitata per il tuo Google Cloud progetto.

Abilita l'API Web Risk:

Ruoli richiesti per abilitare le API

Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo servizi (roles/serviceusage.serviceUsageAdmin), che contiene l' serviceusage.services.enable autorizzazione. Scopri come concedere i ruoli.

gcloud services enable webrisk.googleapis.com

Installa Google Cloud CLI.

Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.

Per inizializzare gcloud CLI, esegui questo comando:

gcloud init

Crea o seleziona un Google Cloud progetto.

Ruoli richiesti per selezionare o creare un progetto

Seleziona un progetto: la selezione di un progetto non richiede un ruolo IAM specifico. Puoi selezionare qualsiasi progetto su cui ti è stato concesso un ruolo.
Crea un progetto: per creare un progetto, devi disporre del ruolo Autore progetto (roles/resourcemanager.projectCreator), che contiene l' resourcemanager.projects.create autorizzazione. Scopri come concedere i ruoli.

Crea un Google Cloud progetto:
```
gcloud projects create PROJECT_ID
```
Sostituisci PROJECT_ID con un nome per il Google Cloud progetto che stai creando.
Seleziona il Google Cloud progetto che hai creato:
```
gcloud config set project PROJECT_ID
```
Sostituisci PROJECT_ID con il nome del Google Cloud progetto.

Verifica che la fatturazione sia abilitata per il tuo Google Cloud progetto.

Abilita l'API Web Risk:

Ruoli richiesti per abilitare le API

gcloud services enable webrisk.googleapis.com

Utilizzare le 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:

Quale API è adatta a me? Lookup o Update?

Web Risk fornisce due API diverse che puoi integrare. Queste API sono l'API Lookup e l'API Update. Entrambe le API forniscono le stesse informazioni. Ovvero, se un URL è stato identificato come dannoso. La più facile da usare è l'API Lookup. Utilizzando l'API Lookup, eseguirai una 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 di Bloom. Ovvero, potrebbero 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 Web Risk vengono contattati raramente e solo per confermare le corrispondenze e disambiguare 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 configurarla in modo rapido e semplice. Utilizza l'API Update se hai bisogno di un controllo degli URL a bassa latenza.

Scegliere le funzionalità client giuste

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

Esistono alcune funzionalità che possono essere ignorate per una più facile integrazione.

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

Utilizza l'API Lookup
Client API Update di base
Client API Update che utilizza le differenze
Client API Update che utilizza 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 sospetto, chiama 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 client, a meno che la latenza media non superi i requisiti.

Client API Update di base

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

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

Utilizzare l'API Update e richiedere gli aggiornamenti delle differenze

Questa soluzione ha la complessità aggiuntiva di applicare la logica delle differenze al database locale. Per saperne di più, consulta Differenze del database. L'utilizzo delle differenze riduce la larghezza di banda a scapito della complessità, rispetto alla richiesta di un nuovo database a ogni ciclo. Un aggiornamento completo del database potrebbe essere di pochi megabyte. Questa soluzione dovrebbe essere sufficiente per la maggior parte dei clienti aziendali.

Utilizzare l'API Update e richiedere gli aggiornamenti delle differenze codificate RICE

Questa soluzione è l'integrazione client più efficiente possibile. La codifica RICE comprime le dimensioni delle differenze e riduce ulteriormente la larghezza di banda di aggiornamento. Questa soluzione è destinata ai clienti con la larghezza di banda più limitata. Un esempio in cui potrebbe essere pertinente è se le query Web Risk sono integrate in un'app per smartphone. Gli utenti di un'app di questo tipo apprezzerebbero sicuramente una soluzione a larghezza di banda inferiore se avessero bisogno di aggiornare il database tramite i dati dello smartphone. Per saperne di più, consulta Compressione.