שימוש במסגרת אמצעי הבקרה למפתחות של CDMC במחסן נתונים של BigQuery

תג של CDMC

הרבה ארגונים פורסים מחסני נתונים בענן כדי לאחסן בהם מידע רגיש ולנתח אותו למגוון מטרות עסקיות. במאמר זה נסביר איך אפשר להשתמש במסגרת אמצעי הבקרה למפתחות של Cloud Data Management Capabilities (CDMC), שמנוהלים על ידי Enterprise Data Management Council במחסן נתונים של BigQuery.

מסגרת אמצעי הבקרה למפתחות של CDMC פורסמה בעיקר לספקים של שירותי ענן וטכנולוגיה. במסגרת מפורטים 14 אמצעי בקרה למפתחות שהספקים יכולים להשתמש בהם כדי לאפשר ללקוחות לנהל ביעילות מידע אישי רגיש בענן, ולשלוט בו. אמצעי הבקרה נכתבו על ידי קבוצת העבודה של CDMC, בשיתוף פעולה בין יותר מ-300 אנשי מקצוע מ-100 חברות. במהלך כתיבת המסגרת, חברי קבוצת העבודה של CDMC לקחו בחשבון את הדרישות המשפטיות והרגולטוריות הרבות שקיימות.

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

ארכיטקטורה

ארכיטקטורת העזר הבאה של Google Cloud תואמת למסגרת אמצעי הבקרה למפתחות של CDMC לפי גרסה 1.1.1 של מפרט הבדיקות. המספרים בתרשים מייצגים את אמצעי הבקרה למפתחות שבהם משתמשים בשירותי Google Cloud.

חלקי הארכיטקטורה של CDMC.

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

למידע נוסף, תוכלו לקרוא על השימוש בארכיטקטורת העזר של Google Cloud CDMC ב-GitHub.

סקירה כללית של מסגרת אמצעי הבקרה למפתחות של CDMC

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

מס' אמצעי הבקרה למפתחות של CDMC דרישת הבקרה של CDMC
1 תאימות לבקרת נתונים מקרים עסקיים של ניהול נתונים ב-Cloud מוגדרים ומפוקחים. יש לוודא שכל נכסי הנתונים שמכילים מידע אישי רגיש תואמים לאמצעי הבקרה למפתחות של CDMC באמצעות מדדים והתראות אוטומטיות.
2 הבעלות על הנתונים היא גם לנתונים שהועברו וגם לנתונים שנוצרו בענן השדה Ownership בקטלוג הנתונים צריך להיות מאוכלס בכל המידע הרגיש או לדווח בדרך אחרת בהתאם לתהליך עבודה מוגדר.
3 פיקוח על מקור הנתונים ועל השימוש בהם בעזרת אוטומציה יש להכין רישום של כל נקודות האספקה ומקורות הנתונים המאושרים לכל נכסי הנתונים שמכילים מידע רגיש או לדווח בדרך אחרת בהתאם לתהליך עבודה מוגדר.
4 ניהול ריבונות הנתונים והמעבר בין גבולות יש לתעד את ריבונות הנתונים והמעבר בין גבולות של כל מידע רגיש, ולפקח על כך בהתאם למדיניות מוגדרת.
5 הטמעת קטלוגים של נתונים ושימוש בהם תוך יכולת פעולה הדדית השימוש בקטלוגים צריך להיות אוטומטי לכל הנתונים בנקודת היצירה או ההטמעה, עם עקביות בין כל הסביבות.
6 הגדרת קטגוריות וסיווג הנתונים הסיווג חייב לפעול אוטומטית לכל הנתונים בנקודת היצירה או ההטמעה. הסיווג צריך להיות מוגדר אוטומטית למצב הבא:
7 ניהול ואכיפה של הרשאות הגישה לנתונים, תוך מעקב אחרי הגישה אמצעי הבקרה הזה מחייב את הדברים הבאים:
  • כברירת מחדל, הרשאות הגישה למידע אישי רגיש צריכות להיות רק ליוצרים ולבעלים, אלא אם ניתן אישור מפורש מגורם מוסמך.
  • חובה לעקוב אחרי הגישה לכל המידע האישי הרגיש.
8 הקפדה על אתיקה בשימוש בנתונים ובגישה אליהם, וניהול תוצרי המידע חובה לציין את מטרת השימוש בנתונים שמכילים מידע אישי רגיש בכל הסכמי שיתוף הנתונים. במטרה צריך לפרט את סוג הנתונים הנדרשים, ולארגונים עם נוכחות גלובלית צריך לציין את היקף המדינות או הישות המשפטית.
9 אבטחת הנתונים ותיעוד אמצעי הבקרה אמצעי הבקרה הזה מחייב את הדברים הבאים:
  • כדי להגן על מידע אישי רגיש, חובה להפעיל את אמצעי הבקרה המתאימים .
  • יש לתעד את אמצעי הבקרה שמשמשים לאבטחת המידע בקטלוג הנתונים של כל מידע אישי רגיש.
