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:
- Prüfjobs 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:
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 einSchedule
-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 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.