מפו את הסביבה ואת מי שיכול לנהל אותה
רשמו דומיינים, משתמשים, קבוצות, מנהלים ואנשי קשר לשחזור. חשבון Super Admin יכול לשנות תחומים רחבים, ולכן צריך להבין מתי משתמשים בו ומי יכול להחליף את המנהל במקרה הצורך. Google ממליצה על הגנת מנהלים, אמצעי התאוששות והרשאות מתאימות למשימות יומיומיות.
היקף הבדיקה כולל גם משתמשים שעזבו, ספקים וחשבונות שאינם שייכים לעובד קבוע. לא מוחקים חשבון רק כי שמו אינו מוכר. מבררים צורך ותלות, ושומרים סמכות גישה מסודרת לפני שינוי שמשפיע על אנשים או על אוטומציה.
בדקו תחומים נפרדים עם ראיה לכל אחד
הטבלה היא כלי סקירה מקורי, ואינה טבלת זכאות לכל מהדורות Workspace. סמנו מה נבדק, מה לא זמין ומה מחייב גורם נוסף. תצורה ברמת הארגון יכולה לכלול חריגות או היקף מסוים; לא מניחים שכל משתמש וכל קובץ מקבלים אותה תוצאה.
| תחום | שאלת קבלה | ראיה שימושית |
|---|---|---|
| מנהלים | מי צריך סמכות ובאיזה היקף | תפקיד, בעלים ודרך החלפה |
| אימות והתאוששות | האם המשתמש מוכן ומה קורה באובדן | בדיקת ניסיון ללא נעילה |
| Gmail | אילו הגנות ונתיבי שליחה חלים | תצורה וכיסוי שנבדקו |
| Drive ויומן | מי רואה ומשנה מידע חיצוני | פריט ניסיון ונתיב שיתוף |
| יישומים | איזה שירות ו-scope קיבלו גישה | מזהה, צורך ובעלים |
| מעקב ושחזור | מי בודק אירוע ומה ניתן להחזיר | נתיב טיפול ובדיקת כיסוי |
אכיפת אימות מתחילה במוכנות ובחלופה
מפו מנהלים ומשתמשים שזקוקים לאמצעי אימות ושחזור. לפני אכיפה בדקו הרשמה, תקשורת עם המשתמש ויכולת ניהול חלופית לפי ההנחיות. קוד גיבוי הוא סוד ולא נספח לדוח. שמירתו והגישה אליו דורשות מנגנון מוגן שמיועד למורשים בלבד.
כבר קיים מדריך נפרד להפעלת MFA ב-Workspace; הרשימה כאן בודקת גם בעלות והיקף לאחר ההפעלה. אמצעי אימות רשום אינו בהכרח ראיה שכל מדיניות הכניסה חלה כפי שתוכננה. אם משתמש איבד אמצעי, פועלים במסלול התאוששות מתאים ולא מבטלים הגנה לכל הארגון.
שיתוף והרשאת יישום הם שני מסלולי גישה
בדקו קישורים, קבוצות, אורחים ובעלות על קבצים ויומנים. הרשאה יכולה להגיע בדרך עקיפה, ולכן שינוי קישור אחד אינו בהכרח ביטול כל גישה. השתמשו בפריט ניסיון שאינו מכיל מידע לקוחות ובחנו צפייה, שינוי וגבולות בהתאם למדיניות העסקית שסוכמה.
ב-API controls אפשר לבחון יישומים, מזהים ושירותים שביקשו גישה. Google מבחינה בין יישומים שהוגדרה להם מדיניות לבין יישומים שניגשו לנתונים. רשימה ריקה בתצוגה אחת אינה בהכרח הוכחה שאין חיבורים. לפני חסימה או שינוי אמון ממפים תלות ומגדירים בדיקת סיום.
דוגמה: סיסמה הוחלפה אך החיבור העסקי נשאר נפרד
התרחיש להמחשה בלבד. עובד משנה סיסמה לאחר חשד, אבל סקירת השגרה מוצאת יישום עם גישה שדורש בירור נפרד. הצוות בודק מזהה, scope, בעלים וצורך. לא מסיק משינוי הסיסמה שכל הרשאות היישומים נבדקו, ולא מסמן כל חיבור כזדוני בלי ראיה.
לשינוי בקרת יישומים יכולה להיות השפעה על אוטומציה ועל כניסה לשירותים. לא בוחרים חסימה גורפת רק כדי לקבל רשימה קצרה יותר. כאשר נמצא סימן לאירוע פעיל, הגבלת גישה ושימור מידע מתוכננים במסגרת האירוע ולא רק כתיקון מסמך בדיקה.
סגרו פערים עם תוצר ואחריות להמשך
מסרו מצב, היקף וחריגות למנהלים, לאימות, לדואר ולשיתוף. בדקו מי מקבל התראה ומי יכול לברר אותה, ומה נשאר מחוץ לכיסוי הרישוי או הסקירה. גיבוי דואר ושחזור קבצים מקבלים בירור נפרד; תקינות כניסה אינה מוכיחה שאפשר להחזיר מידע שנמחק.
ב-CyberFixCrew אפשר לברר סקירת גישה ודואר לפי שירותי החברה והסביבה. אין במדריך התחייבות לניהול כל תכונת Google או אישור עמידה בכל דרישה. בפנייה תארו צורך ומבנה בלי להעביר מפתחות, קודי שחזור או מידע תיבות וקבצים.
