במאמר הזה מוסבר איך ליצור ולבנות מחדש מילונים גדולים בהתאמה אישית. הוא גם כולל כמה תרחישי שגיאה.
מתי כדאי לבחור במילון מותאם אישית גדול ולא במילון מותאם אישית רגיל
גלאים רגילים של מילונים בהתאמה אישית מתאימים אם יש לכם עשרות אלפי מילים או ביטויים רגישים שאתם רוצים לסרוק בתוכן. אם יש לכם יותר מונחים או שרשימת המונחים משתנה לעיתים קרובות, כדאי ליצור מילון גדול בהתאמה אישית, שיכול לתמוך בעשרות מיליוני מונחים.
מה ההבדל בין מילונים גדולים בהתאמה אישית לבין סוגי מידע אישי אחרים בהתאמה אישית
מילונים גדולים בהתאמה אישית שונים מסוגי מידע מותאמים אישית אחרים בכך שכל מילון גדול בהתאמה אישית מורכב משני רכיבים:
- רשימה של ביטויים שאתם יוצרים ומגדירים. הרשימה מאוחסנת כקובץ טקסט ב-Cloud Storage או כעמודה בטבלה ב-BigQuery.
- קובצי המילון, שנוצרים על ידי Sensitive Data Protection ומאוחסנים ב-Cloud Storage. קובצי המילון מורכבים מעותק של רשימת המונחים שלכם וממסנני בלום, שעוזרים בחיפוש ובהתאמה.
יצירת מילון גדול בהתאמה אישית
בקטע הזה מוסבר איך ליצור, לערוך ולבנות מחדש מילון גדול בהתאמה אישית.
יצירת רשימת מונחים
יוצרים רשימה שמכילה את כל המילים והביטויים שאתם רוצים שהגלאי החדש של infoType יחפש. מבצעים אחת מהפעולות הבאות:
- מציבים קובץ טקסט עם כל מילה או ביטוי בשורה נפרדת בקטגוריה של 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 display name, מזינים שם לסוג המידע השמור.
אפשר להשתמש ברווחים ובסימני פיסוק בשם.
בשדה Description, מזינים תיאור של מה שסוג המידע השמור מזהה.
בקטע סוג אחסון, בוחרים את המיקום של רשימת המונחים:
- BigQuery: מזינים את מזהה הפרויקט, מזהה מערך הנתונים ומזהה הטבלה. בשדה Field name, מזינים את מזהה העמודה. אפשר להגדיר עמודה אחת לכל היותר מהטבלה.
- Google Cloud Storage: מזינים את הנתיב לקובץ.
בשדה Output bucket or folder, מזינים את המיקום ב-Cloud Storage של התיקייה שיצרתם בשלב 1.
לוחצים על יצירה.
מופיע סיכום של ה-infoType ששמור. כשהמילון נוצר וסוג המידע המאוחסן החדש מוכן לשימוש, הסטטוס של סוג המידע הוא 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. ה-methodcreateמקבל את הפרמטרים הבאים:- אובייקט
StoredInfoTypeConfig, שמכיל את ההגדרה של ה-infoType השמור. הוא כולל:-
description: תיאור המילון. -
displayName: השם שרוצים לתת למילון. LargeCustomDictionaryConfig: מכיל את ההגדרות של המילון הגדול בהתאמה אישית. הוא כולל:-
BigQueryField: מצוין אם רשימת המונחים מאוחסנת ב-BigQuery. כולל הפניה לטבלה שבה הרשימה מאוחסנת, וגם את השדה שמכיל כל ביטוי במילון. CloudStorageFileSet: מצוין אם רשימת המונחים מאוחסנת ב-Cloud Storage. כולל את כתובת ה-URL למיקום המקור ב-Cloud Storage, בפורמט הבא:"gs://[PATH_TO_GS]". יש תמיכה בתווים כלליים לחיפוש.-
outputPath: הנתיב למיקום בקטגוריה של Cloud Storage שבו יאוחסן המילון שנוצר.
-
-
-
storedInfoTypeId: המזהה של ה-infoType השמור. המזהה הזה משמש כדי להפנות ל-infoType השמור כשבונים אותו מחדש, מוחקים אותו או משתמשים בו במשימת בדיקה או במשימת הסרת פרטי זיהוי. אם משאירים את השדה הזה ריק, המערכת יוצרת מזהה בשבילכם.
- אובייקט
בהמשך מוצגת דוגמה ל-JSON שכאשר שולחים אותו ל-method storedInfoTypes.create, הוא יוצר stored infoType חדש – באופן ספציפי, גלאי מילון גדול בהתאמה אישית. בדוגמה הזו נוצר stored infoType מרשימת מונחים שמאוחסנת במסד נתונים שזמין לכולם ב-BigQuery (bigquery-public-data.samples.github_nested). מסד הנתונים מכיל את כל שמות המשתמשים ב-GitHub שנעשה בהם שימוש ב-commits. נתיב הפלט של המילון שנוצר מוגדר לקטגוריה של Cloud Storage בשם dlptesting, וה-infoType שמאוחסן נקרא 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.
מוסיפים, מסירים או משנים את המונחים או הביטויים לפי הצורך.
יוצרים גרסה חדשה של ה-infoType המאוחסן על ידי "בנייה מחדש" שלו באמצעות מסוף Google Cloud או באמצעות השיטה
storedInfoTypes.patch.בנייה מחדש יוצרת גרסה חדשה של המילון, שמחליפה את המילון הישן.
כשבונים מחדש גרסה חדשה של infoType מאוחסן, הגרסה הישנה נמחקת. בזמן ש-Sensitive Data Protection מעדכן את ה-infoType המאוחסן, הסטטוס שלו הוא pending. במהלך הזמן הזה, הגרסה הישנה של ה-infoType המאוחסן עדיין קיימת. כל הסריקות שתריצו בזמן שסוג המידע המאוחסן נמצא במצב המתנה יופעלו באמצעות הגרסה הישנה של סוג המידע המאוחסן.
כדי לבנות מחדש את ה-infoType השמור:
המסוף
- מעדכנים ושומרים את רשימת המונחים ב-Cloud Storage או ב-BigQuery.
במסוף Google Cloud , נכנסים לרשימה של סוגי המידע השמורים.
לוחצים על המזהה של ה-infoType השמור שרוצים לעדכן.
בדף InfoType details, לוחצים על Rebuild data.
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. מציינים את השם המלא של המשאב של ה-infoType השמור שרוצים לבנות מחדש.
התבניות הבאות מייצגות ערכים חוקיים בשדה name:
organizations/ORGANIZATION_ID/storedInfoTypes/STORED_INFOTYPE_IDprojects/PROJECT_ID/storedInfoTypes/STORED_INFOTYPE_ID
מחליפים את STORED_INFOTYPE_ID במזהה של ה-infoType המאוחסן שרוצים לבנות מחדש.
אם אתם לא יודעים את המזהה של ה-infoType השמור, אתם יכולים להפעיל את ה-method storedInfoTypes.list כדי לראות רשימה של כל ה-infoTypes השמורים הנוכחיים.
דוגמה
PATCH https://dlp.googleapis.com/v2/projects/PROJECT_ID/storedInfoTypes/STORED_INFOTYPE_ID
במקרה כזה, לא צריך גוף בקשה.
החלפת רשימת המונחים של המקור
אתם יכולים לשנות את רשימת המונחים של המקור של infoType מאוחסן, מרשימה שמאוחסנת ב-BigQuery לרשימה שמאוחסנת ב-Cloud Storage. משתמשים ב-method storedInfoTypes.patch, אבל כוללים אובייקט CloudStorageFileSet ב-LargeCustomDictionaryConfig במקום שבו השתמשתם באובייקט BigQueryField קודם לכן. אחר כך מגדירים את הפרמטר updateMask לפרמטר של סוג המידע המאוחסן שיצרתם מחדש, בפורמט 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.
סריקת תוכן באמצעות גלאי מילון גדול בהתאמה אישית
סריקת תוכן באמצעות גלאי מילון מותאם אישית גדול דומה לסריקת תוכן באמצעות כל גלאי infoType מותאם אישית אחר.
ההנחה היא שכבר יש לכם infoType מאוחסן. מידע נוסף מופיע בקטע יצירת stored infoType שבדף הזה.
המסוף
אפשר להחיל גלאי של מילון גדול בהתאמה אישית כשמבצעים את הפעולות הבאות:
- יצירת משימה חדשה
- יצירה או עריכה של טריגר של משימה
- יצירה או עריכה של תבנית
- הגדרת יצירת פרופילים של נתונים
בקטע Configure detection בדף, בסעיף המשנה InfoTypes, אתם יכולים לציין את ה-infoType של המילון הגדול בהתאמה אישית.
- לוחצים על Manage infoTypes.
- בחלונית InfoTypes, לוחצים על הכרטיסייה Custom.
- לוחצים על Add custom infoType.
בחלונית Add custom infoType:
- בשדה Type, בוחרים באפשרות Stored infoType.
- בשדה InfoType, מזינים שם ל-infoType בהתאמה אישית. אפשר להשתמש באותיות, במספרים ובקווים תחתונים.
בשדה Likelihood, בוחרים את רמת הסבירות שרוצים להקצות כברירת מחדל לכל הממצאים שתואמים לסוג ה-infoType המותאם אישית. אפשר גם לכוונן את רמת הסבירות של ממצאים ספציפיים באמצעות כללי הרחבה (Hotword).
אם לא מציינים ערך ברירת מחדל, רמת הסבירות שמוגדרת כברירת מחדל היא
VERY_LIKELY. מידע נוסף זמין במאמר סבירות להתאמה.בקטע Sensitivity, בוחרים את רמת הרגישות שרוצים להקצות לכל הממצאים שתואמים לסוג ה-infoType המותאם אישית הזה. אם לא תציינו ערך, רמות הרגישות של הממצאים האלה יוגדרו כ-
HIGH.ציוני רגישות משמשים בפרופילי נתונים. כשמגדירים פרופיל לנתונים, Sensitive Data Protection משתמש בציוני הרגישות של ה-infoTypes כדי לחשב את רמת הרגישות.
בשדה Stored infoType name, בוחרים את ה-infoType השמור שעליו רוצים לבסס את ה-infoType החדש בהתאמה אישית.
לוחצים על Done כדי לסגור את החלונית Add custom infoType.
אופציונלי: בכרטיסייה Built-in, עורכים את הבחירה של סוגי המידע המובנים.
לוחצים על Done כדי לסגור את החלונית InfoTypes.
ה-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
כששולחים את הדוגמה הבאה ל-method content.inspect, היא סורקת את הטקסט שצוין באמצעות הגלאי של stored infoType שצוין. הפרמטר infoType נדרש כי לכל סוגי המידע המותאמים אישית חייב להיות שם שלא מתנגש עם סוגי מידע מובנים או עם סוגי מידע מותאמים אישית אחרים. הפרמטר storedType מכיל את נתיב המשאב המלא של ה-infoType השמור.
קלט מסוג 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."
}
}
פתרון בעיות במקרה של שגיאות
אם אתם מקבלים הודעת שגיאה כשאתם מנסים ליצור stored infoType מרשימת מונחים שמאוחסנת ב-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" (
roles/storage.admin) או את התפקידים "בעלים של נתוני BigQuery" (roles/bigquery.dataOwner) ו"משתמש במשימות של BigQuery" (roles/bigquery.jobUser).
סקירה כללית על ממשקי API
אם אתם יוצרים גלאי מילון גדול בהתאמה אישית, אתם צריכים ליצור סוג מידע מאוחסן.
סוג infoType מאוחסן מיוצג ב-Sensitive Data Protection באמצעות האובייקט StoredInfoType. הוא מורכב מהאובייקטים הקשורים הבאים:
StoredInfoTypeVersionכולל את התאריך והשעה של היצירה, ואת חמש הודעות השגיאה האחרונות שהתרחשו כשהגרסה הנוכחית נוצרה.
StoredInfoTypeConfigמכיל את ההגדרה של infoType השמור, כולל השם והתיאור שלו. אם המילון המותאם אישית גדול, הערך של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: יוצרת stored infoType חדש לפי ה-StoredInfoTypeConfigשציינתם. -
storedInfoTypes.patch: בנייה מחדש של ה-infoType השמור עםStoredInfoTypeConfigחדש שאתם מציינים. אם לא מציינים גרסה, השיטה הזו יוצרת גרסה חדשה של ה-infoType השמור עם ה-StoredInfoTypeConfigהקיים. -
storedInfoTypes.get: מאחזר אתStoredInfoTypeConfigואת כל הגרסאות בהמתנה של ה-infoType שצוין ונשמר. -
storedInfoTypes.list: הצגת רשימה של כל סוגי המידע המאוחסנים הנוכחיים. storedInfoTypes.delete: מחיקה של ה-infoType השמור שצוין.