Bösartige URLs mit Web Risk erkennen

Hinweise

Authentifizierung einrichten und die Web Risk API aktivieren

  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

APIs verwenden

Wenn Sie die Web Risk APIs verwenden, sollten Sie mit dem Service Level Agreement und mit den Nutzungslimits von Web Risk vertraut sein.

Informationen zur Verwendung von Web Risk finden Sie in den folgenden Themen:

Welche API ist die richtige für mich? Lookup oder Update?

Web Risk bietet zwei verschiedene APIs, die Sie einbinden können. Diese APIs sind die Lookup API und die Update API. Beide APIs liefern dieselben Informationen. Das heißt, ob eine URL als schädlich eingestuft wurde. Die einfachste Methode ist die Lookup API. Mit der Lookup API fragen Sie Web Risk nach jeder URL ab, die Sie prüfen möchten.

Die Update API ist komplexer, verfügt jedoch über einige wünschenswerte Eigenschaften. Mit der Update API verwalten Sie eine lokale Datenbank. Diese Datenbank kann geprüft werden, um festzustellen, ob eine URL schädlich ist. Diese Datenbank fungiert als Bloomfilter. Das heißt, es kann falsche positive Ergebnisse geben (eine URL wird als schädlich identifiziert, ist sie aber nicht), aber es sollte keine falschen negativen Ergebnisse geben (eine URL wird als nicht schädlich identifiziert, ist sie aber). Aus diesem Grund werden die Web Risk-Server nur selten kontaktiert. Sie werden nur kontaktiert, um Übereinstimmungen zu bestätigen und falsch positive Ergebnisse zu unterscheiden. In den meisten Fällen müssen Sie beim Prüfen einer URL mit der Update API überhaupt keine Verbindung zu den Web Risk-Servern herstellen. Sie sollten Web Risk-Server nur dann kontaktieren, wenn Sie die lokale Datenbank aktualisieren und Sie bestätigen möchten, dass eine URL schädlich ist.

Zusammenfassend lässt sich sagen, dass die Einrichtung mit der Lookup API schnell und einfach ist. Verwenden Sie die Update API, wenn Sie eine URL-Prüfung mit geringerer Latenz benötigen.

Richtige Client-Funktionen auswählen

Wenn Sie die Update API verwenden, müssen Sie möglicherweise nicht die gesamte Spezifikation implementieren. Es gibt einige Funktionen, die für weit verteilte Clients entwickelt wurden (z. B. Webbrowser), die in vielen Fällen zu häufig optimiert werden.

Es gibt einige Funktionen, die zur Vereinfachung der Einbindung ignoriert werden können.

Hier sind die Integrationslösungen von Web Risk in der Reihenfolge ihrer Komplexität:

  1. LookUp API verwenden
  2. Basic Update API-Client
  3. API-Client mit Diffs aktualisieren
  4. API-Client mit komprimierten RICE-Diffs aktualisieren

Lookup API verwenden

Die Verwendung der Lookup API ist am einfachsten. Wenn eine potenziell verdächtige URL vorhanden ist, rufen Sie einfach die Lookup API mit der URL auf, um ein Ergebnis zu sehen. Die Kanonisierung und Formatierung der URL wird vom Web Risk-Server übernommen. Diese Lösung sollte für die meisten Clients gültig sein, sofern die durchschnittliche Latenz die Anforderungen nicht überschreitet.

Basic Update API-Client

Die Update API erfordert die zusätzliche Komplexität der Verwaltung einer lokalen Datenbank und kanonischer URLs vor Abfragen.

Bei einer typischen Client-Einbindung mit Web Risk wendet ein Client Datenbank-Diffs an, um auf dem neuesten Stand zu bleiben. Es kann einige Zeit dauern, bis die Anwendungslogik von Diff korrekt implementiert ist. In den einfachsten Fällen empfehlen wir daher, dass Clients in jedem Zyklus Diffs ignorieren und eine vollständige neue Datenbank von Web Risk anfordern. Diese Datenbank wird weiterhin für eine effiziente Abfrage gespeichert. Sie können ein vollständiges Zurücksetzen der Datenbank anfordern, indem Sie das Feld versionToken in der threatLists.computeDiff-Anfrage leer lassen. Diese Lösung sollte für Clients gültig sein, es sei denn, die Latenz der Bandbreiten- oder Datenbanksynchronisierung übersteigt die Anforderungen.

Update API verwenden und Diff-Aktualisierungen anfragen

Diese Lösung hat die zusätzliche Komplexität der Anwendung der Diff-Logik auf die lokale Datenbank. Weitere Informationen finden Sie unter Datenbank-Diffs. Die Verwendung von Diffs reduziert die Bandbreite auf Kosten der Komplexität im Vergleich zur Anforderung einer neuen Datenbank in jedem Zyklus. Eine vollständige Datenbankaktualisierung kann einige Megabyte groß sein. Diese Lösung sollte für die meisten Unternehmenskunden ausreichen.

Mit der Update API RICE-codierte Diff-Aktualisierungen anfragen

Diese Lösung ist die effizienteste Client-Einbindung. Die RICE-Codierung komprimiert DIFF-Größen und reduziert die Aktualisierungsbandbreite weiter. Diese Lösung ist für die Kunden mit den meisten Bandbreitenbeschränkungen vorgesehen. Ein Beispiel hierfür könnte sein, wenn Web Risk-Abfragen in eine Telefon-App eingebunden sind. Die Nutzer einer solchen Anwendung würden sich sicher für eine Lösung mit geringerer Bandbreite entscheiden, wenn sie die Datenbank über Telefondaten aktualisieren müssten. Weitere Informationen finden Sie unter Komprimierung.