日付は、広く使用されているデータの種類です。日付がセンシティブ データや個人情報(PII)とみなされる場合は、一般化または難読化するか、削除する必要があります。
これを行うための 1 つの方法が一般化またはバケット化です。ただし、使用方法や構成によっては、バケット化によって日付から有用性が失われる場合があります。たとえば、すべての日付を 1 年に一般化すると、その年に発生したイベントの順序が失われます。日付を難読化してこの問題に対処する別の方法が日付シフトです。
日付シフト手法では、日付のセットがランダムにシフトされますが、期間の順序と持続時間は保持されます。通常、日付シフトは、個人またはエンティティのコンテキストで使用されます。つまり、各個人の日付は、その個人に固有の時間だけシフトされます。
日付シフトの例
次のようなデータがあるとします。
user_id | date | action |
---|---|---|
1 | 2009-06-09 | run |
1 | 2009-06-03 | walk |
1 | 2009-05-23 | crawl |
2 | 2010-11-03 | crawl |
2 | 2010-11-22 | walk |
… | … | … |
この日付を年に一般化すると、次のようになります。
user_id | date_year | action |
---|---|---|
1 | 2009 | run |
1 | 2009 | walk |
1 | 2009 | crawl |
2 | 2010 | crawl |
2 | 2010 | walk |
… | … | … |
しかし、これではユーザーごとの順序がわからなくなります。
代わりに、日付を変更してみましょう。
user_id | date | action |
---|---|---|
1 | 2009-07-17 | run |
1 | 2009-07-11 | walk |
1 | 2009-06-30 | crawl |
2 | 2011-01-26 | crawl |
2 | 2011-02-14 | walk |
… | … | … |
日付は変わりましたが、順序と持続時間は保持されていることに注目してください。日付がシフトされた量は user_id
1 と 2 で異なります。
Sensitive Data Protection での日付のずれ
Sensitive Data Protection の content.deidentify
メソッド用に構成する JSON オブジェクトは、以下のとおりです。
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"
}
}
}
}
}
}
}
シフトの上限と下限はそれぞれ upper_bound_days
と lower_bound_days
の値で指定されます。このシフトが適用されるコンテキストまたはスコープは、entity_id_field
の値(この場合は "user_id"
)に基づきます。
crypto_key
が使用されていることにも注意してください。これは、仮名化での使用方法に似ています。このキーを使用すると、これらの日付シフトの整合性を複数のリクエストまたはデータ実行間で保つことができます
関連情報
機密データの保護で日付シフトとその他のメソッドを使用してデータを匿名化する方法の詳細については、以下をご覧ください。
機密データの保護のプリミティブ変換に関する API リファレンス情報については、以下をご覧ください。
DeidentifyConfig
オブジェクト: 匿名化オプションを構成するオブジェクト。PrimitiveTransformations
オブジェクト: 日付シフトは機密データの保護の「プリミティブ変換」です。DateShiftConfig
オブジェクト:PrimitiveTransformations
オブジェクトを構成するオブジェクト。DateShiftConfig
オブジェクトを指定することで、日付をランダムな日数だけシフトできます。