Problemi noti

In questa pagina sono elencati i problemi noti di Sensitive Data Protection, insieme ai modi per evitarli o risolverli.

Archiviazione dei risultati in BigQuery

Quando un job o una scansione di discovery memorizza i risultati in BigQuery, nei log viene visualizzato un errore Already exists. L'errore non indica che si è verificato un problema; i risultati verranno archiviati come previsto.

Scansione di BigQuery

Questa sezione descrive i problemi che potresti riscontrare durante l'ispezione o la profilazione dei dati di BigQuery.

Problemi comuni alle operazioni di ispezione e profilazione

I seguenti problemi si applicano sia alle operazioni di ispezione che di profilazione di BigQuery.

Impossibile scansionare le righe con sicurezza a livello di riga

Le policy di sicurezza a livello di riga possono impedire a Sensitive Data Protection di ispezionare e profilare le tabelle BigQuery protette. Se alle tue tabelle BigQuery sono applicate policy di sicurezza a livello di riga, ti consigliamo di impostare un filtro TRUE e di includere l'agente di servizio nell'elenco dei beneficiari:

Righe duplicate

Quando scrive i dati in una tabella BigQuery, Sensitive Data Protection potrebbe scrivere righe duplicate.

Dati trasmessi in streaming di recente

Sensitive Data Protection non analizza i dati trasmessi in streaming di recente (precedentemente noti come buffer di streaming). Per saperne di più, consulta Disponibilità dei dati in modalità flusso nella documentazione di BigQuery.

Problemi di ispezione di BigQuery

I seguenti problemi si applicano solo alle operazioni di ispezione sui dati BigQuery. Non influiscono sui profili dati.

I risultati esportati non hanno valori per il campo row_number

Quando configuri Sensitive Data Protection per salvare i risultati in BigQuery, il campo location.content_locations.record_location.record_key.big_query_key.row_number nella tabella BigQuery generata viene dedotto al momento della scansione della tabella di input. Il suo valore non è deterministico, non può essere sottoposto a 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 identificativi sono disponibili nella tabella BigQuery generata, nel campo location.content_locations.record_location.record_key.id_values.

Limitazione delle scansioni ai nuovi contenuti di BigQuery

Se limiti le scansioni solo ai nuovi contenuti e utilizzi l'API BigQuery Storage Write (gRPC) per compilare la tabella di input, Sensitive Data Protection potrebbe saltare la scansione di alcune righe.

Per mitigare questo problema, nel job di ispezione, assicurati che il timestampField dell'oggetto TimespanConfig sia un timestamp di commit generato automaticamente da BigQuery. Tuttavia, non è ancora garantito che non vengano saltate righe, perché Sensitive Data Protection non legge i dati trasmessi in streaming di recente.

Se vuoi generare automaticamente i timestamp di commit per una colonna e utilizzi l'API di flussi di dati legacy per compilare la tabella di input, segui questi passaggi:

  1. Nello schema della tabella di input, assicurati che la colonna del timestamp sia di tipo TIMESTAMP.

    Schema di esempio

    L'esempio seguente definisce il campo commit_time_stamp e ne imposta il tipo su TIMESTAMP:

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

  2. Nel campo rows[].json del metodo tabledata.insertAll, assicurati che i valori nella colonna del timestamp siano impostati su AUTO.

    Esempio di struttura JSON

    L'esempio seguente imposta il valore del campo commit_time_stamp su AUTO:

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

Limitazione delle scansioni impostando una percentuale o un numero di righe massimi

Quando imposti un limite di campionamento basato su una percentuale del numero totale di righe della tabella (rowsLimitPercent), Sensitive Data Protection può ispezionare più righe del previsto. Se devi impostare un limite rigido per il numero di righe da analizzare, ti consigliamo di impostare un numero massimo di righe (rowsLimit).

Problemi di profilazione di BigQuery

I seguenti problemi sono applicabili solo alle operazioni di profilazione sui dati BigQuery. Per saperne di più, consulta Profili dati per i dati di BigQuery.

Organizzazioni o progetti con più di 500 milioni di tabelle

Sensitive Data Protection restituisce un errore se tenti di profilare un'organizzazione o un progetto con più di 500 milioni di tabelle. Se riscontri questo errore, segui le istruzioni riportate nel messaggio di errore.

Se il numero di tabelle della tua organizzazione è superiore a 500 milioni 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 disponi di dati in più regioni, utilizza più template di ispezione, uno per ogni regione in cui sono presenti i dati. Puoi anche utilizzare un template di ispezione archiviato nella regione global. Se includi un template nella regione global, Sensitive Data Protection lo utilizza per tutti i dati che non hanno un template specifico per la regione. Per saperne di più, consulta Considerazioni sulla residenza dei dati.

