Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.
Détecter les URL malveillantes avec Web Risk

Détecter les URL malveillantes avec Web Risk

Avant de commencer

Configurer l'authentification et activer l'API Web Risk

  1. Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.
  2. Installez et initialisez Google Cloud CLI.
  3. Créez ou sélectionnez un projet Google Cloud.

    • Créez un projet Cloud :

      gcloud projects create PROJECT_ID
    • Sélectionnez le projet Cloud que vous avez créé :

      gcloud config set project PROJECT_ID
  4. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier si la facturation est activée sur un projet.

  5. Activer l'API Web Risk :

    gcloud services enable webrisk.googleapis.com
  6. Installez et initialisez Google Cloud CLI.
  7. Créez ou sélectionnez un projet Google Cloud.

    • Créez un projet Cloud :

      gcloud projects create PROJECT_ID
    • Sélectionnez le projet Cloud que vous avez créé :

      gcloud config set project PROJECT_ID
  8. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier si la facturation est activée sur un projet.

  9. Activer l'API Web Risk :

    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.