Auf dieser Seite werden bekannte Probleme mit dem Schutz sensibler Daten sowie Möglichkeiten zur Vermeidung oder Behebung der folgenden Probleme aufgeführt.
Ergebnisse in BigQuery speichern
Wenn ein Job oder ein Erkennungsscan Ergebnisse in BigQuery speichert, wird in den Logs der Fehler Already exists angezeigt. Der Fehler weist nicht auf ein Problem hin. Ihre Ergebnisse werden wie erwartet gespeichert.
BigQuery-Scans
In diesem Abschnitt werden Probleme beschrieben, die beim Prüfen oder Erstellen von Profilen für BigQuery-Daten auftreten können.
Probleme, die bei Prüf- und Profilerstellungsvorgängen häufig auftreten
Die folgenden Probleme treten sowohl bei Prüf- als auch bei Profilerstellungsvorgängen in BigQuery auf.
Zeilen mit Sicherheit auf Zeilenebene können nicht gescannt werden
Richtlinien zur Sicherheit auf Zeilenebene können verhindern, dass der Schutz sensibler Daten die geschützten BigQuery-Tabellen prüft und Profile dafür erstellt. Wenn auf Ihre BigQuery Tabellen Richtlinien zur Sicherheit auf Zeilenebene angewendet werden, empfehlen wir, einen TRUE-Filter festzulegen und den Dienst-Agent in die Liste der Berechtigten aufzunehmen:
- Wenn Sie Profile für Daten auf Organisations- oder Ordnerebene erstellen, fügen Sie der Liste der Berechtigten den Dienst-Agent des Container projekts hinzu.
- Wenn Sie Profile für Daten auf Projektebene erstellen oder einen Prüfjob für eine Tabelle ausführen, fügen Sie der Liste der Berechtigten den Dienst-Agenten des Projekts hinzu.
Doppelte Zeilen
Beim Schreiben von Daten in eine BigQuery-Tabelle kann der Schutz sensibler Daten doppelte Zeilen schreiben.
Kürzlich gestreamte Daten
Der Schutz sensibler Daten scannt keine kürzlich gestreamten Daten (früher als Streaming-Puffer bezeichnet). Weitere Informationen finden Sie in der BigQuery-Dokumentation unter Datenverfügbarkeit beim Streamen.
Probleme bei der BigQuery-Prüfung
Die folgenden Probleme treten nur bei Prüfvorgängen für BigQuery-Daten auf. 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 Prüfjobs 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 BigQuery Storage Write API verwenden, um die Eingabetabelle zu füllen, überspringt der Schutz sensibler Daten möglicherweise einige Zeilen.
Um dieses Problem zu beheben, muss in Ihrem Prüfjob sichergestellt werden, dass das timestampField des
TimespanConfig
Objekts ein Commit-Zeitstempel ist, der automatisch von BigQuery generiert wird.
Es gibt jedoch keine Garantie dafür, dass keine Zeilen übersprungen werden, da
der Schutz sensibler Daten keine
kürzlich gestreamten Datenliest.
Wenn Sie automatisch Commit-Zeitstempel für eine Spalte generieren möchten und Sie verwenden die Legacy Streaming API, um Ihre Eingabetabelle zu füllen, gehen Sie so vor:
Prüfen Sie im Schema der Eingabetabelle, ob die Zeitstempelspalte den Typ
TIMESTAMPhat.Beispielschema
Im folgenden Beispiel wird das Feld
commit_time_stampdefiniert und der Typ aufTIMESTAMPfestgelegt:... { "name": "commit_time_stamp", "type": "TIMESTAMP" } ...Prüfen Sie im Feld
rows[].jsondertabledata.insertAllMethode, ob die Werte in der Zeitstempelspalte aufAUTOfestgelegt sind.Beispiel-JSON
Im folgenden Beispiel wird der Wert des Felds
commit_time_stampaufAUTOfestgelegt:{ ... "commit_time_stamp": "AUTO", ... }
Scans durch Festlegen eines maximalen Prozentsatzes oder einer maximalen Anzahl von Zeilen beschränken
Wenn Sie ein Stichprobenlimit basierend auf einem Prozentsatz der Gesamtzahl der Tabellen
zeilen
(rowsLimitPercent) festlegen,
kann der Schutz sensibler Daten mehr Zeilen als erwartet prüfen. Wenn Sie ein festes Limit für die Anzahl der zu scannenden Zeilen festlegen müssen, empfehlen wir stattdessen, eine maximale
Anzahl von Zeilen
(rowsLimit)
festzulegen.
Probleme bei der BigQuery-Profilerstellung
Die folgenden Probleme treten nur bei Profilerstellungsvorgä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 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 verwenden, 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 der Inspektions vorlage verwiesen wird, muss in einer der folgenden Regionen gespeichert sein:
- 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 Sichtbarkeitsklassifizierung, 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 Sichtbarkeit der Ressource für die Tabelle falsch sein. Dieses Problem betrifft die Erkennung für BigQuery und Erkennung für Vertex AI.
In der Google Cloud Console wird die Sichtbarkeit der Ressource im Tabellendaten
profils im Feld Öffentlich angegeben. In der Cloud Data Loss Prevention API wird die Sichtbarkeit der Ressource
im resourceVisibility
Feld des
TableDataProfileangegeben.
Cloud Storage-Scans
In diesem Abschnitt werden Probleme beschrieben, die beim Prüfen oder De-Identifizieren von Daten auftreten können.
Die Prüfung von Strict XLSX-Dateien wird nicht unterstützt
Eine Datei mit der Erweiterung .xlsx kann zwei Typen haben. Ein Typ ist eine Strict Office Open XML-Tabelle, die vom Schutz sensibler Daten nicht unterstützt wird.
Der andere Typ ist eine Standard-Microsoft Excel-Arbeitsmappe, die unterstützt wird.
Strukturierte Dateien werden im Binärmodus gescannt
In bestimmten Fällen werden Dateien, die normalerweise im strukturierten Parsermodus gescannt werden, möglicherweise im Binärmodus gescannt. Dieser Modus enthält nicht die Verbesserungen des strukturierten Parsermodus. Weitere Informationen finden Sie unter Strukturierte Dateien im strukturierten Parsermodus scannen.
Begrenzte Dateien de-identifizieren
Wenn Sie eine begrenzte Datei (z. B. eine CSV-Datei) mit einem Prüfjob de-identifizieren, kann die Ausgabe in einigen Zeilen zusätzliche leere Zellen enthalten. Eine Problemumgehung, um
diese zusätzlichen Zellen zu vermeiden, besteht darin, Daten stattdessen mit der content.deidentify
Methode zu de-identifizieren.
Erkennung für Cloud SQL
Doppelte Ergebnisse im Security Command Center
Die Datenprofilerstellung für Cloud SQL unterstützt das Veröffentlichen von Ergebnissen im Security Command Center.
Vor dem 25. April 2024 verursachte ein Fehler, dass der Schutz sensibler Daten gelegentlich doppelte Ergebnisse für Cloud SQL-Instanzen im Security Command Center generierte. Diese Ergebnisse wurden mit eindeutigen Ergebnis-IDs generiert, beziehen sich aber auf dieselben Cloud SQL-Instanzen. Das Problem wurde behoben, die doppelten Ergebnisse sind aber weiterhin vorhanden. Sie können die Duplikate stummschalten, um sie auf der Seite Ergebnisse des Security Command Center auszublenden.
Erkennung für Amazon S3
Ergebnisse für Amazon S3, die der Schutz sensibler Daten an das Security Command Center sendet, enthalten möglicherweise keine Informationen zur AWS-Konto-ID oder zum Anzeigenamen der betroffenen Ressource. Dies tritt in der Regel in den folgenden Fällen auf:
- Der AWS-Connector war nur etwa 24 Stunden gültig, als das Ergebnis an das Security Command Center gesendet wurde.
- Das AWS-Konto war nur etwa 24 Stunden im AWS-Connector enthalten, als das Ergebnis an das Security Command Center gesendet wurde.
Um dieses Problem zu beheben, generieren Sie nach etwa 24 Stunden die Daten profile neu, indem Sie sie löschen oder einen Profilerstellungs zeitplan festlegen. Die vollständigen Ergebnisdetails werden an das 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 vom ausgeführten Vorgang – Prüfung, De-Identifizierung oder Erkennung.
Wörterbuchwörter
Wörterbuchwörter, 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 Skripts.