פסאודונימיזציה

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

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

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

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

להוראות כיצד ליישם שיטות פסאודומניזציה אלו ולדוגמאות נוספות לשימוש ב-Sensitive Data Protection, ראו הסרת מזהה של נתונים רגישים.

שיטות קריפטוגרפיות נתמכות ב-Sensitive Data Protection

הכלי Sensitive Data Protection תומך בשלוש טכניקות של פסאודונימיזציה, שכולן משתמשות במפתחות קריפטוגרפיים. להלן השיטות הזמינות:

• הצפנה דטרמיניסטית באמצעות AES-SIV: ערך קלט מוחלף בערך שהוצפן באמצעות אלגוריתם ההצפנה AES-SIV עם מפתח קריפטוגרפי, מקודד באמצעות base64, ולאחר מכן מוסיף לו ביאור חלופי, אם צוין. שיטה זו מייצרת ערך מגובב, כך שהיא אינה שומרת על ערכת התווים או על אורך ערך הקלט. ניתן לשחזר פרטי זיהוי של ערכים מוצפנים ומגובבים באמצעות המפתח הקריפטוגרפי המקורי וערך הפלט כולו, כולל אנוטציית ממלא מקום. למידע נוסף על פורמט הערכים שעברו אסימונים באמצעות הצפנת AES-SIV.
• הצפנה לשימור פורמט: ערך קלט מוחלף בערך שהוצפן באמצעות אלגוריתם ההצפנה FPE-FFX עם מפתח קריפטוגרפי, ולאחר מכן מוסיף לו ביאור חלופי, אם צוין. כברירת מחדל, גם קבוצת התווים וגם האורך של ערך הקלט נשמרים בערך הפלט. אפשר לשחזר פרטי זיהוי של ערכים מוצפנים באמצעות מפתח קריפטוגרפי מקורי וערך הפלט המלא, כולל אנוטציית ממלא המקום. (בקטע הצפנה ששומרת על הפורמט בהמשך הנושא הזה מפורטים כמה שיקולים חשובים לגבי השימוש בשיטת ההצפנה הזו).
• גיבוב קריפטוגרפי: ערך קלט מוחלף בערך שהוצפן ועבר גיבוב באמצעות HMAC (Hash-based Message Authentication Code)-Secure Hash Algorithm (SHA)-256 על ערך הקלט באמצעות מפתח קריפטוגרפי. הפלט המגובב של הטרנספורמציה הוא תמיד באותו אורך ולא ניתן לזהותו מחדש. למידע נוסף על פורמט של ערכים שעברו טוקניקציה באמצעות גיבוב קריפטוגרפי.

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

	הצפנה דטרמיניסטית באמצעות AES-SIV	הצפנה ששומרת על הפורמט	גיבוב קריפטוגרפי
סוג ההצפנה	AES-SIV	FPE-FFX	‫HMAC-SHA-256
ערכי קלט נתמכים	לפחות תו אחד; אין מגבלות על ערכת התווים.	האורך המינימלי הוא 2 תווים, והקידוד חייב להיות ASCII.	הערך חייב להיות מחרוזת או מספר שלם.
אנוטציית Surrogate	זה שינוי אופציונלי.	זה שינוי אופציונלי.	לא רלוונטי
שינוי ההקשר	זה שינוי אופציונלי.	זה שינוי אופציונלי.	לא רלוונטי
שמירה על ערכת התווים והאורך	✗	✓	✗
הפיך	✓	✓	✗
שלמות רפרנציאלית	✓	✓	✓