10 המסגרת של פרטיות הנתונים מוגדרת ופועלת הערכת ההשפעה של ההגנה על המידע (DPIA) צריכה לפעול אוטומטית לכל מידע אישי, בהתאם לסמכות השיפוט שלו.
11 תכנון וניהול מחזור החיים של הנתונים חובה לנהל את תהליכי שמירת הנתונים, העברתם לארכיון ומחיקתם באופן סופי בהתאם ללוח זמנים מוגדר.
12 ניהול איכות הנתונים יש להפעיל את כלי המדידה של איכות הנתונים למידע אישי רגיש, ולהפיץ את המדדים ככל שאפשר.
13 קביעה ויישום של עקרונות לניהול העלויות יש לקבוע וליישם עקרונות לתכנון טכני. מדדי העלויות שמשויכים ישירות לשימוש בנתונים, לאחסון שלהם ולהעברתם צריכים להיות זמינים בקטלוג.
14 הבנת מקורות הנתונים המידע על מקורות הנתונים צריך להיות זמין לכל נתונים שמכילים מידע אישי רגיש. הוא חייב להכיל לפחות את המקור שממנו הוטמעו הנתונים או שבו הם נוצרו בסביבת הענן.

1. תאימות לבקרת נתונים

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

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

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

בארכיטקטורה נעשה שימוש ב-Dataflow כדי ליצור הרשמה לדוגמה לאירועי הממצאים. אותם הממצאים נשמרים במכונה של BigQuery שפועלת בפרויקט של משילות המידע. באמצעות חלק מהתצוגות הקיימות תוכלו להריץ שאילתות על הנתונים באמצעות סביבת העבודה של SQL במסוף Google Cloud. תוכלו גם ליצור דוחות באמצעות Looker Studio או כלים אחרים של בינה עסקית (BI) שתואמים ל-BigQuery. הדוחות האלה יכללו את:

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

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

חלקי הארכיטקטורה של אמצעי הבקרה הראשון.

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

  • Pub/Sub משמש לפרסום הממצאים.
  • Dataflow להעלאת הממצאים למכונה של BigQuery.
  • BigQuery לשמירת נתוני הממצאים ושימוש בתצוגות סיכום.
  • Looker Studio ללוחות בקרה ודוחות.

בצילום המסך תוכלו לראות דוגמה ללוח בקרה מסכם ב-Looker Studio.

דוגמה ללוח בקרה מסכם ב-Looker Studio.

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

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

2. הבעלות על הנתונים היא גם לנתונים שהועברו וגם לנתונים שנוצרו בענן

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

Data Catalog, שהוא חלק מ-Dataplex, מטפל בשני סוגים של מטא-נתונים: טכניים ועסקיים. בכל פרויקט, Data Catalog מחלק אוטומטית את מערכי הנתונים, הטבלאות והתצוגות של BigQuery ומאכלס את המטא-נתונים הטכניים. הסנכרון בין הקטלוג לנכסי הנתונים נעשה כמעט בזמן אמת.

הארכיטקטורה כוללת את Tag Engine להוספת התגים הבאים של המטא-נתונים העסקיים לתבנית התג CDMC controls ב-Data Catalog:

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

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

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

חלקי הארכיטקטורה של אמצעי הבקרה השני.

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

  • שני מחסני נתונים ב-BigQuery: אחד לאחסון המידע הסודי, והשני לאחסון ברירות המחדל של הבעלות על נכסי הנתונים.
  • המטא-נתונים של הבעלות נשמרים ב-Data Catalog באמצעות תבניות ותגים.
  • שתי מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
  • Pub/Sub משמש לפרסום הממצאים.

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

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

אמצעי הבקרה הזה דורש לסווג את נכסי הנתונים ולנהל רישום של מקורות מידע ומפיצים מורשים. הארכיטקטורה כוללת את Data Catalog כדי להוסיף לתבנית CDMC controls את התג is_authoritative, שמציין אם לנכס הנתונים יש סמכות.

ב-Data Calaog אפשר לקטלג מערכי נתונים, טבלאות ותצוגות של BigQuery עם מטא-נתונים טכניים ועסקיים. המטא-נתונים הטכניים מאוכלסים באופן אוטומטי וכוללים את כתובת ה-URL של המשאב – המיקום של נקודת ההקצאה. המטא-נתונים העסקיים מוגדרים בקובץ התצורה של Tag Engine, וכוללים את התג is_authoritative.

במהלך ההרצה המתוזמנת הבאה, Tag Engine יאכלס את התג is_authoritative בתבנית CDMC controls באמצעות ערכי ברירת המחדל שמאוחסנים בטבלת העזר ב-BigQuery.

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

חלקי הארכיטקטורה של אמצעי הבקרה השלישי.

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

  • שני מחסני נתונים ב-BigQuery: אחד לאחסון המידע הסודי, והשני לאחסון ברירות המחדל של מקור הסמכות של נכסי הנתונים.
  • המטא-נתונים על מקורות הסמכות נשמרים ב-Data Catalog באמצעות תגים.
  • שתי מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
  • Pub/Sub משמש לפרסום הממצאים.

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

