날짜 이동

날짜는 매우 일반적인 데이터 유형입니다. 날짜가 민감한 정보나 개인 식별 정보(PII)로 간주될 수 있는 경우 날짜를 일반화, 난독화 또는 수정해야 할 수 있습니다.

이를 위한 한 가지 방법은 일반화 또는 버케팅입니다. 사용 사례 및 구성에 따라 버케팅을 사용할 경우 날짜의 유용성이 사라질 수 있습니다. 예를 들어 모든 날짜를 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의 날짜 이동 크기는 각기 다릅니다.

민감한 정보 보호에서 날짜 이동

민감한 정보 보호 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도 사용되었습니다. 이는 pseudonymization에 사용되는 방법과 비슷합니다. 키는 여러 요청 또는 데이터 실행에 걸쳐 이러한 날짜 이동의 무결성을 유지할 수 있게 해줍니다.

리소스

민감한 정보 보호에서 데이터 이동과 다른 방법을 사용하여 데이터를 익명화하는 방법은 다음을 참조하세요.

민감한 정보 보호의 기본 변환에 대한 API 참조 정보는 다음을 확인하세요.