Problemi noti

Questa pagina elenca i problemi noti relativi a Sensitive Data Protection, nonché i modi in cui puoi evitarli o recuperarti dai seguenti problemi.

Problemi generici

Archiviazione dei risultati in BigQuery

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

Scansione 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 sono applicabili sia alle operazioni di ispezione sia a quelle di profiling di BigQuery.

Non è possibile 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 creare il profilo delle tabelle BigQuery protette. Se hai criteri di sicurezza a livello di riga applicati alle tue tabelle BigQuery, ti consigliamo di impostare un filtro TRUE e di includere l'agente di servizio nell'elenco dei beneficiari:

Righe duplicate

Quando scrivi dati in una tabella BigQuery, la funzionalità Protezione dei dati sensibili potrebbe scrivere righe duplicate.

Dati sottoposti a streaming di recente

Sensitive Data Protection non analizza i dati sottoposti a streaming di recente (precedentemente noti come buffer dei flussi). Per ulteriori informazioni, consulta la sezione Disponibilità dei dati streaming nella documentazione di BigQuery.

Problemi di ispezione BigQuery

I seguenti problemi sono applicabili solo alle operazioni di ispezione sui dati BigQuery. Non influiscono sui profili dei 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 si trovano nella tabella BigQuery generata, nel campo location.content_locations.record_location.record_key.id_values.

Limitare le 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 attenuare il problema, nel job di ispezione assicurati che timestampField dell'oggetto TimespanConfig sia un timestamp del commit generato automaticamente da BigQuery. Tuttavia, non è ancora garantito che nessuna riga venga saltata, perché la funzionalità Protezione dei dati sensibili non legge i dati sottoposti a streaming di recente.

Se vuoi generare automaticamente i timestamp dei commit per una colonna e utilizzi l'API di streaming precedente per compilare la tabella di input, procedi nel seguente modo:

  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 imposta il relativo 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 JSON

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

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

Limitare le 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 per il numero di righe da scansionare, 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 ulteriori informazioni, consulta Profili di dati per i dati BigQuery.

Organizzazioni o progetti con più di 500 milioni di tabelle

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

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 del profilo 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ù 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 dispongono di un modello specifico per la regione. Per ulteriori informazioni, 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 modello di ispezione deve essere archiviato in uno dei seguenti elementi:

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

In caso contrario, l'operazione di creazione del profilo non riesce con l'errore Resource not found.

Visibilità delle risorse

In un profilo dati della tabella, la classificazione della visibilità della risorsa 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à della risorsa della tabella indicata nel profilo dei dati può essere errata. Questo problema riguarda la scoperta per BigQuery e la scoperta per Vertex AI.

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

Scansione di Cloud Storage

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

Ispezione di file XLSX con rilevatori di dizionari personalizzati di grandi dimensioni

Quando utilizzi un rilevatore di grandi dizionari personalizzati (noto anche come rilevatore di dizionari personalizzati archiviati) per ispezionare un file Microsoft Excel.xlsx, il job di ispezione può essere eseguito lentamente, sembrare bloccato e comportare un gran numero di operazioni di classe B di Cloud Storage. Questo perché Sensitive Data Protection potrebbe leggere l'elenco dei termini di origine del grande dizionario personalizzato una volta per ogni cella del file .xlsx. Il volume delle operazioni di lettura può far sì che il job di ispezione Sensitive Data Protection mostri scarso avanzamento e sembri bloccato.

Per ulteriori informazioni sugli addebiti di fatturazione di Cloud Storage pertinenti, consulta gli addebiti per le operazioni di classe B in Addebiti per le operazioni.

File strutturati sottoposti a scansione in modalità binaria

In alcuni casi, i file che in genere vengono analizzati in modalità di analisi strutturata potrebbero essere analizzati in modalità binaria, che non include i miglioramenti della modalità di analisi strutturata. Per ulteriori informazioni, consulta la sezione Scansione dei 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 Cloud SQL supporta la pubblicazione dei risultati in Security Command Center.

Prima del 25 aprile 2024, un bug causava occasionalmente la generazione di risultati duplicati per le istanze Cloud SQL in Security Command Center da parte di Sensitive Data Protection. 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.

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 o sul nome visualizzato dell'account AWS della risorsa interessata. Questo accade in genere 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 incluso nel connettore AWS solo da circa 24 ore al momento dell'invio del rilevamento a Security Command Center.

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

Analisi intelligente dei documenti

Questa sezione contiene i problemi noti relativi all'analisi del documento.

L'oggetto DocumentLocation non è compilato

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

Rilevamento

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