יצירת פרופיל של נתונים ב-Azure Blob Storage

בדף הזה מוסבר איך להגדיר גילוי של Sensitive Data Protection ב-Azure Blob Storage. התכונה הזו זמינה רק ללקוחות שהפעילו את Security Command Center ברמת Enterprise.

בעזרת Sensitive Data Protection אתם יכולים לגלות את סוגי הנתונים שאתם מאחסנים ב-Blob Storage ואת רמות הרגישות של הנתונים. כשאתם יוצרים פרופיל של הנתונים ב-Blob Storage, אתם יוצרים פרופילי נתונים של מאגרי קבצים, שמספקים תובנות ומטא-נתונים על מאגרי Blob Storage. לכל מאגר Blob Storage, פרופיל נתונים של חנות קבצים כולל את הפרטים הבאים:

• סוגי הקבצים שמאוחסנים במאגר, מחולקים לאשכולות של קבצים
• רמת הרגישות של הנתונים במאגר
• סיכום של כל אשכול קבצים שזוהה, כולל סוגי המידע הרגיש שנמצאו

רשימה מלאה של התובנות והמטא-נתונים בכל פרופיל נתונים של מאגר קבצים מופיעה במאמר פרופילים של נתונים במאגר קבצים.

מידע נוסף על שירות הגילוי זמין במאמר פרופילי נתונים.

תהליך עבודה

תהליך העבודה הכללי ליצירת פרופיל של נתונים ב-Azure Blob Storage:

1. ב-Security Command Center, יוצרים מחבר ל-Microsoft Azure. חשוב לבחור באפשרות הענקת הרשאות לגילוי של Sensitive Data Protection.

2. יוצרים תבנית בדיקה באזור global או באזור שבו מתכננים לאחסן את ההגדרה של סריקת הגילוי ואת כל פרופילי הנתונים שנוצרו.

3. יוצרים הגדרת סריקה של Discovery עבור Azure Blob Storage.

   הכלי Sensitive Data Protection יוצר פרופיל של הנתונים לפי לוח הזמנים שאתם מציינים.

שיקולים לגבי מיקום אחסון הנתונים

כשמתכננים ליצור פרופיל של נתונים מספקי שירותי ענן אחרים, כדאי להביא בחשבון את הדברים הבאים:

• פרופילי הנתונים נשמרים לצד ההגדרות של סריקת הגילוי. לעומת זאת, כשיוצרים פרופיל של נתונים ב- Google Cloud , הפרופילים מאוחסנים באותו אזור שבו מאוחסנים הנתונים שיוצרים להם פרופיל.
• אם מאחסנים את תבנית הבדיקה באזור global, נערכת קריאה של עותק בזיכרון של התבנית באזור שבו מאחסנים את הגדרת סריקת הגילוי.
• הנתונים שלכם לא משתנים. עותק של הנתונים בזיכרון נקרא באזור שבו מאוחסנת ההגדרה של סריקת הגילוי. עם זאת, Sensitive Data Protection לא מבטיח איפה הנתונים יעברו אחרי שהם יגיעו לאינטרנט הציבורי. הנתונים מוצפנים באמצעות SSL.

קבצים ומאגרים ריקים

החיפוש לא סורק קבצים ומאגרים ריקים של Blob Storage, ולא לוקח אותם בחשבון כשהוא מציג את סיומות הקבצים שנמצאו. מאגר שמכיל רק קבצים ריקים נחשב גם הוא למאגר ריק.

לפני שמתחילים

1. ב-Security Command Center, יוצרים מחבר ל-Microsoft Azure. למידע נוסף, קראו את המאמר התחברות ל-Microsoft Azure לצורך איסוף נתוני הגדרות ומשאבים במסמכי התיעוד של Security Command Center.

2. מוודאים שיש לכם את הרשאות ה-IAM שנדרשות להגדרת פרופילי נתונים ברמת הארגון.

   גם אם אין לכם את התפקיד Organization Administrator (roles/resourcemanager.organizationAdmin) או Security Admin (roles/iam.securityAdmin), אתם יכולים ליצור הגדרת סריקה. עם זאת, אחרי שיוצרים את הגדרת הסריקה, משתמש עם אחד מהתפקידים האלה צריך לתת לסוכן השירות גישה ליצירת פרופיל נתונים.

