Détecter les URL malveillantes avec Web Risk

Avant de commencer

Configurer l'authentification et activer l'API Web Risk

  1. 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.
  2. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

    gcloud init
  4. 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.

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Enable the Web Risk API:

    gcloud services enable webrisk.googleapis.com
  7. Install the Google Cloud CLI.
  8. To initialize the gcloud CLI, run the following command:

    gcloud init
  9. 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.

  10. Make sure that billing is enabled for your Google Cloud project.

  11. Enable the Web Risk API:

    gcloud services enable webrisk.googleapis.com

Utiliser les API

Lorsque vous utilisez les API Web Risk, assurez-vous de bien connaître le contrat de niveau de service et les limites d'utilisation de Web Risk.

Pour commencer à utiliser Web Risk, consultez les rubriques suivantes :

Quelle API me convient-elle le mieux ? Lookup ou Update ?

Web Risk fournit deux API différentes que vous pouvez intégrer. Ces API sont : l'API Lookup et l'API Update. Ces deux API fournissent les mêmes informations. À savoir, si une URL a été identifiée comme malveillante. L'API Lookup est la plus simple à utiliser. À l'aide de l'API Lookup, vous interrogerez Web Risk concernant chaque URL que vous souhaitez vérifier.

L'API Update est plus complexe, mais possède certaines propriétés avantageuses. À l'aide de l'API Update, vous gérerez une base de données locale. Cette base de données peut être vérifiée pour déterminer si une URL est malveillante. Cette base de données fait office de filtre de Bloom. Par exemple, il peut y avoir de faux positifs (une URL est identifiée comme malveillante, mais ne l'est pas), mais il ne doit y avoir aucun faux négatif (une URL est identifiée comme n'étant pas malveillante, mais l'est). Par conséquent, les serveurs Web Risk sont rarement contactés et le sont uniquement pour confirmer les correspondances et lever les ambiguïtés sur les faux positifs. Dans la plupart des cas, lorsque vous vérifiez une URL à l'aide de l'API Update, vous n'aurez aucunement besoin de contacter les serveurs Web Risk. Vous ne devez contacter les serveurs Web Risk que lorsque vous mettez à jour la base de données locale et que vous confirmez qu'une URL est malveillante.

En résumé, utilisez l'API Lookup si vous souhaitez obtenir une configuration rapidement et facilement. Utilisez l'API Update si vous devez effectuer une vérification d'URL avec une latence plus faible.

Choisir les fonctionnalités client appropriées

Si vous choisissez d'utiliser l'API Update, vous n'aurez peut-être pas besoin de mettre en œuvre l'intégralité de la spécification. Certaines fonctionnalités conçues pour des clients largement distribués (tels que les navigateurs Web) sont sur-optimisées dans de nombreux cas d'affaires.

Certaines fonctionnalités peuvent être ignorées pour faciliter l'intégration.

Voici les solutions d'intégration Web Risk par ordre de complexité :

  1. Utiliser l'API LookUp
  2. Client de l'API Basic Update
  3. Mettre à jour le client API à l'aide des différences
  4. Mettre à jour le client API à l'aide des différences RICE compressées

Utiliser l'API Lookup

L'API Lookup est la moins complexe à utiliser. En cas d'URL potentiellement suspecte, il vous suffit d'appeler l'API Lookup avec l'URL pour obtenir un résultat. La mise en forme canonique et le formatage de l'URL sont gérés par le serveur Web Risk. Cette solution devrait être valide pour la plupart des clients, sauf si la latence moyenne dépasse les exigences.

Client de l'API Basic Update

L'API Update présente la complexité supplémentaire de gérer une base de données locale et des URL canoniques avant les requêtes.

Lors d'une intégration client classique à l'aide de Web Risk, un client appliquera les différences de bases de données pour rester à jour. La mise en œuvre de la logique d'application des différences peut prendre un certain temps. Dans les cas les plus simples, nous recommandons que les clients ignorent les différences et demandent une nouvelle base de données complète à chaque cycle Web Risk. Cette base de données sera toujours stockée en mémoire pour obtenir des requêtes plus efficaces. Pour demander la réinitialisation complète de la base de données, laissez le champ versionToken vide dans la requête threatLists.computeDiff. Cette solution devrait être valide pour tous les clients, sauf si la latence de synchronisation de la bande passante ou de la base de données dépasse les exigences.

Utiliser l'API Update et demander des mises à jour de différences

Cette solution présente la complexité supplémentaire de mettre en œuvre la logique d'application des différences dans la base de données locale. Pour en savoir plus, consultez la section Différences de bases de données. L'application des différences permet de réduire l'utilisation de la bande passante au prix d'une certaine complexité, par rapport à la demande d'une nouvelle base de données à chaque cycle. Une mise à jour complète de la base de données peut être de l'ordre de quelques mégaoctets. Cette solution devrait être suffisante pour la plupart des clients professionnels.

Utiliser l'API Update et demander des mises à jour de différences des données encodées RICE

Cette solution offre l'intégration client la plus efficace possible. L'encodage RICE compresse les tailles DIFF et réduit davantage la bande passante pour la mise à jour. Cette solution est destinée aux clients les plus limités en bande passante. Par exemple, cette solution peut être pertinente si les requêtes Web Risk sont intégrées dans une application pour téléphone. Les utilisateurs d'une telle application apprécieront sûrement une solution à faible bande passante s'ils doivent mettre à jour la base de données à l'aide des données du téléphone. Pour en savoir plus, consultez la section Compression.