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

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

למה הטמעת אימות רב שלבי לעובדים נכשלת לעיתים

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

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

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

מתחילים ממיפוי זהויות ולא מהגדרה טכנית

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

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

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

בוחרים שיטת אימות לפי רמת סיכון ושימושיות

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

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

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

פריסה מדורגת: קודם סיכון גבוה, אחר כך כלל הארגון

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

1. התחילו בצוותי IT, אדמיניסטרטורים, הנהלה בכירה ומשתמשים בעלי גישה למידע רגיש.
2. עברו לקבוצת פיילוט שמייצגת מחלקות שונות, מכשירים שונים ועובדים מרחוק.
3. תקנו בעיות הרשמה, התאוששות ותאימות לפני הרחבה למחלקות נוספות.
4. אכפו MFA לכלל העובדים רק לאחר שמערך התמיכה והנוהל התפעולי כבר נבדקו בפועל.

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

מדיניות גישה מותנית היא החלק שמבדיל בין MFA בסיסי לבקרה אמיתית

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

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

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

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

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

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

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

מדידה, תאימות ורישוי לאורך זמן

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

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

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

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