3. מוודאים שיש לכם תבנית בדיקה באזור global או באזור שבו אתם מתכננים לאחסן את ההגדרה של סריקת הגילוי ואת כל פרופילי הנתונים שנוצרו.

   המשימה הזו מאפשרת ליצור באופן אוטומטי תבנית בדיקה רק באזור global. אם מדיניות הארגון מונעת מכם ליצור תבנית בדיקה באזור global, לפני שתבצעו את המשימה הזו, תצטרכו ליצור תבנית בדיקה באזור שבו אתם מתכננים לאחסן את הגדרת הסריקה לגילוי.

4. כדי לשלוח התראות Pub/Sub לנושא כשאירועים מסוימים מתרחשים – למשל כש-Sensitive Data Protection יוצר פרופיל של מאגר חדש – צריך ליצור נושא Pub/Sub לפני ביצוע המשימה הזו.

כדי ליצור פרופילים של נתונים, צריך מאגר של סוכני שירות וסוכן שירות בתוכו. המשימה הזו מאפשרת ליצור אותם באופן אוטומטי.

יצירת הגדרות סריקה

1. נכנסים לדף Create scan configuration.

   כניסה לדף Create scan configuration

2. עוברים לארגון. בסרגל הכלים, לוחצים על בורר הפרויקטים ובוחרים את הארגון.

בקטעים הבאים מוסבר בהרחבה על השלבים בדף יצירת הגדרת סריקה. בסיום כל קטע, לוחצים על המשך.

בוחרים סוג גילוי.

בוחרים באפשרות Azure Blob Storage.

בחירת היקף הרשאות

מבצעים אחת מהפעולות הבאות:

• כדי לסרוק את כל הנכסים ב-Blob Storage שיש למחבר Azure שלכם גישה אליהם, בוחרים באפשרות סריקת כל הנכסים ב-Azure שזמינים דרך המחבר.
• כדי לסרוק את הנתונים ב-Blob Storage במינוי אחד ל-Azure, בוחרים באפשרות Scan one Azure subscription. מזינים את מזהה המינוי.
• כדי לסרוק מאגר אחד של Blob Storage, בוחרים באפשרות Scan one Azure Blob Storage container. מזינים את פרטי המאגר שרוצים לסרוק.

ניהול לוחות הזמנים

אם תדירות יצירת הפרופילים שמוגדרת כברירת מחדל מתאימה לצרכים שלכם, אתם יכולים לדלג על החלק הזה בדף Create scan configuration.

כדאי להגדיר את הקטע הזה מהסיבות הבאות:

• כדי לבצע שינויים מדויקים בתדירות יצירת הפרופילים של כל הנתונים או של קבוצות משנה מסוימות של הנתונים.
• כדי לציין את הקונטיינרים שלא רוצים ליצור להם פרופיל.
• כדי לציין את מאגרי הנתונים שאתם לא רוצים ליצור להם פרופיל יותר מפעם אחת.

כדי לבצע התאמות מדויקות בתדירות יצירת הפרופילים, פועלים לפי השלבים הבאים:

1. לוחצים על הוספת לוח זמנים.

   הערה: אם בחרתם מאגר תגים יחיד כהיקף של ההגדרה הזו, לא תוכלו להוסיף לוח זמנים. אפשר לערוך רק את התזמון של כתובת catch-all. בנוסף, אי אפשר לציין מסננים. אפשר לערוך רק את התדירות והתנאים של יצירת הפרופיל.

2. בקטע Filters, מגדירים מסנן אחד או יותר כדי לציין אילו מאגרים נכללים בהיקף של לוח הזמנים. מאגר נחשב כנמצא בהיקף של לוח הזמנים אם הוא תואם לפחות לאחד מהמסננים שהוגדרו.

   כדי להגדיר מסנן, מציינים לפחות אחד מהערכים הבאים:

   • מזהה מינוי או ביטוי רגולרי שמציין מזהה מינוי אחד או יותר
   • שם מאגר או ביטוי רגולרי שמציין מאגר אחד או יותר

   הביטויים הרגולריים צריכים להיות בהתאם לתחביר RE2.

   לדוגמה, אם רוצים שכל מאגרי התגים בחשבון ייכללו במסנן, מזינים את מזהה המינוי בשדה מזהה המינוי.

   כדי להתאים למסנן, מאגר תגים צריך לעמוד בכל הביטויים הרגולריים שצוינו במסנן.

   כדי להוסיף עוד מסננים, לוחצים על הוספת מסנן וחוזרים על השלב הזה.

3. לוחצים על תדירות.

