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

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

למה רכישת MFA נכשלת אחרי הפיילוט

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

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

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

סקירת כלי MFA: ארבע משפחות פתרונות

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

MFA כחלק מפלטפורמת זהויות בענן

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

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

פתרון MFA ייעודי

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

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

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

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

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

MFA שמבוסס על מפתחות אבטחה ואימות ללא סיסמה

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

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

מה לבדוק לפני שמחליטים

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

בדקו במיוחד את ארבעת הנושאים הבאים:

• אינטגרציות בפועל: האם הכלי תומך בפרוטוקולים ובמחברים שאתם צריכים, כולל SAML, RADIUS, LDAP ומערכות מקומיות? אל תניחו שתמיכה כללית ב-VPN או ב-SSO מכסה את הגרסה והארכיטקטורה שלכם.
• שיטות אימות: אפליקציית מאמת, התראות אישור, קודים חד-פעמיים, מפתח אבטחה וביומטריה אינם אותו דבר. הגדירו אילו שיטות מותרות לעובדים, אילו נדרשות למנהלים ואילו אסורות לחשבונות בעלי הרשאות גבוהות.
• התאוששות גישה: מי רשאי לאפס גורם אימות, איך מאמתים את זהות העובד, ומה קורה מחוץ לשעות הפעילות? תהליך חלש כאן יכול לעקוף את כל ההגנה.
• דיווח ובקרה: צוות אבטחה צריך לראות כשלי התחברות, שינויים בגורמי אימות, החרגות ומכשירים חדשים. ודאו שאפשר להעביר אירועים למערכת ניטור האבטחה שלכם ולתחקר אירוע בלי לאסוף נתונים ידנית.

אל תבלבלו בין MFA לבין ניהול סיסמאות

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

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

רישוי MFA הוא גם עניין של FinOps

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

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

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

פריסת MFA בלי לשתק את הארגון

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

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

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

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