Cette page explique comment Sensitive Data Protection peut créer des copies anonymisées des données stockées dans Cloud Storage. Elle liste également les limites de cette opération et les points à prendre en compte avant de commencer.
Pour savoir comment utiliser Sensitive Data Protection afin de créer des copies anonymisées de vos données Cloud Storage, consultez les pages suivantes :
- Créer des copies anonymisées des données stockées dans Cloud Storage à l'aide de la console Google Cloud
- Créer des copies anonymisées des données stockées dans Cloud Storage à l'aide de l'API
À propos de l'anonymisation
L'anonymisation est le processus qui consiste à éliminer les informations personnelles contenues dans les données. Son objectif est de permettre l'utilisation et le partage d'informations personnelles (comme des informations sur la santé, financières ou démographiques) tout en respectant les exigences de confidentialité. Pour en savoir plus sur l'anonymisation, consultez Supprimer l'identification des données sensibles.
Pour en savoir plus sur les transformations d'anonymisation dans Sensitive Data Protection, consultez la documentation de référence sur les transformations. Pour en savoir plus sur la façon dont Sensitive Data Protection masque les données sensibles dans les images, consultez Inspection et masquage d'images.
Quand utiliser la désidentification du stockage
Voici quelques cas d'utilisation courants :
- Générez des ensembles de données anonymisés pour les environnements non destinés à la production : créez des copies anonymisées des fichiers de production stockés dans Cloud Storage avant de transférer les données dans des environnements de développement, de test ou d'entraînement.
- Partagez des dépôts de fichiers assainis avec des tiers : masquez les champs sensibles dans les documents groupés et les fichiers non structurés tout en préservant la hiérarchie des dossiers d'origine pour les partenaires commerciaux ou les auditeurs externes.
- Automatiser les pipelines de confidentialité pour les documents ingérés : transformez les données sensibles des fichiers nouvellement importés en un bucket de sortie désigné sans modifier les fichiers sources ni perturber les pipelines en amont.
- Appliquer la résidence et la compartimentation des données : stockez des copies miroirs anonymisées des composants sensibles dans des buckets Cloud Storage distincts avec des contrôles d'accès Identity and Access Management distincts.
Processus d'anonymisation
Cette section décrit le processus d'anonymisation dans Sensitive Data Protection pour le contenu dans Cloud Storage.
Pour utiliser cette fonctionnalité, vous devez créer un job d'inspection (DlpJob) configuré pour créer des copies anonymisées des fichiers Cloud Storage.
Sensitive Data Protection analyse les fichiers à l'emplacement spécifié et les inspecte en fonction de votre configuration. Lorsqu'il inspecte chaque fichier, Sensitive Data Protection anonymise toutes les données qui correspondent à vos critères de données sensibles, puis écrit le contenu dans un nouveau fichier. Le nouveau fichier porte toujours le même nom que le fichier d'origine.
Il stocke ce nouveau fichier dans un répertoire de sortie que vous spécifiez. Si un fichier est inclus dans votre analyse, mais qu'aucune donnée ne correspond à vos critères de désidentification et qu'il n'y a aucune erreur dans son traitement, le fichier est copié, sans être modifié, dans le répertoire de sortie.
Le répertoire de sortie que vous définissez doit se trouver dans un bucket Cloud Storage différent de celui contenant vos fichiers d'entrée. Dans votre répertoire de sortie, la protection des données sensibles crée une structure de fichiers qui reflète celle du répertoire d'entrée.
Par exemple, supposons que vous définissiez les répertoires d'entrée et de sortie suivants :
- Répertoire d'entrée :
gs://input-bucket/folder1/folder1a - Répertoire de sortie :
gs://output-bucket/output-directory
Lors de l'anonymisation, Sensitive Data Protection stocke les fichiers anonymisés dans gs://output-bucket/output-directory/folder1/folder1a.
Si un fichier portant le même nom qu'un fichier anonymisé existe dans le répertoire de sortie, il est écrasé. Si vous ne souhaitez pas que les fichiers existants soient écrasés, modifiez le répertoire de sortie avant d'exécuter cette opération. Vous pouvez également activer la gestion des versions d'objets sur le bucket de sortie.
Les listes de contrôle des accès (LCA) au niveau des fichiers d'origine sont copiées dans les nouveaux fichiers, que des données sensibles aient été trouvées et désidentifiées ou non. Toutefois, si le bucket de sortie n'est configuré que pour les autorisations uniformes au niveau du bucket, et non pour les autorisations précises (au niveau de l'objet), les LCA ne sont pas copiées dans les fichiers désidentifiés.
Le diagramme suivant illustre le processus de désidentification pour quatre fichiers stockés dans un bucket Cloud Storage. Chaque fichier est copié, que Sensitive Data Protection détecte ou non des données sensibles. Chaque fichier copié porte le même nom que l'original.
Tarifs
Pour en savoir plus sur les tarifs, consultez Inspection et transformation des données dans le stockage.
Types de fichiers compatibles
Sensitive Data Protection peut anonymiser les groupes de types de fichiers suivants :
- CSV
- Image
- Texte
- TSV
Comportement d'anonymisation par défaut
Si vous souhaitez définir la façon dont Sensitive Data Protection transforme les résultats, vous pouvez fournir des modèles d'anonymisation pour les types de fichiers suivants :
- Fichiers non structurés, comme des fichiers texte avec du texte libre
- Fichiers structurés, comme les fichiers CSV
- Images
Si vous ne fournissez aucun modèle d'anonymisation, Sensitive Data Protection transforme les résultats comme suit :
- Dans les fichiers structurés et non structurés, Sensitive Data Protection remplace tous les résultats par leur infoType correspondant, comme décrit dans Remplacement des infoTypes.
- Dans les images, Sensitive Data Protection couvre tous les résultats avec une boîte noire.
Limites et points à noter
Tenez compte des points suivants avant de créer des copies anonymisées des données Cloud Storage.
Espace disque
Cette opération n'est compatible qu'avec le contenu stocké dans Cloud Storage.
Cette opération crée une copie de chaque fichier lors de son inspection par la protection des données sensibles. Il ne modifie ni ne supprime le contenu d'origine. Les données copiées occuperont à peu près la même quantité d'espace disque supplémentaire que les données d'origine.
Accès en écriture à l'espace de stockage
Étant donné que Sensitive Data Protection crée une copie des fichiers d'origine, l'agent de service de votre projet doit disposer d'un accès en écriture au bucket de sortie Cloud Storage.
Échantillonnage et définition de limites pour les résultats
Cette opération n'est pas compatible avec l'échantillonnage. Plus précisément, vous ne pouvez pas limiter la quantité de chaque fichier que Sensitive Data Protection analyse et anonymise. En d'autres termes, si vous utilisez l'API Cloud Data Loss Prevention, vous ne pouvez pas utiliser bytesLimitPerFile et bytesLimitPerFilePercent dans l'objet CloudStorageOptions de votre DlpJob.
Vous ne pouvez pas non plus contrôler le nombre maximal de résultats à renvoyer.
Si vous utilisez l'API DLP, vous ne pouvez pas définir d'objet FindingLimits dans votre DlpJob.
Exigence d'inspecter les données
Lorsque vous exécutez votre job d'inspection, Sensitive Data Protection inspecte d'abord les données en fonction de votre configuration d'inspection, avant de procéder à l'anonymisation. Il ne peut pas ignorer le processus d'inspection.
Exigence d'utiliser des extensions de fichier
La protection des données sensibles s'appuie sur les extensions de fichier pour identifier les types de fichiers dans votre répertoire d'entrée. Il est possible que les fichiers sans extension ne soient pas désidentifiés, même s'ils sont de types compatibles.
Fichiers ignorés
Lorsque vous anonymisez des fichiers dans le stockage, Sensitive Data Protection ignore les fichiers suivants :
- Fichiers de plus de 60 000 Ko Si vous avez des fichiers volumineux qui dépassent cette limite, envisagez de les diviser en plusieurs parties plus petites.
- Les types de fichiers qui ne figurent pas dans la section Types de fichiers compatibles sur cette page.
- Types de fichiers que vous avez volontairement exclus de la configuration d'anonymisation. Si vous utilisez l'API DLP, les types de fichiers que vous avez exclus du champ
file_types_to_transformde l'actionDeidentifyde votreDlpJobsont ignorés. - Fichiers ayant rencontré des erreurs de transformation.
Ordre des lignes de sortie dans les tables anonymisées
Rien ne garantit que l'ordre des lignes d'un tableau anonymisé correspond à celui des lignes du tableau d'origine. Si vous souhaitez comparer le tableau d'origine au tableau anonymisé, vous ne pouvez pas vous fier au numéro de ligne pour identifier les lignes correspondantes. Si vous souhaitez comparer des lignes de tableaux, vous devez utiliser un identifiant unique pour identifier chaque enregistrement.
Clés temporaires
Si vous choisissez une méthode cryptographique comme méthode de transformation, vous devez d'abord créer une clé encapsulée à l'aide de Cloud Key Management Service. Fournissez ensuite cette clé dans votre modèle d'anonymisation. Les clés temporaires (brutes) ne sont pas acceptées.
Étapes suivantes
- Découvrez comment anonymiser les données sensibles stockées dans Cloud Storage à l'aide de l'API DLP.
- Découvrez comment anonymiser les données sensibles stockées dans Cloud Storage à l'aide de la console Google Cloud .
- Suivez l'atelier de programmation Créer une copie anonymisée des données dans Cloud Storage.
- Découvrez comment inspecter le stockage pour identifier les données sensibles.