4. בקטע Frequency, מציינים אם ליצור פרופיל של הקונטיינרים שנבחרו, ואם כן, באיזו תדירות:

   • אם אתם לא רוצים שהמאגרים יאופיינו אף פעם, השביתו את האפשרות אפיון הנתונים האלה.

   • אם רוצים שהמאגרים יתועדו לפחות פעם אחת, צריך להשאיר את האפשרות תיעוד הנתונים האלה מופעלת.

     מציינים אם צריך ליצור פרופיל חדש לנתונים ואילו אירועים צריכים להפעיל את הפעולה הזו. מידע נוסף זמין במאמר תדירות היצירה של פרופילי נתונים.

     1. אם בחרתם באפשרות On a schedule, ציינו באיזו תדירות אתם רוצים שהקונטיינרים יעברו פרופיילינג מחדש. הפרופילים של הקונטיינרים נוצרים מחדש בלי קשר לשאלה אם הם עברו שינויים כלשהם.
     2. בשדה When inspect template changes, מציינים אם רוצים ליצור פרופיל מחדש לנתונים כשמעדכנים את תבנית הבדיקה המשויכת, ואם כן, באיזו תדירות.
        הערה: אתם מציינים את תבניות הבדיקה שבהן אתם רוצים להשתמש בשלב בחירת תבנית בדיקה בדף הזה.

        שינוי בתבנית בדיקה מזוהה באחד מהמקרים הבאים:

        • השם של תבנית הבדיקה משתנה בהגדרת הסריקה.
        • הערך של updateTime בתבנית בדיקה משתנה.

     לדוגמה, אם הגדרתם תבנית בדיקה לאזור us-west1 ועדכנתם את תבנית הבדיקה הזו, רק הנתונים באזור us-west1 יוגדרו מחדש.

5. אופציונלי: לוחצים על תנאים.

   בקטע Conditions מציינים את התנאים שבהם המאגרים (שהוגדרו במסננים) צריכים לעמוד כדי ש-Sensitive Data Protection יצור להם פרופיל.

   כברירת מחדל, Sensitive Data Protection סורק את כל האובייקטים במאגר. אם רוצים לסרוק רק את האובייקטים ברמת גישה מסוימת של Blob, בוחרים את רמות הגישה האלה. כדי לכלול אובייקטים מסוג blob שאין להם רמת גישה, בוחרים באפשרות לא רלוונטי.

6. לוחצים על סיום.

7. אופציונלי: כדי להוסיף עוד לוחות זמנים, לוחצים על Add schedule וחוזרים על השלבים הקודמים.

8. כדי לציין את סדר העדיפויות בין לוחות הזמנים, משנים את הסדר שלהם באמצעות החיצים למעלה ו- למטה.

   סדר לוחות הזמנים קובע איך לפתור התנגשויות בין לוחות זמנים. אם מאגר תואם למסננים של שני לוחות זמנים שונים, התדירות שבה יתבצע פרופיל המשתמשים במאגר הזה תהיה התדירות שמוגדרת בלוח הזמנים שמופיע גבוה יותר ברשימת לוחות הזמנים.

   הערה: אם מצב התמחור של הסריקה הוא מצב מינוי, קצב יצירת הפרופילים של הנתונים ב-Sensitive Data Protection מושפע מהקיבולת שרכשתם. כדי לדעת מה הקיבולת היומית שלכם ליצירת פרופילים, אפשר לעיין במאמר בנושא מעקב אחרי ניצול. אם הקצאתם קיבולת נמוכה מדי, יכול להיות שהמערכת לא תפעל לפי התדירויות של יצירת הפרופילים שהגדרתם בלוחות הזמנים. אם יש צבר של נתונים שצריך ליצור להם פרופיל, סדר התזמון לא קובע את הסדר שבו Sensitive Data Protection יוצר פרופיל לנתונים בצבר. במקום זאת, לכל מקורות הנתונים בהיקף מוקצה משבצת בתור באופן אקראי.

9. אופציונלי: עורכים או משביתים את לוח הזמנים הכללי.

   לוח הזמנים האחרון ברשימה הוא לוח הזמנים הכללי. התזמון הזה חל על המאגרים בהיקף שבחרתם שלא תואמים לאף אחד מהתזמונים שיצרתם. לוח הזמנים הכולל פועל לפי תדירות ברירת המחדל של המערכת ליצירת פרופילים.

   • כדי לשנות את לוח הזמנים של ה-catch-all, לוחצים על עריכת לוח הזמנים ומשנים את ההגדרות לפי הצורך.
   • כדי למנוע מ-Sensitive Data Protection ליצור פרופיל של משאב כלשהו שכלול בתזמון הכולל, משביתים את האפשרות יצירת פרופיל למשאבים שלא תואמים לאף תזמון בהתאמה אישית.

