משרות וטריגרים של משרות

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

יש כרגע שני סוגים של משימות Sensitive Data Protection:

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

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

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

השלבים הבאים

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

בנוסף, זמין מדריך למתחילים:

אובייקט JobTrigger

טריגר של עבודה מיוצג ב-DLP API על ידי האובייקט JobTrigger.

שדות להגדרת טריגרים של משימות

כל JobTrigger מכיל כמה שדות הגדרה, כולל:

  • השם והשם המוצג של הטריגר, ותיאור.
  • אוסף של אובייקטים מסוג Trigger, שכל אחד מהם מכיל אובייקט מסוג Schedule, שמגדיר את מחזוריות הסריקה בשניות.
  • אובייקט InspectJobConfig שמכיל את פרטי ההגדרה של העבודה שהופעלה.
  • Status ספירה שמציינת אם הטריגר פעיל כרגע.
  • שדות של חותמות זמן שמייצגים את מועדי היצירה, העדכון וההפעלה האחרונה.
  • אוסף של אובייקטים מסוג Error, אם נתקלו בהם כשמופעל הטריגר.

שיטות להפעלת משימות

כל אובייקט JobTrigger כולל גם כמה שיטות מובנות. בעזרת השיטות האלה אפשר:

זמן האחזור של המשימה

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

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

  • אם האפשרות דגימה זמינה למשימה או לטריגר של המשימה, מפעילים אותה.

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

    • PERSON_NAME
    • FEMALE_NAME
    • MALE_NAME
    • FIRST_NAME
    • LAST_NAME
    • DATE_OF_BIRTH
    • LOCATION
    • STREET_ADDRESS
    • ORGANIZATION_NAME

  • תמיד צריך לציין במפורש את סוגי המידע. אל תשתמשו ברשימה ריקה של infoTypes.

  • אם אפשר, כדאי להשתמש באזור עיבוד אחר.

אם עדיין יש בעיות של זמן אחזור בעבודות אחרי שמנסים את הטכניקות האלה, אפשר לשקול להשתמש בבקשות של content.inspect או של content.deidentify במקום בעבודות. השיטות האלה מכוסות בהסכם רמת השירות. מידע נוסף מופיע בהסכם רמת השירות (SLA) של שירות Sensitive Data Protection.

הגבלת הסריקות לתוכן חדש בלבד

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

...
  timespan_config {
        enable_auto_population_of_timespan_config: true
      }
...

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

הפעלת משימות בהעלאת קובץ

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

מידע על הגדרת הפעולה הזו מופיע במאמר אוטומציה של סיווג נתונים שהועלו ל-Cloud Storage.