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

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

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

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

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

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

מתי להשתמש בפסאודונימיזציה

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

• שמירה על שלמות ההפניות במערכי נתונים אנליטיים: החלפת מזהי לקוחות ומפתחות ראשיים באסימונים קריפטוגרפיים עקביים, כדי שהצוותים יוכלו לאחד ולצבור טבלאות ב-BigQuery בלי לחשוף מזהים רגישים.
• צמצום היקף התאימות והביקורת: החלפת מספרי כרטיסי אשראי ופרטים אישיים מזהים (PII) בטוקנים ששומרים על הפורמט, כדי לצמצם את גבולות התאימות ל-PCI DSS או ל-HIPAA באפליקציות במורד הזרם.
• הגנה על סביבות בדיקה ופיתוח: שכפול מסדי נתונים של סביבת ייצור לסביבות פיתוח ברמה נמוכה יותר עם שדות שעברו טוקניזציה. כך המפתחים יכולים לבדוק אפליקציות עם מבני נתונים מציאותיים בלי לגשת לרשומות של לקוחות אמיתיים.
• הפעלת הפיכות מאובטחת לתהליכי עבודה מורשים: משתמשים בהצפנה דו-כיוונית (כמו AES-SIV או FPE) עם מפתחות שמאוחסנים ב-Cloud Key Management Service, כדי שרק שירותים מורשים ובעלי הרשאות לקצה העורפי יוכלו לבטל את הטוקניזציה של הערכים המקוריים כשנדרש על פי חוק.
• אכיפת הסתרת נתונים בלתי הפיכה באמצעות גיבוב קריפטוגרפי: יצירת תקצירים חד-כיווניים של HMAC-SHA-256. השיטה הזו מתאימה כשנדרשת קורלציה בין רשומות לצורך ניתוח סטטיסטי, אבל שחזור הטקסט הפשוט המקורי חייב להישאר בלתי אפשרי מבחינה חישובית.

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

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

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

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

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

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

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

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

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

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

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

• באמצעות אריזה באמצעות Cloud Key Management Service‏ (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. ה-infoType החלופי האופציונלי הוגדר לערך NAM_PHONE_NUMB:

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

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

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

כשמסירים פרטי זיהוי באמצעות הצפנה ששומרת על הפורמט, ערך קלט (ואופציונלית, כל שינוי הקשר שצוין) מוצפן באמצעות מצב 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

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

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

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

הערה: כחלק מהתכנון, 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 Key Management Service. המפתחות האלה מאוחסנים ב-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