4. ניהול ריבונות הנתונים והמעבר בין גבולות

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

הארכיטקטורה כוללת את השימוש ב-Data Catalog כדי להוסיף לתבנית CDMC controls את התג approved_storage_location, שמגדיר את המיקום הגיאוגרפי שבו מותר לאחסן את נכס הנתונים.

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

בשירות של מדיניות הארגון למגבלה על מיקומי המשאבים מוגדר באילו אזורים ב-Google Cloud אפשר לאחסן נתונים. כברירת מחדל, הארכיטקטורה מגדירה את המגבלה על הפרויקט של המידע הסודי, אבל תוכלו לשנות אותה ברמת הארגון או התיקייה אם תעדיפו. Tag Engine מעתיק את המיקומים המותרים לתבנית תגים של Data Catalog, ומאחסן את המיקום בתג approved_storage_location. אם מפעילים את המסלול Security Command Center Premium, ומישהו מעדכן את השירות של מדיניות הארגון למגבלה על מיקומי המשאבים, Security Command Center יוצר ממצאי נקודות חולשה למשאבים שמאוחסנים מחוץ למיקומים המעודכנים במדיניות החדשה.

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

כדי לעקוב אחרי תנועת הנתונים, BigQuery שומר על מסלול ביקורת מלא לכל משימה ושאילתה בכל מערך נתונים. מסלול הביקורת מאוחסן בתצוגה Information Schema Jobs ב-BigQuery.

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

חלקי הארכיטקטורה של אמצעי הבקרה הרביעי.

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

  • השירות של מדיניות הארגון מגדיר ואוכף את המגבלות על מיקומי המשאבים.
  • Access Context Manager מגדיר באילו מיקומים המשתמשים חייבים להיות כדי שתהיה להם גישה לנתונים.
  • שני מחסני נתונים ב-BigQuery: אחד לאחסון המידע הסודי, והשני לאחסון הפונקציה המרוחקת שמשמשת לבדיקת מדיניות המיקום.
  • מיקומי האחסון המאושרים מאוחסנים ב-Data Catalog בתור תגים.
  • שתי מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
  • Pub/Sub משמש לפרסום הממצאים.
  • Cloud Logging משמש לכתיבת יומני הביקורת.
  • ב-Security Command Center מדווחים הממצאים שקשורים למיקום המשאבים או לגישה לנתונים.

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

5. הטמעת קטלוגים של נתונים ושימוש בהם תוך יכולת פעולה הדדית

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

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

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

חלקי הארכיטקטורה של אמצעי הבקרה החמישי.

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

  • שני מחסני נתונים ב-BigQuery: אחד לאחסון המידע הסודי, והשני לאחסון המידע הלא סודי.
  • ב-Data Catalog נשמרים המטא-נתונים הטכניים של הטבלאות והשדות.

כברירת מחדל, בארכיקטורה הזו Data Catalog שומר מטא-נתונים טכניים מ-BigQuery. אם צריך, תוכלו לשלב את Data Catalog עם מקורות אחרים של נתונים.

6. הגדרת קטגוריות וסיווג הנתונים

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

הקטגוריות נשמרות בתג sensitive_category בתבנית התגים של Data Catalog ברמת הטבלה וברמת העמודה. בעזרת טבלת עזר לסיווג אפשר לדרג את רמת הזמינות של Sensitive Data Protection לפי סוגי המידע (infoTypes), עם דירוגים גבוהים יותר לתוכן רגיש יותר.

כדי לעמוד בדרישות של אמצעי הבקרה הזה, הארכיטקטורה כוללת שימוש ב-Sensitive Data Protection, ב-Data Catalog וב-Tag Engine כדי להוסיף את התגים הבאים לעמודות עם מידע רגיש בטבלאות של BigQuery:

  • is_sensitive: האם נכס הנתונים מכיל מידע רגיש
  • sensitive_category: אחת מקטגוריות הנתונים הבאות
    • פרטים אישיים מזהים בעלי רגישות גבוהה (SPII)
    • פרטים אישיים מזהים (PII)
    • מידע אישי רגיש
    • מידע אישי
    • מידע ציבורי

אתם יכולים לשנות את קטגוריות הנתונים בהתאם לדרישות שלכם. לדוגמה, תוכלו להוסיף את הקטגוריה 'תוכן חיוני לא ציבורי' (MNPI).

אחרי בדיקת הנתונים באמצעות Sensitive Data Protection, הטבלאות של DLP results נקראות ב-Tag Engine לכל נכס כדי ליצור את הממצאים. אם טבלה מכילה עמודות עם infoType רגיש אחד או יותר, ה-infoType הרגיש ביותר הוא הקובע. גם העמודות הרגישות וגם הטבלה כולה יתויגו ויסווגו לקטגוריה הגבוהה ביותר. בנוסף, Tag Engine יקצה תג מדיניות תואם לעמודה ואת התג הבוליאני is_sensitive לטבלה.

