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 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 lorsque vous inspectez ou profilez des 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.

Les lignes avec sécurité au niveau des lignes ne peuvent pas être analysées

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

Lorsque vous écrivez des données dans une table BigQuery, Sensitive Data Protection peut écrire des lignes en double.

Données de streaming récentes

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

Problèmes d'inspection BigQuery

Les problèmes suivants ne s'appliquent qu'aux opérations d'inspection des données BigQuery. Ils n'ont aucune incidence sur 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 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 aux nouveaux contenus et que vous utilisez l'API BigQuery Storage Write pour remplir la table d'entrée, il est possible que Sensitive Data Protection ignore l'analyse de certaines lignes.

Pour atténuer ce problème, assurez-vous que le timestampField de l'objet TimespanConfig est un code temporel de commit généré automatiquement par BigQuery dans votre job d'inspection. Toutefois, il n'est toujours pas garanti qu'aucune ligne ne soit ignorée, car la protection des données sensibles ne lit pas les données récemment diffusées en flux continu.

Si vous souhaitez générer automatiquement des codes temporels de commit pour une colonne et que vous utilisez l'ancienne API 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",
  ...
}

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

Lorsque vous définissez une limite d'échantillonnage basée sur un pourcentage du nombre total de lignes du tableau (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 Profils de données pour les données BigQuery.

Organisations ou projets contenant plus de 500 millions de tables

Sensitive Data Protection 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, 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 des tables et des 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 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, Sensitive Data Protection l'utilise pour toutes les données qui ne disposent pas d'un modèle spécifique à une région. Pour en savoir plus, consultez 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 :

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

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

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, et non 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 console Google Cloud , la visibilité des ressources est indiquée dans le champ Public du profil de données de table. Dans l'API Cloud Data Loss Prevention, la visibilité des ressources est indiquée dans le champ resourceVisibility de TableDataProfile.

Analyse Cloud Storage

Cette section décrit les problèmes que vous pouvez rencontrer lorsque vous inspectez ou désidentifiez des données.

L'inspection des fichiers XLSX stricts n'est pas prise en charge

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

Fichiers structurés analysé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 Analyser des fichiers structurés en mode d'analyse structurée.

Anonymiser les fichiers délimités

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

Discovery pour Cloud SQL

Résultats en double de Security Command Center

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

Avant le 25 avril 2024, un bug entraînait parfois la génération de résultats en double pour les instances Cloud SQL dans Security Command Center. Ces résultats ont été générés avec des ID 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 masquer les doublons pour les cacher sur la page Résultats de Security Command Center.

Découverte pour Amazon S3

Il est possible que les résultats pour Amazon S3 que la protection des données sensibles envoie à Security Command Center ne contiennent pas 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 pendant environ 24 heures au moment où le résultat a été envoyé à Security Command Center.
  • Le compte AWS n'avait été inclus dans le connecteur AWS que pendant environ 24 heures au moment où le résultat a été envoyé à Security Command Center.

Pour résoudre ce problème, régénérez les profils de données au bout de 24 heures environ en les supprimant ou en définissant un calendrier de profilage. Les détails complets des résultats sont envoyés à Security Command Center.

Analyse intelligente des documents

Cette section liste les problèmes connus liés à l'analyse des 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, désidentification ou découverte).

Mots du dictionnaire

Les mots du dictionnaire contenant des caractères du plan multilingue supplémentaire de la norme Unicode peuvent générer des résultats inattendus. Il peut s'agir, par exemple, d'emoji, de symboles scientifiques ou d'écritures historiques.

Règles d'exclusion

Les règles d'exclusion ne peuvent pas être appliquées aux infoTypes d'objet.