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