תוכלו להשתמש ב-Cloud Scheduler כדי להגדיר שהבדיקות של Sensitive Data Protection יבוצעו אוטומטית.

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

חלקי הארכיטקטורה של אמצעי הבקרה השישי.

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

  • ארבעה מחסני נתונים ב-BigQuery, לאחסון המידע הבא:
    • מידע סודי
    • מידע על התוצאות של Sensitive Data Protection
    • נתוני עזר לסיווג המידע
    • מידע על ייצוא התגים
  • תגי הסיווג נשמרים ב-Data Catalog.
  • Sensitive Data Protection בודק אם יש בנכסים infoTypes רגישים.
  • Compute Engine מריץ את הסקריפט Inspect Datasets, שמפעיל משימה של Sensitive Data Protection לכל אחד ממערכי הנתונים ב-BigQuery.
  • שתי מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
  • Pub/Sub משמש לפרסום הממצאים.

כדי לזהות בעיות שקשורות לאמצעי הבקרה הזה, הארכיטקטורה כוללת את הבדיקות הבאות:

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

7. ניהול ואכיפה של הרשאות הגישה לנתונים, תוך מעקב אחרי הגישה

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

כדי לעמוד בדרישות של אמצעי הבקרה הזה, הארכיטקטורה כוללת שימוש בטקסונומיה של תגי המדיניות cdmc sensitive data classification ב-BigQuery כדי לשלוט בגישה לעמודות שמכילות מידע סודי בטבלאות של BigQuery. הטקסונומיה כוללת את תגי המדיניות הבאים:

  • פרטים אישיים מזהים בעלי רגישות גבוהה (SPII)
  • פרטים אישיים מזהים (PII)
  • מידע אישי רגיש
  • מידע אישי

בעזרת תגי המדיניות אפשר להחליט מי יכול לראות עמודות רגישות בטבלאות של BigQuery. הארכיטקטורה ממפה את תגי המדיניות האלה לקטגוריות רגישות שנגזרות מ-infoTypes של Sensitive Data Protection. לדוגמה, תג המדיניות sensitive_personal_identifiable_information וקטגוריית הרגישות ממופים ל-infoTypes כמו AGE, DATE_OF_BIRTH, PHONE_NUMBER ו-EMAIL_ADDRESS.

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

כדי להבטיח שרק למשתמשים מאומתים יתהיה גישה לנתונים, אנחנו משתמשים ב-Cloud Identity ב-Google Cloud, שאפשר לאחד עם ספקי הזהויות הקיימים שלכם כדי לאמת את המשתמשים.

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

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

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

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

חלקי הארכיטקטורה של אמצעי הבקרה השביעי.

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

  • מחסן נתונים (data warehouse) ב-BigQuery לאחסון הנתונים הסודיים והקישורים של תגי המדיניות כדי ליצור בקרת גישה פרטנית.
  • IAM לניהול הגישה.
  • Data Catalog לאחסון תגים של קטגוריות רגישות ברמת הטבלה והעמודה.
  • שתי מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.

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

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

אמצעי הבקרה הזה מחייב לכלול בארכיטקטורה רכיב לאחסון הסכמי שיתוף הנתונים של ספק הנתונים ושל צרכני הנתונים, כולל רשימה של מטרות מאושרות לשימוש. מטרת השימוש במידע אישי רגיש תמופה לפי ההרשאות שמאוחסנות ב-BigQuery באמצעות תוויות של שאילתות. כשצרכן שולח שאילתה לקבלת מידע אישי רגיש ב-BigQuery, עליו לציין מטרה חוקית שתואמת להרשאה שלו (לדוגמה, SET @@query_label = “use:3”;).

הארכיטקטורה כוללת את השימוש ב-Data Catalog כדי להוסיף לתבנית התג CDMC controls את התגים הבאים, שמייצגים את הסכם שיתוף הנתונים עם ספק הנתונים:

  • approved_use: המשתמשים שאושרו או מטרת השימוש שאושרה לנכס הנתונים
  • sharing_scope_geography: רשימת המיקומים הגיאוגרפיים שבהם אפשר לשתף את נכס הנתונים
  • sharing_scope_legal_entity: רשימת הישויות שאושר להם לשתף את נכס הנתונים

מחסן נתונים נפרד ב-BigQuery כולל את מערך הנתונים entitlement_management, עם הטבלאות הבאות:

  • provider_agreement: הסכם שיתוף הנתונים עם ספק הנתונים, כולל הישות המשפטית המוסכמת וההיקף הגיאוגרפי. הנתונים האלה הם ברירות המחדל לתגים shared_scope_geography ו-sharing_scope_legal_entity.
  • consumer_agreement: הסכם שיתוף הנתונים עם צרכן הנתונים, כולל הישות המשפטית המוסכמת וההיקף הגיאוגרפי. כל הסכם צריך להיות משויך לישות ב-IAM לנכס הנתונים.
  • use_purpose: מטרת השימוש, למשל תיאור השימוש והפעולות המותרות בנכס הנתונים.
  • data_asset: מידע על נכס הנתונים, כמו שם הנכס ופרטים על בעלי הנתונים.

