Problèmes connus

Cette page répertorie les problèmes connus de Cloud DLP et vous indique comment les éviter ou les résoudre.

Analyse BigQuery

Cette section décrit les problèmes que vous pouvez rencontrer lors de l'inspection ou du profilage de données BigQuery.

Problèmes courants liés aux opérations d'inspection et de profilage

Les problèmes suivants s'appliquent aux opérations d'inspection et de profilage BigQuery.

Impossible d'analyser les lignes avec sécurité au niveau des lignes

Les règles de sécurité au niveau des lignes peuvent empêcher Cloud DLP d'inspecter les tables BigQuery protégées et de les profiler. Si vous avez des règles de sécurité au niveau des lignes appliquées à vos tables BigQuery, nous vous recommandons de définir un filtre TRUE et d'inclure l'agent de service dans la liste des bénéficiaires:

Lignes en double

Lors de l'écriture de données dans une table BigQuery, Cloud DLP peut écrire des lignes en double.

Données diffusées récemment

Cloud DLP n'analyse pas les données récemment diffusées (anciennement tampon par flux). Pour en savoir plus, consultez la section Disponibilité des données en streaming dans la documentation BigQuery.

Problèmes d'inspection BigQuery

Les problèmes suivants ne s'appliquent qu'aux opérations d'inspection sur les données BigQuery. Elles n'affectent pas les profils de données.

Les résultats exportés n'ont pas de valeur pour le champ row_number.

Lorsque vous configurez Cloud DLP pour enregistrer les résultats dans BigQuery, le champ location.content_locations.record_location.record_key.big_query_key.row_number de la table BigQuery générée est déduit au moment de l'analyse de la table d'entrée. Sa valeur est non déterministe, ne peut pas être interrogée et peut être nulle pour les tâches d'inspection.

Si vous devez identifier des lignes spécifiques où des résultats sont présents, spécifiez inspectJob.storageConfig.bigQueryOptions.identifyingFields au moment de la création de la tâche.

Les champs d'identification se trouvent dans la table BigQuery générée, dans le champ location.content_locations.record_location.record_key.id_values.

Limiter les analyses au nouveau contenu BigQuery

Si vous limitez les analyses au nouveau contenu et que vous utilisez l'API BigQuery Storage Write pour remplir la table d'entrée, Cloud DLP peut ignorer l'analyse de certaines lignes.

Pour atténuer ce problème, dans votre tâche d'inspection, assurez-vous que timestampField de l'objet TimespanConfig est un horodatage de commit généré automatiquement par BigQuery. Cependant, rien ne garantit qu'aucune ligne ne sera ignorée, car Cloud DLP ne lit pas les données diffusées récemment.

Si vous souhaitez générer automatiquement des horodatages de commit pour une colonne et que vous utilisez l'ancienne API de streaming pour remplir votre table d'entrée, procédez comme suit:

  1. Dans le schéma de la table d'entrée, assurez-vous que la colonne d'horodatage est de type TIMESTAMP.

    Exemple de schéma

    L'exemple suivant définit le champ commit_time_stamp et définit son type sur TIMESTAMP:

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

  2. Dans le champ rows[].json de la méthode tabledata.insertAll, assurez-vous que les valeurs de la colonne d'horodatage sont définies sur AUTO.

    Exemple JSON

    L'exemple suivant définit la valeur du champ commit_time_stamp sur AUTO:

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

Problèmes de profilage BigQuery

Les problèmes suivants ne s'appliquent qu'aux opérations de profilage des données BigQuery. Pour en savoir plus, consultez Profils de données pour les données BigQuery.

Organisations ou projets contenant plus de 500 millions de tables

Cloud DLP renvoie une erreur si vous essayez de profiler une organisation ou un projet comportant plus de 500 millions de tables. Si vous rencontrez cette erreur, vous pouvez envoyer vos commentaires par e-mail à l'adresse cloud-dlp-feedback@google.com.

Si votre organisation compte plus de 500 millions de tables et que votre projet comporte un nombre de tables inférieur, essayez plutôt d'effectuer une analyse au niveau du projet.

Pour en savoir plus sur les limites des tables et des colonnes, consultez la page Limites de profilage des données.

Modèles d'inspection

Le modèle d'inspection doit se trouver dans la même région que les données à profiler. Si vous avez des données dans plusieurs régions, utilisez plusieurs modèles d'inspection (un pour chaque région où vous avez des données). Vous pouvez également utiliser un modèle d'inspection stocké dans la région global. Si vous incluez un modèle dans la région global, Cloud DLP l'utilise pour toutes les données qui n'ont pas de modèle spécifique à la région. Pour en savoir plus, consultez la section Considérations sur la résidence des données.

InfoTypes stockés

Un infoType stocké (également appelé détecteur de dictionnaire personnalisé stocké) référencé dans votre modèle d'inspection doit être stocké dans l'un des emplacements suivants:

  • Région global.
  • La même région que le modèle d'inspection.

Sinon, l'opération de profilage échoue et affiche l'erreur suivante : Resource not found.

VPC Service Controls

L'utilisation de cette fonctionnalité avec des zones VPC Service Controls n'est pas officiellement disponible. Si vous essayez d'analyser des données dans une zone VPC Service Controls, indiquez-nous les problèmes que vous rencontrez en envoyant un e-mail à cloud-dlp-feedback@google.com.

Analyse Cloud Storage

Cette section décrit les problèmes que vous pouvez rencontrer lors de l'inspection ou de l'anonymisation des données.

Inspection des fichiers XLSX avec de grands détecteurs de dictionnaires personnalisés

Lorsque vous inspectez un fichier Microsoft Excel .xlsx, vous utilisez un détecteur de dictionnaire personnalisé de grande taille (également appelé détecteur de dictionnaire personnalisé stocké), la tâche d'inspection peut s'exécuter lentement, apparaître bloquée et entraîner de nombreuses opérations de classe B de Cloud Storage. En effet, Cloud DLP peut lire la liste des termes sources du dictionnaire personnalisé volumineux une fois pour chaque cellule du fichier .xlsx. Le volume d'opérations de lecture peut faire que la tâche d'inspection Cloud DLP affiche un faible progrès et semble bloquée.

Pour en savoir plus sur les frais de facturation Cloud Storage pertinents, consultez les frais liés aux opérations de classe B dans Frais d'opération.

En-tête répété dans une copie anonymisée des fichiers délimités

Lorsque vous anonymisez un fichier délimité (par exemple, un fichier CSV ou TSV) dans Cloud Storage, le fichier anonymisé résultant peut parfois avoir des lignes d'en-tête en double.

Prenons l'exemple suivant :

Header1,Header2
Cell1,Cell2
Cell3,Cell4
Cell5,Cell6

Dans le fichier anonymisé obtenu, la ligne d'en-tête peut apparaître à deux endroits:

Header1,Header2
DeidentifiedCell1,DeidentifiedCell2
DeidentifiedCell3,DeidentifiedCell4
Header1,Header2
DeidentifiedCell5,DeidentifiedCell6

Si la taille du fichier respecte la limite de taille de requête (0,5 Mo), vous pouvez supprimer l'identification du contenu à l'aide d'une requête projects.content.deidentify.

Analyse intelligente des documents

Cette section contient des problèmes connus concernant l'analyse de documents.

L'objet DocumentLocation n'est pas renseigné

Le champ location.content_locations.document_location.file_offset n'est pas renseigné pour le mode d'analyse de document intelligent.