Bekannte Probleme

Auf dieser Seite werden bekannte Probleme mit Sensitive Data Protection sowie Möglichkeiten zur Vermeidung oder Behebung dieser Probleme aufgeführt.

Ergebnisse in BigQuery speichern

Wenn in einem Job oder Discovery-Scan Ergebnisse in BigQuery gespeichert werden, wird in den Logs ein Already exists-Fehler angezeigt. Der Fehler bedeutet nicht, dass ein Problem vorliegt. Ihre Ergebnisse werden wie erwartet gespeichert.

BigQuery-Scans

In diesem Abschnitt werden Probleme beschrieben, die beim Untersuchen oder Erstellen von Profilen für BigQuery-Daten auftreten können.

Häufige Probleme bei Prüf- und Profilingvorgängen

Die folgenden Probleme gelten sowohl für BigQuery-Prüfungs- als auch für Profiling-Vorgänge.

Zeilen mit Sicherheit auf Zeilenebene können nicht gescannt werden

Richtlinien für die Sicherheit auf Zeilenebene können verhindern, dass der Schutz sensibler Daten die geschützten BigQuery-Tabellen untersucht und profiliert. Wenn Sie Richtlinien für die Sicherheit auf Zeilenebene auf Ihre BigQuery-Tabellen angewendet haben, empfehlen wir, einen TRUE-Filter festzulegen und den Dienst-Agent in die Liste der Empfänger aufzunehmen:

Doppelte Zeilen

Beim Schreiben von Daten in eine BigQuery-Tabelle kann es vorkommen, dass der Schutz sensibler Daten doppelte Zeilen schreibt.

Kürzlich gestreamte Daten

Mit Sensitive Data Protection werden keine kürzlich gestreamten Daten gescannt (früher als Streamingpuffer bezeichnet). Weitere Informationen finden Sie in der BigQuery-Dokumentation unter Verfügbarkeit von Streamingdaten.

Probleme bei der BigQuery-Prüfung

Die folgenden Probleme gelten nur für Prüfvorgä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 Sensitive Data Protection 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 neue BigQuery-Inhalte beschränken

Wenn Sie Scans auf neue Inhalte beschränken und die Eingabetabelle mit der BigQuery Storage Write API füllen, überspringt Sensitive Data Protection möglicherweise das Scannen einiger Zeilen.

Um dieses Problem zu beheben, muss im Prüfjob die timestampField des TimespanConfig-Objekts ein Commit-Zeitstempel sein, der automatisch von BigQuery generiert wird. Es gibt jedoch keine Garantie dafür, dass keine Zeilen übersprungen werden, da Sensitive Data Protection nicht aus kürzlich gestreamten Daten liest.

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

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

    Beispielschema

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

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

  2. Achten Sie im Feld rows[].json der Methode tabledata.insertAll darauf, dass 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 festgelegt:

    {
  ...
  "commit_time_stamp": "AUTO",
  ...
}

Scans durch Festlegen eines maximalen Prozentsatzes oder einer maximalen Anzahl von Zeilen begrenzen

Wenn Sie ein Stichprobenlimit auf Grundlage eines Prozentsatzes der Gesamtzahl der Tabellenzeilen (rowsLimitPercent) festlegen, kann der Schutz sensibler Daten mehr Zeilen als erwartet prüfen. Wenn Sie die Anzahl der zu scannenden Zeilen begrenzen müssen, empfehlen wir, stattdessen eine maximale Anzahl von Zeilen (rowsLimit) festzulegen.

Probleme mit der Profilerstellung in BigQuery

Die folgenden Probleme treten nur bei Profiling-Vorgängen für BigQuery-Daten auf. 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, folgen Sie der Anleitung in der Fehlermeldung.

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 Prüfungsvorlage 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 einfügen, wird sie von Sensitive Data Protection 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 Speicherorte gespeichert werden:

  • Die Region global.
  • Dieselbe Region wie die Inspektionsvorlage.

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

Sichtbarkeit von Ressourcen