כדי לפקח אחרי הסכמי שיתוף הנתונים, BigQuery שומר על מסלול ביקורת מלא לכל משימה ושאילתה בכל מערך נתונים. מסלול הביקורת מאוחסן בתצוגה Information Schema Jobs ב-BigQuery. אחרי שמקשרים תווית שאילתה לסשן ומריצים שאילתות בסשן, אפשר לאסוף יומני ביקורת לשאילתות עם אותה תווית שאילתה. במסמך בנושא שימוש ביומני ביקורת ב-BigQuery תוכלו לקרוא מידע נוסף.

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

חלקי הארכיטקטורה של אמצעי הבקרה השמיני.

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

  • שני מחסני נתונים ב-BigQuery: אחד לאחסון המידע הסודי, והשני לאחסון נתוני ההרשאות, כולל הסכמי שיתוף הנתונים של הספק ושל הצרכנים ומטרת השימוש המאושרת.
  • Data Catalog משמש לאחסון הפרטים של הסכם שיתוף הנתונים של הספק כתגים.
  • שתי מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
  • Pub/Sub משמש לפרסום הממצאים.

כדי לזהות בעיות שקשורות לאמצעי הבקרה הזה, הארכיטקטורה כוללת את הבדיקות הבאות:

  • האם יש רשומה של נכס נתונים במערך הנתונים entitlement_management.
  • האם הפעולה מתבצעת בטבלה עם מידע אישי רגיש בתרחיש לדוגמה שפג תוקפו (למשל, valid_until_date ב-consumer_agreement table פג תוקף).
  • האם הפעולה מתבצעת בטבלה עם מידע אישי רגיש ומַפתח התווית שגוי.
  • האם הפעולה מתבצעת בטבלה עם מידע אישי רגיש וערך התווית של התרחיש לדוגמה ריק או ללא אישור.
  • האם נשלחת שאילתה לטבלה עם מידע אישי רגיש בשיטת פעולה שלא אושרה (לדוגמה, SELECT או INSERT).
  • האם המטרה המתועדת שהצרכן ציין בשאילתה לקבלת מידע אישי רגיש תואמת להסכם שיתוף הנתונים.

9. אבטחת הנתונים ותיעוד אמצעי הבקרה

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

הארכיטקטורה הזו מבוססת על אבטחת ברירת המחדל של Google, כולל הצפנה במנוחה. בנוסף, הארכיטקטורה מאפשרת לכם לנהל מפתחות משלכם – מפתחות הצפנה בניהול הלקוח (CMEK). ב-Cloud KMS תוכלו להצפין את הנתונים עם מפתחות הצפנה שמגובים באמצעות תוכנה, או עם מודולים לאבטחת חומרה (HSM) באימות FIPS 140-2 Level 3.

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

כברירת מחדל, בארכיטקטורה משתמשים בהצפנה עם CMEK ו-HSM, אבל אפשר גם להשתמש ב-Cloud External Key Manager (‏Cloud EKM).

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

רגישות הנתונים שיטת ברירת המחדל להצפנה שיטות הצפנה אחרות שמותר להשתמש בהן שיטת ברירת המחדל להסרת פרטי הזיהוי שיטות אחרות להסרת פרטי הזיהוי שמותר להשתמש בהן
מידע ציבורי הצפנת ברירת המחדל הכול אין הכול
פרטים אישיים מזהים בעלי רגישות גבוהה (SPII) CMEK עם HSM EKM איפוס גיבוב (hash) מסוג SHA-256 או ערך ברירת מחדל לאנונימיזציה
פרטים אישיים מזהים (PII) CMEK עם HSM EKM גיבוב (hash) מסוג SHA-256 איפוס או ערך ברירת מחדל לאנונימיזציה
מידע אישי רגיש CMEK עם HSM EKM ערך ברירת מחדל לאנונימיזציה גיבוב (hash) מסוג SHA-256 או איפוס
מידע אישי CMEK עם HSM EKM ערך ברירת מחדל לאנונימיזציה גיבוב (hash) מסוג SHA-256 או איפוס

הארכיטקטורה כוללת את השימוש ב-Data Catalog כדי להוסיף לתבנית CDMC controls את התג encryption_method. באמצעות encryption_method מוגדרת שיטת ההצפנה שבה משתמשים בנכס הטבלה.

בנוסף, הארכיטקטורה כוללת את יצירת התג security policy template כדי לזהות איזו שיטה להסרת פרטי הזיהוי יושמה בשדה מסוים. הארכיטקטורה כוללת שימוש ב-platform_deid_method באמצעות אנונימיזציה דינמית של הנתונים. תוכלו להוסיף את השדה app_deid_method ולאכלס אותו באמצעות צינורות העיבוד להטמעת נתונים של Dataflow ו-Sensitive Data Protection, שכלולים בתוכנית המאובטחת של מחסן הנתונים.

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

