באמצעות Sensitive Data Protection אפשר להסיר פרטי זיהוי ממידע אישי רגיש בתוכן טקסט, כולל טקסט שמאוחסן במבני קונטיינר כמו טבלאות. הסרת פרטי הזיהוי היא תהליך של הסרת פרטים אישיים מזהים מנתונים. ממשק ה-API מזהה מידע אישי רגיש כמו פרטים אישיים מזהים (PII), ואז משתמש בשינוי לצורך הסרת פרטים מזהים כדי לבצע אנונימיזציה, למחוק או להצפין את הנתונים. לדוגמה, טכניקות להסרת פרטים מזהים יכולות לכלול כל אחת מהפעולות הבאות:
- הסתרת נתונים רגישים על ידי החלפה חלקית או מלאה של תווים בסמל, כמו כוכבית (*) או סולמית (#).
- החלפת כל מופע של נתונים רגישים בטוקן או במחרוזת תחליפית.
- הצפנה והחלפה של מידע אישי רגיש באמצעות מפתח שנוצר באופן אקראי או מפתח שנקבע מראש.
אפשר להזין מידע ל-API באמצעות JSON ב-HTTPS, וגם באמצעות CLI ומספר שפות תכנות באמצעות ספריות הלקוח של Sensitive Data Protection. כדי להגדיר את ה-CLI, אפשר לעיין במדריך למתחילים. למידע נוסף על שליחת מידע בפורמט JSON, אפשר לעיין במדריך למתחילים בנושא JSON.
סקירה כללית על ממשקי API
כדי להסיר פרטי זיהוי ממידע אישי רגיש, אפשר להשתמש בשיטה content.deidentify של Sensitive Data Protection.
קריאה ל-API להסרת פרטים מזהים כוללת שלושה חלקים:
- הנתונים לבדיקה: מחרוזת או מבנה טבלה
(
ContentItemאובייקט) לבדיקה על ידי ה-API. מה לבדוק: מידע על הגדרות הזיהוי (
InspectConfig), כמו אילו סוגי נתונים (או infoTypes) לחפש, אם לסנן ממצאים שחורגים מסף מסוים של סבירות, ואם להחזיר מספר מסוים של תוצאות לכל היותר.באובייקט
InspectConfig, חשוב לכלול את infoTypes שרוצים לסרוק. אחרת, Sensitive Data Protection סורק קבוצת ברירת מחדל של infoTypes (ALL_BASIC), שחלקם אולי לא רלוונטיים לכם. סריקה של סוגי מידע שלא נדרשים יכולה להוסיף זמן אחזור מיותר לבקשה.נדרש אובייקט
InspectConfigבבקשה, עם חריגה אחת. מידע נוסף זמין בקטע שינויים ברשומות בדף הזה.מה עושים עם הממצאים של הבדיקה: פרטי ההגדרה (
DeidentifyConfig) שמגדירים איך רוצים להסיר את הפרטים המזהים מהמידע האישי הרגיש. הטיעון הזה מוסבר בפירוט בקטע הבא.
ממשק ה-API מחזיר את אותם פריטים שסיפקתם לו, באותו פורמט, אבל כל טקסט שזוהה כטקסט שמכיל מידע רגיש לפי הקריטריונים שלכם עבר הסרת פרטים מזהים.
ציון קריטריוני זיהוי
גלאי סוגי מידע (או infoType) הם המנגנונים ש-Sensitive Data Protection משתמש בהם כדי למצוא מידע אישי רגיש.
Sensitive Data Protection כולל כמה סוגים של גלאי infoType, וכולם מסוכמים כאן:
- גלאי infoType מובנים הם חלק מ-Sensitive Data Protection. הם כוללים מזהים לסוגי מידע אישי רגיש שספציפיים למדינה או לאזור, וגם לסוגי נתונים שרלוונטיים באופן גלובלי.
- מזהים מותאמים אישית של סוגי מידע הם מזהים שאתם יוצרים בעצמכם. יש שלושה סוגים של גלאי סוגי מידע בהתאמה אישית:
- מזהים רגילים של מילונים בהתאמה אישית הם רשימות פשוטות של מילים שבהן מתבצעת התאמה של Sensitive Data Protection. משתמשים בגלאים רגילים של מילון מותאם אישית כשיש רשימה של עד כמה עשרות אלפי מילים או ביטויים. מומלץ להשתמש במזהים רגילים של מילונים בהתאמה אישית אם לא צפויים שינויים משמעותיים ברשימת המילים.
- גלאים של מילונים מותאמים אישית מאוחסנים נוצרים על ידי Sensitive Data Protection באמצעות רשימות גדולות של מילים או ביטויים שמאוחסנים ב-Cloud Storage או ב-BigQuery. כדאי להשתמש בגלאים של מילון מותאם אישית מאוחסן אם יש לכם רשימה גדולה של מילים או ביטויים – עד עשרות מיליוני מילים או ביטויים.
- מזהים של ביטויים רגולריים (regex) מאפשרים ל-Sensitive Data Protection לזהות התאמות על סמך דפוס של ביטוי רגולרי.
כדי לשפר את תוצאות הסריקה, אפשר ליצור כללי בדיקה.
טרנספורמציות של הסרת פרטי הזיהוי
כשמגדירים את התצורה של הסרת הפרטים המזהים (DeidentifyConfig), צריך לציין טרנספורמציה אחת או יותר. יש שתי קטגוריות של טרנספורמציות:
-
InfoTypeTransformations: טרנספורמציות שמוחלות רק על ערכים בטקסט שנשלח, שמזוהים כסוג מידע ספציפי. -
RecordTransformations: טרנספורמציות שמוחלות רק על ערכים בנתוני טקסט טבלאיים שנשלחו, שזוהו כסוג מידע ספציפי, או על עמודה שלמה של נתונים טבלאיים.
טרנספורמציות של InfoType
אפשר לציין טרנספורמציה אחת או יותר של infoType לכל בקשה. בתוך כל אובייקט InfoTypeTransformation, מציינים את שני הפרטים הבאים:
- אחד או יותר infoTypes שצריך להחיל עליהם טרנספורמציה (אובייקט המערך
infoTypes[]). - טרנספורמציה פרימיטיבית (האובייקט
PrimitiveTransformation).
הערה: ציון infoType הוא אופציונלי, אבל אם לא מציינים לפחות infoType אחד בארגומנט InspectConfig, הטרנספורמציה תחול על כל סוגי המידע המובנים שלא צוינה להם טרנספורמציה. לא מומלץ לעשות זאת, כי זה עלול להוביל לירידה בביצועים ולעלייה בעלויות.
טרנספורמציות פרימיטיביות
צריך לציין לפחות טרנספורמציה פרימיטיבית אחת שתחול על הקלט, בלי קשר לשאלה אם היא חלה רק על סוגי מידע מסוימים או על מחרוזת הטקסט כולה. בקטעים הבאים מתוארות דוגמאות לשיטות טרנספורמציה שבהן אפשר להשתמש. רשימה של כל שיטות הטרנספורמציה ש-Sensitive Data Protection מציע מופיעה במאמר חומר עזר בנושא טרנספורמציה.
replaceConfig
הגדרת replaceConfig לאובייקט ReplaceValueConfig
מחליפה ערכי קלט תואמים בערך שאתם מציינים.
לדוגמה, נניח שהגדרתם את replaceConfig ל-[email-address] לכל סוגי המידע EMAIL_ADDRESS, והמחרוזת הבאה נשלחת ל-Sensitive Data Protection:
My name is Alicia Abernathy, and my email address is aabernathy@example.com.
המחרוזת שתוחזר תהיה:
My name is Alicia Abernathy, and my email address is [email-address].
בדוגמה הבאה בפורמט JSON ובקוד בכמה שפות אפשר לראות איך יוצרים את בקשת ה-API ומה מוחזר מ-DLP API:
Python
מידע על התקנת ספריית הלקוח של 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. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
REST
למידע נוסף על שימוש ב-DLP API עם JSON, אפשר לעיין במדריך לתחילת העבודה עם JSON.
קלט JSON:
POST https://dlp.googleapis.com/v2/projects/[PROJECT_ID]/content:deidentify?key={YOUR_API_KEY}
{
"item":{
"value":"My name is Alicia Abernathy, and my email address is aabernathy@example.com."
},
"deidentifyConfig":{
"infoTypeTransformations":{
"transformations":[
{
"infoTypes":[
{
"name":"EMAIL_ADDRESS"
}
],
"primitiveTransformation":{
"replaceConfig":{
"newValue":{
"stringValue":"[email-address]"
}
}
}
}
]
}
},
"inspectConfig":{
"infoTypes":[
{
"name":"EMAIL_ADDRESS"
}
]
}
}
פלט JSON:
{
"item":{
"value":"My name is Alicia Abernathy, and my email address is [email-address]."
},
"overview":{
"transformedBytes":"22",
"transformationSummaries":[
{
"infoType":{
"name":"EMAIL_ADDRESS"
},
"transformation":{
"replaceConfig":{
"newValue":{
"stringValue":"[email-address]"
}
}
},
"results":[
{
"count":"1",
"code":"SUCCESS"
}
],
"transformedBytes":"22"
}
]
}
}
redactConfig
ציון של
redactConfig
מצנזר ערך מסוים על ידי הסרתו לחלוטין. להודעה redactConfig אין ארגומנטים, אבל ציון שלה מאפשר את ההמרה שלה.
לדוגמה, נניח שציינתם redactConfig לכל EMAIL_ADDRESSinfoTypes, והמחרוזת הבאה נשלחת ל-Sensitive Data Protection:
My name is Alicia Abernathy, and my email address is aabernathy@example.com.
המחרוזת שתוחזר תהיה:
My name is Alicia Abernathy, and my email address is .
בדוגמאות הבאות אפשר לראות איך יוצרים את בקשת ה-API ומה מוחזר מ-DLP API:
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
קלט JSON:
POST https://dlp.googleapis.com/v2/projects/[PROJECT_ID]/content:deidentify?key={YOUR_API_KEY}
{
"item":{
"value":"My name is Alicia Abernathy, and my email address is aabernathy@example.com."
},
"deidentifyConfig":{
"infoTypeTransformations":{
"transformations":[
{
"infoTypes":[
{
"name":"EMAIL_ADDRESS"
}
],
"primitiveTransformation":{
"redactConfig":{
}
}
}
]
}
},
"inspectConfig":{
"infoTypes":[
{
"name":"EMAIL_ADDRESS"
}
]
}
}
פלט JSON:
{
"item":{
"value":"My name is Alicia Abernathy, and my email address is ."
},
"overview":{
"transformedBytes":"22",
"transformationSummaries":[
{
"infoType":{
"name":"EMAIL_ADDRESS"
},
"transformation":{
"redactConfig":{
}
},
"results":[
{
"count":"1",
"code":"SUCCESS"
}
],
"transformedBytes":"22"
}
]
}
}
characterMaskConfig
הגדרת characterMaskConfig לאובייקט CharacterMaskConfig מסווה חלק ממחרוזת על ידי החלפת מספר נתון של תווים בתו קבוע. ההסתרה יכולה להתחיל מתחילת המחרוזת או מסוף המחרוזת. ההמרה הזו פועלת גם עם סוגי מספרים כמו מספרים שלמים ארוכים.
לאובייקט CharacterMaskConfig יש כמה ארגומנטים משלו:
-
maskingCharacter: התו שישמש להסתרת כל תו של ערך רגיש. לדוגמה, אפשר לציין כוכבית (*) או סולמית (#) כדי להסתיר סדרת מספרים כמו אלה שמופיעים במספר כרטיס אשראי. -
numberToMask: מספר התווים להסתרת המידע. אם לא מגדירים את הערך הזה, כל התווים התואמים יוסתרו. -
reverseOrder: האם להסתיר את התווים בסדר הפוך. הגדרת הערךreverseOrderכ-true גורמת להסתרת התווים בערכים התואמים מהסוף להתחלה של הערך. אם מגדירים את הערך כ-false, ההסתרה מתחילה בתחילת הערך. -
charactersToIgnore[]: תו אחד או יותר שצריך לדלג עליהם כשמסתירים ערכים. לדוגמה, אם מציינים כאן מקף, המקפים יישארו במקומם כשמסתירים מספר טלפון. אפשר גם לציין קבוצה של תווים נפוצים (CharsToIgnore) להתעלמות מהם בהסתרת נתונים.
לדוגמה, נניח שהגדרתם את characterMaskConfig להסתרת נתונים באמצעות '#' עבור סוגי מידע EMAIL_ADDRESS, למעט התווים '.' ו-'@'. אם המחרוזת הבאה נשלחת אל Sensitive Data Protection:
My name is Alicia Abernathy, and my email address is aabernathy@example.com.
המחרוזת שתוחזר תהיה:
My name is Alicia Abernathy, and my email address is ##########@#######.###.
בדוגמאות הבאות אפשר לראות איך משתמשים ב-DLP API כדי להסיר את הפרטים המזהים ממידע אישי רגיש באמצעות טכניקות של מיסוך.
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. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Python
מידע על התקנת ספריית הלקוח של 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. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
PHP
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
C#
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
REST
בדוגמה הבאה בפורמט JSON מוצג איך ליצור את בקשת ה-API ומה ה-DLP API מחזיר:
קלט JSON:
POST https://dlp.googleapis.com/v2/projects/[PROJECT_ID]/content:deidentify?key={YOUR_API_KEY}
{
"item":{
"value":"My name is Alicia Abernathy, and my email address is aabernathy@example.com."
},
"deidentifyConfig":{
"infoTypeTransformations":{
"transformations":[
{
"infoTypes":[
{
"name":"EMAIL_ADDRESS"
}
],
"primitiveTransformation":{
"characterMaskConfig":{
"maskingCharacter":"#",
"reverseOrder":false,
"charactersToIgnore":[
{
"charactersToSkip":".@"
}
]
}
}
}
]
}
},
"inspectConfig":{
"infoTypes":[
{
"name":"EMAIL_ADDRESS"
}
]
}
}
פלט JSON:
{
"item":{
"value":"My name is Alicia Abernathy, and my email address is ##########@#######.###."
},
"overview":{
"transformedBytes":"22",
"transformationSummaries":[
{
"infoType":{
"name":"EMAIL_ADDRESS"
},
"transformation":{
"characterMaskConfig":{
"maskingCharacter":"#",
"charactersToIgnore":[
{
"charactersToSkip":".@"
}
]
}
},
"results":[
{
"count":"1",
"code":"SUCCESS"
}
],
"transformedBytes":"22"
}
]
}
}
cryptoHashConfig
הגדרת cryptoHashConfig לאובייקט CryptoHashConfig מבצעת פסאודונימיזציה על ערך קלט על ידי יצירת ערך חלופי באמצעות גיבוב קריפטוגרפי.
בשיטה הזו, ערך הקלט מוחלף ב "תמצית" מוצפנת, או בערך גיבוב.
התמצית מחושבת על ידי גיבוב (hash) של ערך הקלט באמצעות אלגוריתם SHA-256.
המפתח הקריפטוגרפי שמשמש ליצירת הגיבוב הוא אובייקט CryptoKey, והגודל שלו חייב להיות 32 או 64 בייט.
הפלט של השיטה הוא ייצוג בקידוד Base64 של הפלט שעבר גיבוב. בשלב הזה, אפשר לבצע גיבוב רק של ערכים מסוג מחרוזת ומסוג מספר שלם.
לדוגמה, נניח שציינתם cryptoHashConfig לכל סוגי המידע EMAIL_ADDRESS, ואובייקט CryptoKey מורכב ממפתח שנוצר באופן אקראי (TransientCryptoKey). במקרה כזה, המחרוזת הבאה נשלחת אל Sensitive Data Protection:
My name is Alicia Abernathy, and my email address is aabernathy@example.com.
המחרוזת שמוחזרת, שנוצרה באמצעות הצפנה, תיראה כך:
My name is Alicia Abernathy, and my email address is 41D1567F7F99F1DC2A5FAB886DEE5BEE.
כמובן, מחרוזת ה-hex תיווצר באופן קריפטוגרפי ותהיה שונה מזו שמוצגת כאן.
dateShiftConfig
הגדרת dateShiftConfig לאובייקט DateShiftConfig מבצעת הזזה של תאריכים בערך קלט של תאריך, על ידי הזזת התאריכים במספר אקראי של ימים.
טכניקות של שינוי תאריכים משנות באופן אקראי קבוצה של תאריכים, אבל שומרות על הרצף ועל משך הזמן של תקופה מסוימת. הזזת תאריכים מתבצעת בדרך כלל בהקשר של אדם או ישות. כלומר, אתם רוצים להזיז את כל התאריכים של אדם מסוים באמצעות אותו הפרש הזזה, אבל להשתמש בהפרש הזזה נפרד לכל אדם אחר.
מידע נוסף על שינוי תאריכים זמין במאמר הסבר על שינוי תאריכים.
בדוגמת הקוד הבאה, שמוצגת בכמה שפות, אפשר לראות איך משתמשים ב-DLP API כדי להסיר פרטים מזהים מתאריכים באמצעות שינוי תאריכים.
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. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Python
מידע על התקנת ספריית הלקוח של 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. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
PHP
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
C#
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
cryptoReplaceFfxFpeConfig
הגדרת cryptoReplaceFfxFpeConfig לאובייקט CryptoReplaceFfxFpeConfig מבצעת פסאודונימיזציה על ערך קלט על ידי החלפת ערך קלט באסימון. האסימון הזה:
- ערך הקלט המוצפן.
- באורך זהה לערך הקלט.
- הערך מחושב באמצעות הצפנה ששומרת על הפורמט במצב FFX (FPE-FFX) עם מפתח קריפטוגרפי שמוגדר על ידי
cryptoKey. - מורכב מהתווים שצוינו על ידי
alphabet. אפשרויות תקפות:NUMERICHEXADECIMALUPPER_CASE_ALPHA_NUMERICALPHA_NUMERIC
ערך הקלט:
- האורך המינימלי הוא שני תווים (או מחרוזת ריקה).
- הערך חייב לכלול את התווים שצוינו על ידי
alphabet.alphabetיכול לכלול בין 2 ל-95 תווים. (alphabetעם 95 תווים כולל את כל התווים שניתנים להדפסה בערכת התווים US-ASCII).
התכונה Sensitive Data Protection מחשבת את אסימון ההחלפה באמצעות מפתח קריפטוגרפי. יש שלוש דרכים לספק את המפתח הזה:
- הטמעת המפתח בבקשת ה-API ללא הצפנה. מומלץ לא לעשות זאת.
- על ידי בקשה מ-Sensitive Data Protection ליצור אותו.
- על ידי הטמעה מוצפנת בבקשת ה-API.
אם בוחרים להטמיע את המפתח בבקשת ה-API, צריך ליצור מפתח ולארוז (להצפין) אותו באמצעות מפתח של Cloud Key Management Service (Cloud KMS). ערך ברירת המחדל שמוחזר הוא מחרוזת בקידוד Base64. כדי להגדיר את הערך הזה ב-Sensitive Data Protection, צריך לפענח אותו למחרוזת בייטים. בקטעי הקוד הבאים מודגש איך עושים את זה בכמה שפות. אחרי קטעי הקוד האלה מופיעות דוגמאות מקצה לקצה.
Java
KmsWrappedCryptoKey.newBuilder()
.setWrappedKey(ByteString.copyFrom(BaseEncoding.base64().decode(wrappedKey)))
Python
# The wrapped key is base64-encoded, but the library expects a binary
# string, so decode it here.
import base64
wrapped_key = base64.b64decode(wrapped_key)
PHP
// Create the wrapped crypto key configuration object
$kmsWrappedCryptoKey = (new KmsWrappedCryptoKey())
->setWrappedKey(base64_decode($wrappedKey))
->setCryptoKeyName($keyName);
C#
WrappedKey = ByteString.FromBase64(wrappedKey)
מידע נוסף על הצפנה ופענוח של נתונים באמצעות Cloud KMS מופיע במאמר הצפנה ופענוח של נתונים.
כברירת מחדל, FPE-FFX שומר על האורך ועל מערכת התווים של טקסט הקלט. כלומר, חסרים בו אימות ווקטור אתחול, מה שגורם להרחבת האורך בטוקן הפלט. שיטות אחרות כמו AES-SIV מספקות את ערבויות האבטחה החזקות האלה, ומומלצות לתרחישי שימוש בטוקניזציה, אלא אם שמירה על אורך ועל ערכת התווים היא דרישה מחמירה – למשל, לצורך תאימות לאחור עם מערכת נתונים מדור קודם.
בדוגמת הקוד הבאה, שמוצגת בכמה שפות, אפשר לראות איך משתמשים ב-Sensitive Data Protection כדי לבטל את הזיהוי של נתונים רגישים על ידי החלפת ערך קלט בטוקן.
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. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Python
מידע על התקנת ספריית הלקוח של 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. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
PHP
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
C#
מידע על התקנת ספריית הלקוח של Sensitive Data Protection והשימוש בה מופיע במאמר ספריות הלקוח של Sensitive Data Protection.
כדי לבצע אימות ב-Sensitive Data Protection, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
במאמר הצפנה ששומרת על הפורמט: דוגמאות לשחזור פרטי זיהוי אפשר למצוא דוגמאות לקוד שמדגימות איך להשתמש ב-Sensitive Data Protection כדי לשחזר פרטי זיהוי מידע אישי רגיש שעבר הסרת פרטי הזיהוי באמצעות שיטת הטרנספורמציה CryptoReplaceFfxFpeConfig.
fixedSizeBucketingConfig
הטרנספורמציות של חלוקה לקטגוריות – זו ו-bucketingConfig – משמשות להסתרת נתונים מספריים על ידי חלוקה שלהם לקטגוריות בטווחים. טווח המספרים שמתקבל הוא מחרוזת עם מקף שמורכבת מגבול תחתון, מקף וגבול עליון.
ההגדרה fixedSizeBucketingConfig ל-FixedSizeBucketingConfig ממיינת ערכי קלט של אובייקטים לפי טווחי גודל קבועים. אובייקט FixedSizeBucketingConfig מורכב מהרכיבים הבאים:
-
lowerBound: הערך של הגבול התחתון של כל הקטגוריות. ערכים שקטנים מהערך הזה מקובצים יחד בדלי אחד. -
upperBound: ערך הגבול העליון של כל הקטגוריות. ערכים שגדולים מהערך הזה מקובצים יחד בדלי אחד. -
bucketSize: הגודל של כל קטגוריה, מלבד הקטגוריות המינימליות והמקסימליות.
לדוגמה, אם הערך של lowerBound הוא 10, הערך של upperBound הוא 89 והערך של bucketSize הוא 10, המערכת תשתמש בדליים הבאים: -10, 10-20, 20-30, 30-40, 40-50, 50-60, 60-70, 70-80, 80-89, 89+.
מידע נוסף על המושג 'קטגוריות' זמין במאמר הכללה וקטגוריות.
bucketingConfig
הטרנספורמציה bucketingConfig מציעה יותר גמישות מהטרנספורמציה האחרת של חלוקה לקטגוריות, fixedSizeBucketingConfig.
במקום לציין גבולות עליונים ותחתונים וערך של מרווח ליצירת דליים בגודל שווה, מציינים את הערכים המקסימליים והמינימליים של כל דלי שרוצים ליצור. כל זוג של ערך מקסימלי וערך מינימלי חייב להיות מאותו סוג.
הגדרת bucketingConfig לאובייקט BucketingConfig מציינת קטגוריות בהתאמה אישית. אובייקט BucketingConfig מורכב ממערך buckets[] של אובייקטים Bucket. כל אובייקט Bucket מורכב מהרכיבים הבאים:
-
min: הגבול התחתון של טווח הקטגוריה. כדי ליצור קבוצת ערכים ללא גבול תחתון, לא מציינים את הערך הזה. -
max: הגבול העליון של טווח הקטגוריה. אם רוצים ליצור קבוצת משנה ללא גבול עליון, לא מציינים את הערך הזה. -
replacementValue: הערך שבו יוחלפו הערכים שנמצאים בין הגבולות התחתון והעליון. אם לא תספקוreplacementValue, המערכת תשתמש בטווחmin-maxעם מקף.
אם ערך מסוים לא נמצא בטווחים המוגדרים, הערך שמוחזר על ידי TransformationSummary יכיל הודעת שגיאה.
לדוגמה, נניח שהגדרתם את ההגדרה הבאה לטרנספורמציה bucketingConfig:
"bucketingConfig":{
"buckets":[
{
"min":{
"integerValue":"1"
},
"max":{
"integerValue":"30"
},
"replacementValue":{
"stringValue":"LOW"
}
},
{
"min":{
"integerValue":"31"
},
"max":{
"integerValue":"65"
},
"replacementValue":{
"stringValue":"MEDIUM"
}
},
{
"min":{
"integerValue":"66"
},
"max":{
"integerValue":"100"
},
"replacementValue":{
"stringValue":"HIGH"
}
}
]
}
ההגדרה הזו מגדירה את ההתנהגות הבאה:
- ערכים שלמים בין 1 ל-30 מוסווים על ידי החלפה ב-
LOW. - ערכים של מספרים שלמים בין 31 ל-65 מוסתרים על ידי החלפה ב-
MEDIUM. - ערכים של מספרים שלמים בין 66 ל-100 מוסתרים באמצעות החלפה בערך
HIGH.
מידע נוסף על המושג 'קטגוריות' זמין במאמר הכללה וקטגוריות.
replaceWithInfoTypeConfig
אם מציינים
replaceWithInfoTypeConfig
כל ערך תואם מוחלף בשם של infoType. להודעה
replaceWithInfoTypeConfig אין ארגומנטים. ציון ההודעה מאפשר את ההמרה שלה.
לדוגמה, נניח שציינתם replaceWithInfoTypeConfig לכל ה-infoType EMAIL_ADDRESS, והמחרוזת הבאה נשלחת ל-Sensitive Data Protection:
My name is Alicia Abernathy, and my email address is aabernathy@example.com.
המחרוזת שתוחזר תהיה:
My name is Alicia Abernathy, and my email address is EMAIL_ADDRESS.
timePartConfig
הגדרת timePartConfig לאובייקט TimePartConfig שומרת חלק מערך תואם שכולל את הערכים Date, Timestamp ו-TimeOfDay. אובייקט TimePartConfig מורכב מארגומנט partToExtract, שאפשר להגדיר לו כל אחד מהערכים המנויים TimePart, כולל שנה, חודש, יום בחודש וכן הלאה.
לדוגמה, נניח שהגדרתם טרנספורמציה של timePartConfig על ידי הגדרת partToExtract ל-YEAR. אחרי שליחת הנתונים בעמודה הראשונה שלמטה אל Sensitive Data Protection, תקבלו את הערכים שעברו טרנספורמציה בעמודה השנייה:
| ערכים מקוריים | ערכים שעברו שינוי |
|---|---|
9/21/1976 |
1976 |
6/7/1945 |
1945 |
1/20/2009 |
2009 |
7/4/1776 |
1776 |
8/1/1984 |
1984 |
4/21/1982 |
1982 |
תיעוד טרנספורמציות
הטרנספורמציות של הרשומות (אובייקט RecordTransformations) חלות רק על ערכים בנתונים טבלאיים שמזוהים כסוג מידע ספציפי. בתוך RecordTransformations, יש עוד שתי קטגוריות משנה של טרנספורמציות:
-
fieldTransformations[]: טרנספורמציות שחלות על טרנספורמציות שונות של שדות. -
recordSuppressions[]: כללים שמגדירים אילו רשומות יוסתרו לחלוטין. רשומות שתואמות לכלל השמטה כלשהו בטווחrecordSuppressions[]מושמטות מהפלט.
טרנספורמציות של שדות
כל אובייקט FieldTransformation כולל שלושה ארגומנטים:
-
fields: שדה קלט אחד או יותר (אובייקטים מסוגFieldID) להחלת הטרנספורמציה. -
condition: תנאי (אובייקטRecordCondition) שצריך להחזיר את הערך true כדי שהטרנספורמציה תוחל. לדוגמה, אפשר להחיל טרנספורמציה של חלוקה לקטגוריות על עמודת גיל של רשומה רק אם עמודת המיקוד של אותה רשומה נמצאת בטווח מסוים. או, לצנזר שדה רק אם בשדה תאריך הלידה מופיע גיל של 85 ומעלה. אחד משני הארגומנטים הבאים של סוג הטרנספורמציה. חובה לציין אחד מהערכים הבאים:
-
infoTypeTransformations: התוכן בשדה הוא טקסט חופשי, וסימןPrimitiveTransformationיופיע רק אם התוכן תואם לסימןInfoType. ההמרות האלה מוסברות בחלק הקודם של הנושא הזה.
primitiveTransformation: החלת הטרנספורמציה הפרימיטיבית שצוינה (אובייקטPrimitiveTransformation) על השדה כולו. הטרנספורמציות האלה מוסברות בחלק הקודם של המאמר הזה.אם אובייקט
RecordTransformationsמכיל רקprimitiveTransformationולא מכילinfoTypeTransformations, לא צריך לכלול אובייקטInspectConfigבבקשה. אם כן, הכלי Sensitive Data Protection מתעלם ממנו.
-
דוגמה לטרנספורמציות של שדות
בדוגמה הבאה נשלחת בקשת projects.content.deidentify עם שני שינויים בשדות:
הטרנספורמציה הראשונה של השדה חלה על שתי העמודות הראשונות (
column1ו-column2). מכיוון שסוג הטרנספורמציה הוא אובייקטprimitiveTransformation(במיוחד,CryptoDeterministicConfig), Sensitive Data Protection מבצע טרנספורמציה של השדה כולו.הטרנספורמציה השנייה של השדה חלה על העמודה השלישית (
column3). מכיוון שסוג הטרנספורמציה הוא אובייקטinfoTypeTransformations, Sensitive Data Protection מחיל את הטרנספורמציה הפרימיטיבית (בספציפיות,ReplaceWithInfoTypeConfig) רק על התוכן שתואם לסוג המידע שמוגדר בהגדרות הבדיקה.
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
-
PROJECT_ID: מזהה הפרויקט ב- Google Cloud . מזהי פרויקטים הם מחרוזות אלפאנומריות, כמוmy-project.
ה-method של ה-HTTP וכתובת ה-URL:
POST https://dlp.googleapis.com/v2/projects/PROJECT_ID/content:deidentify
תוכן בקשת JSON:
{
"item": {
"table": {
"headers": [
{
"name": "column1"
},
{
"name": "column2"
},
{
"name": "column3"
}
],
"rows": [
{
"values": [
{
"stringValue": "Example string 1"
},
{
"stringValue": "Example string 2"
},
{
"stringValue": "My email address is dani@example.org"
}
]
},
{
"values": [
{
"stringValue": "Example string 1"
},
{
"stringValue": "Example string 3"
},
{
"stringValue": "My email address is cruz@example.org"
}
]
}
]
}
},
"deidentifyConfig": {
"recordTransformations": {
"fieldTransformations": [
{
"fields": [
{
"name": "column1"
},
{
"name": "column2"
}
],
"primitiveTransformation": {
"cryptoDeterministicConfig": {
"cryptoKey": {
"unwrapped": {
"key": "YWJjZGVmZ2hpamtsbW5vcA=="
}
}
}
}
},
{
"fields": [
{
"name": "column3"
}
],
"infoTypeTransformations": {
"transformations": [
{
"primitiveTransformation": {
"replaceWithInfoTypeConfig": {}
}
}
]
}
}
]
}
},
"inspectConfig": {
"infoTypes": [
{
"name": "EMAIL_ADDRESS"
}
]
}
}
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
{
"item": {
"table": {
"headers": [
{
"name": "column1"
},
{
"name": "column2"
},
{
"name": "column3"
}
],
"rows": [
{
"values": [
{
"stringValue": "AWttmGlln6Z2MFOMqcOzDdNJS52XFxOOZsg0ckDeZzfc"
},
{
"stringValue": "AUBTE+sQB6eKZ5iD3Y0Ss682zANXbijuFl9KL9ExVOTF"
},
{
"stringValue": "My email address is [EMAIL_ADDRESS]"
}
]
},
{
"values": [
{
"stringValue": "AWttmGlln6Z2MFOMqcOzDdNJS52XFxOOZsg0ckDeZzfc"
},
{
"stringValue": "AU+oD2pnqUDTLNItE8RplY3E0fTHeO4rZkX4GeFHN2CI"
},
{
"stringValue": "My email address is [EMAIL_ADDRESS]"
}
]
}
]
}
},
"overview": {
"transformedBytes": "96",
"transformationSummaries": [
{
"field": {
"name": "column1"
},
"results": [
{
"count": "2",
"code": "SUCCESS"
}
],
"fieldTransformations": [
{
"fields": [
{
"name": "column1"
},
{
"name": "column2"
}
],
"primitiveTransformation": {
"cryptoDeterministicConfig": {
"cryptoKey": {
"unwrapped": {
"key": "YWJjZGVmZ2hpamtsbW5vcA=="
}
}
}
}
}
],
"transformedBytes": "32"
},
{
"field": {
"name": "column2"
},
"results": [
{
"count": "2",
"code": "SUCCESS"
}
],
"fieldTransformations": [
{
"fields": [
{
"name": "column1"
},
{
"name": "column2"
}
],
"primitiveTransformation": {
"cryptoDeterministicConfig": {
"cryptoKey": {
"unwrapped": {
"key": "YWJjZGVmZ2hpamtsbW5vcA=="
}
}
}
}
}
],
"transformedBytes": "32"
},
{
"infoType": {
"name": "EMAIL_ADDRESS",
"sensitivityScore": {
"score": "SENSITIVITY_MODERATE"
}
},
"field": {
"name": "column3"
},
"results": [
{
"count": "2",
"code": "SUCCESS"
}
],
"fieldTransformations": [
{
"fields": [
{
"name": "column3"
}
],
"infoTypeTransformations": {
"transformations": [
{
"primitiveTransformation": {
"replaceWithInfoTypeConfig": {}
}
}
]
}
}
],
"transformedBytes": "32"
}
]
}
}השבתת הקלטה
בנוסף לטרנספורמציות של נתוני שדות, אפשר גם להנחות את Sensitive Data Protection להסיר את הפרטים המזהים מהנתונים על ידי השמטה פשוטה של רשומות, כשמתקיימים תנאי השמטה מסוימים. אפשר להחיל באותה בקשה גם שינויים בשדות וגם השמטות של רשומות.
מגדירים את ההודעה recordSuppressions של אובייקט RecordTransformations
כמערך של אובייקט RecordSuppression אחד או יותר.
כל אובייקט RecordSuppression מכיל אובייקט RecordCondition אחד, שבתורו מכיל אובייקט Expressions אחד.
אובייקט Expressions
כולל:
-
logicalOperator: אחד מסוגי הנתונים המפורטיםLogicalOperator. -
conditions: אובייקט מסוגConditionsשמכיל מערך של אובייקט אחד או יותר מסוגCondition.Conditionהוא השוואה בין ערך של שדה לערך אחר, כאשר שניהם הם מסוגstring,boolean,integer,double,TimestampאוTimeofDay.
אם תוצאת ההשוואה היא True, הרשומה מושמטת, ולהפך. אם הערכים שמשווים ביניהם הם לא מאותו סוג, מוצגת אזהרה והתנאי מקבל את הערך false.
טרנספורמציות הפיכות
כשמבטלים את הזיהוי של נתונים באמצעות הטרנספורמציות של סוגי המידע
CryptoReplaceFfxFpeConfig
או
CryptoDeterministicConfig, אפשר לשחזר פרטי זיהוי של הנתונים האלה, כל עוד יש לכם את
CryptoKey
ששימשו לביטול הזיהוי של הנתונים במקור.
מידע נוסף זמין במאמר בנושא טרנספורמציות של טוקניזציה מבוססת-הצפנה.
מגבלה על מספר הממצאים
אם בבקשה יש יותר מ-3,000 ממצאים, Sensitive Data Protection מחזיר את ההודעה הבאה:
Too many findings to de-identify. Retry with a smaller request.
רשימת הממצאים שמוחזרת מ-Sensitive Data Protection היא קבוצת משנה שרירותית של כל הממצאים בבקשה. כדי לקבל את כל הממצאים, צריך לפצל את הבקשה לקבוצות קטנות יותר.
המאמרים הבאים
מידע נוסף על האופן שבו תהליך עבודה של הסרת פרטים מזהים מתאים לפריסות בחיים האמיתיים
עוברים על ה-codelab בנושא צנזור מידע אישי רגיש באמצעות Sensitive Data Protection.
דוגמה שממחישה איך יוצרים מפתח עטוף, יוצרים טוקניזציה של תוכן ומבצעים שחזור פרטי זיהוי של תוכן שעבר טוקניזציה.
מידע נוסף על יצירת עותק של נתונים שעברו הסרת פרטים מזהים באחסון