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 :

user_id date action
1 2009-06-09 run
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 date_year action
1 2009 run
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 run
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 la section "Protection des données sensibles"

Voici un objet JSON permettant de configurer ce paramètre pour la méthode content.deidentify de la protection des données sensibles:

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 l'anonymisation des données à l'aide du changement de date et d'autres méthodes de protection des données sensibles, consultez les pages suivantes:

Pour obtenir des informations de référence de l'API sur les transformations primitives dans la protection des données sensibles, consultez les pages suivantes:

  • Objet DeidentifyConfig : objet dans lequel vous configurez les options d'anonymisation.
  • Objet PrimitiveTransformations: le changement de date est une "transformation primitive" dans la protection des données sensibles.
  • Objet DateShiftConfig : objet permettant de configurer l'objet PrimitiveTransformations. En spécifiant l'objet DateShiftConfig, vous pouvez décaler les dates d'un nombre de jours aléatoire.