In einem Tabellendatenprofil hängt die Klassifizierung der Ressourcensichtbarkeit, die einer BigQuery-Tabelle zugewiesen wird, von der Sichtbarkeit des Datasets ab, das die Tabelle enthält, und nicht von der Sichtbarkeit der Tabelle. Wenn sich die IAM-Berechtigungen einer Tabelle von den IAM-Berechtigungen des Datasets unterscheiden, kann die im Datenprofil angegebene Ressourcensichtbarkeit der Tabelle falsch sein. Dieses Problem betrifft die Erkennung für BigQuery und die Erkennung für Vertex AI.

In der Google Cloud Console wird die Sichtbarkeit der Ressource im Feld Öffentlich des Tabellendatenprofils angegeben. In der Cloud Data Loss Prevention API wird die Sichtbarkeit von Ressourcen im Feld resourceVisibility der TableDataProfile angegeben.

Cloud Storage-Scan

In diesem Abschnitt werden Probleme beschrieben, die beim Überprüfen oder Anonymisieren von Daten auftreten können.

Prüfung von Strict XLSX-Dateien wird nicht unterstützt

Eine Datei mit der Erweiterung .xlsx kann einen von zwei Typen haben. Ein Typ ist eine Strict Office Open XML-Tabelle, die vom Schutz vertraulicher Daten nicht unterstützt wird. Der andere Typ ist eine Standard-Microsoft Excel-Arbeitsmappe, die unterstützt wird.

Strukturierte Dateien, die im Binärmodus gescannt werden

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

Dateien mit Trennzeichen de-identifizieren

Wenn Sie eine Datei mit Trennzeichen (z. B. eine CSV-Datei) mit einem Prüfjob anonymisieren, enthält die Ausgabe in einigen Zeilen möglicherweise zusätzliche leere Zellen. Eine Möglichkeit, diese zusätzlichen Zellen zu vermeiden, besteht darin, Daten stattdessen mit der Methode content.deidentify zu anonymisieren.

Discovery für Cloud SQL

Doppelte Ergebnisse im Security Command Center

Das Cloud SQL-Datenprofiling unterstützt das Veröffentlichen von Ergebnissen in Security Command Center.

Vor dem 25. April 2024 wurden aufgrund eines Fehlers gelegentlich doppelte Ergebnisse für Cloud SQL-Instanzen in Security Command Center generiert. Diese Ergebnisse wurden mit eindeutigen Ergebnis-IDs generiert, beziehen sich aber auf dieselben Cloud SQL-Instanzen. Das Problem wurde behoben, aber die doppelten Ergebnisse sind weiterhin vorhanden. Sie können die Duplikate ausblenden, um sie auf der Seite Ergebnisse im Security Command Center zu verbergen.

Discovery für Amazon S3

Ergebnisse für Amazon S3, die Sensitive Data Protection an Security Command Center sendet, enthalten möglicherweise keine Informationen zur AWS-Konto-ID oder zum Anzeigenamen der betroffenen Ressource. Das passiert in der Regel in folgenden Fällen:

  • Der AWS-Connector war nur etwa 24 Stunden lang gültig, als das Ergebnis an Security Command Center gesendet wurde.
  • Das AWS-Konto war erst seit etwa 24 Stunden im AWS-Connector enthalten, als der Befund an Security Command Center gesendet wurde.

Um dieses Problem zu beheben, generieren Sie die Datenprofile nach etwa 24 Stunden neu, indem Sie sie löschen oder einen Profiling-Zeitplan festlegen. Die vollständigen Ergebnisdetails werden an Security Command Center gesendet.

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

Die folgenden bekannten Probleme beschreiben Probleme bei der Erkennung, unabhängig davon, welchen Vorgang Sie ausführen – Überprüfung, Anonymisierung oder Ermittlung.

Wörterbuchwörter

Wörter in Wörterbüchern, die Zeichen in der Supplementary Multilingual Plane des Unicode-Standards enthalten, können zu unerwarteten Ergebnissen führen. Beispiele für solche Zeichen sind Emojis, wissenschaftliche Symbole und historische Schriftarten.

Ausschlussregeln

Ausschlussregeln können nicht auf object infoTypes angewendet werden.