Problèmes connus

Cette page répertorie les problèmes connus liés à la protection des données sensibles, ainsi que les moyens de les éviter ou de les résoudre.

Stocker les résultats dans BigQuery

Lorsqu'une tâche ou une analyse de découverte stocke des résultats dans BigQuery, une erreur Already exists (Existe déjà) s'affiche dans les journaux. Cette erreur n'indique pas qu'il y a 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' 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 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 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, la protection des données sensibles peut écrire des lignes en double.

Données récemment diffusées

La protection des données sensibles n'analyse pas les données récemment diffusées (anciennement appelées tampon de diffusion). Pour en savoir plus, consultez la section Disponibilité des données de diffusion 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. 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 inféré 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 uniquement et que vous utilisez l'API BigQuery Storage Write pour remplir la table d'entrée, la protection des données sensibles peut ignorer l'analyse de certaines lignes.

Pour atténuer ce problème, dans votre tâche d'inspection, assurez-vous que le timestampField de l' TimespanConfig objet est un code temporel de commit généré automatiquement par BigQuery. Toutefois, rien ne garantit qu'aucune ligne ne sera 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 codes temporels de commit pour une colonne et que vous utilisez l'ancienne API de diffusion 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 de code temporel 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 tabledata.insertAll méthode, assurez-vous que les valeurs de la colonne de code temporel 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",
  ...
}

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 lignes (rowsLimitPercent), la protection des données sensibles peut inspecter plus de lignes que prévu. Si vous devez définir une limite stricte sur le nombre de lignes à analyser, nous vous recommandons de définir un nombre maximal de lignes (rowsLimit) à la place.

Problèmes de profilage BigQuery

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

Organisations ou projets contenant plus de 500 millions de tables

La protection des données sensibles renvoie une erreur si vous essayez de profiler une organisation ou un projet comportant plus de 500 millions de tables. Si cette erreur se produit, suivez les instructions du message d'erreur.

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 de tables et de colonnes, consultez la section 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 dans laquelle 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, la protection des données sensibles l'utilise pour toutes les données qui ne disposent pas d'un modèle spécifique à la région. Pour en savoir plus, consultez la section Considérations relatives à 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 :

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

Sinon, l'opération de profilage échoue et renvoie l'erreur Resource not found (Ressource introuvable).

Visibilité des ressources

Dans un profil de données de table, la classification de la visibilité des ressources attribuée à une table BigQuery dépend de la visibilité de l'ensemble de données contenant la table, plutôt que de la visibilité de la table. Par conséquent, si les autorisations IAM d'une table diffèrent de celles de l'ensemble de données, la visibilité des ressources de la table indiquée dans le profil de données peut être incorrecte. Ce problème affecte la découverte pour BigQuery et la découverte pour Vertex AI.

Dans la Google Cloud console, la visibilité des ressources est indiquée dans le champ Public du profil de données de la table. Dans l'API Cloud Data Loss Prevention, la visibilité des ressources est indiquée dans le resourceVisibility champ du TableDataProfile.

Analyse Cloud Storage

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

L'inspection des fichiers XLSX strict n'est pas acceptée

Un fichier avec une extension .xlsx peut être de deux types. L'un est une feuille de calcul Strict Office Open XML, qui n'est pas compatible avec la protection des données sensibles. L'autre est un classeur Microsoft Excel par défaut, qui est compatible.

Analyse de fichiers structurés en mode binaire

Dans certains cas, les fichiers qui sont 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.

Anonymiser les fichiers délimités

Lorsque vous anonymisez un fichier délimité (par exemple, un fichier CSV) avec une tâche d'inspection, la sortie peut comporter des cellules vides supplémentaires dans certaines lignes. Pour éviter ces cellules supplémentaires, vous pouvez anonymiser les données à l'aide de la content.deidentify méthode.

Découverte pour Cloud SQL

Résultats en double dans Security Command Center

Le profilage des données Cloud SQL est compatible avec la publication de résultats dans Security Command Center.

Avant le 25 avril 2024, un bug entraînait la génération occasionnelle de résultats en double par la protection des données sensibles pour les instances Cloud SQL dans Security Command Center. Ces résultats ont été générés avec des ID de résultat uniques, mais ils concernent les mêmes instances Cloud SQL. Le problème a été résolu, mais les résultats en double existent toujours. Vous pouvez désactiver les doublons pour les masquer sur la page Résultats de Security Command Center.

Découverte pour Amazon S3

Les résultats pour Amazon S3 que la protection des données sensibles envoie à Security Command Center peuvent ne pas contenir d'informations sur l'ID de compte AWS ou le nom à afficher de la ressource concernée. Cela se produit généralement dans les cas suivants :

  • Le connecteur AWS n'était valide que depuis environ 24 heures au moment où le résultat a été envoyé à Security Command Center.
  • Le compte AWS n'était inclus dans le connecteur AWS que depuis environ 24 heures au moment où le résultat a été envoyé à Security Command Center.

Pour résoudre ce problème, après environ 24 heures, régénérez les profils de données en les supprimant ou en définissant une programmation de profilage. Les détails complets du résultat sont envoyés à Security Command Center.

Analyse intelligente des documents

Cette section contient des 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 problèmes connus suivants décrivent les problèmes de détection, quelle que soit l'opération que vous effectuez : inspection, anonymisation ou découverte.

Mots du dictionnaire

Les mots du dictionnaire contenant des caractères dans le plan multilingue supplémentaire de la norme Unicode peuvent générer des résultats inattendus. Par exemple, les emoji, les symboles scientifiques et les scripts historiques.