יצירת פרופיל של נתוני Cloud SQL בפרויקט יחיד

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

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

איך זה עובד

זהו תהליך העבודה הכללי ליצירת פרופילים של נתונים ב-Cloud SQL:

  1. יצירת הגדרת סריקה

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

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

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

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

שירותים נתמכים

התכונה הזו תומכת באפשרויות הבאות:

  • Cloud SQL ל-MySQL
  • Cloud SQL ל-PostgreSQL

אי אפשר להשתמש ב-Cloud SQL ל-SQL Server.

אזורי עיבוד ואחסון

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

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

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

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

  2. מוודאים שה-Cloud Data Loss Prevention API מופעל בפרויקט:

    1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

      Roles required to select or create a project

      • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
      • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

      Go to project selector

    2. Verify that billing is enabled for your Google Cloud project.

    3. Enable the required API, if it is not already enabled.

      Roles required to enable APIs

      To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

      Enable the API

  3. מוודאים שיש לכם את הרשאות ה-IAM שנדרשות להגדרת פרופילי נתונים ברמת הפרויקט.

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

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

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

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

  7. אתם יכולים להגדיר את Sensitive Data Protection כך שיצרף אוטומטית היבטים למשאבי Cloud SQL שנוצר להם פרופיל, על סמך תובנות מממצאים. כדי להשתמש בתכונה הזו, צריך להפעיל את השילוב של הקטלוג האוניברסלי במכונה של Cloud SQL ל-MySQL או במכונה של Cloud SQL ל-PostgreSQL.

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

  1. עוברים לדף יצירת הגדרת סריקה.

    כניסה לדף Create scan configuration

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

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

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

בוחרים באפשרות Cloud SQL.

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

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

  • אם רוצים לסרוק טבלה אחת, בוחרים באפשרות סריקת טבלה אחת.

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

    ממלאים את הפרטים של הטבלה שרוצים ליצור לה פרופיל.

  • כדי לבצע פרופיילינג רגיל ברמת הפרויקט, לוחצים על Scan selected project.

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

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

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

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

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

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

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

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

    • מזהה פרויקט או ביטוי רגולרי שמציין פרויקט אחד או יותר.
    • מזהה מכונה או ביטוי רגולרי שמציין מכונה אחת או יותר.
    • מזהה מסד נתונים או ביטוי רגולרי שמציין מסד נתונים אחד או יותר.
    • מזהה טבלה או ביטוי רגולרי שמציין טבלה אחת או יותר. מזינים את הערך הזה בשדה Database resource name or regular expression.

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

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

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

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

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

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

    • אם אתם לא רוצים שהטבלאות ינותחו, משביתים את האפשרות ניתוח הנתונים.

    • אם רוצים ליצור פרופיל לטבלאות לפחות פעם אחת, משאירים את האפשרות Do profile this data מופעלת.

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

      1. בקטע On a schedule, מציינים את התדירות שבה רוצים ליצור פרופיל מחדש לטבלאות. הטבלאות עוברות פרופיל מחדש, בלי קשר לשאלה אם הן עברו שינויים כלשהם.
      2. בקטע When schema changes, מציינים באיזו תדירות Sensitive Data Protection צריך לבדוק אם בוצעו שינויים בסכימה של הטבלאות שנבחרו מאז הפעם האחרונה שנוצר להן פרופיל. רק טבלאות עם שינויים בסכימה ינותחו מחדש.
      3. בקטע Types of schema change (סוגי שינוי בסכימה), מציינים אילו סוגי שינוי בסכימה צריכים להפעיל פעולת יצירה מחדש של פרופיל. בוחרים אחת מהאפשרויות הבאות:
        • עמודות חדשות: צריך ליצור פרופיל מחדש של הטבלאות שנוספו להן עמודות חדשות.
        • עמודות שהוסרו: צריך ליצור פרופיל מחדש לטבלאות שהוסרו מהן עמודות.

        לדוגמה, נניח שיש לכם טבלאות שנוספות להן עמודות חדשות מדי יום, ואתם צריכים ליצור פרופיל של התוכן שלהן בכל פעם. אפשר להגדיר את When schema changes ל-Reprofile daily, ואת Types of schema change ל-New columns.

      4. בשדה When inspect template changes, מציינים אם רוצים ליצור פרופיל מחדש לנתונים כשמעדכנים את תבנית הבדיקה המשויכת, ואם כן, באיזו תדירות.

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

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

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

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

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

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

    1. לוחצים על השדה Database resource types.
    2. בוחרים את סוגי משאבי מסד הנתונים שרוצים ליצור להם פרופיל.

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

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

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

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

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

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

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

    • כדי לשנות את לוח הזמנים של ה-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 מדביקים את שם המשאב המלא של התבנית.
  3. כדי להוסיף תבנית בדיקה לאזור אחר, לוחצים על Add inspection template ומזינים את שם המשאב המלא של התבנית. חוזרים על הפעולה הזו בכל אזור שבו יש לכם תבנית בדיקה ייעודית.
  4. אופציונלי: מוסיפים תבנית בדיקה שמאוחסנת באזור global. ‫Sensitive Data Protection משתמשת אוטומטית בתבנית הזו לנתונים באזורים שבהם אין לכם תבנית בדיקה ייעודית.

