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

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

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

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

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

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

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

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

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

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

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

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

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

שלב 1: Sensitive Data Protection בוחר נתונים להמרת טוקנים. הדרך הנפוצה ביותר לעשות את זה היא להשתמש בגלאי מסוג מידע מובנה או מותאם אישית כדי להתאים לערכי הנתונים הרגישים הרצויים. אם אתם סורקים נתונים מובנים (למשל טבלה ב-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. סוג המידע החלופי האופציונלי הוגדר לערך NAM_PHONE_NUMB:

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

אם לא מציינים הערת תחליף, הטוקן שמתקבל שווה לערך שעבר טרנספורמציה, או ל-#4 בתרשים עם ההערות. כדי לשחזר פרטי זיהוי של נתונים לא מובנים, נדרש האסימון כולו, כולל האנוטציה של תחליף. כשמבצעים טרנספורמציה של נתונים מובְנים כמו טבלה, אפשר להשתמש בהערת סרוגייט, אבל היא לא חובה. אפשר להשתמש ב-Sensitive Data Protection כדי לבצע דה-איдентификаציה ואי-דה-איдентификаציה בעמודה שלמה באמצעות RecordTransformation בלי הערת סרוגייט.

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

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

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

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

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

הטוקן שמתקבל, בהנחה שצוין 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.

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

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

• מפתח קריפטוגרפי זמני: מפתח קריפטוגרפי זמני נוצר על ידי 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 להסיר פרטי זיהוי של מזהי המטופלים בטבלה, היא תסיר פרטי זיהוי של מזהי מטופלים חוזרים לאותם ערכים כברירת מחדל, כמו שמוצג בטבלה הבאה. לדוגמה, שני המקרים של מזהה המטופל "43789" עוברים הסרת פרטים מזהים והופכים ל-"47222". (בעמודה patient_id מוצגים ערכי הטוקן אחרי פסאודונימיזציה באמצעות FPE-FFX, והיא לא כוללת הערות של תחליפים. מידע נוסף זמין במאמר בנושא הצפנה ששומרת על הפורמט).

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

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

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

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

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

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

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

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

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

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

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

• מעיינים בדוגמאות קוד שמדגימות איך ליצור טוקנים לנתונים רגישים.

• איך מסירים פרטים מזהים מנתונים באמצעות DLP API