חלקי הארכיטקטורה של אמצעי הבקרה התשיעי.

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

  • שתי מכונות אופציונליות של Dataflow: אחת להסרת פרטי הזיהוי ברמת האפליקציה והשנייה לשחזור פרטי הזיהוי.
  • שלושה מחסני נתונים ב-BigQuery: אחד לאחסון המידע הסודי, שני לאחסון מידע לא סודי ושלישי לאחסון מדיניות האבטחה.
  • Data Catalog משמש לאחסון תבניות התגים של ההצפנה ושל הסרת פרטי הזיהוי.
  • שתי מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
  • הממצאים מפורסמים ב-Pub/Sub.

כדי לזהות בעיות שקשורות לאמצעי הבקרה הזה, הארכיטקטורה כוללת את הבדיקות הבאות:

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

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

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

הארכיטקטורה כוללת את השימוש ב-Data Catalog כדי להוסיף לתבנית התג Impact assessment את התגים הבאים:

  • subject_locations: המיקום של האנשים שאליהם מתייחס המידע בנכס הזה.
  • is_dpia: האם בוצעה הערכה להשפעה על פרטיות המידע (DPIA) בנכס הזה.
  • is_pia: האם בוצעה הערכה להשפעה על הפרטיות (PIA) בנכס הזה.
  • impact_assessment_reports: קישור חיצוני למקום שבו נשמר דוח הערכת ההשפעה.
  • most_recent_assessment: התאריך של הערכת ההשפעה האחרונה.
  • oldest_assessment: התאריך של הערכת ההשפעה הראשונה.

Tag Engine מוסיף את התגים האלה לכל נכס של מידע אישי רגיש, כפי שמוגדר באמצעי הבקרה השישי. הגלאי מאמת את התגים האלה מול טבלת מדיניות ב-BigQuery, שכוללת שילובים חוקיים של מיקום הנתונים, מיקום האדם שאליו מתייחס המידע, מידת הרגישות של המידע (לדוגמה, אם מדובר בפרטים אישיים מזהים) והסוג הנדרש של הערכת ההשפעה (PIA או DPIA).

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

חלקי הארכיטקטורה של אמצעי הבקרה העשירי.

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

  • ארבעה מחסני נתונים ב-BigQuery, לאחסון המידע הבא:
    • מידע סודי
    • מידע לא סודי
    • מדיניות להערכת ההשפעה וחותמות הזמן של ההרשאות
    • ייצוא תגים שמשמשים במרכז הבקרה
  • הפרטים של הערכת ההשפעה נשמרים ב-Data Catalog בתגים בתוך תבניות תגים.
  • שתי מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
  • Pub/Sub משמש לפרסום הממצאים.

כדי לזהות בעיות שקשורות לאמצעי הבקרה הזה, הארכיטקטורה כוללת את הבדיקות הבאות:

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

11. תכנון וניהול מחזור החיים של הנתונים

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

הארכיטקטורה כוללת את השימוש ב-Data Catalog כדי להוסיף לתבנית התג CDMC controls את התגים הבאים:

  • retention_period: משך הזמן (בימים) לשמירת הטבלה
  • expiration_action: האם להעביר לארכיון או למחוק באופן סופי את הטבלה בסיום תקופת השמירה

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

קטגוריית מידע תקופת שמירה (בימים) פעולת התפוגה
פרטים אישיים מזהים בעלי רגישות גבוהה (SPII) 60 מחיקה באופן סופי
פרטים אישיים מזהים (PII) 90 העברה לארכיון
מידע אישי רגיש 180 העברה לארכיון
מידע אישי 180 העברה לארכיון

Record Manager – נכס בקוד פתוח ל-BigQuery, שמבצע אוטומציה של המחיקה באופן סופיה וההעברה לארכיון של טבלאות ב-BigQuery לפי ערכי התג שלמעלה וקובץ התצורה. בתהליך המחיקה באופן סופי מוגדר תאריך תפוגה בטבלה ונוצרת טבלת snapshot עם מועד תפוגה, שמוגדר בתצורה של Record Manager. כברירת מחדל, מועד התפוגה הוא אחרי 30 יום. במהלך תקופת המחיקה עם יכולת שחזור אפשר לשחזר את הטבלה. בתהליך ההעברה לארכיון נוצרת טבלה חיצונית לכל טבלה ב-BigQuery שעוברת את תקופת השמירה שלה. הטבלה מאוחסנת ב-Cloud Storage בפורמט parquet ומשודרגת לטבלת BigLake – כך אפשר לתייג את הקובץ החיצוני באמצעות מטא-נתונים ב-Data Catalog.

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

