Anonymisation des données Cloud Storage sensibles

Cette page explique comment la protection des données sensibles peut créer des copies anonymisées des données stockées dans Cloud Storage. Il liste également les limites de cette opération et les points à prendre en compte avant de commencer.

Pour savoir comment utiliser la protection des données sensibles pour créer des copies anonymisées de vos données Cloud Storage, consultez les articles suivants:

À propos de l'anonymisation

La suppression de l'identification est le processus qui consiste à supprimer des informations d'identification dans des données. Son objectif est de permettre l'utilisation et le partage d'informations personnelles (telles que des informations sur la santé, les finances ou les données démographiques) tout en respectant les exigences de confidentialité. Pour en savoir plus sur l'anonymisation, consultez la section Supprimer l'identification des données sensibles.

Pour en savoir plus sur les transformations d'anonymisation dans la protection des données sensibles, consultez la documentation de référence sur les transformations. Pour en savoir plus sur la façon dont la protection des données sensibles masque les données sensibles dans les images, consultez la section Inspection et masquage d'images.

Quand utiliser cette fonctionnalité ?

Cette fonctionnalité est utile si les fichiers que vous utilisez dans vos activités commerciales contiennent des données sensibles, telles que des informations permettant d'identifier personnellement l'utilisateur. Cette fonctionnalité vous permet d'utiliser et de partager des informations dans le cadre de vos processus métier, tout en masquant les données sensibles.

Processus d'anonymisation

Cette section décrit le processus d'anonymisation dans la protection des données sensibles pour le contenu stocké dans Cloud Storage.

Pour utiliser cette fonctionnalité, vous devez créer une tâche d'inspection (DlpJob) configurée pour créer des copies anonymisées des fichiers Cloud Storage. Sensitive Data Protection analyse les fichiers à l'emplacement spécifié, en les inspectant conformément à votre configuration. Lors de l'inspection de 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'aucune erreur n'est détectée lors de son traitement, le fichier est copié, sans modification, 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 la structure de fichiers 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, la protection des données sensibles stocke les fichiers anonymisés dans gs://output-bucket/output-directory/folder1/folder1a.

Si un fichier existe dans le répertoire de sortie avec le même nom de fichier qu'un fichier anonymisé, ce fichier 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 anonymisées ou non. Toutefois, si le bucket de sortie n'est configuré que pour des autorisations uniformes au niveau du bucket et non pour des autorisations précises (au niveau de l'objet), les LCA ne sont pas copiées dans les fichiers anonymisés.

Le diagramme suivant illustre le processus de désidentification de quatre fichiers stockés dans un bucket Cloud Storage. Chaque fichier est copié, que la protection des données sensibles détecte ou non des données sensibles. Chaque fichier copié porte le même nom que l'original.

Anonymisation des fichiers stockés dans Cloud Storage.
Anonymisation des fichiers stockés dans Cloud Storage (cliquez pour agrandir).

Tarifs

Pour connaître les tarifs, consultez la section Inspection et transformation des données stockées.

Types de fichiers compatibles

La protection des données sensibles 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 manière dont la protection des données sensibles transforme les résultats, vous pouvez fournir des modèles d'anonymisation pour les types de fichiers suivants:

  • Fichiers non structurés, tels que 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 la section Remplacement d'un infoType.
  • Dans les images, la protection des données sensibles recouvre tous les résultats d'une zone 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 pendant que la protection des données sensibles l'inspecte. Il ne modifie ni ne supprime pas 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 la protection des données sensibles 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 des limites de recherche

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 la protection des données sensibles analyse et anonymise. Autrement dit, 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.

Obligation d'inspecter les données

Lorsque vous exécutez votre tâche d'inspection, Sensitive Data Protection inspecte d'abord les données, conformément à votre configuration d'inspection, avant d'effectuer l'anonymisation. Il ne peut pas ignorer le processus d'inspection.

Obligation 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 de votre répertoire d'entrée. Il est possible que cette fonctionnalité ne désidentifie pas les fichiers qui ne comportent pas d'extension, même s'ils sont de types compatibles.

Fichiers ignorés

Lorsque vous anonymisez des fichiers stockés, la protection des données sensibles ignore les fichiers suivants:

  • Fichiers de plus de 60 000 ko Si vous disposez de fichiers volumineux qui dépassent cette limite, envisagez de les scinder en plusieurs parties.
  • Fichiers de types non acceptés. Pour obtenir la liste des types de fichiers compatibles, consultez la section Types de fichiers compatibles sur cette page.
  • Types de fichiers que vous avez intentionnellement 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_transform de l'action Deidentify de votre DlpJob sont ignorés.
  • Fichiers pour lesquels des erreurs de transformation se sont produites.

Ordre des lignes de sortie dans les tables anonymisées

Rien ne garantit que l'ordre des lignes d'une table anonymisée correspond à celui de la table d'origine. Si vous souhaitez comparer la table d'origine à la table anonymisée, vous ne pouvez pas vous fier au numéro de ligne pour identifier les lignes correspondantes. Si vous souhaitez comparer les lignes des tables, 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. Indiquez ensuite cette clé dans votre modèle d'anonymisation. Les clés temporaires (brutes) ne sont pas acceptées.

Étape suivante