Cloud Data Loss Prevention (Cloud DLP) fait désormais partie de la protection des données sensibles. Le nom de l'API reste le même: API Cloud Data Loss Prevention (API DLP). Pour en savoir plus sur les services qui constituent la protection des données sensibles, consultez la présentation de la protection des données sensibles.

Cette page a été traduite par l'API Cloud Translation.

Problèmes connus

Cette page répertorie les problèmes connus liés à la protection des données sensibles, ainsi que des moyens de les éviter ou de 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 des résultats dans BigQuery, une erreur Already exists s'affiche dans les journaux. Cette erreur n'indique pas qu'un problème est survenu. 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 profiliez des données BigQuery.

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

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

Impossible d'analyser les lignes avec la 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 créer des profils des 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:

Si vous effectuez un profilage des données au niveau de l'organisation ou du dossier, incluez l'agent de service du projet de conteneur dans la liste des bénéficiaires.
Si vous effectuez un profilage des données au niveau du projet ou exécutez un job d'inspection sur une table, incluez l'agent de service du projet dans la liste des bénéficiaires.

Lignes en double

Lorsque vous écrivez des données dans une table BigQuery, la protection des données sensibles 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 de 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 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 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 aux nouveaux contenus 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, dans votre tâche d'inspection, assurez-vous que l'timestampField de l'objet TimespanConfig est un code temporel de validation généré automatiquement par BigQuery. Toutefois, il n'est pas garanti 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 validation pour une colonne et que vous utilisez l'ancienne API de streaming pour renseigner votre table d'entrée, procédez comme suit:

Dans le schéma du tableau 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"
}
...
```
Dans le champ rows[].json de la méthode tabledata.insertAll, assurez-vous que les valeurs de la colonne "code temporel" sont définies sur AUTO.

Exemple de fichier 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 table (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 plutôt un nombre maximal de lignes (rowsLimit).

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 vous rencontrez cette erreur, suivez les instructions indiquées dans le message.

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 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 disposez de 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 propre à 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 éléments 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 qui contient 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 la 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 anonymisez des données.

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

Lorsque vous utilisez un grand détecteur de dictionnaire personnalisé (également appelé détecteur de dictionnaire personnalisé stocké) pour inspecter un fichier .xlsx Microsoft Excel, la tâche d'inspection peut s'exécuter lentement, sembler bloquée et générer un grand nombre d'opérations de classe B Cloud Storage. En effet, la protection des données sensibles peut lire la liste des termes sources du grand dictionnaire personnalisé une fois pour chaque cellule du fichier .xlsx. Le volume d'opérations de lecture peut entraîner une faible progression de la tâche d'inspection de la protection des données sensibles et donner l'impression qu'elle est bloquée.

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

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, ce 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.

Supprimer l'identification des fichiers délimités

Lorsque vous anonymisez un fichier délimité (par exemple, un fichier CSV) à l'aide d'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 méthode content.deidentify.

Discovery pour Cloud SQL

Résultats en double de Security Command Center

Le profilage des données Cloud SQL permet de publier les 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 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 masquer les doublons pour les masquer sur la page Résultats de Security Command Center.

Discovery pour Amazon S3

Les résultats pour Amazon S3 que le service de 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ù la découverte a été envoyée à Security Command Center.

Pour résoudre ce problème, après environ 24 heures, regénérez les profils de données 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 contient 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 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 d'emoji, de symboles scientifiques ou d'écritures historiques, par exemple.