日期轉移

日期是很常見且實用的資料類型。然而,在某些情況下,需要將日期加以一般化、模糊處理或予以遮蓋。執行相關動作的一種方法就是採用一般化或特徵分塊。另一種方法就是「日期轉移」。要採取何種做法要視用途與設定而定,但採取特徵分塊會將日期中的功用移除。例如,如果將所有日期一般化,只以年來表示,事件發生的順序便會消失不見。如需解決這個問題,對日期進行模糊處理的替代方法就是「日期轉移」

日期轉移的做法是隨機將一組日期加以移動,但其中仍保留日期的順序和持續時間的長短。日期的轉移通常是依個人或實體來達成。也就是說,您會想要透過相同的轉移差異來轉移特定個人的所有日期,但會對個人之間使用的轉移差異加以區隔。

日期轉移範例

請考慮使用下列的資料:

user_id 日期 動作
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 動作
1 2009 run
1 2009 walk
1 2009 crawl
2 2010 crawl
2 2010 walk

現在我們已失去日期順序對每位使用者所代表的意義。

因此我們會改為使用日期轉移:

user_id 日期 動作
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 和 user_id 2 這兩位使用者在日期轉移幅度上有差異。

在 Cloud DLP 中轉移日期

要使用 Cloud DLP API 進行設定,操作方式大致如下:

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: "id"
          }
          crypto_key {
            unwrapped {
              key: "123456789012345678901234567890ab"
            }
          }
        }
      }
    }
  }
}

日期轉移範圍的上限和下限分別由 upper_bound_dayslower_bound_days 的值指定。日期轉移所適用的狀況或範圍是根據 entity_id_field 的值來決定,而在上述狀況下,日期轉移則是由 "user_id" 的值定義。

請留意,這裡也是使用 crypto_key,做法類似在匿名化中用到的方法。這個金鑰會讓您在多個要求或資料執行作業之間,保有這些日期轉移的完整性。

資源

如要進一步瞭解如何使用日期轉移和其他 Cloud DLP 的方法來將資料去識別化,請參閱:

如需關於 Cloud DLP API 中進行原始轉換作業的 API 參考資訊,請參閱:

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Data Loss Prevention