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.
Déplacement de date dans Sensitive Data Protection
Voici un exemple d'objet JSON permettant de configurer le changement de date 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 la suppression de l'identification des données à l'aide du changement de date et d'autres méthodes dans la protection des données sensibles, consultez les pages suivantes:
Pour obtenir des informations de référence sur les transformations primitives dans la protection des données sensibles, consultez les ressources 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'objetPrimitiveTransformations
. En spécifiant l'objetDateShiftConfig
, vous pouvez décaler les dates d'un nombre de jours aléatoire.