Détecter les URL malveillantes avec Web Risk

Détecter les URL malveillantes avec Web Risk

Avant de commencer

Activer l'API Web Risk

  1. Activez Web Risk API.

    Activer l'API

  2. Créez un compte de service :

    1. Dans Cloud Console, accédez à la page Créer un compte de service.

      Accéder à la page "Créer un compte de service"
    2. Sélectionnez votre projet.
    3. Dans le champ Nom du compte de service, saisissez un nom. Cloud Console remplit le champ ID du compte de service en fonction de ce nom.

      Dans le champ Description du compte de service, saisissez une description. Exemple : Service account for quickstart.

    4. Cliquez sur Créer et continuer.
    5. Cliquez sur OK pour terminer la création du compte de service.

      Ne fermez pas la fenêtre de votre navigateur. Vous en aurez besoin lors de la tâche suivante.

    Créez une clé de compte de service :

    1. Dans Cloud Console, cliquez sur l'adresse e-mail du compte de service que vous avez créé.
    2. Cliquez sur Keys (Clés).
    3. Cliquez sur Ajouter une clé, puis sur Créer une clé.
    4. Cliquez sur Create (Créer). Un fichier de clé JSON est téléchargé sur votre ordinateur.
    5. Cliquez sur Close (Fermer).
  3. Fournissez des identifiants d'authentification au code de votre application en définissant la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS. Cette variable ne s'applique qu'à la session d'interface système actuelle. Si vous souhaitez que la variable s'applique aux sessions d'interface système futures, définissez-la dans votre fichier de démarrage de l'interface système, par exemple dans le fichier ~/.bashrc ou ~/.profile.

    Linux ou macOS

    export GOOGLE_APPLICATION_CREDENTIALS="KEY_PATH"

    Remplacez KEY_PATH par le chemin du fichier JSON contenant la clé de votre compte de service.

    Exemple :

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

    Windows

    Pour PowerShell :

    $env:GOOGLE_APPLICATION_CREDENTIALS="KEY_PATH"

    Remplacez KEY_PATH par le chemin du fichier JSON contenant la clé de votre compte de service.

    Exemple :

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

    Pour l'invite de commande :

    set GOOGLE_APPLICATION_CREDENTIALS=KEY_PATH

    Remplacez KEY_PATH par le chemin du fichier JSON contenant la clé de votre compte de service.

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.