• סוג הצפנה: סוג ההצפנה המשמשת בטרנספורמציה להסרת זיהוי.
• ערכי קלט נתמכים: דרישות מינימליות לערכי קלט.
• הערת placeholder: הערה שמוגדרת על ידי המשתמש ומוצגת לפני ערכים מוצפנים כדי לספק הקשר למשתמשים ומידע לשירות Sensitive Data Protection לשימוש בזיהוי מחדש של ערך שעבר הסרת פרטים מזהים. כדי לבצע זיהוי מחדש של נתונים לא מובְנים, צריך להשתמש בהערה חלופית. זה אופציונלי בעת שינוי עמודה של נתונים מובנים, או טבלאיים, עםRecordTransformation.
• שינוי הקשר: הפניה לשדה נתונים ש "משנה" את ערך הקלט כך שניתן יהיה לבטל את הזיהוי של ערכי קלט זהים לערכי פלט שונים. התאמת ההקשר היא אופציונלית כשמבצעים טרנספורמציה בעמודה של נתונים מובנים או טבלאיים באמצעות RecordTransformation. מידע נוסף זמין במאמר שימוש בשינויים בהקשר.
• קבוצת תווים ואורך שנשמרו: האם ערך שאינו מזוהה מורכב מאותה קבוצת תווים כמו הערך המקורי, והאם אורך הערך שאינו מזוהה תואם את אורך הערך המקורי שלו.
• הפיך: ניתן לזהות מחדש באמצעות המפתח הקריפטוגרפי, ביאור חלופי וכל שינוי הקשר.
• שלמות רפרנציאלית: שלמות רפרנציאלית מאפשרת לרשומות לשמור על הקשר ביניהן גם אחרי שהנתונים שלהן עברו הסרת פרטים מזהים. אם משתמשים באותו מפתח הצפנה ובאותו שינוי בהקשר, טבלת נתונים תוחלף באותו פורמט מוסתר בכל פעם שהיא תעבור המרה. כך מובטח שהקשרים בין הערכים (ובנתונים מובְנים, בין הרשומות) יישמרו, גם בין טבלאות שונות.

איך טוקניזציה פועלת ב-Sensitive Data Protection

התהליך הבסיסי של טוקניזציה זהה לכל שלוש השיטות שנתמכות על ידי Sensitive Data Protection.

שלב 1: Sensitive Data Protection בוחר נתונים להמרת טוקנים. הדרך הנפוצה ביותר לעשות את זה היא להשתמש בגלאי מסוג מידע מובנה או מותאם אישית כדי להתאים לערכי הנתונים הרגישים הרצויים. אם אתם סורקים נתונים מובנים (כגון טבלה ב-BigQuery), תוכלו גם לבצע טוקניזציה על עמודות נתונים שלמות באמצעות טרנספורמציות רשומות.

מידע נוסף על שתי הקטגוריות של טרנספורמציות – infoType וטרנספורמציות של רשומות – זמין במאמר טרנספורמציות של הסרת פרטים מזהים.

שלב 2: באמצעות מפתח קריפטוגרפי, Sensitive Data Protection מצפין כל ערך קלט. ניתן לספק מפתח זה באחת משלוש דרכים:

• על ידי עטיפתו באמצעות שירות ניהול מפתחות בענן (Cloud KMS). (לשמירה על רמת אבטחה מקסימלית, מומלץ להשתמש ב-Cloud KMS).
• באמצעות מפתח זמני, ש-Sensitive Data Protection יוצרת בזמן הסרת הפרטים המזהים ואז משליכה אותו. מפתח חולף שומר על שלמות רק לפי בקשת API. אם אתם צריכים לשמור על שלמות הנתונים או מתכננים לשחזר פרטי זיהוי של הנתונים האלה, אל תשתמשו בסוג המפתח הזה.
• ישירות בטופס טקסט גולמי. (לא מומלץ).

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

שלב 3 (גיבוב קריפטוגרפי והצפנה דטרמיניסטית עם AES-SIV בלבד): Sensitive Data Protection מקודדת את הערך המוצפן באמצעות base64. בגיבוב קריפטוגרפי, הערך המוצפן והמקודד הזה הוא האסימון, והתהליך ממשיך לשלב 6. בהצפנה דטרמיניסטית באמצעות AES-SIV, הערך המוצפן המקודד הזה הוא ערך הסרוגייט, שהוא רק רכיב אחד של הטוקן. התהליך ממשיך עם שלב 4.

