Bekannte Probleme

Auf dieser Seite werden bekannte Probleme beim Schutz sensibler Daten sowie Möglichkeiten zur Vermeidung oder Behebung der folgenden Probleme aufgeführt.

Allgemeine Probleme

Ergebnisse in BigQuery speichern

Wenn Ergebnisse von einem Job- oder Discovery-Scan in BigQuery gespeichert werden, wird in den Logs der Fehler Already exists angezeigt. Der Fehler weist nicht auf ein Problem hin. Die Ergebnisse werden wie erwartet gespeichert.

BigQuery-Scans

In diesem Abschnitt werden Probleme beschrieben, die bei der inspecting oder der Profilerstellung für BigQuery-Daten auftreten können.

Häufige Probleme bei Inspektions- und Profilerstellungsvorgängen

Die folgenden Probleme betreffen sowohl BigQuery-Inspektions- als auch Profilerstellungsvorgänge.

Die folgenden Probleme gelten auch für De-Identifikationsvorgänge in BigQuery (in der Vorabversion).

Zeilen mit Sicherheit auf Zeilenebene können nicht gescannt werden

Sicherheitsrichtlinien auf Zeilenebene können verhindern, dass der Schutz sensibler Daten die geschützten BigQuery-Tabellen prüft und ein Profil erstellt. Wenn auf Ihre BigQuery-Tabellen Sicherheitsrichtlinien auf Zeilenebene angewendet werden, empfehlen wir, einen WAHR-Filter festzulegen und den Dienst-Agent in die Liste der Empfänger aufzunehmen:

Doppelte Zeilen

Beim Schreiben von Daten in eine BigQuery-Tabelle kann der Schutz sensibler Daten doppelte Zeilen schreiben.

Kürzlich gestreamte Daten

Beim Schutz sensibler Daten werden kürzlich gestreamte Daten (früher als Streaming-Zwischenspeicher bezeichnet) nicht gescannt. Weitere Informationen finden Sie unter Verfügbarkeit von Streamingdaten in der BigQuery-Dokumentation.

BigQuery-Prüfungsprobleme

Die folgenden Probleme betreffen nur Inspektionsvorgänge an BigQuery-Daten. Sie wirken sich nicht auf Datenprofile aus.

Exportierte Ergebnisse haben keine Werte für das Feld "row_number"

Wenn Sie den Schutz sensibler Daten so konfigurieren, dass Ergebnisse in BigQuery gespeichert werden, wird das Feld location.content_locations.record_location.record_key.big_query_key.row_number in der generierten BigQuery-Tabelle beim Scannen der Eingabetabelle abgeleitet. Der Wert ist unbestimmt, kann nicht abgefragt werden und kann für Inspektionsjobs null sein.

Wenn Sie bestimmte Zeilen identifizieren müssen, in denen Ergebnisse vorhanden sind, geben Sie beim Erstellen des Jobs inspectJob.storageConfig.bigQueryOptions.identifyingFields an.

Identifizierende Felder finden Sie in der generierten BigQuery-Tabelle im Feld location.content_locations.record_location.record_key.id_values.

Scans auf neue BigQuery-Inhalte beschränken

Dieses Problem betrifft auch De-Identifikationsvorgänge in BigQuery (in der Vorabversion).

Wenn Sie Scans nur auf neue Inhalte beschränken und die BigQuery Storage Write API zum Ausfüllen der Eingabetabelle verwenden, überspringt der Schutz sensibler Daten möglicherweise das Scannen einiger Zeilen.

Sie können dieses Problem beheben, indem Sie in Ihrem Inspektionsjob dafür sorgen, dass die timestampField des TimespanConfig-Objekts ein Commit-Zeitstempel ist, den BigQuery automatisch generiert. Es gibt jedoch immer noch keine Garantie, dass keine Zeilen übersprungen werden, da der Schutz sensibler Daten nicht aus kürzlich gestreamten Daten liest.

Wenn Sie automatisch Commit-Zeitstempel für eine Spalte generieren möchten und die Legacy Streaming API zum Füllen der Eingabetabelle verwenden, gehen Sie so vor:

  1. Achten Sie im Schema der Eingabetabelle darauf, dass die Zeitstempelspalte vom Typ TIMESTAMP ist.

    Beispielschema

    Im folgenden Beispiel wird das Feld commit_time_stamp definiert und als Typ auf TIMESTAMP festgelegt:

    ...
{
 "name": "commit_time_stamp",
 "type": "TIMESTAMP"
}
...

  2. Achten Sie darauf, dass im Feld rows[].json der Methode tabledata.insertAll die Werte in der Zeitstempelspalte auf AUTO festgelegt sind.

    JSON-Beispiel

    Im folgenden Beispiel wird der Wert des Felds commit_time_stamp auf AUTO festgelegt:

    {
  ...
  "commit_time_stamp": "AUTO",
  ...
}
Informationen zum manuellen Entfernen von Duplikaten

Scans durch Festlegen eines maximalen Prozentsatzes oder maximaler Zeilen beschränken

