Jobs und Job-Trigger

Ein Job ist eine Aktion, die der Schutz sensibler Daten ausführt, um Inhalte auf sensible Daten zu scannen oder das Risiko einer Re-Identifikation zu berechnen. Beim Schutz sensibler Daten wird eine Jobressource erstellt und ausgeführt, wenn Sie ihn auffordern, Ihre Daten zu prüfen.

Derzeit gibt es zwei Arten von Jobs für den Schutz sensibler Daten:

• Mit Prüfjobs werden Ihre Inhalte anhand der angegebenen Kriterien auf sensible Daten geprüft. In den daraus generierten Zusammenfassungen wird dargestellt, welche Art von sensiblen Daten vorhanden sind und wo diese sich befinden.
• Mit Risikoanalysejobs werden de-identifizierte Daten analysiert, um Messwerte zur Wahrscheinlichkeit zurückzugeben, dass die Daten wieder identifiziert werden können.

Mit Job-Triggern können Sie planen, wann der Schutz sensibler Daten Jobs ausführt. Ein Job-Trigger ist ein Ereignis, das das Erstellen von Jobs zum Schutz sensibler Daten automatisiert, um Google Cloud Storage-Repositories zu scannen, einschließlich Cloud Storage-Buckets, BigQuery-Tabellen und Datastore-Arten.

Mit Job-Triggern können Sie Scanjobs planen, indem Sie Intervalle festlegen, in denen jeder Trigger ausgelöst wird. Sie können so konfiguriert werden, dass sie nach neuen Ergebnissen seit dem letzten Scan suchen, um Änderungen oder Ergänzungen des Inhalts zu überwachen oder aktuelle Ergebnisberichte zu generieren. Geplante Trigger werden in einem festgelegten Intervall von 1 bis 60 Tagen ausgeführt.

Hinweis: Ein vorzeitiges Abbrechen eines Vorgangs in der Mitte eines Jobs verursacht weiterhin Kosten für den Teil des Jobs, der abgeschlossen wurde. Weitere Informationen zur Abrechnung finden Sie unter Preise für den Schutz sensibler Daten.

Nächste Schritte

Informationen zum Erstellen, Bearbeiten und Ausführen von Jobs und Job-Triggern finden Sie in den folgenden Themen:

• Inspektionsjobs und Job-Trigger für den Schutz sensibler Daten erstellen
• Risiko der Re-Identifikation und Offenlegung messen (mit Informationen zu Risikoanalysejobs)

Außerdem steht Ihnen folgende Kurzanleitung zur Verfügung:

• Kurzanleitung: Job-Trigger für den Schutz sensibler Daten erstellen

Das JobTrigger-Objekt

Ein Job-Trigger wird in der DLP API durch das Objekt JobTrigger dargestellt.

Job-Trigger-Konfigurationsfelder

Jedes JobTrigger enthält mehrere Konfigurationsfelder, darunter:

• Triggername, Anzeigename und eine Beschreibung
• Eine Sammlung von Trigger-Objekten, von denen jedes ein Schedule-Objekt enthält, das die Wiederholungsrate in Sekunden definiert.
• Ein InspectJobConfig-Objekt, das die Konfigurationsinformationen für den ausgelösten Job enthält.
• Eine Status-Enum, die angibt, ob der Trigger derzeit aktiv ist.
• Zeitstempelfelder für die Erstellung, Aktualisierung und letzte Ausführung
• Eine Sammlung von Error-Objekten, die beim Aktivieren des Triggers gefunden wurden.

Job-Trigger-Methoden

Jedes JobTrigger-Objekt enthält auch mehrere integrierte Methoden. Mit diesen Methoden können Sie:

• Einen neuen Job-Trigger erstellen: projects.jobTriggers.create
• Einen vorhandenen Job-Trigger aktualisieren: projects.jobTriggers.patch
• Einen vorhandenen Job-Trigger löschen: projects.jobTriggers.delete
• Einen vorhandenen Job-Trigger einschließlich Konfiguration und Status abrufen: projects.jobTriggers.get
• Alle vorhandenen Job-Trigger auflisten: projects.jobTriggers.list

Joblatenz

Für Jobs und Job-Trigger werden keine Service Level Objectives (SLO) garantiert. Die Latenz wird von mehreren Faktoren beeinflusst, darunter die Menge der zu scannenden Daten, das gescannte Speicher-Repository, der Typ und die Anzahl der infoTypes, nach denen Sie scannen, die Region, in der der Job verarbeitet wird, und die in dieser Region verfügbaren Rechenressourcen. Daher kann die Latenz von Inspektionsjobs nicht im Voraus bestimmt werden.

Versuchen Sie Folgendes, um die Joblatenz zu reduzieren:

• Wenn Stichproben für den Job oder Job-Trigger verfügbar ist, aktivieren Sie sie.

• Vermeiden Sie die Aktivierung von infoTypes, die Sie nicht benötigen. Obwohl Folgendes in bestimmten Szenarien nützlich ist, können diese infoTypes Anfragen wesentlich langsamer ausführen als Anfragen, die sie nicht enthalten:

  • PERSON_NAME
  • FEMALE_NAME
  • MALE_NAME
  • FIRST_NAME
  • LAST_NAME
  • DATE_OF_BIRTH
  • LOCATION
  • STREET_ADDRESS
  • ORGANIZATION_NAME

• Geben Sie infoTypes immer explizit an. Verwenden Sie keine leere infoTypes-Liste.

• Verwenden Sie nach Möglichkeit eine andere Verarbeitungsregion.

Wenn Sie nach dem Ausführen dieser Techniken immer noch Latenzprobleme mit Jobs haben, sollten Sie anstelle von Jobs content.inspect- oder content.deidentify-Anfragen verwenden. Diese Methoden sind im Service Level Agreement (SLA) abgedeckt. Weitere Informationen finden Sie unter Service Level Agreement (SLA) für sensible Daten.

Scans ausschließlich auf neuen Inhalt beschränken

Sie können den Job-Trigger so konfigurieren, dass der Zeitraum für Dateien, die in Cloud Storage oder BigQuery gespeichert sind, automatisch eingestellt wird. Wenn Sie für das Objekt TimespanConfig das automatische Ausfüllen festlegen, scannt der Schutz sensibler Daten nur Daten, die seit der letzten Ausführung des Triggers hinzugefügt oder geändert wurden:

...
  timespan_config {
        enable_auto_population_of_timespan_config: true
      }
...

Hinweis: Sehen Sie sich das bekannte Problem in Bezug auf diesen Vorgang an.

Jobs beim Hochladen von Dateien auslösen

Neben der Unterstützung für Job-Trigger, die in den Schutz sensibler Daten eingebunden ist, bietet Google Cloud auch eine Vielzahl anderer Komponenten, mit denen Sie Jobs zum Schutz sensibler Daten einbinden oder auslösen können. Beispielsweise können Sie Cloud Functions verwenden, um bei jedem Hochladen einer Datei in Cloud Storage einen Scan zum Schutz sensibler Daten auszulösen.

Informationen zum Einrichten dieses Vorgangs finden Sie unter Klassifizierung der in Cloud Storage hochgeladenen Daten automatisieren.