בחירת תבנית בדיקה

בהתאם לאופן שבו אתם רוצים לספק הגדרת בדיקה, בחרו אחת מהאפשרויות הבאות. לא משנה באיזו אפשרות תבחרו, Sensitive Data Protection סורק את הנתונים באזור שבו הם מאוחסנים. כלומר, הנתונים לא יוצאים מהאזור המקורי שלהם.

אפשרות 1: יצירת תבנית בדיקה

בוחרים באפשרות הזו אם רוצים ליצור תבנית חדשה לבדיקה באזור global.

1. לוחצים על יצירת תבנית בדיקה חדשה.

2. אופציונלי: כדי לשנות את ברירת המחדל של סוגי המידע, לוחצים על ניהול סוגי מידע.

   במאמר ניהול של טיפוסי מידע באמצעות מסוףGoogle Cloud מוסבר איך לנהל טיפוסי מידע מובנים ובהתאמה אישית.

   כדי להמשיך, צריך לבחור לפחות סוג מידע אחד.

3. אופציונלי: אפשר להוסיף עוד כללים ולהגדיר סף מהימנות כדי להגדיר עוד את תבנית הבדיקה. מידע נוסף זמין במאמר בנושא הגדרת זיהוי.

כשההגדרה של הסריקה נוצרת ב-Sensitive Data Protection, תבנית הבדיקה החדשה נשמרת באזור global.

אפשרות 2: שימוש בתבנית בדיקה קיימת

כדאי לבחור את האפשרות הזו אם יש לכם תבניות בדיקה קיימות שבהן אתם רוצים להשתמש.

1. לוחצים על בחירה בתבנית בדיקה קיימת.
2. מזינים את שם המשאב המלא של תבנית הבדיקה שבה רוצים להשתמש. השדה אזור מאוכלס אוטומטית בשם האזור שבו מאוחסנת תבנית הבדיקה.

   תבנית הבדיקה שאתם מזינים צריכה להיות באותו אזור שבו אתם מתכננים לאחסן את ההגדרה של סריקת הגילוי ואת כל פרופילי הנתונים שנוצרו.

   כדי לכבד את מיקום אחסון הנתונים, Sensitive Data Protection לא משתמש בתבנית בדיקה מחוץ לאזור שבו התבנית מאוחסנת.

   כדי למצוא את שם המשאב המלא של תבנית בדיקה:

   1. עוברים לרשימת תבניות הבדיקה. הדף ייפתח בכרטיסייה נפרדת.

      מעבר לתבניות בדיקה

   2. בוחרים את הפרויקט שמכיל את תבנית הבדיקה שבה רוצים להשתמש.
   3. לוחצים על Configuration > Templates > Inspect (הגדרה > תבניות > בדיקה), ואז לוחצים על מזהה התבנית שרוצים להשתמש בה.
   4. בדף שנפתח, מעתיקים את שם המשאב המלא של התבנית. הפורמט של השם המלא של המשאב הוא:

      projects/PROJECT_ID/locations/REGION/inspectTemplates/TEMPLATE_ID

   5. בדף Create scan configuration, בשדה Template name מדביקים את שם המשאב המלא של התבנית.

הוספת פעולות

בקטע הזה מוסבר איך מציינים פעולות שרוצים ש-Sensitive Data Protection יבצע אחרי יצירת פרופיל של קונטיינר. הפעולות האלה שימושיות אם רוצים לשלוח תובנות שנאספו מפרופילי נתונים לשירותים אחרים שלGoogle Cloud .

הערה: במאמר תמחור הייצוא של פרופילי נתונים מוסבר איך שירותי Google Cloud אחרים עשויים לחייב אתכם על הגדרת פעולות.

פרסום ב-Google Security Operations

מדדים שנאספים מפרופילי נתונים יכולים להוסיף הקשר לממצאים של Google Security Operations. ההקשר הנוסף יכול לעזור לכם לקבוע מהן בעיות האבטחה הכי חשובות שצריך לטפל בהן.

לדוגמה, אם אתם בודקים סוכן שירות מסוים, Google Security Operations יכול לקבוע לאילו משאבים סוכן השירות ניגש, ואם יש במשאבים האלה נתונים רגישים.