InfoType archiviati

Un infoType archiviato (noto anche come rilevatore di dizionario personalizzato archiviato) a cui viene fatto riferimento nel template di ispezione deve essere archiviato in uno dei seguenti modi:

  • La regione global.
  • La stessa regione del template di ispezione.

In caso contrario, l'operazione di profilazione non va a buon fine e viene visualizzato l'errore Resource not found.

Visibilità delle risorse

In un profilo dei dati della tabella, la classificazione della visibilità delle risorse assegnata a una tabella BigQuery dipende dalla visibilità del set di dati che contiene la tabella, anziché dalla visibilità della tabella. Pertanto, se le autorizzazioni IAM di una tabella sono diverse da quelle del set di dati, la visibilità delle risorse della tabella indicata nel profilo dati potrebbe non essere corretta. Questo problema riguarda il rilevamento per BigQuery e il rilevamento per Vertex AI.

Nella console Google Cloud , la visibilità delle risorse è indicata nel campo Pubblico del profilo dei dati della tabella. Nell'API Cloud Data Loss Prevention, la visibilità della risorsa è indicata nel campo resourceVisibility di TableDataProfile.

Timestamp di scadenza errato per le tabelle che non scadono

Tra luglio 2025 e giugno 2026, alcuni profili dati delle tabelle salvati in BigQuery contenevano un timestamp 1970-01-01 errato anziché NULL in expiration_time per le tabelle che non scadono.

Scansione di Cloud Storage

Questa sezione descrive i problemi che potresti riscontrare durante l'ispezione o l'anonimizzazione dei dati.

L'ispezione dei file XLSX rigidi non è supportata

Un file con estensione .xlsx può essere di due tipi. Un tipo è un foglio di lavoro Strict Office Open XML, che non è supportato da Sensitive Data Protection. L'altro tipo è un foglio di lavoro Microsoft Excel predefinito, che è supportato.

File strutturati analizzati in modalità binaria

In alcuni casi, i file che vengono generalmente analizzati in modalità di analisi strutturata potrebbero essere analizzati in modalità binaria, che non include i miglioramenti della modalità di analisi strutturata. Per saperne di più, consulta Scansione di file strutturati in modalità di analisi strutturata.

Anonimizzazione dei file delimitati

Quando anonimizzi un file delimitato (ad esempio un file CSV) con un job di ispezione, l'output potrebbe contenere celle vuote aggiuntive in alcune righe. Una soluzione alternativa per evitare queste celle aggiuntive è anonimizzare i dati utilizzando il metodo content.deidentify.

Discovery per Cloud SQL

Risultati duplicati di Security Command Center

La profilazione dei dati di Cloud SQL supporta la pubblicazione dei risultati in Security Command Center.

Prima del 25 aprile 2024, un bug causava la generazione occasionale di risultati duplicati da parte di Sensitive Data Protection per le istanze Cloud SQL in Security Command Center. Questi risultati sono stati generati con ID risultati univoci, ma riguardano le stesse istanze Cloud SQL. Il problema è stato risolto, ma i risultati duplicati esistono ancora. Puoi disattivare i duplicati per nasconderli nella pagina Risultati di Security Command Center.

Discovery per Amazon S3

I risultati per Amazon S3 che Sensitive Data Protection invia a Security Command Center potrebbero non contenere informazioni sull'ID account AWS o sul nome visualizzato della risorsa interessata. In genere, questo accade nei seguenti casi:

  • Il connettore AWS era valido solo da circa 24 ore al momento dell'invio del risultato a Security Command Center.
  • L'account AWS era stato incluso nel connettore AWS solo per circa 24 ore quando il risultato è stato inviato a Security Command Center.

Per risolvere il problema, dopo circa 24 ore, rigenera i profili dati eliminandoli o impostando una pianificazione della profilazione. I dettagli completi dei risultati vengono inviati a Security Command Center.

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 è compilato per la modalità di scansione Analisi intelligente dei documenti.

Rilevamento

I seguenti problemi noti descrivono i problemi di rilevamento, indipendentemente dall'operazione che stai eseguendo: ispezione, anonimizzazione o rilevamento.

Parole del dizionario

Le parole del dizionario contenenti caratteri nel Supplementary Multilingual Plane dello standard Unicode possono produrre risultati imprevisti. Esempi di questi caratteri sono emoji, simboli scientifici e scritture storiche.