Jobs und Job-Trigger

Ein Job ist eine Aktion, die im Rahmen des Schutzes sensibler Daten ausgeführt wird, um in Inhalten nach sensiblen Daten zu suchen oder das Risiko einer Re-Identifikation zu berechnen. Jedes Mal, wenn Sie den Schutz sensibler Daten dazu anweisen, Ihre Daten zu überprüfen, wird eine Jobressource erstellt und ausgeführt.

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 Jobs vom Schutz sensibler Daten ausgeführt werden. Ein Job-Trigger ist ein Ereignis, das die Erstellung von Jobs zum Schutz sensibler Daten zum Scannen von Google Cloud-Speicher-Repositories, einschließlich Cloud Storage-Buckets, BigQuery-Tabellen und Datenspeichertypen, automatisiert.

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.

Nächste Schritte

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

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

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:

Joblatenz

Für Jobs und Jobtrigger werden keine Service Level Objectives (SLOs) garantiert. Die Latenz hängt von mehreren Faktoren ab, darunter die zu scannende Datenmenge, das zu scannende Speicher-Repository, der Typ und die Anzahl der Infotypen, nach denen Sie suchen, 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 Stichprobenerhebung für Ihren Job oder Job-Trigger verfügbar ist, aktivieren Sie sie.
  • Aktivieren Sie nicht benötigte infoTypes. Die folgenden „infoTypes“ sind in bestimmten Szenarien zwar nützlich, können aber dazu führen, dass Anfragen viel langsamer ausgeführt werden als Anfragen ohne diese „infoTypes“:

    • 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 Ausprobieren dieser Methoden weiterhin Latenzprobleme mit Jobs haben, sollten Sie anstelle von Jobs content.inspect- oder content.deidentify-Anfragen verwenden. Für diese Methoden gilt das Service Level Agreement. Weitere Informationen finden Sie in der Service Level Agreement zum Schutz sensibler Daten.

Scans ausschließlich auf neuen Inhalt beschränken

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

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

Bei der BigQuery-Prüfung werden nur Zeilen, die mindestens drei Stunden alt sind, in den Scan einbezogen. Weitere Informationen finden Sie im Hilfeartikel zu bekannten Problemen.

Jobs beim Hochladen von Dateien auslösen

Zusätzlich zur Unterstützung von Job-Triggern, die in den Schutz sensibler Daten eingebunden sind, bietet Google Cloud eine Vielzahl anderer Komponenten, mit denen Sie Jobs für den Schutz sensibler Daten einbinden oder auslösen können. Beispielsweise können Sie Cloud Run-Funktionen verwenden, um bei jedem Hochladen einer Datei in Cloud Storage einen Scan für den Schutz sensibler Daten auszulösen.

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