כדי לשלוח את הפרופילים של הנתונים למכונה של Google Security Operations, מפעילים את האפשרות Publish to Google Security Operations.

אם לא הפעלתם מכונה של Google Security Operations בארגון – דרך המוצר הנפרד או דרך Security Command Center Enterprise – להפעלת האפשרות הזו לא תהיה השפעה.

פרסום ב-Security Command Center

הממצאים מפרופילי הנתונים מספקים הקשר כשאתם ממיינים ומפתחים תוכניות תגובה לממצאי הפגיעויות והאיומים ב-Security Command Center.

הערה: אתם יכולים גם להגדיר את Security Command Center כך שייתן עדיפות אוטומטית למשאבים בתכונה "סימולציה של נתיב התקפה", בהתאם לרגישות המחושבת של הנתונים שהמשאבים מכילים. מידע נוסף זמין במאמר הגדרה אוטומטית של ערכי העדיפות של המשאבים לפי רגישות הנתונים.

כדי לשלוח את התוצאות של פרופילי הנתונים אל Security Command Center, מוודאים שהאפשרות פרסום ב-Security Command Center מופעלת.

מידע נוסף זמין במאמר פרסום פרופילי נתונים ב-Security Command Center.

שמירת עותקים של פרופילי נתונים ב-BigQuery

‫Sensitive Data Protection שומר עותק של כל פרופיל נתונים שנוצר בטבלה ב-BigQuery. אם לא תספקו את פרטי הטבלה המועדפת, Sensitive Data Protection תיצור מערך נתונים וטבלה בקונטיינר של סוכן השירות. כברירת מחדל, שם מערך הנתונים הוא sensitive_data_protection_discovery ושם הטבלה הוא discovery_profiles.

חשוב: טבלת הפלט משתמשת בסכימה DataProfileBigQueryRowSchema. הסכימה הזו יכולה להשתנות כשמוסיפים תכונות ל-Sensitive Data Protection. חשוב לוודא שתהליכי העבודה שלכם יכולים להתמודד עם שינויים בסכימה, למשל על ידי התעלמות משדות לא ידועים.

הפעולה הזו מאפשרת לכם לשמור היסטוריה של כל הפרופילים שיצרתם. היסטוריה כזו יכולה להיות שימושית ליצירת דוחות ביקורת ולהצגה חזותית של פרופילי נתונים. אפשר גם לטעון את המידע הזה למערכות אחרות.

בנוסף, האפשרות הזו מאפשרת לכם לראות את כל פרופילי הנתונים בתצוגה אחת, בלי קשר למיקום אחסון הנתונים שלכם. אפשר גם לראות את פרופילי הנתונים דרך מסוףGoogle Cloud , אבל במסוף מוצגים הפרופילים רק באזור אחד בכל פעם.

אם Sensitive Data Protection לא מצליח ליצור פרופיל של מאגר, הוא מנסה שוב באופן תקופתי. כדי לצמצם את הרעש בנתונים שמיוצאים, Sensitive Data Protection מייצא ל-BigQuery רק את הפרופילים שנוצרו בהצלחה.

הייצוא של פרופילים ב-Sensitive Data Protection מתחיל ברגע שמפעילים את האפשרות הזו. פרופילים שנוצרו לפני שהפעלתם את הייצוא לא נשמרים ב-BigQuery.

הערה: לסוכן השירות צריכה להיות גישת כתיבה בטבלה שבה יישמרו עותקי הפרופילים. אם עדיין אין לכם סוכן שירות, תוכלו ליצור אותו מאוחר יותר בדף Create scan configuration ב-Sensitive Data Protection.

לדוגמה, שאילתות שאפשר להשתמש בהן כשמנתחים פרופילי נתונים מופיעות במאמר ניתוח פרופילי נתונים.

שמירת ממצאים לדוגמה של נתונים שזוהו ב-BigQuery

‫Sensitive Data Protection יכול להוסיף ממצאים לדוגמה לטבלה ב-BigQuery לבחירתכם. הממצאים לדוגמה מייצגים קבוצת משנה של כל הממצאים, ויכול להיות שהם לא מייצגים את כל סוגי המידע שנמצאו. בדרך כלל, המערכת יוצרת כ-10 ממצאים לדוגמה לכל מאגר, אבל המספר הזה יכול להשתנות בכל הרצה של גילוי.

