שינוי התאריך

תאריכים הם סוג נפוץ מאוד של נתונים. במקרים שבהם תאריכים יכולים להיחשב כמידע אישי רגיש או כפרטים אישיים מזהים (PII), יכול להיות שתצטרכו להכליל, לטשטש או לצנזר אותם.

שיטה אחת לעשות זאת היא הכללה או חלוקה לקטגוריות. עם זאת, בהתאם לתרחיש לדוגמה ולהגדרה, חלוקה לקטגוריות יכולה להסיר את התועלת שבתאריכים. לדוגמה, אם מכלילים את כל התאריכים לשנה בלבד, יכול להיות שהסדר שבו האירועים מתרחשים באותה שנה יאבד. שיטה חלופית לטשטוש תאריכים שפותרת את הבעיה הזו היא הזזת תאריכים.

בשיטות של שינוי תאריכים, קבוצה של תאריכים משתנה באופן אקראי, אבל הרצף ומשך הזמן נשמרים. הזזת תאריכים מתבצעת בדרך כלל בהקשר של אדם פרטי או ישות. כלומר, התאריכים של כל אדם מוזזים בפרק זמן ייחודי לאותו אדם.

מתי כדאי להשתמש בשינוי תאריכים

הנה כמה תרחישי שימוש נפוצים:

  • שמירה על פרטיות המטופלים במחקר בתחום הבריאות: הסתרת תאריכי הקבלה והשחרור של המטופלים כדי לעמוד בדרישות של HIPAA Safe Harbor להסרת פרטי הזיהוי, תוך שמירה על מרווחי הזמן בין האירועים.
  • הסרת תוכן זדוני או רגיש מיומני ביקורת וטרנזקציות: הסתרת תאריכי טרנזקציות מוחלטים כשמכינים מסדי נתונים לבדיקה, תוך שמירה על סדר האירועים היחסי שנדרש לאימות תהליכי עבודה באצווה.
  • ניתוח קבוצות משתמשים לשימור: אנונימיזציה של חותמות הזמן של פעילות הלקוחות לצורך ניתוח קבוצות משתמשים, תוך שמירה על מגמות כרונולוגיות לאורך ימים או חודשים.
  • שמירה על רצפי אירועים במחקרים ארוכי טווח: הגנה על הפרטיות של אנשים במחקרי מעקב רב-שנתיים על ידי שינוי חותמות הזמן באופן אחיד לכל משתתף, בלי לעוות את הקשרים הסיבתיים או הכרונולוגיים.

דוגמה לשינוי תאריכים

לדוגמה, נניח שיש לכם את הנתונים הבאים:

user_id תאריך פעולה
1 2009-06-09 הפעלה
1 2009-06-03 הליכה
1 2009-05-23 לסרוק
2 2010-11-03 לסרוק
2 2010-11-22 הליכה
... ... ...

אם תכלילו את התאריכים האלה לפי שנה, הפלט יהיה:

user_id date_year פעולה
1 2009 הפעלה
1 2009 הליכה
1 2009 לסרוק
2 2010 לסרוק
2 2010 הליכה
... ... ...

עם זאת, הרצף הכרונולוגי של האירועים של כל משתמש אובד.

במקום זאת, נסו להזיז את התאריכים:

user_id תאריך פעולה
1 2009-07-17 הפעלה
1 2009-07-11 הליכה
1 2009-06-30 לסרוק
2 2011-01-26 לסרוק
2 2011-02-14 הליכה
... ... ...

שימו לב שהתאריכים שונים, אבל הרצף ומשך הזמן נשמרים. התאריכים הוזזו במידה שונה בין user_id 1 ל- 2.

הזזת תאריכים ב-Sensitive Data Protection

אובייקט JSON להגדרת השיטה content.deidentify של Sensitive Data Protection:

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 מופיע. השימוש הזה דומה לשימוש בפסאודונימיזציה. המפתח יאפשר לכם לשמור על העקביות של שינויי התאריכים האלה בכמה בקשות או הרצות של נתונים.

משאבים

למידע נוסף על הסרת פרטי הזיהוי באמצעות הזזת תאריכים ושיטות אחרות ב-Sensitive Data Protection:

למידע על טרנספורמציות פרימיטיביות ב-Sensitive Data Protection, עיינו במאמרי העזרה של ה-API:

  • האובייקט DeidentifyConfig: האובייקט שבו מגדירים את האפשרויות להסרת פרטים מזהים.
  • PrimitiveTransformations ‎: הזזת תאריכים היא "טרנספורמציה פרימיטיבית" ב-Sensitive Data Protection.
  • DateShiftConfig object: אובייקט שבאמצעותו מגדירים את האובייקט PrimitiveTransformations. אם מציינים את האובייקט DateShiftConfig, אפשר להזיז את התאריכים במספר אקראי של ימים.