10110010011101001011001101101110101018200.devFrom Enterprise.Systems

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

The 8200.dev Teamקריאה של 5 דק׳

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

הגדירו תחולה ויעדים

הערכת סיכונים בלי תחולה נסחפת לביקורת אינסופית. קבעו את הגבולות קודם:

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

תחומי ההערכה

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

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

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

3. קשרים חיצוניים. מי מחוץ לדומיין שלכם יכול להגיע לנתונים, והאם כל קשר עדכני? ראו סיכון השיתוף החיצוני.

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

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

מתודולוגיה שמפיקה מספר בר-הגנה

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

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

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

דווחו סיכון במונחים עסקיים

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

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

הפכו את זה לרציף, לא שנתי

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

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

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

תוכנית 30 יום לקו בסיס בר-הגנה

אם אתם מתחילים מ״אנחנו לא באמת יודעים,״ חודש ממוקד מביא אתכם לעמדה שאפשר לעמוד מאחוריה:

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

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

מדדים שחשובים להנהלה

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

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

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

שיתוףX / TwitterLinkedIn

מאמרים קשורים