Diese Seite wurde von der Cloud Translation API übersetzt.

Bekannte Probleme

Auf dieser Seite werden bekannte Probleme mit Cloud DLP sowie Möglichkeiten zur Vermeidung oder Behebung der folgenden Probleme aufgeführt.

BigQuery-Scans

In diesem Abschnitt werden Probleme beschrieben, die bei der Prüfung oder Profilerstellung von BigQuery-Daten auftreten können.

Häufige Probleme bei Inspektions- und Profilerstellungsvorgängen

Die folgenden Probleme gelten sowohl für BigQuery-Prüfungen als auch für die Profilerstellung.

Zeilen mit Sicherheit auf Zeilenebene können nicht gescannt werden

Sicherheitsrichtlinien auf Zeilenebene können verhindern, dass Cloud DLP die geschützten BigQuery-Tabellen prüft und ein Profil für sie erstellt. Wenn Sie auf Ihre BigQuery-Tabellen Sicherheitsrichtlinien auf Zeilenebene angewendet haben, sollten Sie einen TRUE-Filter festlegen und den Dienst-Agent in die Liste der Empfänger aufnehmen:

Wenn Sie Daten auf Organisations- oder Ordnerebene erstellen, nehmen Sie den Dienst-Agent des Containerprojekts in die Liste der Empfänger auf.
Wenn Sie ein Profil auf Datenebene erstellen oder einen Inspektionsjob für eine Tabelle ausführen, nehmen Sie den Dienst-Agent des Projekts in die Liste der Empfänger auf.

Doppelte Zeilen

Beim Schreiben von Daten in eine BigQuery-Tabelle schreibt Cloud DLP möglicherweise doppelte Zeilen.

Kürzlich gestreamte Daten

Cloud DLP scannt keine kürzlich gestreamten Daten (früher als Streamingpuffer bezeichnet). Weitere Informationen finden Sie unter Verfügbarkeit von Streamingdaten in der Dokumentation zu BigQuery.

Probleme bei der BigQuery-Prüfung

Die folgenden Probleme gelten nur für Inspektionsvorgänge für BigQuery-Daten. Sie wirken sich nicht auf Datenprofile aus.

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

Wenn Sie Cloud DLP zum Speichern von Ergebnissen in BigQuery konfigurieren, 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 neuen BigQuery-Inhalt beschränken

Wenn Sie Scans nur auf neuen Inhalt beschränken und die BigQuery Storage Write API zum Ausfüllen der Eingabetabelle verwenden, überspringt Cloud DLP möglicherweise das Scannen einiger Zeilen.

Achten Sie zur Behebung dieses Problems darauf, dass in Ihrem Inspektionsjob der timestampField des TimespanConfig-Objekts ein Commit-Zeitstempel ist, der von BigQuery automatisch generiert wird. Es gibt jedoch keine Garantie, dass keine Zeilen übersprungen werden, da Cloud DLP nicht aus zuletzt gestreamten Daten liest.

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

Achten Sie im Schema der Eingabetabelle darauf, dass die Zeitstempelspalte den Typ TIMESTAMP hat.

Beispielschema

Im folgenden Beispiel wird das Feld commit_time_stamp definiert und der Typ auf TIMESTAMP festgelegt:
```
...
{
 "name": "commit_time_stamp",
 "type": "TIMESTAMP"
}
...
```
Achten Sie darauf, dass im Feld rows[].json der Methode tabledata.insertAll die Werte in der Zeitstempelspalte auf AUTO festgelegt sind.

Beispiel für JSON

Im folgenden Beispiel wird der Wert des Felds commit_time_stamp auf AUTO gesetzt:
```
{
  ...
  "commit_time_stamp": "AUTO",
  ...
}
```

Probleme mit der BigQuery-Profilerstellung

Die folgenden Probleme gelten nur für die Profilerstellung für BigQuery-Daten. Weitere Informationen finden Sie unter Datenprofile für BigQuery-Daten.

Organisationen oder Projekte mit mehr als 500 Millionen Tabellen

Cloud DLP 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 die Region global einfügen, verwendet Cloud DLP sie für alle Daten, die keine regionsspezifische Vorlage haben. 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 Verzeichnisse gespeichert werden:

Die Region global.
Dieselbe Region wie bei der Inspektionsvorlage.

Andernfalls schlägt die Profilerstellung mit dem Fehler Resource not found fehl.

VPC Service Controls

Die Verwendung dieses Features mit VPC Service Controls-Zonen wird nicht offiziell unterstützt. Senden Sie eine E-Mail an cloud-dlp-feedback@google.com, wenn Sie versuchen, Daten in einer VPC Service Controls-Zone zu scannen.

Cloud Storage-Scan

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

XLSX-Dateien mit großen benutzerdefinierten Wörterbuchdetektoren prüfen

Wenn Sie einen großen benutzerdefinierten Wörterbuchdetektor (auch als gespeichertes benutzerdefiniertes Wörterbuchdetektor bezeichnet) zur Prüfung einer Microsoft Excel-.xlsx-Datei verwenden, kann der Inspektionsjob langsam, hängen bleiben und eine große Menge an Cloud Storage-Klasse-B-Vorgängen ausführen. Das liegt daran, dass Cloud DLP die Liste der Quellbegriffe des großen benutzerdefinierten Wörterbuchs für jede Zelle in der Datei .xlsx einmal lesen kann. Das Volumen der Lesevorgänge kann dazu führen, dass der Cloud DLP-Inspektionsjob nur wenig Fortschritt zeigt und hängen bleibt.

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

Wiederholter Header in einer de-identifizierten Kopie der Dateien mit Trennzeichen

Wenn Sie in Cloud Storage eine de-identifizierte Datei de-identifizieren, z. B. eine CSV- oder TSV-Datei, enthält die resultierende de-identifizierte Datei manchmal doppelte Kopfzeilen.

Dazu ein Beispiel:

Header1,Header2
Cell1,Cell2
Cell3,Cell4
Cell5,Cell6

In der resultierenden de-identifizierten Datei kann die Kopfzeile an zwei Stellen erscheinen:

Header1,Header2
DeidentifiedCell1,DeidentifiedCell2
DeidentifiedCell3,DeidentifiedCell4
Header1,Header2
DeidentifiedCell5,DeidentifiedCell6

Wenn die Dateigröße innerhalb des Limits für die Anfragegröße (0,5 MB) liegt, können Sie den Inhalt mit einer projects.content.deidentify-Anfrage de-identifizieren.

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.