במאמר הזה מוסבר איך ליצור מילונים גדולים בהתאמה אישית ולבנות אותם מחדש. הוא גם כולל מידע על תרחישי שגיאה שונים.
מתי כדאי לבחור מילון מותאם אישית גדול במקום מילון מותאם אישית רגיל
מזהים רגילים של מילונים מותאמים אישית מספיקים אם יש לכם עשרות אלפי מילים או ביטויים רגישים שאתם רוצים לסרוק בתוכן שלכם. אם יש לכם יותר מ-10,000 מונחים או אם רשימת המונחים משתנה לעיתים קרובות, כדאי ליצור מילון מותאם אישית גדול, שיכול לתמוך בעשרות מיליוני מונחים.
מה ההבדל בין מילונים מותאמים אישית גדולים לבין סוגי מידע מותאמים אישית אחרים
מילונים גדולים בהתאמה אישית שונים מסוגי מידע אחרים בהתאמה אישית בכך שלכל מילון גדול בהתאמה אישית יש שני רכיבים:
- רשימה של ביטויים שאתם יוצרים ומגדירים. הרשימה מאוחסנת כקובץ טקסט ב-Cloud Storage או כעמוד בטבלה ב-BigQuery.
- קובצי המילון, שנוצרים על ידי Sensitive Data Protection ומאוחסנים ב-Cloud Storage. קבצי מילון מורכבים מעותק של רשימת המונחים שלכם בתוספת מסנני בלום, שמסייעים בחיפוש ובהתאמה.
יצירת מילון גדול בהתאמה אישית
בקטע הזה מוסבר איך ליצור, לערוך ולבנות מחדש מילון גדול בהתאמה אישית.
יצירת רשימת מונחים
יוצרים רשימה שמכילה את כל המילים והביטויים שרוצים שמנגנון זיהוי סוג המידע החדש יחפש. מבצעים אחת מהפעולות הבאות:
- ממקמים קובץ טקסט עם כל מילה או ביטוי בשורה נפרדת בקטגוריה של Cloud Storage.
- מגדירים עמודה אחת בטבלה ב-BigQuery כמאגר למילים ולביטויים. כל רשומה צריכה להיות בשורה נפרדת בעמודה. אפשר להשתמש בטבלה ב-BigQuery קיימת, בתנאי שכל המילים והביטויים במילון נמצאים בעמודה אחת.
יכול להיות שתצליחו ליצור רשימת מונחים גדולה מדי לעיבוד על ידי הכלי Sensitive Data Protection. אם מופיעה הודעת שגיאה, אפשר לעיין בקטע פתרון בעיות שגיאה בהמשך המאמר.
יצירה של infoType מאוחסן
אחרי שיוצרים את רשימת המונחים, משתמשים ב-Sensitive Data Protection כדי ליצור מילון:
המסוף
בקטגוריה של Cloud Storage, יוצרים תיקייה חדשה שבה Sensitive Data Protection ישמור את המילון שנוצר.
הכלי Sensitive Data Protection יוצר תיקיות שמכילות את קובצי המילון במיקום שאתם מציינים.
נכנסים לדף Create infoType במסוף Google Cloud .
בקטע סוג, בוחרים באפשרות מילון גדול בהתאמה אישית.
בשדה InfoType ID (מזהה InfoType), מזינים מזהה של InfoType מאוחסן.
תשתמשו במזהה הזה כשמגדירים את עבודות הבדיקה והסרת הפרטים המזהים. אפשר להשתמש באותיות, במספרים, במקפים ובקווים תחתונים בשם.
בשדה שם התצוגה של סוג המידע, מזינים שם לסוג המידע המאוחסן.
אפשר להשתמש ברווחים ובסימני פיסוק בשם.
בשדה תיאור, מזינים תיאור של מה שסוג המידע המאוחסן מגלה.
בשדה סוג אחסון, בוחרים את המיקום של רשימת המונחים:
- BigQuery: מזינים את מזהה הפרויקט, מזהה מערך הנתונים ומזהה הטבלה. בשדה Field name, מזינים את מזהה העמודה. אפשר להגדיר לכל היותר עמודה אחת מהטבלה.
- Google Cloud Storage: מזינים את הנתיב לקובץ.
בשדה Output bucket or folder (תיקייה או קטגוריה של פלט), מזינים את המיקום ב-Cloud Storage של התיקייה שיצרתם בשלב 1.
Sensitive Data Protection נשמרות.לוחצים על יצירה.
מוצג סיכום של סוג המידע המאוחסן. כשמילון נוצר וסוג המידע החדש שמאוחסן מוכן לשימוש, הסטטוס של סוג המידע הוא Ready (מוכן).
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
- יוצרים תיקייה חדשה למילון בקטגוריה של Cloud Storage. הכלי Sensitive Data Protection יוצר תיקיות שמכילות את קובצי המילון במיקום שאתם מציינים. יישמרו.
- יוצרים את המילון באמצעות ה-method
storedInfoTypes.create. השיטהcreateמקבלת את הפרמטרים הבאים:- אובייקט
StoredInfoTypeConfigשמכיל את ההגדרה של סוג המידע המאוחסן. היא כוללת:-
description: תיאור המילון. -
displayName: השם שרוצים לתת למילון. -
LargeCustomDictionaryConfig: מכיל את ההגדרה של מילון מותאם אישית גדול. היא כוללת:-
BigQueryField: הפרמטר הזה מצוין אם רשימת המונחים מאוחסנת ב-BigQuery. כולל הפניה לטבלה שבה הרשימה מאוחסנת, וגם לשדה שמכיל כל ביטוי במילון. -
CloudStorageFileSet: הערך הזה מצוין אם רשימת המונחים מאוחסנת ב-Cloud Storage. כולל את כתובת ה-URL של מיקום המקור ב-Cloud Storage, בפורמט הבא:"gs://[PATH_TO_GS]". יש תמיכה בתווים כלליים לחיפוש. -
outputPath: הנתיב למיקום בקטגוריה של Cloud Storage שבו יאוחסן המילון שנוצר.
-
-
-
storedInfoTypeId: המזהה של סוג המידע המאוחסן. משתמשים במזהה הזה כדי להתייחס לסוג המידע המאוחסן כשבונים אותו מחדש, מוחקים אותו או משתמשים בו בעבודת בדיקה או בעבודת הסרת פרטים מזהים. אם לא ממלאים את השדה הזה, המערכת יוצרת מזהה בשבילכם.
- אובייקט
זוהי דוגמה ל-JSON שכששולחים אותו לשיטת storedInfoTypes.create, הוא יוצר סוג מידע מאוחסן חדש – ספציפית, גלאי מילון מותאם אישית גדול. בדוגמה הזו נוצר סוג מידע מאוחסן מרשימת מונחים שמאוחסנת במסד נתונים ב-BigQuery שזמין לציבור (bigquery-public-data.samples.github_nested). מסד הנתונים מכיל את כל שמות המשתמשים ב-GitHub שנעשה בהם שימוש בהתחייבויות. נתיב הפלט של המילון שנוצר מוגדר לקטגוריה של Cloud Storage בשם dlptesting, וסוג המידע המאוחסן נקרא github-usernames.
קלט JSON
POST https://dlp.googleapis.com/v2/projects/PROJECT_ID/storedInfoTypes
{
"config":{
"displayName":"GitHub usernames",
"description":"Dictionary of GitHub usernames used in commits",
"largeCustomDictionary":{
"outputPath":{
"path":"gs://[PATH_TO_GS]"
},
"bigQueryField":{
"table":{
"datasetId":"samples",
"projectId":"bigquery-public-data",
"tableId":"github_nested"
}
}
}
},
"storedInfoTypeId":"github-usernames"
}
בנייה מחדש של המילון
כדי לעדכן את המילון, קודם מעדכנים את רשימת מונחי המקור, ואז מנחים את Sensitive Data Protection לבנות מחדש את ה-infoType המאוחסן.
מעדכנים את רשימת מונחי המקור הקיימת ב-Cloud Storage או ב-BigQuery.
מוסיפים, מסירים או משנים את המונחים או הצירופים לפי הצורך.
כדי ליצור גרסה חדשה של סוג המידע המאוחסן, צריך 'לבנות אותו מחדש' באמצעות מסוף Google Cloud או באמצעות השיטה
storedInfoTypes.patch.בנייה מחדש יוצרת גרסה חדשה של המילון, שמחליפה את המילון הישן.
כשבונים מחדש סוג מידע מאוחסן לגרסה חדשה, הגרסה הישנה נמחקת. בזמן ש-Sensitive Data Protection מעדכן את ה-infoType המאוחסן, הסטטוס שלו הוא pending. במהלך הזמן הזה, הגרסה הישנה של סוג המידע המאוחסן עדיין קיימת. כל הסריקות שתריצו בזמן שסוג המידע המאוחסן נמצא במצב 'בהמתנה' יפעלו באמצעות הגרסה הישנה של סוג המידע המאוחסן.
כדי לבנות מחדש את סוג המידע שמאוחסן:
המסוף
- מעדכנים ושומרים את רשימת המונחים ב-Cloud Storage או ב-BigQuery.
במסוף Google Cloud , עוברים לרשימת סוגי המידע (infoType) שנשמרו.
לוחצים על המזהה של סוג המידע המאוחסן שרוצים לעדכן.
בדף פרטים של סוג המידע, לוחצים על בנייה מחדש של הנתונים.
Sensitive Data Protection בונה מחדש את ה-infoType המאוחסן עם השינויים שביצעתם ברשימת מונחי המקור. אחרי שהסטטוס של infoType המאוחסן הוא Ready (מוכן), אפשר להשתמש בו. כל התבניות או הטריגרים של העבודות שמשתמשים ב-infoType המאוחסן ישתמשו אוטומטית בגרסה שנבנתה מחדש.
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
עדכון רשימת המונחים
אם אתם מעדכנים רק את רשימת המונחים במילון הגדול המותאם אישית, הבקשה שלכם storedInfoTypes.patch צריכה לכלול רק את השדה name. מזינים את השם המלא של המשאב של סוג המידע המאוחסן שרוצים לבנות מחדש.
הדפוסים הבאים מייצגים ערכים תקינים בשדה name:
organizations/ORGANIZATION_ID/storedInfoTypes/STORED_INFOTYPE_IDprojects/PROJECT_ID/storedInfoTypes/STORED_INFOTYPE_ID
מחליפים את STORED_INFOTYPE_ID במזהה של סוג המידע המאוחסן שרוצים לבנות מחדש.
אם אתם לא יודעים מה המזהה של סוג המידע המאוחסן, אתם יכולים להפעיל את השיטה
storedInfoTypes.list
כדי לראות רשימה של כל סוגי המידע המאוחסנים הנוכחיים.
דוגמה
PATCH https://dlp.googleapis.com/v2/projects/PROJECT_ID/storedInfoTypes/STORED_INFOTYPE_ID
במקרה כזה, אין צורך בגוף הבקשה.
החלפת רשימת מונחי המקור
אפשר לשנות את רשימת מונחי המקור של סוג מידע מאוחסן, מאחסון ב-BigQuery לאחסון ב-Cloud Storage. משתמשים בשיטה storedInfoTypes.patch, אבל כוללים אובייקט CloudStorageFileSet ב-LargeCustomDictionaryConfig במקום אובייקט BigQueryField שבו השתמשתם קודם. לאחר מכן מגדירים את הפרמטר updateMask לפרמטר infoType שאוחסן ושבניתם מחדש, בפורמט FieldMask. לדוגמה, ב-JSON הבא מצוין בפרמטר updateMask שכתובת ה-URL של הנתיב ב-Cloud Storage עודכנה (large_custom_dictionary.cloud_storage_file_set.url):
דוגמה
PATCH https://dlp.googleapis.com/v2/projects/PROJECT_ID/storedInfoTypes/github-usernames
{
"config":{
"largeCustomDictionary":{
"cloudStorageFileSet":{
"url":"gs://[BUCKET_NAME]/[PATH_TO_FILE]"
}
}
},
"updateMask":"large_custom_dictionary.cloud_storage_file_set.url"
}
באופן דומה, אפשר להחליף את רשימת המונחים מרשימה שמאוחסנת בטבלה ב-BigQuery לרשימה שמאוחסנת בקטגוריה של Cloud Storage.
סריקת תוכן באמצעות מזהה מותאם אישית של מילון גדול
סריקת תוכן באמצעות מזהה מילון מותאם אישית גדול דומה לסריקת תוכן באמצעות כל מזהה אחר של סוג מידע מותאם אישית.
ההליך הזה מניח שיש לכם סוג מידע מאוחסן קיים. מידע נוסף זמין במאמר בנושא יצירת סוג מידע מאוחסן בדף הזה.
המסוף
אפשר להחיל מזהה מילון גדול בהתאמה אישית כשמבצעים את הפעולות הבאות:
- יצירת משרה חדשה
- יצירה או עריכה של טריגר להפעלת משימה
- יצירה או עריכה של תבנית
- הגדרה של פרופיל נתונים
בקטע Configure detection בדף, בקטע המשנה InfoTypes, אפשר לציין את סוג המידע של המילון הגדול בהתאמה אישית.
- לוחצים על ניהול סוגי מידע.
- בחלונית InfoTypes, לוחצים על הכרטיסייה Custom.
- לוחצים על הוספת סוג מידע בהתאמה אישית.
בחלונית Add custom infoType (הוספת סוג מידע מותאם אישית):
- בשדה Type, בוחרים באפשרות Stored infoType.
- בשדה InfoType, מזינים שם לסוג המידע המותאם אישית. אפשר להשתמש באותיות, במספרים ובקווים תחתונים.
בקטע סבירות, בוחרים את רמת הסבירות שרוצים להקצות כברירת מחדל לכל הממצאים שתואמים לסוג המידע המותאם אישית הזה. אפשר לכוונן עוד יותר את רמת הסבירות של ממצאים ספציפיים באמצעות כללים של מילות הפעלה.
אם לא מציינים ערך ברירת מחדל, רמת הסבירות שמוגדרת כברירת מחדל היא
VERY_LIKELY. מידע נוסף זמין במאמר בנושא הסתברות להתאמה.בקטע רגישות, בוחרים את רמת הרגישות שרוצים להקצות לכל הממצאים שתואמים לסוג המידע המותאם אישית הזה. אם לא מציינים ערך, רמות הרגישות של הממצאים האלה מוגדרות כ
HIGH.ציוני הרגישות משמשים בפרופילים של נתונים. כשמבצעים פרופיל לנתונים, Sensitive Data Protection משתמש בציוני הרגישות של ה-infoTypes כדי לחשב את רמת הרגישות.
בשדה Stored infoType name, בוחרים את סוג המידע המאוחסן שרוצים לבסס עליו את סוג המידע החדש בהתאמה אישית.
לוחצים על סיום כדי לסגור את החלונית הוספת סוג מידע בהתאמה אישית.
אופציונלי: בכרטיסייה Built-in (מוכלל), עורכים את הבחירה של סוגי המידע המוכללים.
לוחצים על סיום כדי לסגור את החלונית סוגי מידע.
ה-infoType המותאם אישית יתווסף לרשימת ה-infoTypes ש-Sensitive Data Protection סורק. עם זאת, הבחירה הזו לא סופית עד שתשמרו את העבודה, את טריגר העבודה, את התבנית או את הגדרות הסריקה.
כשמסיימים ליצור או לערוך את ההגדרה, לוחצים על שמירה.
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
בדוגמה הבאה, הטקסט שצוין נסרק באמצעות גלאי מסוג infoType מאוחסן שצוין, כששולחים אותו לשיטה content.inspect. הפרמטר infoType נדרש כי לכל סוגי המידע המותאמים אישית צריך להיות שם שלא מתנגש עם סוגי מידע מובנים או עם סוגי מידע מותאמים אישית אחרים. הפרמטר storedType מכיל את הנתיב המלא של המשאב של סוג המידע המאוחסן.
קלט JSON
POST https://dlp.googleapis.com/v2/projects/PROJECT_ID/content:inspect
{
"inspectConfig":{
"customInfoTypes":[
{
"infoType":{
"name":"GITHUB_LOGINS"
},
"storedType":{
"name":"projects/PROJECT_ID/storedInfoTypes/github-logins"
}
}
]
},
"item":{
"value":"The commit was made by githubuser."
}
}
פתרון בעיות במקרה של שגיאות
אם מופיעה שגיאה כשמנסים ליצור סוג מידע מאוחסן מרשימת מונחים שמאוחסנת ב-Cloud Storage, יכולות להיות לכך הסיבות הבאות:
- הגעת למגבלה עליונה על סוגי מידע מאוחסנים. בהתאם לבעיה, יש כמה פתרונות עקיפים:
- אם נתקלתם במגבלה העליונה של קובץ קלט יחיד ב-Cloud Storage (200MB), נסו לפצל את הקובץ לכמה קבצים. אפשר להשתמש בכמה קבצים כדי להרכיב מילון מותאם אישית אחד, כל עוד הגודל הכולל של כל הקבצים לא עולה על 1GB.
- ב-BigQuery אין את אותן מגבלות כמו ב-Cloud Storage. אפשר להעביר את התנאים לטבלה ב-BigQuery. הגודל המקסימלי של עמודה של מילון מותאם אישית ב-BigQuery הוא 1GB, ומספר השורות המקסימלי הוא 5,000,000.
- אם קובץ רשימת המונחים חורג מכל המגבלות הרלוונטיות לרשימות של מונחי מקור, צריך לפצל את קובץ רשימת המונחים לכמה קבצים וליצור מילון לכל קובץ. לאחר מכן, יוצרים עבודת סריקה נפרדת לכל מילון.
- אחד או יותר מהמונחים שלכם לא מכילים לפחות אות אחת או מספר אחד. הכלי Sensitive Data Protection לא יכול לסרוק מונחים שמורכבים רק מרווחים או מסמלים. צריך להוסיף לפחות אות אחת או מספר אחד. בודקים את רשימת המונחים כדי לראות אם יש בה מונחים כאלה, ואז מתקנים או מוחקים אותם.
- רשימת המונחים שלך מכילה ביטוי עם יותר מדי 'רכיבים'. רכיב בהקשר הזה הוא רצף רציף שמכיל רק אותיות, רק מספרים או רק תווים שהם לא אותיות ולא ספרות, כמו רווחים או סמלים. צריך לבדוק את רשימת המונחים ולראות אם יש בה מונחים כאלה, ואז לתקן או למחוק אותם.
- לסוכן השירות של Sensitive Data Protection אין גישה לנתוני המקור של המילון או לקטגוריה של Cloud Storage שבה מאוחסנים קובצי המילון. כדי לפתור את הבעיה הזו, צריך להעניק לסוכן השירות של Sensitive Data Protection את התפקיד Storage Admin (
roles/storage.admin) או את התפקידים BigQuery Data Owner (roles/bigquery.dataOwner) ו-BigQuery Job User (roles/bigquery.jobUser).
סקירה כללית על ממשקי API
חובה ליצור סוג מידע מאוחסן אם יוצרים מזהה מילון גדול בהתאמה אישית.
ב-Sensitive Data Protection, סוג מידע מאוחסן מיוצג על ידי האובייקט StoredInfoType. הוא מורכב מהאובייקטים הקשורים הבאים:
StoredInfoTypeVersionכולל את התאריך והשעה של היצירה ואת חמש הודעות השגיאה האחרונות שהתרחשו כשנוצרה הגרסה הנוכחית.
StoredInfoTypeConfigמכיל את ההגדרה של סוג המידע המאוחסן, כולל השם והתיאור שלו. אם המילון המותאם אישית גדול,typeצריך להיותLargeCustomDictionaryConfig.-
LargeCustomDictionaryConfigמציין את שני הדברים הבאים:- המיקום ב-Cloud Storage או ב-BigQuery שבו מאוחסנת רשימת הביטויים.
- המיקום ב-Cloud Storage שבו יישמרו קובצי המילון שנוצרו.
-
StoredInfoTypeStateמכיל את המצב של הגרסה העדכנית ביותר ושל גרסאות ממתינות של ה-infoType המאוחסן. פרטי המצב כוללים מידע על סוג המידע המאוחסן, למשל אם הוא נבנה מחדש, מוכן לשימוש או לא תקין.
פרטים ספציפיים לגבי התאמה במילון
בהמשך מוסבר איך התכונה Sensitive Data Protection מתאימה מילים וביטויים במילון. הנקודות האלה רלוונטיות גם למילונים רגילים בהתאמה אישית וגם למילונים גדולים בהתאמה אישית:
- המילים במילון הן לא תלויות-רישיות. אם המילון שלכם כולל את
Abby, הוא יתאים ל-abby, ל-ABBY, ל-Abbyוכן הלאה. - כל התווים – במילונים או בתוכן שצריך לסרוק – מלבד אותיות, ספרות ותווים אלפביתיים אחרים שנכללים ב-Basic Multilingual Plane של Unicode, נחשבים לרווחים כשסורקים התאמות. אם המילון שלכם סורק את
Abby Abernathy, הוא יתאים ל-abby abernathy, ל-Abby, Abernathy, ל-Abby (ABERNATHY)וכן הלאה. - התווים שמקיפים התאמה כלשהי צריכים להיות מסוג שונה (אותיות או ספרות) מהתווים הסמוכים בתוך המילה. אם המילון שלכם סורק את
Abi, הוא יתאים לשלוש התווים הראשונים שלAbi904, אבל לא שלAbigail. - מילים במילון שמכילות תווים במישור הרב-לשוני המשני של תקן Unicode עשויות להניב ממצאים לא צפויים. דוגמאות לתווים כאלה: סמלי אמוג'י, סמלים מדעיים וכתבים היסטוריים.
ההגדרה של אותיות, ספרות ותווים אלפביתיים אחרים היא כדלקמן:
- אותיות: תווים עם קטגוריות כלליות
Lu,Ll,Lt,LmאוLoבמפרט Unicode - ספרות: תווים עם קטגוריה כללית
Ndבמפרט Unicode - תווים אלפביתיים אחרים: תווים עם קטגוריה כללית
Nlבמפרט Unicode או עם מאפיין תורםOther_Alphabeticכפי שמוגדר בתקן Unicode
כדי ליצור, לערוך או למחוק סוג מידע מאוחסן, משתמשים בשיטות הבאות:
-
storedInfoTypes.create: יוצר סוג מידע מאוחסן חדש בהתאם ל-StoredInfoTypeConfigשאתם מציינים. -
storedInfoTypes.patch: בנייה מחדש של infoType מאוחסן עםStoredInfoTypeConfigחדש שאתם מציינים. אם לא מצוין אף אחד, השיטה הזו יוצרת גרסה חדשה של סוג המידע המאוחסן עםStoredInfoTypeConfigקיים. -
storedInfoTypes.get: מאחזר אתStoredInfoTypeConfigואת כל הגרסאות בהמתנה של סוג המידע המאוחסן שצוין. -
storedInfoTypes.list: מציג רשימה של כל סוגי המידע הנוכחיים שמאוחסנים. -
storedInfoTypes.delete: מחיקת סוג המידע המאוחסן שצוין.