日付シフト

日付は、広く使用されているデータの種類です。日付がセンシティブ データや個人情報（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 オブジェクトを指定することで、日付をランダムな日数だけシフトできます。