שלב 4 (הצפנה דטרמיניסטית ושמירה על הפורמט באמצעות AES-SIV בלבד): ‫Sensitive Data Protection מוסיף הערת סורוגט אופציונלית לערך המוצפן. ההערה המחליפה עוזרת לזהות ערכים מחליפים מוצפנים על ידי הוספת מחרוזת תיאורית שאתם מגדירים לפני הערכים. לדוגמה, בלי הערה לא תוכלו להבדיל בין מספר טלפון שעבר הסרת פרטים מזהים לבין מספר תעודת זהות או מספר מזהה אחר שעבר הסרת פרטים מזהים. בנוסף, כדי לשחזר פרטי זיהוי של ערכים בנתונים לא מובנים שעברו הסרת פרטי הזיהוי באמצעות הצפנה ששומרת על הפורמט או הצפנה דטרמיניסטית, צריך לציין אנוטציה של החלפה. (אין צורך בהערות חלופיות כשמבצעים טרנספורמציה בעמודה של נתונים מובְנים או טבלאיים באמצעות RecordTransformation).

שלב 5 (שימור פורמט והצפנה דטרמיניסטית עם AES-SIV של נתונים מובנים בלבד): Sensitive Data Protection יכולה להשתמש בהקשר אופציונלי משדה אחר כדי "לכוונן" את האסימון שנוצר. כך תוכלו לשנות את היקף האסימון. לדוגמה, נניח שיש לכם מסד נתונים של נתוני קמפיינים שיווקיים שכולל כתובות אימייל, ואתם רוצים ליצור טוקנים ייחודיים לאותה כתובת אימייל, עם שינוי קל לפי מזהה הקמפיין. הפעולה הזו תאפשר למישהו לצרף נתונים של אותו משתמש באותו קמפיין, אבל לא בקמפיינים שונים. אם נעשה שימוש בשינוי הקשר כדי ליצור את האסימון, נדרש גם שינוי הקשר הזה כדי לבטל את השינויים של הסרת הפרטים המזהים. הצפנה דטרמיניסטית ששומרת על הפורמט באמצעות תמיכה בהקשרים של AES-SIV. מידע נוסף על שימוש בשינויים בהקשר

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

שלב 6: Sensitive Data Protection מחליפה את הערך המקורי בערך שעבר הסרת פרטים מזהים.

השוואת ערך אסימונית

סעיף זה מדגים כיצד נראים אסימונים אופייניים לאחר ביטול הזיהוי באמצעות כל אחת משלוש השיטות הנדונות בנושא זה. דוגמה לערך של נתונים רגישים היא מספר טלפון בצפון אמריקה (1-206-555-0123).

הצפנה דטרמיניסטית באמצעות AES-SIV

בשיטה להסרת פרטים מזהים באמצעות הצפנה דטרמיניסטית ו-AES-SIV, ערך קלט (ואופציונלית, כל שינוי הקשר שצוין) מוצפן באמצעות AES-SIV עם מפתח קריפטוגרפי, מקודד באמצעות base64, ואז אופציונלית מתווספת לפניו הערת סרוגייט, אם צוינה. שיטה זו אינה שומרת על קבוצת התווים (או ה "אלף-בית") של ערך הקלט. כדי ליצור פלט שניתן להדפסה, הערך שמתקבל מקודד בפורמט Base64.

האסימון שמתקבל, בהנחה שצוין infoType חלופי, הוא מהצורה הבאה:

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

הדיאגרמה המבוארת הבאה מציגה דוגמה לאסימון - הפלט של פעולת זיהוי באמצעות הצפנה דטרמיניסטית עם AES-SIV על הערך 1-206-555-0123. סוג המידע האופציונלי של הסורוגייט הוגדר ל-NAM_PHONE_NUMB:

1. הערה לגבי נתונים חלופיים
2. סוג מידע חלופי (מוגדר על ידי המשתמש)
3. מספר התווים של הערך שעבר טרנספורמציה
4. ערך חלופי (טרנספורמציה)

אם לא מציינים אנוטציית ממלא מקום, הטוקן שמתקבל שווה לערך שעבר טרנספורמציה, או ל-#4 בדיאגרמה עם האנוטציות. כדי לשחזר פרטי זיהוי נתונים לא מובנים, נדרש אסימון זה כולו, כולל ביאור החלופי. כשמבצעים טרנספורמציה של נתונים מובְנים כמו טבלה, אפשר להשתמש בהערת ה-surrogate, אבל היא לא חובה. אפשר להשתמש ב-Sensitive Data Protection כדי לבצע דה-אינדנטיפיקציה ואינדנטיפיקציה מחדש בעמודה שלמה באמצעות RecordTransformation בלי להשתמש בהערת surrogate.

