בעיות מוכרות

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

שמירת תוצאות ב-BigQuery

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

סריקה ב-BigQuery

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

בעיות נפוצות בפעולות של בדיקה ויצירת פרופילים

הבעיות הבאות רלוונטיות גם לבדיקה וגם ליצירת פרופילים ב-BigQuery.

אי אפשר לסרוק שורות עם אבטחה ברמת השורה

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

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

שורות כפולות

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

נתונים שהועברו בסטרימינג לאחרונה

הכלי Sensitive Data Protection לא סורק נתונים שהועברו בסטרימינג לאחרונה (לשעבר מאגר זמני לסטרימינג). מידע נוסף זמין במאמר זמינות נתונים בסטרימינג במאמרי העזרה של BigQuery.

בעיות בבדיקה של BigQuery

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

לממצאים שמייצאים אין ערכים בשדה row_number

כשמגדירים את Sensitive Data Protection כך שהממצאים יישמרו ב-BigQuery, השדה location.content_locations.record_location.record_key.big_query_key.row_number בטבלה ב-BigQuery שנוצרת מוסק בזמן הסריקה של טבלת הקלט. הערך שלו לא דטרמיניסטי, אי אפשר לשלוח אליו שאילתות והוא יכול להיות null עבור משימות בדיקה.

אם אתם צריכים לזהות שורות ספציפיות שבהן נמצאו ממצאים, צריך לציין את inspectJob.storageConfig.bigQueryOptions.identifyingFields כשיוצרים את המשימה.

אפשר לזהות את השדות בטבלה ב-BigQuery שנוצרה, בשדה location.content_locations.record_location.record_key.id_values.

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

אם הגבלתם את הסריקות כך שיכללו רק תוכן חדש ואתם משתמשים ב-BigQuery Storage Write API כדי לאכלס את טבלת הקלט, יכול להיות ש-Sensitive Data Protection ידלג על סריקה של חלק מהשורות.

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

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

1. בסכימה של טבלת הקלט, מוודאים שעמודת חותמת הזמן היא מהסוג TIMESTAMP.

   דוגמה לסכימה

   בדוגמה הבאה מוגדר השדה commit_time_stamp והסוג שלו מוגדר ל-TIMESTAMP:

   ...
   {
    "name": "commit_time_stamp",
    "type": "TIMESTAMP"
   }
   ...
   

2. בשדה rows[].json של השיטה tabledata.insertAll, מוודאים שהערכים בעמודה של חותמת הזמן מוגדרים ל-AUTO.

   דוגמה ל-JSON

   בדוגמה הבאה, הערך של השדה commit_time_stamp מוגדר כ-AUTO:

   {
     ...
     "commit_time_stamp": "AUTO",
     ...
   }
   

הגבלת הסריקות על ידי הגדרת אחוז מקסימלי או שורות

כשמגדירים מגבלת דגימה על סמך אחוז ממספר השורות הכולל בטבלה (rowsLimitPercent), יכול להיות ש-Sensitive Data Protection יבדוק יותר שורות מהצפוי. אם אתם צריכים להגביל את מספר השורות לסריקה, מומלץ להגדיר מספר מקסימלי של שורות (rowsLimit) במקום זאת.

בעיות בפרופיל BigQuery

הבעיות הבאות רלוונטיות רק לפעולות פרופיל בנתוני BigQuery. מידע נוסף על פרופילי נתונים לנתוני BigQuery

ארגונים או פרויקטים עם יותר מ-500 מיליון טבלאות

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

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

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

תבניות בדיקה

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

סוגי מידע שנשמרו

stored infoType (שנקרא גם stored custom dictionary detector) שאליו יש הפניה בתבנית הבדיקה שלכם צריך להיות מאוחסן באחד מהמקומות הבאים:

• אזור global.
• אותו אזור כמו תבנית הבדיקה.

אחרת, פעולת יצירת הפרופיל נכשלת עם השגיאה Resource not found.

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

בפרופיל נתוני טבלה, סיווג הרשאות הגישה למשאב שניתן לטבלה ב-BigQuery תלוי בהרשאות הגישה למערך הנתונים שמכיל את הטבלה, ולא בהרשאות הגישה לטבלה. לכן, אם הרשאות ה-IAM של טבלה שונות מהרשאות ה-IAM של מערך הנתונים, יכול להיות שהמידע על נראות המשאב של הטבלה שמופיע בפרופיל הנתונים יהיה שגוי. הבעיה הזו משפיעה על גילוי ב-BigQuery ועל גילוי ב-Vertex AI.

במסוף Google Cloud , רמת החשיפה של המשאב מצוינת בשדה Public בפרופיל של נתוני הטבלה. ב-Cloud Data Loss Prevention API, רמת החשיפה של המשאב מצוינת בשדה resourceVisibility של TableDataProfile.

סריקה של Cloud Storage

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

אין תמיכה בבדיקה של קובצי XLSX בפורמט Strict

קובץ עם הסיומת .xlsx יכול להיות אחד משני סוגים. סוג אחד הוא גיליון אלקטרוני של Office Open XML, שלא נתמך על ידי Sensitive Data Protection. הסוג השני הוא חוברת עבודה רגילה של Microsoft Excel, ויש תמיכה בסוג הזה.

קבצים מובְנים שנסרקים במצב בינארי

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

הסרת פרטים מזהים מקבצים מופרדים

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

גילוי ב-Cloud SQL

ממצאים כפולים ב-Security Command Center

פרופיל הנתונים ב-Cloud SQL תומך בפרסום הממצאים ב-Security Command Center.

לפני 25 באפריל 2024, באג גרם לכך שהכלי Sensitive Data Protection יצר מדי פעם ממצאים כפולים עבור מופעי Cloud SQL ב-Security Command Center. הממצאים האלה נוצרו עם מזהי ממצאים ייחודיים, אבל הם מתייחסים לאותן מכונות Cloud SQL. הבעיה נפתרה, אבל הממצאים הכפולים עדיין קיימים. אפשר להשתיק את הכפילויות כדי להסתיר אותן בדף Findings ב-Security Command Center.

גילוי ב-Amazon S3

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

• מחבר AWS היה בתוקף למשך 24 שעות בלבד בזמן שהממצא נשלח אל Security Command Center.
• החשבון ב-AWS נכלל במחבר AWS רק למשך כ-24 שעות עד שהממצא נשלח למרכז האבטחה.

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

ניתוח חכם של מסמכים

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

האובייקט DocumentLocation לא מאוכלס

השדה location.content_locations.document_location.file_offset לא מאוכלס במצב הסריקה של ניתוח מסמכים חכם.

זיהוי

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

מילים במילון

מילים במילון שמכילות תווים במישור הרב-לשוני המשני של תקן Unicode עשויות להניב ממצאים לא צפויים. דוגמאות לתווים כאלה: סמלי אמוג'י, סמלים מדעיים וכתבים היסטוריים.