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

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

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

מה נדרש מפתרונות אימות דו שלבי לארגונים

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

פתרון ארגוני צריך להתחבר לספק הזהויות הקיים, בדרך כלל Active Directory, Microsoft Entra ID או סביבת זהויות אחרת, ולתמוך בפרוטוקולים מקובלים כגון SAML, OAuth ו-OpenID Connect.
ללא חיבור נכון לזהויות, כל אפליקציה הופכת לפרויקט נפרד, המשתמשים מקבלים חוויית כניסה לא אחידה וצוות ה-IT מאבד שליטה על מחזור חיי החשבון.

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

לא כל גורם שני מספק אותה הגנה

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

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

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

קודם ממפים זהויות, אחר כך רוכשים רישיונות

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

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

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

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

פריסה מדורגת מצמצמת התנגדות ותקלות

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

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

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

המדיניות חייבת לפגוש את המציאות התפעולית

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

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

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

מדדי הצלחה שאפשר להציג להנהלה

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

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

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

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