Changer la date

Les dates représentent un type de données très commun. Lorsqu'elles peuvent être considérées comme des données sensibles ou des informations personnelles, il est possible que vous deviez les généraliser, les obscurcir ou les masquer.

Pour effectuer cette action, vous pouvez recourir à la généralisation (ou binning). Néanmoins, en fonction du cas d'utilisation et de la configuration, le binning peut rendre les dates inutiles. Par exemple, si vous généralisez toutes les dates à une seule année, vous risquez de perdre l'ordre dans lequel se produisent les événements au cours de cette année. Le changement de date est une méthode alternative qui permet de contourner ce problème.

Les techniques de changement de date modifient un ensemble de dates de manière aléatoire, tout en préservant la séquence et la durée d'une période. Le changement de date s'effectue généralement dans le contexte d'un individu ou d'une entité. Autrement dit, les dates liées à chaque individu sont modifiées à l'aide d'un intervalle de temps unique à cet individu.

Exemple de changement de date

Examinez les données suivantes :

ID_utilisateur date action
1 2009-06-09 courir
1 2009-06-03 marcher
1 2009-05-23 ramper
2 2010-11-03 ramper
2 2010-11-22 marcher

En généralisant ces dates à l'année, nous obtenons :

user_id année action
1 2009 courir
1 2009 marcher
1 2009 ramper
2 2010 ramper
2 2010 marcher

Ici, nous avons toutefois perdu toute idée de séquence par utilisateur.

Essayons plutôt de modifier les dates :

user_id date action
1 2009-07-17 courir
1 2009-07-11 marcher
1 2009-06-30 ramper
2 2011-01-26 ramper
2 2011-02-14 marcher

Vous noterez que les dates sont différentes, mais que la séquence et la durée sont préservées. L'ampleur du changement de date n'est pas non plus la même pour les ID user_id 1 et 2.

Changement de date dans Cloud DLP

Voici un exemple d'objet JSON permettant de configurer le changement de date pour la méthode content.deidentify de Cloud DLP.

deidentify_config {
  record_transformations {
    field_transformations {
      fields {
        name: "date"
      }
      primitive_transformation {
        date_shift_config {
          upper_bound_days: 100
          lower_bound_days: -100
          entity_field_id {
            name: "user_id"
          }
          crypto_key {
            unwrapped {
              key: "123456789012345678901234567890ab"
            }
          }
        }
      }
    }
  }
}

Les limites supérieure et inférieure du changement de date sont respectivement spécifiées par les valeurs upper_bound_days et lower_bound_days. Le contexte ou le champ d'application auquel le changement s'applique est basé sur la valeur entity_id_field, qui correspond à "user_id" dans cet exemple.

Notez également qu'une clé de chiffrement (crypto_key) a été utilisée. Son rôle est comparable à celui qu'elle joue dans la pseudonymisation. La clé vous permet de préserver l'intégrité de ces changements de date entre plusieurs requêtes ou exécutions de données.

Ressources

Pour en savoir plus sur la suppression de l'identification des données à l'aide du changement de date et d'autres méthodes dans Cloud DLP, consultez la page suivante :

Pour obtenir des informations de référence sur les transformations primitives dans Cloud DLP, consultez les ressources suivantes :