날짜는 매우 일반적인 데이터 유형입니다. 날짜가 민감한 정보나 개인 식별 정보(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 참조 정보는 다음을 확인하세요.
DeidentifyConfig
객체: 익명화 옵션을 구성하는 객체PrimitiveTransformations
객체: 날짜 이동은 민감한 정보 보호의 '기본 변환'입니다.DateShiftConfig
객체:PrimitiveTransformations
객체를 구성하는 데 사용되는 객체DateShiftConfig
객체를 지정하면 무작위 날짜 수만큼 날짜를 이동할 수 있습니다.