In questa pagina sono elencati i problemi noti di Cloud DLP e i modi in cui puoi evitare o recuperare i seguenti problemi.
Scansione di BigQuery
Questa sezione descrive i problemi che potresti riscontrare durante l'ispezione o la profilazione dei dati BigQuery.
Problemi comuni relativi alle operazioni di ispezione e profilazione
I seguenti problemi riguardano le operazioni di ispezione e profilazione di BigQuery.
Impossibile analizzare le righe con sicurezza a livello di riga
I criteri di sicurezza a livello di riga possono impedire a Cloud DLP di ispezionare e profilare le tabelle BigQuery protette. Se hai applicato criteri di sicurezza a livello di riga alle tabelle BigQuery, ti consigliamo di impostare un filtro TRUE e di includere l'agente di servizio nell'elenco dei beneficiari:
- Se profili i dati a livello di organizzazione o di cartella, includi l'agente di servizio del progetto container nell'elenco dei beneficiari.
- Se profili i dati a livello di progetto o esegui un job di ispezione su una tabella, includi l'agente di servizio del progetto nell'elenco dei beneficiari.
Duplica righe
Quando scrivi dati in una tabella BigQuery, Cloud DLP potrebbe scrivere righe duplicate.
Dati trasmessi di recente
Cloud DLP non esegue la scansione dei dati trasmessi di recente (precedentemente nota come buffer di streaming). Per ulteriori informazioni, consulta Disponibilità dei flussi di dati nella documentazione di BigQuery.
Problemi di ispezione di BigQuery
I seguenti problemi si applicano solo alle operazioni di ispezione sui dati di BigQuery. Non influiscono sui profili dati.
I risultati esportati non hanno valori per il campo row_number
Quando configuri Cloud DLP per salvare i risultati in BigQuery, il campo location.content_locations.record_location.record_key.big_query_key.row_number
nella tabella BigQuery generato viene dedotto al momento della scansione della tabella di input. Il suo valore non è deterministico, non può essere oggetto di query e può essere null per i job di ispezione.
Se devi identificare righe specifiche in cui sono presenti risultati, specifica inspectJob.storageConfig.bigQueryOptions.identifyingFields
al momento della creazione del job.
I campi di identificazione si trovano nella tabella BigQuery generata, nel campo location.content_locations.record_location.record_key.id_values
.
Limitazione delle scansioni ai nuovi contenuti BigQuery
Se stai limitando le scansioni solo ai nuovi contenuti e utilizzi l'API BigQuery Storage Write per completare la tabella di input, Cloud DLP potrebbe saltare la scansione di alcune righe.
Per risolvere il problema, nel job di ispezione, assicurati che timestampField
nell'oggetto TimespanConfig
sia un timestamp del commit generato automaticamente da BigQuery.
Tuttavia, non è ancora garantito che nessuna riga venga ignorata, perché Cloud DLP non legge i dati trasmessi di recente.
Se vuoi generare automaticamente i timestamp di commit per una colonna e utilizzi l'API Streaming legacy per completare la tabella di input, procedi come segue:
Nello schema della tabella di input, assicurati che la colonna timestamp sia di tipo
TIMESTAMP
.Schema di esempio
Nel seguente esempio viene definito il campo
commit_time_stamp
e viene impostato il tipo suTIMESTAMP
:... { "name": "commit_time_stamp", "type": "TIMESTAMP" } ...
Nel campo
rows[].json
del metodotabledata.insertAll
, assicurati che i valori nella colonna timestamp siano impostati suAUTO
.JSON di esempio
Nell'esempio seguente il valore del campo
commit_time_stamp
viene impostato suAUTO
:{ ... "commit_time_stamp": "AUTO", ... }
Problemi di profilazione di BigQuery
I seguenti problemi si applicano solo alle operazioni di profilazione sui dati BigQuery. Per ulteriori informazioni, vedi Profili di dati per dati BigQuery.
Organizzazioni o progetti con più di 500 milioni di tabelle
Cloud DLP restituisce un errore se tenti di profilare un'organizzazione o un progetto che ha più di 500 milioni di tabelle. Se riscontri questo errore, puoi inviare un feedback all'indirizzo cloud-dlp-feedback@google.com.
Se il conteggio delle tabelle della tua organizzazione ha più di 500 milioni di tabelle e hai un progetto con un numero di tabelle inferiore, prova a eseguire una scansione a livello di progetto.
Per informazioni sui limiti di tabelle e colonne, consulta Limiti di profilazione dei dati.
Modelli di ispezione
Il modello di ispezione deve trovarsi nella stessa regione dei dati da profilare. Se hai dati in più aree geografiche, utilizza più modelli di ispezione, uno per ogni area geografica in cui sono disponibili dati.
Puoi anche utilizzare un modello di ispezione memorizzato nella regione global
.
Se includi un modello nella regione global
, Cloud DLP lo utilizza per tutti i dati che non hanno un modello specifico per regione. Per ulteriori informazioni, consulta la sezione Considerazioni sulla residenza dei dati.
InfoType archiviati
Un infoType archiviato (chiamato anche rilevatore di dizionario personalizzato memorizzato) a cui si fa riferimento nel tuo modello di ispezione deve essere archiviato in uno dei seguenti elementi:
- La regione
global
. - La stessa area geografica del modello di ispezione.
In caso contrario, l'operazione di profilazione non riesce e restituisce l'errore Resource not found
.
Controlli di servizio VPC
L'utilizzo di questa funzionalità con le zone Controlli di servizio VPC non è ufficialmente supportato. Se provi a eseguire la scansione dei dati all'interno di una zona Controlli di servizio VPC, comunicaci i problemi che hai riscontrato inviando un'email all'indirizzo cloud-dlp-feedback@google.com.
Analisi di Cloud Storage
Questa sezione descrive i problemi che potresti riscontrare durante l'ispezione o l'anonimizzazione dei dati.
Ispezione dei file XLSX con grandi rilevatori di dizionari personalizzati
Quando utilizzi un rilevatore di dizionari personalizzato di grandi dimensioni (noto anche come rilevatore di dizionari personalizzati archiviato) per ispezionare un file Microsoft Excel
.xlsx
, il job di ispezione può essere eseguito lentamente, apparire bloccato e comportare
una grande quantità di
operazioni di classe B Cloud Storage.
Questo perché Cloud DLP potrebbe leggere una volta l'elenco dei termini di origine del dizionario personalizzato grande una sola volta per ogni cella del file .xlsx
. Il volume delle operazioni di lettura può far sì che il job di ispezione di Cloud DLP mostri poco avanzamento e sembri essere bloccato.
Per ulteriori informazioni sugli addebiti della fatturazione Cloud Storage pertinenti, consulta gli addebiti per le operazioni di Classe B in Addebiti operativi.
Intestazione ripetuta nella copia anonimizzata dei file delimitati
Quando anonimizzi un file delimitato, ad esempio un file CSV o TSV, in Cloud Storage, il file anonimizzato risultante potrebbe talvolta avere righe di intestazione duplicate.
Considera l'esempio seguente:
Header1,Header2
Cell1,Cell2
Cell3,Cell4
Cell5,Cell6
Nel file anonimizzato risultante, la riga di intestazione potrebbe comparire in due posizioni:
Header1,Header2
DeidentifiedCell1,DeidentifiedCell2
DeidentifiedCell3,DeidentifiedCell4
Header1,Header2
DeidentifiedCell5,DeidentifiedCell6
Se le dimensioni del file rientrano nel limite di dimensioni della richiesta (0,5 MB), puoi anonimizzare i contenuti utilizzando una richiesta projects.content.deidentify
.
Analisi intelligente dei documenti
Questa sezione contiene i problemi noti relativi all'analisi dei documenti.
L'oggetto DocumentLocation
non è compilato
Il campo location.content_locations.document_location.file_offset
non viene completato per la modalità di analisi dell'analisi intelligente dei documenti.