חלקי הארכיטקטורה של אמצעי הבקרה האחד עשר.

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

  • שני מחסני נתונים ב-BigQuery: אחד לאחסון המידע הסודי, והשני לאחסון מדיניות שמירת הנתונים.
  • שתי מכונות של Cloud Storage: אחת לאחסון בארכיון והשניה לאחסון הרשומות.
  • תקופת השמירה והפעולה מאוחסנות ב-Data Catalog בתבניות תגים ותגים.
  • שתי מכונות של Cloud Run: אחת להפעלה של Record Manager והשנייה לפריסת הגלאים.
  • שלוש מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
    • במכונה אחרת פועל Record MAnager, שמאפשר את האוטומציה של המחיקה באופן סופי וההעברה לארכיון של טבלאות ב-BigQuery.
  • Pub/Sub משמש לפרסום הממצאים.

כדי לזהות בעיות שקשורות לאמצעי הבקרה הזה, הארכיטקטורה כוללת את הבדיקות הבאות:

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

12. ניהול איכות הנתונים

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

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

  • column_name: שם העמודה שאליה מתייחס המדד
  • metric: שם המדד או כלל האיכות
  • rows_validated: מספר השורות המאומתות
  • success_percentage: אחוז הערכים שעומדים במדד
  • acceptable_threshold: ערך הסף הקביל למדד
  • meets_threshold: האם ציון האיכות (הערך success_percentage) עומד בערך הסף הקביל
  • most_recent_run: הפעם האחרונה שבה כלל האיכות או המדד הופעלו

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

חלקי הארכיטקטורה של אמצעי הבקרה השניים עשר.

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

  • שלושה מחסני נתונים ב-BigQuery: אחד לאחסון המידע האישי הרגיש, שני לאחסון מידע לא רגיש ושלישי לאחסון מדדי כלל האיכות.
  • התוצאות של בדיקת איכות הנתונים מאוחסנות ב-Data Catalog בתניות תגים ותגים.
  • ב-Cloud Scheduler מוגדר מתי צריך להפעיל את Cloud Data Quality Engine.
  • שלוש מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
    • המכונה השלישית מפעילה את Cloud Data Quality Engine.
  • Cloud Data Quality Engine מגדיר כללים לאיכות הנתונים ומתזמן את הבדיקות של איכות הנתונים לטבלאות ולעמודות.
  • Pub/Sub משמש לפרסום הממצאים.

במרכז הבקרה של Looker Studio מופיעים הדוחות על איכות הנתונים – גם ברמת הטבלה וגם ברמת העמודה.

כדי לזהות בעיות שקשורות לאמצעי הבקרה הזה, הארכיטקטורה כוללת את הבדיקות הבאות:

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

במקום Cloud Data Quality Engine, אפשר להגדיר משימות של בקרת איכות ב-Dataplex.

13. קביעה ויישום של עקרונות לניהול העלויות

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