הוספת פעולות

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

פרסום ב-Security Command Center

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

כדי להשתמש בפעולה הזו, צריך להפעיל את Security Command Center ברמת הארגון. כשמפעילים את Security Command Center ברמת הארגון, הממצאים משירותים משולבים כמו Sensitive Data Protection מתחילים לזרום. השירות Sensitive Data Protection פועל עם Security Command Center בכל רמות השירות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SELECT
 findings_table.quote,
 findings_table.infotype.name,
 findings_table.location.container_name,
 findings_table.location.data_profile_finding_record_location.field.name AS field_name,
 profiles_table.table_profile.dataset_project_id AS project_id,
 profiles_table.table_profile.dataset_id AS dataset_id,
 profiles_table.table_profile.table_id AS table_id,
 profiles_table.table_profile.sensitivity_score AS table_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.table_profile.name
 AND findings_table.timestamp.timestamp=profiles_table.table_profile.profile_last_generated.timestamp

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

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

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

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

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

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

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

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

צירוף תגים למשאבים

כשמפעילים את האפשרות Attach tags to resources, המערכת של Sensitive Data Protection מתייגת אוטומטית את הנתונים בהתאם לרמת הרגישות שחושבה. כדי לבצע את המשימות בקטע הזה, קודם צריך לבצע את המשימות בקטע שליטה בגישה של IAM למשאבים על סמך רגישות הנתונים.

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

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

  2. לכל רמת רגישות (גבוהה, בינונית, נמוכה ולא ידועה), מזינים את הנתיב של ערך התג שיצרתם עבור רמת הרגישות הנתונה.

    אם מדלגים על רמת רגישות, לא מצורף תג לרמה הזו.

  3. כדי להוריד באופן אוטומטי את רמת הסיכון של נתונים במשאב כשתג רמת הרגישות קיים, בוחרים באפשרות When a tag is applied to a resource, lower the data risk of its profile to LOW. האפשרות הזו עוזרת לכם למדוד את השיפור ברמת אבטחת המידע והפרטיות שלכם.

  4. בוחרים אחת מהאפשרויות הבאות או את שתיהן:

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

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

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

פרסום ב-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, ‏Sensitive Data Protection שולח התראה כשחל שינוי ברמת הרגישות, ברמת הסיכון של הנתונים, בסוגי המידע שזוהו, בגישה הציבורית ובמדדים חשובים אחרים בפרופיל.

  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 ישלח התראה.

שליחה ל-Knowledge Catalog כהיבטים

הפעולה הזו מאפשרת לכם להוסיף מאפיינים של Knowledge Catalog לטבלאות עם פרופילים על סמך תובנות מפרופילי נתונים. הפעולה הזו חלה רק על פרופילים חדשים ומעודכנים. פרופילים קיימים שלא עודכנו לא נשלחים אל Knowledge Catalog.

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

כדי לשלוח את פרופילי הנתונים ל-Knowledge Catalog, ודאו שהאפשרות Send to Dataplex Catalog as aspects מופעלת.

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

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

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

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

בדיקה ויצירה

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

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

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

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

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

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

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

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

איך מעדכנים את החיבורים