כל ממצא כולל את המחרוזת בפועל (שנקראת גם ציטוט) שזוהתה ואת המיקום המדויק שלה.

הפעולה הזו שימושית אם רוצים לבדוק אם הגדרת הבדיקה תואמת לסוג המידע שרוצים לסמן כרגיש. בעזרת פרופילי הנתונים שיוצאו והממצאים לדוגמה שיוצאו, אתם יכולים להריץ שאילתות כדי לקבל מידע נוסף על הפריטים הספציפיים שסומנו, על סוגי המידע שהם תאמו, על המיקומים המדויקים שלהם, על רמות הרגישות המחושבות שלהם ועל פרטים נוספים.

חשוב: טבלת הפלט משתמשת בסכימה DataProfileFinding. הסכימה הזו עשויה להשתנות ככל ש-Sensitive Data Protection מוסיף תכונות. חשוב לוודא שתהליכי העבודה שלכם יכולים להתמודד עם שינויים בסכימה, למשל על ידי התעלמות משדות לא ידועים.

שאילתה לדוגמה: הצגת ממצאים לדוגמה שקשורים לפרופילי נתונים של מאגרי קבצים

בדוגמה הזו צריך להפעיל גם את האפשרות שמירת עותקים של פרופילי נתונים ב-BigQuery וגם את האפשרות שמירת ממצאים לדוגמה של סריקה ב-BigQuery.

בשאילתה הבאה נעשה שימוש בפעולת INNER JOIN גם בטבלה של פרופילי הנתונים שיוצאו וגם בטבלה של הממצאים לדוגמה שיוצאו. בטבלה שנוצרת, כל רשומה מציגה את הציטוט של הממצא, את ה-infoType שתואם לו, את המשאב שמכיל את הממצא ואת רמת הרגישות המחושבת של המשאב.

SELECT
 findings_table.quote,
 findings_table.infotype.name,
 findings_table.location.container_name,
 profiles_table.file_store_profile.file_store_path as bucket_name,
 profiles_table.file_store_profile.sensitivity_score as bucket_sensitivity_score
FROM
 `FINDINGS_TABLE_PROJECT_ID.FINDINGS_TABLE_DATASET_ID.FINDINGS_TABLE_ID_latest_v1` AS findings_table
INNER JOIN
 `PROFILES_TABLE_PROJECT_ID.PROFILES_TABLE_DATASET_ID.PROFILES_TABLE_ID_latest_v1` AS profiles_table
ON
 findings_table.data_profile_resource_name=profiles_table.file_store_profile.name
 AND findings_table.timestamp.timestamp=profiles_table.file_store_profile.profile_last_generated.timestamp

כדי לשמור ממצאים לדוגמה בטבלה ב-BigQuery:

1. מפעילים את האפשרות שמירת ממצאי גילוי לדוגמה ב-BigQuery.

2. מזינים את פרטי הטבלה ב-BigQuery שבה רוצים לשמור את הממצאים לדוגמה.

   הטבלה שמציינים לפעולה הזו צריכה להיות שונה מהטבלה שמשמשת לפעולה שמירת עותקים של פרופיל הנתונים ב-BigQuery.

   • בשדה Project ID, מזינים את מזהה הפרויקט של פרויקט קיים שאליו רוצים לייצא את הממצאים.

   • בשדה Dataset ID, מזינים את השם של מערך נתונים קיים בפרויקט.

   • בשדה Table ID, מזינים את שם הטבלה ב-BigQuery שבה רוצים לשמור את הממצאים. אם הטבלה הזו לא קיימת, Sensitive Data Protection יוצר אותה בשבילכם באופן אוטומטי באמצעות השם שסיפקתם.

הערה: לסוכן השירות צריכה להיות גישת כתיבה בטבלה. אם עדיין אין לכם סוכן שירות, תוכלו ליצור אותו בהמשך בדף Create scan configuration (יצירת הגדרת סריקה) של Sensitive Data Protection.

למידע על התוכן של כל ממצא שנשמר בטבלה ב-BigQuery, אפשר לעיין במאמר DataProfileFinding.

פרסום ב-Pub/Sub

הפעלת האפשרות Publish to Pub/Sub מאפשרת לבצע פעולות פרוגרמטיות על סמך תוצאות הפרופיילינג. אתם יכולים להשתמש בהתראות של Pub/Sub כדי לפתח תהליך עבודה לזיהוי ולתיקון של ממצאים עם סיכון משמעותי או רגישות גבוהה של נתונים.