הצפנה משמרת פורמט

בשיטה להסרת פרטים מזהים באמצעות הצפנה ששומרת על הפורמט, ערך קלט (ובאופן אופציונלי, כל שינוי בהקשר שצוין) מוצפן באמצעות מצב FFX של הצפנה ששומרת על הפורמט (FPE-FFX) עם מפתח קריפטוגרפי, ולאחר מכן, באופן אופציונלי, מתווספת לפניו הערת תחליף, אם צוינה כזו.

בניגוד לשיטות האחרות של טוקניזציה שמתוארות בנושא הזה, ערך הסרוגט של הפלט הוא באורך זהה לערך הקלט, והוא לא מקודד באמצעות base64. אתם מגדירים את ערכת התווים – או 'האלפבית' – שמהם מורכב הערך המוצפן. יש שלוש דרכים לציין את האלפבית ש-Sensitive Data Protection ישתמש בו בערך הפלט:

• אפשר להשתמש באחד מארבעת הערכים המנויים שמייצגים את ארבעת קבוצות התווים או האלפביתים הנפוצים ביותר.
• משתמשים בערך בסיס, שמציין את גודל האלפבית. ציון ערך הרדיקל המינימלי של 2 מביא לאלפבית המורכב מ-0 ו-1 בלבד. ציון ערך הרדיקל המקסימלי של 95 מביא לאלפבית הכולל את כל התווים המספריים, תווי אלפא גדולים, תווי אלפא קטנים ותווי סמלים.
• יוצרים אלפבית על ידי רישום התווים המדויקים שרוצים להשתמש בהם. לדוגמה, ציון 1234567890-* יביא לערך חלופי המורכב רק ממספרים, מקפים וכוכביות.

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

בנוסף, למרות שאורך הערך שעבר טרנספורמציה נשמר, בגלל היעדר אימות ווקטור אתחול, FPE מספק פחות הבטחות אבטחה בהשוואה לשיטות הצפנה דטרמיניסטיות אחרות, כמו הצפנה דטרמיניסטית עם AES-SIV.

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

