שיטות מומלצות לצמצום הסיכון לאובדן נתונים

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

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

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

הפעלה של מיון מידע אישי רגיש

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

שירות הגילוי פועל כמקור אמין לגבי נכסי הנתונים שלכם, ויכול לדווח באופן אוטומטי על מדדים בדוחות ביקורת. בנוסף, התכונה 'גילוי' יכולה להתחבר לשירותים אחרים כמו Google Cloud Security Command Center,‏ Google Security Operations ו-Knowledge Catalog כדי לשפר את פעולות האבטחה וניהול הנתונים.

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

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

דוח מוכן מראש

יוצרים קמפיינים על סמך תוצאות החיפוש

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

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

תרחיש 1: נמצא מידע אישי רגיש והוא מוגן כראוי

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

מומלץ לבצע את הפעולות הבאות:

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

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

תרחיש 2: נמצא מידע אישי רגיש שלא מוגן כראוי

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

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

המלצות כלליות

כדאי לנסות את הפעולות הבאות:

המלצות להגנה על נתונים ב-BigQuery

המלצות להגנה על נתונים ב-Cloud Storage

תרחיש 3: נמצאו נתונים רגישים, אבל נדרשת חקירה נוספת

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

שירות הבדיקה מאפשר להריץ סריקה יסודית של משאב יחיד, כמו טבלה ב-BigQuery או קטגוריה של Cloud Storage. אם מקורות הנתונים לא נתמכים ישירות על ידי שירות הבדיקה, אפשר לייצא את הנתונים לקטגוריה של Cloud Storage או לטבלה ב-BigQuery ולהריץ משימת בדיקה על המשאב הזה. לדוגמה, אם יש לכם נתונים שאתם צריכים לבדוק במסד נתונים של Cloud SQL, אתם יכולים לייצא את הנתונים האלה לקובץ CSV או AVRO ב-Cloud Storage ולהריץ משימת בדיקה.

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

בנוסף לשלבים המומלצים בתרחיש 2, כדאי לבצע פעולות שימנעו את הכנסת מידע רגיש לאחסון הנתונים של ה-Backend. השיטות content של Cloud Data Loss Prevention API יכולות לקבל נתונים מכל עומס עבודה או אפליקציה לצורך בדיקה והסתרת נתונים בתנועה. לדוגמה, האפליקציה יכולה:

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

סיכום השיטות המומלצות

בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במסמך הזה:

אתגר פעולה
אתם רוצים לדעת איזה סוג נתונים הארגון שלכם מאחסן. הפעלת גילוי ברמת הארגון, התיקייה או הפרויקט.
מצאתם מידע אישי רגיש במשאב שכבר מוגן. מעקב רציף אחרי המשאב באמצעות הפעלת גילוי וייצוא אוטומטי של פרופילים אל Security Command Center,‏ Google SecOps ו-Knowledge Catalog.
מצאתם מידע אישי רגיש במשאב שלא מוגן. להסתיר או להציג נתונים בהתאם למי שצופה בהם. אפשר להשתמש ב-IAM, באבטחה ברמת העמודה או באבטחה ברמת השורה. אפשר גם להשתמש בכלים להסרת פרטי הזיהוי של Sensitive Data Protection כדי לבצע טרנספורמציה או להסיר את הרכיבים הרגישים.
מצאתם מידע אישי רגיש ואתם צריכים להמשיך בבדיקה כדי להבין את היקף הסיכון לנתונים. מריצים עבודת בדיקה על המשאב. אפשר גם למנוע באופן יזום את הכנסת המידע האישי הרגיש למאגר הנתונים העורפי באמצעות contentהשיטות הסינכרוניות של DLP API, שמעבדות את הנתונים כמעט בזמן אמת.