Problemi noti

Questa pagina elenca i problemi noti di Sensitive Data Protection, nonché i modi per evitarli o risolverli.

Archiviazione dei risultati in BigQuery

Quando un job o una scansione di rilevamento memorizza i risultati in BigQuery, nei log viene visualizzato un errore Already exists. L'errore non indica che esiste 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 si applicano sia alle operazioni di ispezione che di profilazione di BigQuery.

Le righe con sicurezza a livello di riga non possono essere scansionate

Le norme 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 applicati criteri 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 dati in una tabella BigQuery, Sensitive Data Protection potrebbe scrivere righe duplicate.

Dati di streaming recenti

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

Problemi di ispezione di BigQuery

I seguenti problemi si applicano solo alle operazioni di ispezione dei 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 lavori 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 risolvere il problema, nel job di ispezione, assicurati che 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 streaming legacy per popolare 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 di righe massimi

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 imporre un limite rigido al numero di righe da scansionare, ti consigliamo di impostare un numero massimo di righe (rowsLimit).

Problemi di profilazione di BigQuery

I seguenti problemi si applicano solo alle operazioni di profilazione dei 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 si verifica questo errore, segui le istruzioni riportate nel messaggio di errore.

Se il conteggio delle tabelle della tua organizzazione supera i 500 milioni e hai un progetto con un conteggio delle tabelle inferiore, prova a eseguire una scansione a livello di progetto.

Per informazioni sui limiti di tabelle e colonne, consulta Limiti della 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ù modelli di ispezione, uno per ogni regione in cui sono presenti 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 per la regione. Per saperne di più, consulta Considerazioni sulla residenza dei dati.

InfoType archiviati

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

  • 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 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 differiscono da quelle del set di dati, la visibilità delle risorse della tabella indicata nel profilo dei dati può essere errata. Questo problema interessa l'individuazione per BigQuery e l'individuazione 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à delle risorse è indicata nel campo resourceVisibility di TableDataProfile.

Scansione di Cloud Storage

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

L'ispezione dei file XLSX rigorosi 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 vengono in genere analizzati in modalità di analisi strutturata potrebbero essere analizzati in modalità binaria, che non include i miglioramenti della modalità di analisi strutturata. Per maggiori informazioni, consulta la sezione Scansione di file strutturati in modalità di analisi strutturata.

Anonimizzazione dei file delimitati

Quando de-identifichi 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 consiste nell'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 ha causato la generazione occasionale 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 risultato unici, 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. Ciò si verifica in genere 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 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 problemi noti relativi all'analisi dei documenti.

L'oggetto DocumentLocation non è compilato

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

Rilevamento

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

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 caratteri storici.

Regole di esclusione

Le regole di esclusione non possono essere applicate agli infoType oggetto.