Wenn Sie ein Stichprobenlimit basierend auf einem Prozentsatz der Gesamtzahl von Tabellenzeilen (rowsLimitPercent) festlegen, kann der Schutz sensibler Daten mehr Zeilen prüfen als erwartet. Wenn Sie ein festes Limit für die Anzahl der zu scannenden Zeilen festlegen müssen, empfehlen wir stattdessen, eine maximale Anzahl von Zeilen festzulegen (rowsLimit).

Probleme bei der BigQuery-Profilerstellung

Die folgenden Probleme betreffen nur Profilerstellungsvorgänge für BigQuery-Daten. Weitere Informationen finden Sie unter Datenprofile für BigQuery-Daten.

Organisationen oder Projekte mit mehr als 500 Millionen Tabellen

Der Schutz sensibler Daten gibt einen Fehler zurück, wenn Sie versuchen, ein Profil für eine Organisation oder ein Projekt mit mehr als 500 Millionen Tabellen zu erstellen. Wenn dieser Fehler auftritt, senden Sie Ihr Feedback per E-Mail an cloud-dlp-feedback@google.com.

Wenn die Tabellenanzahl Ihrer Organisation mehr als 500 Millionen Tabellen umfasst und Sie ein Projekt mit einer niedrigeren Tabellenanzahl haben, versuchen Sie stattdessen, einen Scan auf Projektebene durchzuführen.

Informationen zu den Limits für Tabellen und Spalten finden Sie unter Limits für die Datenprofilerstellung.

Inspektionsvorlagen

Die Inspektionsvorlage muss sich in derselben Region wie die Daten befinden, für die ein Profil erstellt werden soll. Wenn Sie Daten in mehreren Regionen haben, verwenden Sie mehrere Inspektionsvorlagen – eine für jede Region, in der Sie Daten haben. Sie können auch eine Inspektionsvorlage verwenden, die in der Region global gespeichert ist. Wenn Sie eine Vorlage in der Region global angeben, wird sie vom Schutz sensibler Daten für alle Daten verwendet, für die keine regionsspezifische Vorlage vorhanden ist. Weitere Informationen finden Sie unter Überlegungen zum Datenstandort.

Gespeicherte infoTypes

Ein gespeicherter infoType (auch als gespeicherter benutzerdefinierter Wörterbuchdetektor bezeichnet), auf den in Ihrer Inspektionsvorlage verwiesen wird, muss in einem der folgenden Formate gespeichert werden:

  • Die Region global.
  • Die Region, in der sich auch die Inspektionsvorlage befindet.

Andernfalls schlägt der Profilerstellungsvorgang mit dem Fehler Resource not found fehl.

VPC Service Controls

Die Verwendung dieses Features mit VPC Service Controls-Zonen wird nicht offiziell unterstützt. Wenn Sie versuchen, Daten in einer VPC Service Controls-Zone zu scannen, senden Sie eine E-Mail an cloud-dlp-feedback@google.com, um uns über die aufgetretenen Probleme zu informieren.

Cloud Storage-Scans

In diesem Abschnitt werden Probleme beschrieben, die bei der inspecting oder De-Identifikation von Daten auftreten können.

Prüfung von XLSX-Dateien mit großen benutzerdefinierten Wörterbuchdetektoren

Wenn Sie einen großen benutzerdefinierten Wörterbuchdetektor (auch als gespeicherter benutzerdefinierter Wörterbuchdetektor bezeichnet) zum Prüfen einer Microsoft Excel-.xlsx-Datei verwenden, kann der Inspektionsjob langsam ausgeführt werden, hängen geblieben sein und eine große Anzahl von Vorgängen der Cloud Storage-Klasse B ausführen. Dies liegt daran, dass der Schutz sensibler Daten die Liste der Quellbegriffe des großen benutzerdefinierten Wörterbuchs möglicherweise einmal für jede Zelle in der Datei .xlsx liest. Aufgrund der Menge der Lesevorgänge kann der Inspektionsjob für den Schutz sensibler Daten wenig Fortschritt zeigen und scheinbar hängen geblieben sein.

Weitere Informationen zu den entsprechenden Abrechnungsgebühren für Cloud Storage finden Sie unter Vorgangsgebühren unter den Gebühren für Vorgänge der Klasse B.

Strukturierte Dateien werden im Binärmodus gescannt

In bestimmten Fällen werden Dateien, die normalerweise im strukturierten Parsing-Modus gescannt werden, möglicherweise auch im Binärmodus gescannt, in dem die Verbesserungen des strukturierten Parsing-Modus nicht enthalten sind. Weitere Informationen finden Sie unter Strukturierte Dateien im strukturierten Parsing-Modus scannen.

Intelligentes Parsen von Dokumenten

Dieser Abschnitt enthält bekannte Probleme im Zusammenhang mit dem Parsen von Dokumenten.

Das Objekt DocumentLocation ist nicht ausgefüllt

Das Feld location.content_locations.document_location.file_offset wird für den Scanmodus "Intelligentes Parsen von Dokumenten" nicht ausgefüllt.

Erkennung

Wörterbuchwörter, die Zeichen in der Supplementary Multilingual Plane des Unicode-Standards enthalten, können unerwartete Ergebnisse liefern. Beispiele für solche Zeichen sind Chinesisch, Japanisch, Koreanisch und Emojis.