Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.
Rilevare URL dannosi con Web Risk

Rilevare URL dannosi con Web Risk

Prima di iniziare

Abilita l'API Web Risk

  1. Attiva Web Risk API.

    Abilita l'API

  2. Crea un account di servizio:

    1. In Google Cloud Console, vai alla pagina Crea account di servizio.

      Vai a Crea account di servizio
    2. Seleziona il progetto.
    3. Nel campo Nome account di servizio, inserisci un nome. Google Cloud Console compila il campo ID account di servizio in base a questo nome.

      Nel campo Descrizione account di servizio, inserisci una descrizione. Ad esempio: Service account for quickstart.

    4. Fai clic su Crea e continua.
    5. Fai clic su Fine per completare la creazione dell'account di servizio.

      Non chiudere la finestra del browser. Lo utilizzerai nel passaggio successivo.

    Crea una chiave dell'account di servizio:

    1. Nella console Google Cloud, fai clic sull'indirizzo email dell'account di servizio che hai creato.
    2. Fai clic su Chiavi.
    3. Fai clic su Aggiungi chiave, quindi su Crea nuova chiave.
    4. Fai clic su Crea. Il file di una chiave JSON viene scaricato sul computer.
    5. Fai clic su Chiudi.
  3. Fornisci le credenziali di autenticazione al codice della tua applicazione impostando la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS. Questa variabile si applica solo alla sessione shell corrente. Se vuoi che la variabile venga applicata alle sessioni shell future, impostala nel file di avvio della shell, ad esempio nel file ~/.bashrc o ~/.profile.

    Linux o macOS

    export GOOGLE_APPLICATION_CREDENTIALS="KEY_PATH"

    Sostituisci KEY_PATH con il percorso del file JSON che contiene la chiave dell'account di servizio.

    Ad esempio:

    export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/service-account-file.json"

    Windows

    Per PowerShell:

    $env:GOOGLE_APPLICATION_CREDENTIALS="KEY_PATH"

    Sostituisci KEY_PATH con il percorso del file JSON che contiene la chiave dell'account di servizio.

    Ad esempio:

    $env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\Downloads\service-account-file.json"

    Per il prompt dei comandi:

    set GOOGLE_APPLICATION_CREDENTIALS=KEY_PATH

    Sostituisci KEY_PATH con il percorso del file JSON che contiene la chiave dell'account di servizio.

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 i seguenti argomenti:

Quale API è adatta a me? Vuoi cercare o aggiornare?

Web Risk fornisce due diverse API con cui puoi eseguire l'integrazione. Queste API sono l'API Lookup e l'API Update. Entrambe queste API forniscono le stesse informazioni. Vale a dire se un URL è stato identificato come dannoso. L'API Lookup è più facile da usare. Utilizzando l'API Lookup, eseguirai una query di Web Risk per ogni URL che vuoi controllare.

L'API Update è più complessa, ma ha alcune proprietà desiderabili. Utilizzando l'API Update, gestirai un database locale. Questo database potrebbe essere controllato per verificare se un URL è dannoso. Questo database funge da filtro per la fioritura. In altre parole, possono verificarsi falsi positivi (un URL è identificato come dannoso, ma non lo è), ma non devono verificarsi 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 controlli un URL utilizzando l'API Update non devi contattare affatto i server Web Risk. Devi contattare i server Web Risk solo quando aggiorna il database locale e quando verifichi un URL dannoso.

In sintesi, utilizza l'API Lookup se vuoi eseguire la configurazione in modo semplice e veloce. Utilizza l'API Update se hai bisogno di un controllo degli URL a latenza inferiore.

Scegliere le funzionalità giuste per il client

Se scegli di utilizzare l'API Update, potresti non dover implementare l'intera specifica. Esistono alcune funzionalità progettate per client ampiamente distribuiti, come i browser web, che sono ottimizzati in eccesso in molti casi aziendali.

Alcune funzionalità potrebbero essere ignorate per una più facile integrazione.

Ecco le soluzioni di integrazione del rischio web in ordine di complessità

  1. Usare l'API LookUp
  2. Client di base per l'API Update
  3. Aggiornamento del client API utilizzando le differenze
  4. Aggiornamento del client API tramite diff compresse RICE

Utilizzo dell'API Lookup

L'utilizzo dell'API Lookup ha la complessità più bassa. Ogni volta che esiste un URL potenzialmente sospetto, è sufficiente chiamare l'API Lookup con l'URL per visualizzare un esito. La canonicalizzazione 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 di base per l'API Update

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

In una tipica integrazione del client con Web Risk, il client applicherà le differenze di database per rimanere aggiornato. L'implementazione corretta della logica dell'applicazione diff può richiedere del tempo, 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 verrà comunque archiviato in memoria per eseguire query efficaci. 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 dei database non superi i requisiti.

Utilizzare l'API Update e richiedere gli aggiornamenti delle differenze

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

Utilizzare l'API Update e richiedere gli aggiornamenti diff con codifica RICE

Questa soluzione è l'integrazione client più efficiente possibile. La codifica RICE comprime le dimensioni DIFF e riduce ulteriormente la larghezza di banda di aggiornamento. Questa soluzione è destinata a essere utilizzata dalla maggior parte dei clienti con larghezza di banda limitata. Un esempio di questo tipo può essere pertinente se le query Web Risk sono integrate in un'app per telefono. Gli utenti di tale app apprezzano sicuramente una soluzione con larghezza di banda inferiore se devono aggiornare il database tramite i dati telefonici. Per ulteriori informazioni, consulta la sezione Compressione.