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

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

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

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

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

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

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

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

הנה כמה תרחישי שימוש נפוצים:

• אוטומציה של סריקות תאימות חוזרות: אפשר לתזמן סריקות בדיקה קבועות של קטגוריות Cloud Storage וטבלאות BigQuery כדי לשמור על נראות רציפה של מידע אישי רגיש חדש שמאוחסן.
• אופטימיזציה של עלויות הבדיקה באחסון דינמי: מגדירים כללים של טווח זמן בהפעלות של משימות כדי לסרוק רק תוכן שנוסף או שונה מאז מחזור הסריקה הקודם.
• מעקב אחרי סחף נתונים מתמשך במסדי נתונים של סביבת ייצור: כדי לעקוב אחרי שינויים בחשיפה של מידע אישי רגיש לאורך זמן, אפשר ליצור סיכומים תקופתיים של ממצאים לצורך בדיקת מצב האבטחה.
• תיאום עם צינורות נתונים מבוססי-אירועים: הפעלת עבודות בדיקה בתגובה לאירועי העלאה ב-Cloud Storage או לאבני דרך אוטומטיות בצינור ETL.

השלבים הבאים

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

• יצירת משימות בדיקה וטריגרים למשימות של Sensitive Data Protection
• מדידת הסיכון לשחזור פרטי זיהוי ולחשיפת מידע (כולל משימות של ניתוח סיכונים)

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

• הפעלה מהירה של יצירת Sensitive Data Protection job trigger

אובייקט JobTrigger

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

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

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

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

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

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

• יוצרים טריגר חדש להפעלת משימה: projects.jobTriggers.create
• עדכון של טריגר קיים של משימה: projects.jobTriggers.patch
• מחיקה של טריגר קיים למשימה: projects.jobTriggers.delete
• אחזור טריגר קיים של משימה, כולל ההגדרה והסטטוס שלו: projects.jobTriggers.get
• רשימה של כל הטריגרים הקיימים של משימות: projects.jobTriggers.list

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

אין יעדים למדידת רמת השירות (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.