האפשרות לציין אזור שבו יתבצעו הפעולות של 'הגנה על מידע רגיש' מאפשרת לכם לשלוט במיקום שבו יעובדו הנתונים הרגישים הפוטנציאליים שלכם. במאמר הזה מוסבר המושג 'מיקום העיבוד של Sensitive Data Protection' ומוסבר איך לציין אזור.
רשימה של אזורים נתמכים ואזורים מרובים זמינה במאמר מיקומים של Sensitive Data Protection.
מידע על אזורים ועל אזורים מרובים
אזור – מקום גיאוגרפי ספציפי, כמו מערב ארצות הברית או צפון-מזרח אסיה. מיקום במספר אזורים (או פשוט מספר אזורים) הוא אזור גיאוגרפי נרחב, כמו האיחוד האירופי, שכולל שני אזורים גיאוגרפיים או יותר.
שיקולים בקשר למיקום
מיקום טוב מאזן בין זמן האחזור, הזמינות ועלויות רוחב הפס.
כדאי להשתמש באזור כדי לבצע אופטימיזציה של זמן האחזור ורוחב הפס של הרשת.
משתמשים במרחב רב-אזורי כשרוצים לעבד נתונים שמגיעים מחוץ לרשת של Google ומתפלגים על פני אזורים גיאוגרפיים גדולים, או כשרוצים את הזמינות הגבוהה יותר שמתקבלת מיתירות באזורים שונים.
בדרך כלל, כדאי לעבד את הנתונים במיקום שנוח לכם או שרוב המשתמשים של הנתונים נמצאים בו.
אם הארגון שלכם נדרש לשמור נתונים במעבר במיקום מסוים, אתם צריכים להשתמש רק באזורים או במספר אזורים שתומכים בנקודות קצה אזוריות. במקרה כזה, צריך להשתמש ב-Cloud Data Loss Prevention API, כי נקודות הקצה האזוריות של Sensitive Data Protection לא זמינות לשימוש עם מסוףGoogle Cloud .
ציון אזור
אופן ציון אזור העיבוד תלוי בסוג נקודת הקצה שאליה נשלחת הבקשה – נקודת קצה גלובלית או נקודת קצה אזורית. סוג נקודת הקצה שבוחרים תלוי בדרישה לשמירת נתונים במעבר באזור מסוים. מידע נוסף זמין במאמר בנושא נקודות קצה (endpoint) גלובליות ואזוריות של Sensitive Data Protection.
ציון אזור בבקשה לנקודת הקצה הגלובלית
המסוף
כשמגדירים את הפעולה של Sensitive Data Protection, צריך לבחור אזור.
לדוגמה, כשיוצרים טריגר להפעלת משימה, בוחרים מיקום מהתפריט מיקום המשאב, כמו שמוצג כאן:
אם מיקום העיבוד לא חשוב לכם, תוכלו להשתמש באזור Global ו-Google תבחר את המיקום שבו העיבוד יתבצע. Global היא ברירת המחדל של האזור.
REST
מוסיפים את פרטי האזור לכתובת ה-URL של נקודת הקצה של הבקשה. אם מיקום העיבוד לא חשוב לכם, תוכלו להשתמש באזור global ו-Google תבחר את המיקום שבו יתבצע העיבוד. שימו לב שכל משאב שנוצר על ידי בקשה שמצוין בה אזור global מאוחסן באזור global.
הנה כמה דוגמאות לבקשות לנקודת הקצה הגלובלית.
שימוש באזור הגלובלי
לשתי הבקשות הבאות יש את אותה השפעה. אם לא מציינים אזור, זה כמו לציין locations/global/.
POST https://www.googleapis.com/dlp/v2/projects/PROJECT_ID/locations/global/content:inspect
POST https://www.googleapis.com/dlp/v2/projects/PROJECT_ID/content:inspect
שימוש באזור ספציפי
כדי לציין אזור לעיבוד, מוסיפים לכתובת ה-URL של המשאב את המחרוזת locations/ ואחריה את שם האזור.
POST https://www.googleapis.com/dlp/v2/projects/PROJECT_ID/locations/us-west2/content:inspect
ציון אזור בבקשה לנקודת קצה אזורית
המסוף
ב-Sensitive Data Protection, אי אפשר להשתמש בנקודות קצה אזוריות עם מסוף Google Cloud .
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. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
REST
בדוגמה הבאה נשלחת בקשת content.inspect לנקודת קצה אזורית.
כל הנתונים שמצורפים לבקשה הזו נשארים באזור שצוין בזמן ההעברה, השימוש ובמצב מנוחה.
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
-
REGION: אזור שבו זמין endpoint אזורי ל-Sensitive Data Protection, לדוגמה:us-west2. רשימה מלאה של האזורים זמינה במאמר מיקומים של Sensitive Data Protection. -
PROJECT_ID: מזהה הפרויקט ב- Google Cloud . מזהי פרויקטים הם מחרוזות אלפאנומריות, כמוexample-project.
ה-method של ה-HTTP וכתובת ה-URL:
POST https://dlp.REGION.rep.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/content:inspect
תוכן בקשת JSON:
{
"inspectConfig": {
"infoTypes": [
{
"name": "CREDIT_CARD_NUMBER"
}
]
},
"item": {
"value": "hi, my ccn is 4111111111111111"
}
}
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
{
"result": {
"findings": [
{
"infoType": {
"name": "CREDIT_CARD_NUMBER",
"sensitivityScore": {
"score": "SENSITIVITY_HIGH"
}
},
"likelihood": "LIKELY",
"location": {
"byteRange": {
"start": "14",
"end": "30"
},
"codepointRange": {
"start": "14",
"end": "30"
}
},
"createTime": "2024-08-09T19:54:13.348Z",
"findingId": "2024-08-09T19:54:13.352163Z4747901452516738787"
}
]
}
}שיקולים לגבי מיקום משותף
כשסורקים מאגר אחסון כמו Cloud Storage או BigQuery, צריך לציין בבקשת Sensitive Data Protection את אותו מיקום שבו נמצא המאגר שסורקים. לדוגמה, אם מערך הנתונים ב-BigQuery נמצא במיקום במספר אזורים באיחוד האירופי, צריך לציין את המיקום במספר אזורים באיחוד האירופי (europe) כשמגדירים את העבודה של Sensitive Data Protection.
אם לא תמקמו את הבקשה ל-Sensitive Data Protection באותו מיקום עם מאגר האחסון שאתם סורקים, יכול להיות שהעיבוד של הבקשה יפוצל בין מיקום הנתונים לבין המיקום שצוין בבקשה.
המאמרים הבאים
- מידע נוסף על מיקום גיאוגרפי ואזורים
- רשימת האזורים והאזורים המרובים הנתמכים
- מידע נוסף על נקודות קצה גלובליות ואזוריות עבור Sensitive Data Protection