כדי לשלוח התראות לנושא Pub/Sub, פועלים לפי השלבים הבאים:

1. מפעילים את האפשרות פרסום ב-Pub/Sub.

   מופיעה רשימה של אפשרויות. כל אפשרות מתארת אירוע שגורם ל-Sensitive Data Protection לשלוח התראה ל-Pub/Sub.

2. בוחרים את האירועים שצריכים להפעיל התראה ב-Pub/Sub.

   אם בוחרים באפשרות Send a Pub/Sub notification each time a profile is updated (שליחת התראה ב-Pub/Sub בכל פעם שפרופיל מתעדכן), Sensitive Data Protection שולחת התראה כשמתרחש שינוי ברמת הרגישות, ברמת הסיכון של הנתונים, בסוגי ה-infoType שזוהו, בגישה הציבורית ובמדדים חשובים אחרים בפרופיל.

3. מבצעים את השלבים הבאים לכל אירוע שבוחרים:

   1. מזינים את שם הנושא. השם צריך להיות בפורמט הבא:

      projects/PROJECT_ID/topics/TOPIC_ID
      

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫PROJECT_ID: מזהה הפרויקט שמשויך לנושא ב-Pub/Sub.
      • ‫TOPIC_ID: המזהה של נושא Pub/Sub.

   2. מציינים אם לכלול בהתראה את הפרופיל המלא של הקונטיינר, או רק את שם המשאב המלא של הקונטיינר שנוצר לו פרופיל.

   3. מגדירים את רמות הסיכון והרגישות המינימליות של הנתונים שצריכות להתקיים כדי ש-Sensitive Data Protection ישלח התראה.

   4. מציינים אם צריך לעמוד רק באחד מהתנאים של רמת הסיכון והרגישות של הנתונים, או בשניהם. לדוגמה, אם בוחרים באפשרות AND, שני התנאים – הסיכון לנתונים והרגישות – צריכים להתקיים לפני ש-Sensitive Data Protection ישלח התראה.

הערה: לסוכן השירות צריכה להיות גישת פרסום לנושא Pub/Sub. דוגמה לתפקיד עם הרשאת פרסום הוא "פרסום הודעות ב-Pub/Sub"‏ (roles/pubsub.publisher). אם עדיין אין לכם סוכן שירות, תוכלו ליצור אותו בהמשך בדף Create scan configuration ב-Sensitive Data Protection. אם יש בעיות בהגדרות או בהרשאות של נושא Pub/Sub, Sensitive Data Protection מנסה לשלוח את ההתראה ל-Pub/Sub במשך שבועיים לכל היותר. אחרי שבועיים, ההתראה נמחקת.

ניהול החיוב והקונטיינר של סוכן השירות

בקטע הזה מציינים את הפרויקט שרוצים להשתמש בו בתור מאגר של סוכני שירות. אתם יכולים להגדיר ש-Sensitive Data Protection ייצור פרויקט חדש באופן אוטומטי, או לבחור פרויקט קיים.

בין אם אתם משתמשים בסוכן שירות חדש או בסוכן שירות קיים, חשוב לוודא שיש לו גישת קריאה לנתונים שאתם רוצים ליצור להם פרופיל.

יצירת פרויקט באופן אוטומטי

אם אין לכם את ההרשאות שנדרשות כדי ליצור פרויקט בארגון, אתם צריכים לבחור פרויקט קיים או לקבל את ההרשאות הנדרשות. למידע על ההרשאות הנדרשות, קראו את המאמר התפקידים שנדרשים כדי לעבוד עם פרופילי נתונים ברמת הארגון או התיקייה.

כדי ליצור באופן אוטומטי פרויקט שישמש כמאגר של סוכני השירות:

1. בשדה Service agent container, בודקים את מזהה הפרויקט המוצע ועורכים אותו לפי הצורך.
2. לוחצים על יצירה.
3. אופציונלי: מעדכנים את שם הפרויקט שמוגדר כברירת מחדל.

4. בוחרים את החשבון לחיוב על כל הפעולות שקשורות לפרויקט החדש, כולל פעולות שלא קשורות ל-Discovery.

   הערה: גם אם כבר יש לכם מינוי ל-Discovery ברמת הארגון, עדיין תצטרכו את החשבון לחיוב כדי ליצור את הפרויקט. עם זאת, החיוב על כל פעולות הגילוי מתבצע דרך הפרויקט שמשויך למינוי שלכם.

5. לוחצים על יצירה.

