Problemi noti

Questa pagina elenca i problemi noti di Sensitive Data Protection, nonché i modi in cui puoi evitarli o ripristinarli.

Archiviazione dei risultati in BigQuery

Quando un job o una scansione di rilevamento archivia 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 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 eseguire la scansione delle righe con sicurezza a livello di riga

I criteri di sicurezza a livello di riga possono impedire a Sensitive Data Protection 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 destinatari:

Righe duplicate

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

Dati di cui è stato eseguito lo streaming di recente

Sensitive Data Protection non esegue la scansione dei dati di cui è stato eseguito lo streaming di recente (in precedenza noto come buffer di streaming). Per ulteriori informazioni, consulta Disponibilità dei dati di streaming 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 di 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 nullo 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 sono disponibili nella tabella BigQuery generata, nel campo location.content_locations.record_location.record_key.id_values.

Limitazione delle scansioni ai nuovi contenuti BigQuery

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

Per risolvere questo problema, nel job di ispezione assicurati che timestampField dell' TimespanConfig oggetto 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 di cui è stato eseguito lo streaming di recente.

Se vuoi generare automaticamente i timestamp di commit per una colonna e utilizzi l'API Streaming precedente per compilare la tabella di input:

  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 tabledata.insertAll metodo, assicurati che i valori nella colonna del timestamp siano impostati su AUTO.

    JSON di esempio

    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 massimo di righe

Quando imposti un limite di campionamento in base a 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 al numero di righe da scansionare, ti consigliamo di impostare un numero massimo di righe (rowsLimit) invece.

Problemi di profilazione di BigQuery

I seguenti problemi si applicano solo alle operazioni di profilazione sui dati BigQuery. Per ulteriori informazioni, consulta Profili di dati per dati 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 nel messaggio di errore.

Se il numero di tabelle della tua organizzazione è superiore a 500 milioni e hai un progetto con un numero inferiore di tabelle, 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ù regioni, utilizza più modelli di ispezione, uno per ogni regione in cui hai dati. Puoi anche utilizzare un modello di ispezione archiviato nella regione global. Se includi un modello nella regione global, Sensitive Data Protection lo utilizza per tutti i dati che non hanno un modello specifico della regione. Per ulteriori informazioni, consulta Considerazioni sulla residenza dei dati.

InfoType archiviati

Un infoType archiviato (noto anche come rilevatore di dizionari personalizzati archiviati) a cui viene fatto riferimento nel modello di ispezione deve essere archiviato in una delle seguenti posizioni:

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

In caso contrario, l'operazione di profilazione non riesce e viene visualizzato l'errore Resource not found.

Visibilità delle risorse

In un profilo di 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. Di conseguenza, se le autorizzazioni IAM di una tabella sono diverse dalle autorizzazioni IAM del set di dati, la visibilità delle risorse della tabella indicata nel profilo di dati può essere errata. Questo problema riguarda il rilevamento per BigQuery e il rilevamento per Vertex AI.

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

Scansione di Cloud Storage

Questa sezione descrive i problemi che potresti riscontrare durante l'ispezione o la de-identificazione dei dati.

L'ispezione dei file XLSX Strict 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 è una cartella di lavoro predefinita di Microsoft Excel, che è supportata.

File strutturati scansionati in modalità binaria

In alcuni casi, i file che in genere vengono scansionati in modalità di analisi strutturata potrebbero essere scansionati in modalità binaria, che non include i miglioramenti della modalità di analisi strutturata. Per ulteriori informazioni, 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 avere celle vuote aggiuntive in alcune righe. Una soluzione alternativa per evitare queste celle aggiuntive è anonimizzare i dati utilizzando il content.deidentify metodo.

Rilevamento 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 ha fatto sì che Sensitive Data Protection generasse occasionalmente risultati duplicati per le istanze Cloud SQL in Security Command Center. Questi risultati sono stati generati con ID risultati univoci, ma si riferiscono alle 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.

Rilevamento 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 per 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 al momento dell'invio del risultato a Security Command Center.

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

Analisi intelligente dei documenti

Questa sezione contiene problemi noti relativi all'analisi dei documenti.

L'oggetto DocumentLocation non viene compilato

Il campo location.content_locations.document_location.file_offset non viene compilato per la modalità di scansione di analisi intelligente dei documenti.

Rilevamento

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

Parole del dizionario

Le parole del dizionario che contengono caratteri nel piano multilingue supplementare dello standard Unicode possono produrre risultati imprevisti. Esempi di questi caratteri sono emoji, simboli scientifici e script storici.