הארכיטקטורה כוללת את השימוש ב-Data Catalog כדי להוסיף לתבנית התג cost_metrics את התגים הבאים:

  • total_query_bytes_billed: המספר הכולל של הבייטים של השאילתות שחויבו בנכס הנתונים הזה מאז תחילת החודש הנוכחי.
  • total_storage_bytes_billed: המספר הכולל של הבייטים של האחסון שחויבו בנכס הנתונים הזה מאז תחילת החודש הנוכחי.
  • total_bytes_transferred: סכום הבייטים שהועברו בין אזורים בנכס הנתונים הזה.
  • estimated_query_cost: העלות המשוערת לשאילתה (בדולר ארה"ב) בנכס הנתונים בחודש הנוכחי.
  • estimated_storage_cost: עלות האחסון המשוערת (בדולר ארה"ב) בנכס הנתונים בחודש הנוכחי.
  • estimated_egress_cost: תעבורת נתונים יוצאת (egress) משוערת בדולר ארה"ב לחודש הנוכחי שבו נכס הנתונים שימש כטבלת יעדים.

הארכיטקטורה כוללת את הייצוא של נתוני התמחור מהחיוב ב-Cloud לטבלה ב-BigQuery בשם cloud_pricing_export.

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

חלקי הארכיטקטורה של אמצעי הבקרה השלושה עשר.

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

  • נתוני החיוב מגיעים מהחיוב ב-Cloud.
  • נתוני העלויות נשמרים ב-Data Catalog בתבניות ובתגים של התגים.
  • BigQuery משמש לאחסון נתוני התמחור שיוצאו ואת פרטי המשימות מהיסטוריית השאילתות באמצעות התצוגה המובנית INFORMATION_SCHEMA.
  • שתי מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
  • Pub/Sub משמש לפרסום הממצאים.

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

14. הבנת מקורות הנתונים

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

כדי לשמור מידע על מקורות והשתלשלות הנתונים הארכיטקטורה כוללת שימוש בתכונות המובנות של Data Lineage ב-Data Catalog. בנוסף, הסקריפטים של הטמעת הנתונים מגדירים את המקור האולטימטיבי ומוסיפים את המקור כצומת נוסף לתרשים של השתלשלות הנתונים.

כדי לעמוד בדרישות של אמצעי הבקרה הזה, הארכיטקטורה כוללת שימוש ב-Data Catalog להוספת התג ultimate_source לתבנית התג CDMC controls. התג ultimate_source מגדיר את המקור של נכס הנתונים.

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

חלקי הארכיטקטורה של אמצעי הבקרה הארבעה עשר.

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

  • שני מחסני נתונים ב-BigQuery: אחד לאחסון המידע הסודי, והשני לאחסון נתוני המקור האולטימטיבי.
  • המקור האולטימטיבי נשמר ב-Data Catalog בתבניות תגים ותגים.
  • סקריפטים של הטמעת נתונים משמשים לטעינת הנתונים מ-Cloud Storage, הגדרת המקור האולטימטיבי והוספת המקור לתרשים של השתלשלות הנתונים.
  • שתי מכונות של Cloud Run:
    • באחת נמצא Report Engine, שמשמש לבדיקה אם יש תגים ופרסום התוצאות.
    • בשנייה נמצא Tag Engine, לתיוג הנתונים במחסן הנתונים המאובטח.
  • Pub/Sub משמש לפרסום הממצאים.

כדי לזהות בעיות שקשורות לאמצעי הבקרה הזה, הארכיטקטורה כוללת את הבדיקות הבאות:

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

טבלת עזר לתגים

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

תבניות התגים של אמצעי הבקרה למפתחות CDMC ברמת הטבלה

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

תג מזהה תג אמצעי בקרה רלוונטי לתג
מיקום האחסון שאושר approved_storage_location 4
שימוש מאושר approved_use 8
כתובת האימייל של בעלי הנתונים data_owner_email 2
השם של בעלי הנתונים data_owner_name 2
שיטת ההצפנה encryption_method 9
פעולת התפוגה expiration_action 11
גורם מוסמך is_authoritative 3
מידע אישי רגיש is_sensitive 6
קטגוריית רגישות sensitive_category 6
המיקום הגיאוגרפי בהיקף השיתוף sharing_scope_geography 8
הישות המשפטית בהיקף שיתוף sharing_scope_legal_entity 8
תקופת השמירה retention_period 11
המקור האולטימטיבי ultimate_source 14

תבנית תגים להערכת ההשפעה

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

תג מזהה תג אמצעי בקרה רלוונטי לתג
מיקום האדם שאליו מתייחס המידע subject_locations 10
הערכת ההשפעה מסוג DPIA is_dpia 10
הערכת ההשפעה מסוג PIA is_pia 10
דוחות הערכת ההשפעה impact_assessment_reports 10
הערכת ההשפעה האחרונה most_recent_assessment 10
הערכת ההשפעה הראשונה oldest_assessment 10

תבנית תגים למדדי העלויות

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

תג מזהה הכרטיסייה אמצעי בקרה רלוונטי לתג
עלות משוערת לשאילתה estimated_query_cost 13
עלות אחסון משוערת estimated_storage_cost 13
עלות של תעבורת נתונים יוצאת (egress) estimated_egress_cost 13
סה"כ בייטים לשאילתה total_query_bytes_billed 13
סה"כ בייטים שחויבו על אחסון total_storage_bytes_billed 13
סה"כ בייטים שהועברו total_bytes_transferred 13

תבנית תגים לרגישות המידע

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

תג מזהה תג אמצעי בקרה רלוונטי לתג
שדה עם מידע אישי רגיש sensitive_field 6
סוג המידע האישי הרגיש sensitive_category 6

תבניות תגים למדיניות האבטחה

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

תג מזהה תג אמצעי בקרה רלוונטי לתג
השיטה להסרת פרטי הזיהוי ברמת האפליקציה app_deid_method 9
השיטת להסרת פרטי הזיהוי ברמת הפלטפורמה platform_deid_method 9

תבניות תגים לאיכות הנתונים

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

תג מזהה תג אמצעי בקרה רלוונטי לתג
ערך הסף הקביל acceptable_threshold 12
שם העמודה column_name 12
עומד בערך הסף meets_threshold 12
מדד metric 12
ההפעלה האחרונה most_recent_run 12
שורות מאומתות rows_validated 12
אחוז הצלחה success_percentage 12

תגי מדיניות של CDMC ברמת השדה

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

קטגוריית הנתונים שם התג אמצעי בקרה רלוונטי לתג
פרטים אישיים מזהים (PII) personal_identifiable_information 7
מידע אישי personal_information 7
פרטים אישיים מזהים בעלי רגישות גבוהה (SPII) sensitive_personal_identifiable_information 7
מידע אישי רגיש sensitive_personal_data 7

מטא-נתונים טכניים שמאוכלסים מראש

אלו הם המטא-נתונים הטכניים שמסתנכרנים כברירת מחדל ב-Data Catalog לכל נכסי הנתונים ב-BigQuery.

מטא-נתונים אמצעי בקרה רלוונטי לתג
סוג הנכס
מועד יצירה
מועד תפוגה 11
מיקום 4
כתובת ה-URL של המשאב 3

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