מה זה DSPM? ניהול עמדת אבטחת נתונים במילים פשוטות

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

ההגדרה במשפט אחד

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

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

למה DSPM צמח

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

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

בעולם כזה, השאלות שחשובות השתנו:

• *איפה* הנתונים הרגישים שלנו, על פני כל המערכות האלה?
• *מי* יכול להגיע לכל פיסה מהם — כולל גורמים חיצוניים וזהויות לא-אנושיות?
• האם הגישה הזו *הולמת*, או שמשהו משותף יתר על המידה, ציבורי או מיושן?
• איך *נדע* כשזה משתנה?

DSPM הוא הדיסציפלינה שנבנתה לענות על השאלות האלה ברציפות, ולא פעם בשנה בביקורת.

במה DSPM שונה מ-CSPM, מ-DLP ומ-CIEM

מרק ראשי התיבות אמיתי. כך מתייחסים השכנים זה לזה:

• CSPM (ניהול עמדת אבטחת ענן) מתמקד בתצורות שגויות של *תשתית* ענן — דליי אחסון פתוחים, קבוצות אבטחה מתירניות, אמצעי אחסון לא מוצפנים. הוא שואל ״האם הענן מוגדר בצורה מאובטחת?״ DSPM שואל ״האם הנתונים חשופים, היכן שהם לא יהיו?״ הם חופפים בשכבת האחסון אבל מכוונים לדברים שונים.
• DLP (מניעת אובדן נתונים) מנסה *לעצור* נתונים רגישים מלצאת — חסימת דוא״ל עם מספר כרטיס אשראי, מניעת העלאת קובץ. DLP עוסק בנתונים בתנועה ברגע היציאה. DSPM עוסק בעמדה העומדת: הוא אומר לכם שהקובץ שותף יתר על המידה מלכתחילה, לפני שמשהו זז.
• CIEM (ניהול זכאויות תשתית ענן) מתמקד בזהויות ובזכאויות שלהן בפלטפורמות ענן — מי יכול לעשות מה. DSPM משתמש במידע הזכאויות אבל מציב במרכז את *הנתונים*: הוא ממפה את הגישה חזרה אל המשאבים שחשובים ושופט את החשיפה.

מודל מנטלי מועיל: CSPM מאבטח את הענן, DLP שומר על היציאות, CIEM מתיר את סבך ההרשאות, ו-DSPM מונע מהנתונים עצמם להיחשף מלכתחילה.

מה גישת DSPM עושה בפועל

בקילוף מיצוב הספקים, לתהליך עבודה של DSPM ארבעה מהלכים:

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

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

האם אתם צריכים DSPM?

הבעיה כנראה כבר קיימת אצלכם; השאלה היא אם אתם מנהלים אותה. כמה סימנים שאתם צריכים גישת DSPM מכוונת:

• רוב הנתונים שלכם חיים בפלטפורמות ענן ולא בתשתית שבשליטתכם.
• השיתוף הוא בשירות עצמי — כל משתמש יכול להעניק גישה — ולכן מלאי הגישה שלכם חסר.
• יש לכם חובות ציות (SOC 2, ISO 27001, GDPR, HIPAA) שדורשות להדגים שליטה במי שיכול לגשת לנתונים.
• אינכם מסוגלים כרגע לענות על ״מי יכול לראות את תיקיית הנתונים הרגישים הזו?״ בלי חקירה ידנית.
• סוכנים אוטומטיים וחשבונות שירות מחזיקים גישה לנתונים שלכם ואיש אינו מושל בהם.

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

DSPM בפועל לגוגל וורקספייס

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

איך נראה DSPM טוב בפועל

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

• הוא מתעדף ללא רחמים. כלי שמחזיר עשרת אלפים ממצאים פשוט הזיז את הבעיה. DSPM טוב מדרג לפי סיכון אמיתי — רגישות כפול רוחב גישה כפול רמת גישה — כך שהקומץ שחשוב עולה למעלה והשאר מחכים לתורם.
• הוא מסביר את עצמו. ״קישור ציבורי על קובץ הכספים הרבעוני, נגיש לכל מי שיש לו את הכתובת, כי השיתוף הוגדר לכל-מי-שיש-לו-את-הקישור ב-4 במרץ״ — זה בר-פעולה. קוד ממצא — לא. יכולת ההסבר היא מה שמאפשר למי שאינו מומחה לפעול בלי להסלים.
• הוא בקריאה בלבד כברירת מחדל. גילוי לא אמור לדרוש גישת כתיבה לנתונים שלכם. הכלים בעלי המגע הקל ביותר ממפים ומעריכים בלי יכולת לשנות, מה ששומר על כך שכלי האבטחה עצמו לא יהפוך לסיכון.
• הוא סוגר את המעגל. מציאת חשיפה היא חצי מהעבודה; מעקב אחריה עד לפתרון ואישור שהיא נשארה מתוקנת הם החצי השני. עמדה שנמדדת אך לעולם אינה מטופלת היא רק דאגה מפורטת יותר.

תפיסות שגויות נפוצות

כמה מיתוסים מאטים צוותים:

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

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

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

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