Problèmes connus

Cette page répertorie les problèmes connus liés à la protection des données sensibles et vous explique comment les éviter ou les résoudre.

Problèmes d'ordre général

Stocker les résultats dans BigQuery

Lorsqu'une tâche ou une analyse de découverte stocke les résultats dans BigQuery, une erreur Already exists apparaît dans les journaux. L'erreur n'indique pas l'existence d'un problème ; vos résultats seront stockés comme prévu.

Analyse BigQuery

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

Problèmes courants avec les opérations d'inspection et de profilage

Les problèmes suivants sont applicables à la fois aux opérations d'inspection et de profilage de BigQuery.

Les problèmes suivants sont également applicables aux opérations d'anonymisation dans BigQuery (en version preview).

Impossible d'analyser les lignes protégées par un niveau de sécurité au niveau des lignes

Les règles de sécurité au niveau des lignes peuvent empêcher la protection des données sensibles d'inspecter et de profiler les tables BigQuery protégées. Si des règles de sécurité au niveau des lignes sont appliquées à vos tables BigQuery, nous vous recommandons de définir un filtre VRAI 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, la protection des données sensibles peut écrire des lignes en double.

Données diffusées récemment

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

Problèmes d'inspection BigQuery

Les problèmes suivants ne concernent que les opérations d'inspection des données BigQuery. Ils n'affectent pas les profils de données.

Les résultats exportés ne comportent pas de valeurs pour le champ "row_number"

Lorsque vous configurez la protection des données sensibles 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 où la table d'entrée est analysé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 le champ location.content_locations.record_location.record_key.id_values de la table BigQuery générée.

Limiter les analyses au nouveau contenu BigQuery

Ce problème s'applique également aux opérations d'anonymisation dans BigQuery (en version preview).

Si vous limitez les analyses aux nouveaux contenus uniquement et que vous utilisez l'API BigQuery Storage Write pour renseigner la table d'entrée, la protection des données sensibles peut ignorer l'analyse de certaines lignes.

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

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 de code JSON

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

    {
  ...
  "commit_time_stamp": "AUTO",
  ...
}
Découvrez comment supprimer manuellement les doublons.

Limiter les analyses en définissant un pourcentage ou un nombre maximal de lignes

Lorsque vous définissez une limite d'échantillonnage basée sur un pourcentage du nombre total de lignes de la table (rowsLimitPercent), la protection des données sensibles peut inspecter plus de lignes que prévu. Si vous devez fixer une limite stricte au nombre de lignes à analyser, nous vous recommandons plutôt de définir un nombre maximal de lignes (rowsLimit).

Problèmes de profilage BigQuery

Les problèmes suivants ne concernent que les opérations de profilage sur les données BigQuery. Pour en savoir plus, consultez la page Profils de données pour BigQuery.

Organisations ou projets contenant plus de 500 millions de tables

La protection des données sensibles renvoie une erreur si vous tentez 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 applicables aux tables et aux colonnes, consultez Limites du 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 disposez de données dans plusieurs régions, utilisez plusieurs modèles d'inspection (un pour chaque région concernée). 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, la protection des données sensibles 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 concernant 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 éléments suivants:

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

Sinon, l'opération de profilage échoue et l'erreur Resource not found est renvoyée.

VPC Service Controls

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

Analyse Cloud Storage

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

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

Lorsque vous inspectez un fichier Microsoft Excel .xlsx à l'aide d'un détecteur de dictionnaire personnalisé volumineux (également appelé détecteur de dictionnaire personnalisé stocké) pour inspecter un fichier Microsoft Excel .xlsx, le job d'inspection peut s'exécuter lentement, sembler bloqué et entraîner un grand nombre d'opérations de classe B de Cloud Storage. En effet, la protection des données sensibles peut lire la liste de termes source du grand dictionnaire personnalisé une fois pour chaque cellule du fichier .xlsx. En raison du volume d'opérations de lecture, le job d'inspection de la protection des données sensibles peut indiquer peu de progrès et sembler bloqué.

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

Fichiers structurés analysés en mode binaire

Dans certains cas, les fichiers généralement analysés en mode d'analyse structurée peuvent être analysés en mode binaire, qui n'inclut pas les améliorations du mode d'analyse structurée. Pour en savoir plus, consultez la section Analyser des fichiers structurés en mode d'analyse structurée.

Analyse intelligente des documents

Cette section présente les problèmes connus liés à 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.

Détection

Les mots du dictionnaire contenant des caractères du plan multilingue supplémentaire de la norme Unicode peuvent produire des résultats inattendus. comme le chinois, le japonais, le coréen ou les emoji.