ניתוח הגורמים לדליפה של פרטים אישיים מזהים (PII)

שושלת נתונים ב-Knowledge Catalog (לשעבר Dataplex Universal Catalog) מאפשרת לכם לעקוב אחרי האופן שבו הנתונים עוברים בין טבלאות ותצוגות, כדי לזהות איפה פרטים אישיים מזהים (PII) חוצים את גבולות האבטחה. במדריך הזה נבחן תרחיש שבו כתובות אימייל של לקוחות (user_email) שנועדו ליצירת חשבון, לחשבוניות ולמשלוחים, דולפות לטבלת ניתוח נתונים ברמת הארגון. אתם משתמשים בשושלת היוחסין ברמת העמודה כדי לאתר את העמודה החשופה מהטבלה הציבורית order_status_stats דרך התצוגה status_counts_by_user_v, בחזרה לתהליך הטרנספורמציה שמצרף אותה לנתוני הזהות.

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

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

ניתוח דליפה של מידע אישי באמצעות Lineage Explorer

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

בדוגמה הזו, אתם מאתרים את העמודה user_email מהטבלה הציבורית בחזרה למקור שלה:

1. במסוף Google Cloud , נכנסים לדף BigQuery.
2. משתמשים בשדה החיפוש כדי למצוא את הטבלה order_status_stats.
3. לוחצים על הכרטיסייה Lineage.
4. בחלונית Lineage Explorer:
   1. בקטע Column Level Lineage, בוחרים את שם העמודה user_email מהרשימה.
   2. בקטע Direction, בוחרים באפשרות Upstream.
   3. לוחצים על אישור.
5. חוזרים שלב אחד אחורה בתרשים. בתרשים אפשר לראות שכתובת האימייל נשלפת מהתצוגה המקדימה status_counts_by_user_v.
6. לוחצים על צומת התהליך בין התצוגה לבין התלויות במעלה הזרם. צומת התהליך מראה שמתרחשת פעולת איחוד בין נתוני הזמנה שעברו אנונימיזציה לבין טבלה שמכילה פרטי זהות.

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

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