Auf dieser Seite werden bekannte Probleme mit Sensitive Data Protection sowie Möglichkeiten zur Vermeidung oder Behebung dieser Probleme aufgeführt.
Allgemeine Probleme
Ergebnisse in BigQuery speichern
Wenn bei einem Job oder Suchlauf Ergebnisse in BigQuery gespeichert werden, wird in den Protokollen der Fehler Already exists
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 Prüfen oder Profilieren von BigQuery-Daten auftreten können.
Häufige Probleme bei Prüfungen und Profiling-Vorgängen
Die folgenden Probleme gelten sowohl für BigQuery-Prüf- als auch für BigQuery-Profilierungsvorgänge.
Zeilen mit Sicherheit auf Zeilenebene können nicht gescannt werden
Mit Sicherheitsrichtlinien auf Zeilenebene können Sie verhindern, dass der Schutz sensibler Daten die geschützten BigQuery-Tabellen überprüft und profiliert. Wenn Sie Sicherheitsrichtlinien auf Zeilenebene auf Ihre BigQuery-Tabellen angewendet haben, empfehlen wir, einen TRUE-Filter festzulegen und den Dienstmitarbeiter in die Liste der Begünstigten aufzunehmen:
- Wenn Sie Daten auf Organisations- oder Ordnerebene profilieren, fügen Sie die ID des Dienst-Agenten des Containerprojekts in die Liste der Begünstigten ein.
- Wenn Sie Daten auf Projektebene profilieren oder einen Inspektionsjob für eine Tabelle ausführen, müssen Sie den Dienstkontoinhaber des Projekts in die Liste der Begünstigten aufnehmen.
Doppelte Zeilen
Beim Schreiben von Daten in eine BigQuery-Tabelle werden durch den Schutz sensibler Daten möglicherweise doppelte Zeilen geschrieben.
Kürzlich gestreamte Daten
Der Schutz sensibler Daten scannt keine kürzlich gestreamten Daten (früher Streaming-Puffer). Weitere Informationen finden Sie in der BigQuery-Dokumentation unter Verfügbarkeit von Streaming-Daten.
Probleme bei der BigQuery-Prüfung
Die folgenden Probleme beziehen sich nur auf 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 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
Wenn Sie Scans auf neue Inhalte beschränken und die BigQuery Storage Write API zum Ausfüllen der Eingabetabelle verwenden, werden beim Schutz sensibler Daten möglicherweise einige Zeilen übersprungen.
Um dieses Problem zu vermeiden, achten Sie in Ihrem Prüfjob darauf, dass die 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 Sensitive Data Protection keine kürzlich gestreamten Daten liest.
Wenn Sie Commit-Zeitstempel für eine Spalte automatisch generieren möchten und die alte Streaming API zum Ausfüllen Ihrer Eingabetabelle verwenden, gehen Sie so vor:
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 aufTIMESTAMP
festgelegt:... { "name": "commit_time_stamp", "type": "TIMESTAMP" } ...
Achten Sie darauf, dass die Werte in der Spalte „Zeitstempel“ im Feld
rows[].json
der Methodetabledata.insertAll
aufAUTO
festgelegt sind.Beispiel für JSON
Im folgenden Beispiel wird der Wert des Felds
commit_time_stamp
aufAUTO
festgelegt:{ ... "commit_time_stamp": "AUTO", ... }
Scans durch Festlegen eines maximalen Prozentsatzes oder einer maximalen Anzahl von Zeilen begrenzen
Wenn Sie ein Stichprobenlimit basierend auf einem Prozentsatz der Gesamtzahl der Tabellenzeilen festlegen (rowsLimitPercent
), kann der Schutz sensibler Daten mehr Zeilen als erwartet prüfen. Wenn Sie die Anzahl der zu scannenden Zeilen begrenzen möchten, empfehlen wir, stattdessen eine maximale Zeilenanzahl (rowsLimit
) festzulegen.
Probleme beim BigQuery-Profiling
Die folgenden Probleme beziehen sich nur auf Profiling-Vorgä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, 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
einschließen, 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 an einer der folgenden Stellen gespeichert sein:
- Die Region
global
. - In derselben Region wie die Inspektionsvorlage.
Andernfalls schlägt der Profilervorgang mit dem Fehler Resource not found
fehl.
Sichtbarkeit von Ressourcen
In einem Tabellendatenprofil hängt die Klassifizierung der Ressourcensichtbarkeit für eine BigQuery-Tabelle 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 also von den IAM-Berechtigungen des Datensatzes unterscheiden, kann die im Datenprofil angegebene Sichtbarkeit der Tabelle falsch sein. Dieses Problem betrifft die Erkenntnisse für BigQuery und die Erkenntnisse für Vertex AI.
In der Google Cloud Console wird die Sichtbarkeit der Ressourcen im Feld Öffentlich des Tabellendatenprofils angegeben. In der Cloud Data Loss Prevention API wird die Sichtbarkeit der Ressource im Feld resourceVisibility
der TableDataProfile
angegeben.
Cloud Storage-Scans
In diesem Abschnitt werden Probleme beschrieben, die beim Prüfen oder Entfernen der Identifikationsmerkmale 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 gespeicherter benutzerdefinierter Wörterbuchdetektor genannt) zum Prüfen einer Microsoft Excel-.xlsx
-Datei verwenden, kann der Prüfjob langsam laufen, hängen bleiben und eine große Anzahl von Cloud Storage-Vorgängen der Klasse B verursachen.
Das liegt daran, dass Sensitive Data Protection die Liste der Quellbegriffe des großen benutzerdefinierten Wörterbuchs möglicherweise einmal für jede Zelle in der .xlsx
-Datei liest. Aufgrund der großen Anzahl von Lesevorgängen kann der Inspektionsjob für den Schutz sensibler Daten nur langsam vorankommen und den Anschein erwecken, dass er hängengeblieben ist.
Weitere Informationen zu den relevanten Cloud Storage-Abrechnungsgebühren finden Sie unter Gebühren für Vorgänge im Abschnitt zu Vorgängen der Klasse B.
Strukturierte Dateien, die im Binärmodus gescannt werden
In bestimmten Fällen werden Dateien, die normalerweise im Modus für strukturiertes Parsen gescannt werden, möglicherweise im Binärmodus gescannt. Dieser Modus bietet nicht die Verbesserungen des Modus für strukturiertes Parsen. Weitere Informationen finden Sie unter Strukturierte Dateien im Modus für strukturiertes Parsen scannen.
De-Identifikation von benutzerdefinierten Trennlinien
Wenn Sie mit einem Prüfjob die Identität einer abgegrenzten Datei (z. B. einer CSV-Datei) entfernen, enthält die Ausgabe möglicherweise zusätzliche leere Zellen in einigen Zeilen. Sie können diese zusätzlichen Zellen vermeiden, indem Sie die Daten stattdessen mit der Methode content.deidentify
de-identifizieren.
Discovery für Cloud SQL
Doppelte Ergebnisse im Security Command Center
Das Cloud SQL-Datenprofiling unterstützt die Veröffentlichung von Ergebnissen im Security Command Center.
Vor dem 25. April 2024 führte ein Fehler dazu, 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, aber die doppelten Ergebnisse sind weiterhin vorhanden. Sie können die Duplikate ausblenden, um sie auf der Seite Ergebnisse im Security Command Center auszublenden.
Discovery für Amazon S3
Ergebnisse für Amazon S3, die der Schutz sensibler Daten 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 zum Zeitpunkt des Sendens des Ergebnisses an Security Command Center nur etwa 24 Stunden lang gültig.
- Das AWS-Konto war erst seit etwa 24 Stunden im AWS-Connector enthalten, als die Sicherheitswarnung an Security Command Center gesendet wurde.
Um dieses Problem zu beheben, generieren Sie nach etwa 24 Stunden die Datenprofile neu, indem Sie sie löschen oder einen Zeitplan für das Profiling festlegen. Die vollständigen Details zum Ergebnis werden an das Security Command Center gesendet.
Intelligentes Parsen von Dokumenten
In diesem Abschnitt werden bekannte Probleme im Zusammenhang mit dem Dokumenten-Parsing beschrieben.
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örter in Wörterbüchern, die Zeichen aus 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 Schriften.