הכללה היא תהליך של לקיחת ערך מבחין והפיכתו לערך כללי יותר, פחות מבחין. הכללה מנסה לשמור על השימושיות של הנתונים וגם לצמצם את האפשרות לזהות את הנתונים.
יכולות להיות הרבה רמות של הכללה, בהתאם לסוג הנתונים. כדי לדעת כמה הכללה נדרשת, אפשר להשתמש בטכניקות כמו אלה שכלולות בניתוח הסיכונים של Sensitive Data Protection כדי למדוד את ההכללה במערך נתונים או באוכלוסייה בעולם האמיתי.
אחת מטכניקות ההכללה הנפוצות ששירות Sensitive Data Protection תומך בהן היא חלוקה לקטגוריות. באמצעות bucketing, מקבצים רשומות לקטגוריות קטנות יותר בניסיון לצמצם את הסיכון לכך שתוקף ישייך מידע רגיש לפרטים אישיים מזהים. הפעולה הזו יכולה לשמור על המשמעות והתועלת של הנתונים, אבל היא גם תסתיר את הערכים האישיים שיש להם מעט מדי משתתפים.
מתי כדאי להשתמש בהכללה ובסיווג לקטגוריות
הנה כמה תרחישי שימוש נפוצים:
- הסתרת ערכים מספריים חריגים במערכי נתונים אנליטיים: קיבוץ ערכים מספריים נדירים (כמו משכורות גבוהות במיוחד, דירוג אשראי או גדלים של עסקאות) לטווחים רחבים יותר כדי למנוע זיהוי מחדש של אנשים פרטיים.
- שמירה על התועלת הסטטיסטית במחקר דמוגרפי: החלפת מזהים מדויקים של גיל, הכנסה או מיקום גיאוגרפי במרווחים קטגוריים כדי לתמוך במודלים אנליטיים רחבים בלי לחשוף ערכים נפרדים של פרטים אישיים.
- צמצום הייחודיות של מזהים למחצה לצורך שמירה על k-anonymity: הכללה של מאפיינים שהם מזהים למחצה בשורות, כך שכל שילוב ייחודי יהיה משותף לקבוצה גדולה מספיק של אנשים.
- ניקוי של מערכי נתונים חיצוניים של דוחות: המרת מדדים מפורטים של לקוחות לרמות גבוהות (כמו 'נמוך', 'בינוני' ו'גבוה') לפני שמשתפים דוחות עם ספקים חיצוניים או עם קהלים ציבוריים.
תרחיש 1 של חלוקה לקטגוריות
נניח שיש מסד נתונים שבו מאוחסנים ציוני שביעות רצון של משתמשים, בטווח של 0 עד 100. מסד הנתונים ייראה בערך כך:
| user_id | score |
|---|---|
| 1 | 100 |
| 2 | 100 |
| 3 | 92 |
| ... | ... |
כשמעיינים בנתונים, מבינים שמשתמשים בחלק מהערכים לעיתים רחוקות. למעשה, יש כמה ציונים שממופים רק למשתמש אחד. לדוגמה, רוב המשתמשים בוחרים באחת מהאפשרויות הבאות: 0, 25, 50, 75 או 100. עם זאת, חמישה משתמשים בחרו ב-95, ורק משתמש אחד בחר ב-92. במקום לשמור את הנתונים הגולמיים, אפשר להכליל את הערכים האלה לקבוצות ולמנוע מצב שבו יש קבוצות עם מעט מדי משתתפים. בהתאם לאופן השימוש בנתונים, הכללה של נתונים באופן הזה יכולה לעזור למנוע זיהוי מחדש.
אפשר להסיר את השורות האלה של נתוני חריגים, או לנסות לשמור על התועלת שלהן באמצעות חלוקה לקטגוריות. בדוגמה הזו, נחלק את כל הערכים לקטגוריות לפי הקריטריונים הבאים:
- 0-25: 'נמוך'
- 26-75: 'בינוני'
- 76-100: 'גבוה'
הקטגוריות ב-Sensitive Data Protection הן אחת מתוך הרבה טרנספורמציות פרימיטיביות שזמינות לביטול הזיהוי. ההגדרה הבאה בפורמט JSON ממחישה איך להטמיע את תרחיש ההצבה בדלי הזה ב-DLP API. אפשר לכלול את ה-JSON הזה בבקשה לשיטה content.deidentify:
C#
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Go
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Java
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Node.js
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
PHP
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Python
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
REST
...
{
"primitiveTransformation":
{
"bucketingConfig":
{
"buckets":
[
{
"min":
{
"integerValue": "0"
},
"max":
{
"integerValue": "25"
},
"replacementValue":
{
"stringValue": "Low"
}
},
{
"min":
{
"integerValue": "26"
},
"max":
{
"integerValue": "75"
},
"replacementValue":
{
"stringValue": "Medium"
}
},
{
"min":
{
"integerValue": "76"
},
"max":
{
"integerValue": "100"
},
"replacementValue":
{
"stringValue": "High"
}
}
]
}
}
}
...
תרחיש 2 ליצירת קטגוריות
אפשר להשתמש בקיבוץ למשפחות גם במחרוזות או בערכים ממוספרים. נניח שרוצים לשתף נתוני שכר ולכלול שמות תפקידים. עם זאת, יש תפקידים, כמו מנכ"ל או מהנדס בכיר, שאפשר לקשר לאדם אחד או לקבוצה קטנה של אנשים. קל להתאים את תפקידי העובדים האלה לעובדים שמחזיקים בהם.
גם כאן יכולה לעזור חלוקה לקטגוריות. במקום לכלול שמות משרה מדויקים, אפשר להכליל אותם ולחלק אותם לקטגוריות. לדוגמה, התפקידים 'מהנדס בכיר', 'מהנדס זוטר' ו'מהנדס מצטיין' הופכים לכלליים יותר ומקובצים יחד לתפקיד 'מהנדס'. בטבלה הבאה מוצגות דוגמאות לסיווג של תפקידים ספציפיים לקטגוריות של תפקידים.

תרחישים אחרים
בדוגמאות האלה, ביצענו את ההמרה על נתונים מובְנים. אפשר להשתמש בשיטת ה-Bucketing גם בדוגמאות לא מובְנות, כל עוד אפשר לסווג את הערך באמצעות סוג מידע מוגדר מראש או מותאם אישית. הנה כמה דוגמאות לתרחישים:
- סיווג תאריכים והכנסה שלהם לקטגוריות לפי טווחי שנים
- סיווג שמות והכנסתם לקבוצות על סמך האות הראשונה (א-מ, נ-ת)
משאבים
מידע נוסף על הכללה ועל חלוקה לקטגוריות זמין במאמר בנושא הסרת פרטים מזהים מתוכן טקסט רגיש.
מסמכי התיעוד של ה-API:
projects.content.deidentifymethodBucketingConfigטרנספורמציה: קיבוץ ערכים לפי טווחים מותאמים אישית.-
FixedSizeBucketingConfigטרנספורמציה: קיבוץ ערכים לפי טווחים בגודל קבוע.