הכללה היא תהליך שבו לוקחים ערך מזהה והופכים אותו לערך כללי יותר, שפחות מזהה. הכללה מנסה לשמר את התועלת של הנתונים תוך צמצום היכולת לזהות את הנתונים.
יכולות להיות רמות רבות של הכללה, בהתאם לסוג הנתונים. כדי למדוד את מידת ההכללה הנדרשת בקבוצת נתונים או באוכלוסייה בעולם האמיתי, אפשר להשתמש בטכניקות כמו אלה שכלולות בניתוח הסיכונים של Sensitive Data Protection.
אחת מהשיטות הנפוצות להכללה שנתמכות ב-Sensitive Data Protection היא חלוקה לקטגוריות. כשמשתמשים בחלוקה לקטגוריות, מקבצים רשומות לקטגוריות קטנות יותר כדי לנסות לצמצם את הסיכון שתוקף ישייך מידע רגיש לפרטים אישיים מזהים. כך אפשר לשמור על המשמעות והתועלת, אבל גם להסתיר את הערכים הנפרדים שיש בהם מעט מדי משתתפים.
מתי כדאי להשתמש בהכללה ובחלוקה לקטגוריות
הנה כמה תרחישי שימוש נפוצים:
- הסתרת ערכים חריגים מספריים במערכי נתונים אנליטיים: מקבצים ערכים מספריים נדירים (כמו משכורות קיצוניות, דירוגי אשראי או גודלי עסקאות) לטווחים רחבים יותר כדי למנוע זיהוי מחדש של אנשים פרטיים.
- שמירה על התועלת הסטטיסטית במחקר דמוגרפי: החלפת מזהים מדויקים של גיל, הכנסה או מיקום גיאוגרפי במרווחים קטגוריים כדי לתמוך במודלים אנליטיים רחבים בלי לחשוף ערכים נפרדים של אנשים פרטיים.
- הפחתת הייחודיות של מזהים חלקיים לצורך אנונימיות-k: הכללה של מאפיינים מזהים חלקיים בשורות, כך שכל שילוב ייחודי משותף לקבוצה גדולה מספיק של אנשים.
- הסרת תוכן זדוני או רגיש מקבוצות נתונים של דיווח חיצוני: הפכו מדדי לקוחות מפורטים לרמות כלליות (כמו "נמוך", "בינוני" ו "גבוה") לפני שאתם משתפים דוחות עם ספקים חיצוניים או עם קהלים ציבוריים.
תרחיש 1 של חלוקה לקטגוריות
נניח שיש לנו תרחיש של חלוקה מספרית לקטגוריות: מסד נתונים שמאחסן את ציוני שביעות הרצון של המשתמשים, בטווח שבין 0 ל-100. מסד הנתונים נראה בערך כך:
| user_id | ציון |
|---|---|
| 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 הזה בבקשה ל-method 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 ליצירת קטגוריות
אפשר להשתמש בחלוקה לקטגוריות גם במחרוזות או בערכים ממוספרים. נניח שאתם רוצים לשתף נתוני שכר ולכלול את תיאורי המשרות. עם זאת, יש תפקידים, כמו מנכ"ל או מהנדס בכיר, שאפשר לקשר לאדם אחד או לקבוצה קטנה של אנשים. קל להתאים בין תפקידים כאלה לבין העובדים שממלאים אותם.
גם כאן, חלוקה לקטגוריות יכולה לעזור. במקום לכלול שמות מדויקים של משרות, הכלילו וקבצו אותם. לדוגמה, "מהנדס בכיר", "מהנדס זוטר" ו "מהנדס מצטיין" הופכים למונח כללי ומקובצים פשוט תחת "מהנדס". בטבלה הבאה מוצגות קבוצות של תפקידים ספציפיים שמשויכים לקטגוריות של תפקידים.

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