Rilevare 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 senza costi per l'esecuzione, il test e il deployment dei carichi di lavoro.

  2. Installa Google Cloud CLI.

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

  4. Per inizializzare gcloud CLI, esegui questo comando: 

    gcloud init

  5. 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 per il quale ti è stato concesso un ruolo.
    • Crea un progetto: per creare un progetto, devi disporre del ruolo Autore progetto (roles/resourcemanager.projectCreator), che contiene l'autorizzazione resourcemanager.projects.create. Scopri come concedere i ruoli.

    • Creare 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 progetto Google Cloud .

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

  7. Abilita l'API Web Risk:

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre dell'autorizzazione serviceusage.services.enable. Se hai creato il progetto, probabilmente disponi già di questa autorizzazione tramite il ruolo Proprietario (roles/owner). In caso contrario, puoi ottenere questa autorizzazione tramite il ruolo Amministratore utilizzo dei servizi (roles/serviceusage.serviceUsageAdmin). Scopri come concedere i ruoli. 

    gcloud services enable webrisk.googleapis.com

  8. Installa Google Cloud CLI.

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

  10. Per inizializzare gcloud CLI, esegui questo comando: 

    gcloud init

  11. 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 per il quale ti è stato concesso un ruolo.
    • Crea un progetto: per creare un progetto, devi disporre del ruolo Autore progetto (roles/resourcemanager.projectCreator), che contiene l'autorizzazione resourcemanager.projects.create. Scopri come concedere i ruoli.

    • Creare 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 progetto Google Cloud .

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

  13. Abilita l'API Web Risk:

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre dell'autorizzazione serviceusage.services.enable. Se hai creato il progetto, probabilmente disponi già di questa autorizzazione tramite il ruolo Proprietario (roles/owner). In caso contrario, puoi ottenere questa autorizzazione tramite il ruolo Amministratore utilizzo dei servizi (roles/serviceusage.serviceUsageAdmin). Scopri come concedere i ruoli. 

    gcloud services enable webrisk.googleapis.com
    14.

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:

Quale API è più adatta alle mie esigenze? Ricerca o aggiornamento?

Web Risk fornisce due API diverse che puoi integrare. Queste API sono l'API Lookup e l'API Update. Entrambe queste API forniscono le stesse informazioni. ovvero se un URL è stato identificato come dannoso. La più semplice da utilizzare è l'API Lookup. Utilizzando l'API Lookup, interrogherai 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 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 distinguere i falsi positivi. Nella maggior parte dei casi, quando controlli un URL utilizzando l'API Update, non dovrai contattare i server di Web Risk. Devi 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. Alcune funzionalità progettate per client ampiamente distribuiti (come i browser web) sono eccessivamente ottimizzate in molti casi aziendali.

Per semplificare l'integrazione, alcune funzionalità potrebbero essere ignorate.

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

  1. Utilizzare l'API LookUp
  2. Client API Basic Update
  3. Aggiornare 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 viene rilevato un URL potenzialmente sospetto, chiama l'API Lookup con l'URL per visualizzare un verdetto. La canonizzazione 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 Basic Update

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 applica le differenze del database per rimanere aggiornato. La logica di applicazione delle differenze potrebbe richiedere del tempo per essere implementata correttamente, quindi nei casi più semplici consigliamo ai client di ignorare le differenze e richiedere un nuovo database completo a Web Risk a ogni ciclo. Questo database verrà comunque memorizzato per query efficienti. La richiesta di ripristino completo del database viene effettuata lasciando 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 di sincronizzazione del database non superino i requisiti.

Utilizzare l'API Update e richiedere aggiornamenti differenziali

Questa soluzione presenta la complessità aggiuntiva di applicare la logica diff al database locale. Per saperne di più, consulta Differenze tra database. L'utilizzo delle differenze ridurrà 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 dell'ordine di alcuni megabyte. Questa soluzione dovrebbe essere sufficiente per la maggior parte dei clienti aziendali.

Utilizzare l'API Update e richiedere aggiornamenti differenziali codificati RICE

Questa soluzione è l'integrazione client più efficiente possibile. La codifica RICE comprime le dimensioni delle differenze e riduce ulteriormente la larghezza di banda degli aggiornamenti. Questa soluzione è destinata ai clienti con la larghezza di banda più limitata. Un esempio in cui questo potrebbe essere pertinente è se le query di Navigazione sicura 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 dovessero aggiornare il database tramite i dati dello smartphone. Per ulteriori informazioni, vedi Compressione.