שם האלפבית או מערכת התווים	Radix	רשימת הדמויות
NUMERIC	10	0123456789
HEXADECIMAL	16	0123456789ABCDEF
UPPER_CASE_ALPHA_NUMERIC	36	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
ALPHA_NUMERIC	62	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
-	95	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~`!@#$%^&*()_-+={[}]|\:;"'<,>.?/

הטוקן שמתקבל, בהנחה שצוין surrogate infoType, הוא בפורמט הבא:

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

התרשים הבא עם ההערות הוא הפלט של פעולת הסרת פרטים מזהים (de-identification) ב-Sensitive Data Protection באמצעות הצפנה ששומרת על הפורמט של הערך 1-206-555-0123 עם בסיס 95. סוג המידע החלופי האופציונלי הוגדר כ-NAM_PHONE_NUMB:

1. הערה לגבי נתונים חלופיים
2. סוג מידע חלופי (מוגדר על ידי המשתמש)
3. מספר התווים של הערך שעבר טרנספורמציה
4. ערך חלופי (טרנספורמציה) - אותו אורך כמו ערך הקלט

אם לא מציינים אנוטציית ממלא מקום, הטוקן שמתקבל שווה לערך שעבר טרנספורמציה, או ל-#4 בדיאגרמה עם האנוטציות. כדי לשחזר פרטי זיהוי נתונים לא מובנים, נדרש אסימון זה כולו, כולל ביאור החלופי. כשמבצעים טרנספורמציה של נתונים מובְנים כמו טבלה, אפשר להשתמש בהערת ה-surrogate, אבל היא לא חובה. אפשר להשתמש ב-Sensitive Data Protection כדי לבצע דה-אינדנטיפיקציה ואינדנטיפיקציה מחדש בעמודה שלמה באמצעות RecordTransformation בלי להשתמש ב-surrogate.

הערה: כברירת מחדל, FPE-FFX שומר על האורך ועל ערכת התווים של טקסט הקלט. משמעות הדבר היא שחסרים בו אימות ווקטור אתחול, מה שיגרום להרחבת אורך באסימון הפלט. שיטות אחרות כמו הצפנה דטרמיניסטית באמצעות AES-SIV מספקות את ערבויות האבטחה החזקות האלה, ומומלצות לשימוש בתרחישי טוקניזציה, אלא אם שמירה על אורך ועל ערכת תווים היא דרישה מחמירה – לדוגמה, לצורך תאימות לאחור עם מערכת נתונים מדור קודם.

גיבוב קריפטוגרפי

עם הסרת זיהוי באמצעות גיבוב קריפטוגרפי, ערך קלט עובר גיבוב באמצעות HMAC-SHA-256 עם מפתח קריפטוגרפי, ולאחר מכן מקודד באמצעות base64. הערך שעבר הסרת פרטים מזהים הוא תמיד באורך אחיד, בהתאם לגודל המפתח.

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

בהמשך מוצגת הפלט של פעולת הסרת פרטים מזהים באמצעות גיבוב קריפטוגרפי על הערך 1-206-555-0123. הפלט הזה הוא ייצוג בקידוד base64 של הערך המגובב:

XlTCv8h0GwrCZK+sS0T3Z8txByqnLLkkF4+TviXfeZY=

שימוש במפתחות קריפטוגרפיים

יש שלוש אפשרויות למפתחות קריפטוגרפיים שאפשר להשתמש בהם בשיטות הקריפטוגרפיות לביטול הזיהוי ב-Sensitive Data Protection:

• מפתח קריפטוגרפי עטוף של Cloud KMS: זהו הסוג הכי מאובטח של מפתח קריפטוגרפי שזמין לשימוש עם שיטות ההסרה של פרטים מזהים ב-Sensitive Data Protection. מפתח ארוז של Cloud KMS מורכב ממפתח קריפטוגרפי של 128, 192 או 256 ביט שהוצפן באמצעות מפתח אחר. אתה מספק את המפתח הקריפטוגרפי הראשון, אשר לאחר מכן נעטף באמצעות מפתח קריפטוגרפי המאוחסן בשירות ניהול מפתחות בענן. מפתחות מסוג זה מאוחסנים ב-Cloud KMS לזיהוי מחדש מאוחר יותר. מידע נוסף על יצירה של מפתח ועטיפה שלו לצורך הסרת פרטים מזהים והוספה מחדש של פרטים מזהים זמין במאמר מדריך מהיר: הסרת פרטים מזהים והוספה מחדש של פרטים מזהים בטקסט רגיש.

  הערה: בעת שימוש ב-Cloud KMS לפעולות קריפטוגרפיות, יחולו חיובים. בנוסף, כשמשתמשים במפתח Cloud HSM או במפתח Cloud EKM, נספרת מכסת Cloud KMS בפרויקט שמכיל את המפתח. לעומת זאת, אם אתם משתמשים במפתח Cloud KMS מבוסס-תוכנה עם Sensitive Data Protection, לא חלים ערכי מכסה. למידע נוסף, ראו מכסות בתיעוד של Cloud KMS.

• מפתח קריפטוגרפי חולף: מפתח קריפטוגרפי חולף נוצר על ידי Sensitive Data Protection בזמן ביטול הזיהוי, ולאחר מכן נזרק. מסיבה זו, אין להשתמש במפתח קריפטוגרפי חולף עם כל שיטת זיהוי קריפטוגרפית שברצונך לבטל. מפתחות קריפטוגרפיים זמניים שומרים על שלמות הנתונים רק לכל בקשת API. אם אתם זקוקים לתקינות ביותר מבקשת API אחת או מתכננים לשחזר פרטי זיהוי את הנתונים שלכם, אל תשתמשו בסוג מפתח זה.

• מפתח קריפטוגרפי לא ארוז: מפתח לא ארוז הוא מפתח קריפטוגרפי גולמי בקידוד Base64 של 128, 192 או 256 ביט, שאתם מספקים בבקשה להסרת פרטים מזהים אל DLP API. באחריותכם לשמור על מפתחות קריפטוגרפיים כאלה כדי שתוכלו לזהות מחדש את הנתונים בהמשך. לא מומלץ להשתמש בסוגי המפתחות האלה בגלל הסיכון לדליפת המפתח בטעות. המפתחות האלה יכולים להיות שימושיים לבדיקות, אבל לעומסי עבודה בסביבת ייצור מומלץ להשתמש במפתח קריפטוגרפי שעטוף ב-Cloud KMS.

מידע נוסף על האפשרויות הזמינות כשמשתמשים במפתחות קריפטוגרפיים זמין במאמר CryptoKey בהפניה ל-DLP API.

שימוש בכוונון הקשר

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

כשמבצעים טרנספורמציה של נתונים טבלאיים, מציינים שינוי בהקשר (שנקרא פשוט context ב-DLP API), כי השינוי הוא למעשה מצביע לעמודת נתונים, כמו מזהה. Sensitive Data Protection משתמשת בערך שבשדה שצוין על ידי שינוי ההקשר כדי להצפין את ערך הקלט. כדי לוודא שהערך המוצפן תמיד יהיה ערך ייחודי, צריך לציין עמודה לשינוי שמכילה מזהים ייחודיים.

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

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

record_id	patient_id	icd10_code
5437	43789	E11.9
5438	43671	M25.531
5439	43789	N39.0, I25.710
5440	43766	I10
5441	43766	I10
5442	42989	R07.81
5443	43098	I50.1, R55
...	...	...

אם תנחו את Sensitive Data Protection להסיר פרטי זיהוי של מזהי המטופלים בטבלה, היא תסיר פרטי זיהוי של מזהי מטופלים חוזרים לאותם ערכים כברירת מחדל, כמו שמוצג בטבלה הבאה. לדוגמה, שני המקרים של מזהה המטופל '43789' עוברים הסרת פרטים מזהים והופכים ל-'47222'. (בעמודה patient_id מוצגים ערכי הטוקן אחרי פסאודונימיזציה באמצעות FPE-FFX, והיא לא כוללת הערות של תחליפים. מידע נוסף זמין במאמר בנושא הצפנה ששומרת על הפורמט).

record_id	patient_id	icd10_codes
5437	47222	E11.9
5438	82160	M25.531
5439	47222	N39.0, I25.710
5440	04452	I10
5441	04452	I10
5442	47826	R07.81
5443	52428	I50.1, R55
...	...	...

המשמעות היא שהיקף השלמות ההפניה הוא בכל מערך הנתונים.

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

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

זו הטבלה אחרי הסרת הפרטים המזהים מהעמודה patient_id באמצעות העמודה icd10_codes כהתאמה בהקשר:

record_id	patient_id	icd10_codes
5437	18954	E11.9
5438	33068	M25.531
5439	76368	N39.0, I25.710
5440	29460	I10
5441	29460	I10
5442	23877	R07.81
5443	96129	I50.1, R55
...	...	...

שימו לב שהערכים הרביעי והחמישי של patient_id אחרי הסרת הפרטים המזהים (29460) זהים, כי לא רק הערכים המקוריים של patient_id היו זהים, אלא גם הערכים של icd10_codes בשתי השורות היו זהים. מכיוון שהייתם צריכים להריץ ניתוח עם מזהי מטופלים עקביים במסגרת הערך icd10_codes, זהו אופן הפעולה שחיפשתם.

כדי לנתק לחלוטין את שלמות ההפניות בין ערכי patient_id לערכי icd10_codes, ניתן להשתמש בעמודה record_id כשינוי הקשר:

record_id	patient_id	icd10_code
5437	15826	E11.9
5438	61722	M25.531
5439	34424	N39.0, I25.710
5440	02875	I10
5441	52549	I10
5442	17945	R07.81
5443	19030	I50.1, R55
...	...	...

שימו לב שכל ערך patient_id בטבלה שעבר הסרת פרטים מזהים הוא עכשיו ייחודי.

כדי ללמוד איך להשתמש בשינויים בהקשר ב-DLP API, כדאי לשים לב לשימוש ב-context בנושאים הבאים שמתייחסים לשיטות טרנספורמציה:

• הצפנה ששומרת על הפורמט: CryptoReplaceFfxFpeConfig
• הצפנה דטרמיניסטית באמצעות AES-SIV:CryptoDeterministicConfig
• שינוי תאריך: DateShiftConfig

המאמרים הבאים

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

• עיין בדוגמאות קוד המדגימות כיצד לבצע טוקניזציה של נתונים רגישים.

• למד כיצד לבטל את זיהוי הנתונים באמצעות ממשק ה-DLP API.