‫Sensitive Data Protection יוצר את הפרויקט החדש. סוכן השירות בפרויקט הזה ישמש לאימות ב-Sensitive Data Protection ובממשקי API אחרים.

בחירת פרויקט קיים

כדי לבחור פרויקט קיים בתור מאגר של סוכני שירות, לוחצים על השדה Service agent container ובוחרים את הפרויקט.

הגדרת המיקום לאחסון ההגדרה

ברשימה Resource location, בוחרים את האזור שבו רוצים לאחסן את הגדרת הסריקה. כל הגדרות הסריקה שתיצרו בהמשך יאוחסנו גם הן במיקום הזה.

המיקום שבו תבחרו לאחסן את הגדרות הסריקה לא משפיע על הנתונים שייסרקו. הנתונים שלכם נסרקים באותו אזור שבו הם מאוחסנים. מידע נוסף זמין במאמר שיקולים לגבי מיקום אחסון הנתונים.

הערה: אם כבר יש לכם הגדרת סריקה קיימת, לא תוכלו לשנות את הערך שהוגדר בשדה הזה. כל הגדרות הסריקה נשמרות באותו מיקום. כדי לשנות את המיקום של כל הגדרות הסריקה, צריך למחוק אותן, ליצור אותן מחדש ולאחסן אותן במיקום החדש.

בדיקה ויצירה של ההגדרות האישיות

1. אם אתם רוצים לוודא שהפרופיילינג לא יתחיל באופן אוטומטי אחרי שתיצרו את הגדרת הסריקה, בחרו באפשרות Create scan in paused mode.

   האפשרות הזו שימושית במקרים הבאים:

   • האדמין Google Cloud שלכם עדיין צריך להעניק לסוכן השירות גישה ליצירת פרופיל של הנתונים.
   • אתם רוצים ליצור כמה הגדרות סריקה, וחלק מההגדרות יבטלו הגדרות אחרות.
   • בחרתם לשמור פרופילי נתונים ב-BigQuery ואתם רוצים לוודא שלסוכן השירות יש גישת כתיבה לטבלה ב-BigQuery שבה יישמרו העותקים של פרופילי הנתונים.
   • בחרתם לשמור ממצאים לדוגמה של סריקה ב-BigQuery, ואתם רוצים לוודא שלסוכן השירות יש גישת כתיבה לטבלה ב-BigQuery שבה יישמרו הממצאים לדוגמה.
   • הגדרתם התראות Pub/Sub ואתם רוצים לתת גישת פרסום לסוכן השירות.
2. בודקים את ההגדרות ולוחצים על יצירה.

   ההגדרה של סריקת הממצאים נוצרת ב-Sensitive Data Protection ומתווספת לרשימת ההגדרות של סריקות הממצאים.

כדי לראות או לנהל את הגדרות הסריקה, קראו את המאמר ניהול הגדרות הסריקה.

הערה: אנחנו משפרים את אלגוריתם הזיהוי שלנו באופן קבוע. אם נגלה שהארגון או הפרויקט שלכם יכולים להפיק תועלת משיפור חדש שהטמענו, יכול להיות שניצור מחדש באופן אוטומטי את פרופילי הנתונים ונבצע מחדש את הפעולות בהגדרות הסריקה. לא תחויבו על הפעולה הזו ב-Sensitive Data Protection. עם זאת, מכיוון שנבצע מחדש את הפעולות, יכול להיות שתחויבו על השימוש בשירותים אחרים של Google Cloud . לדוגמה, אם הגדרתם את Sensitive Data Protection לשמירת פרופילי הנתונים ב-BigQuery, יכול להיות שתחויבו על השימוש ב-BigQuery.

המאמרים הבאים

• אם אין לכם את התפקיד 'Organization Administrator' (roles/resourcemanager.organizationAdmin) או 'Security Admin' (roles/iam.securityAdmin), מישהו עם אחד מהתפקידים האלה צריך להעניק לסוכן השירות שלכם גישה ליצירת פרופילים של נתונים.
• איך מנהלים פרופילי נתונים
• איך מנהלים את הגדרות הסריקה
• איך מקבלים ומנתחים הודעות Pub/Sub שפורסמו על ידי הכלי ליצירת פרופילים של נתונים
• איך פותרים בעיות בפרופילי נתונים
• עיינו במגבלות של יצירת פרופיל נתונים.
• בודקים את אשכולות הקבצים שאפשר לסרוק באמצעות מיון מידע אישי רגיש.