למה חובה להפעיל MFA בכל מקום ולא רק בעבודה

אימות דו-שלבי (MFA) הפך מתוספת אבטחה “נחמד להיות” לדרישת סף בכל ארגון שמתייחס לאבטחת מידע ברצינות. הבעיה היא שצוותי IT רבים עדיין תופסים MFA כמנגנון שמיועד רק להתחברות לפורטל הראשי או לדוא”ל הארגוני, ומשאירים מחוץ לתמונה משטחים קריטיים כמו גישת ניהול, VPN, ממשקי API ותשתיות ענן. הפער הזה הוא בדיוק המקום שבו תוקפים אמיתיים פורצים.

מה קרה כשחברות גדולות לא הרחיבו MFA לכל המשטחים

בספטמבר 2022 נפרצה Uber בתקרית שהפכה למקרה בוחן קלאסי. התוקף רכש פרטי התחברות של קונטרקטור בדארקנט, אבל אלה כללו הגנת MFA. במקום לעצור, התוקף הפציץ את המשתמש בעשרות בקשות push notification (“MFA fatigue” / “MFA bombing”) עד שהאחרון, מתוך תשישות, אישר בקשה אחת. משם התוקף קיבל דריסת רגל ברשת הפנימית, ומצא סקריפט PowerShell עם קרדנציאלים קשיחים (hardcoded) לגישה למערכת ניהול הרשאות פנימית בשם Thycotic — מערכת שדווקא לא הוגנה ב-MFA נוסף. התוצאה: גישה למאגרי קוד, לוחות Slack פנימיים, וסביבות ניהול בענן.

המקרה הזה מדגים שני כשלים שחוזרים על עצמם בארגונים רבים: ראשית, MFA מבוסס push בלבד, בלי אימות מספר או אימות מבוסס-הקשר (context-aware), חשוף להתקפות עייפות. שנית — וזה החשוב יותר לענייננו — מערכות ניהול פנימיות קריטיות (privileged access) לא היו מוגנות ב-MFA כלל.

גישת ניהול ו-VPN: המשטח שהכי כדאי לתוקפים

בתקיפת Colonial Pipeline במאי 2021, שהובילה לשבתון של צנרת הדלק הגדולה במזרח ארה”ב, נקודת הכניסה הייתה חשבון VPN ישן שלא היה פעיל אך נותר תקף, ולא היה מוגן ב-MFA. סיסמה אחת שדלפה קודם לכן ברשת אחרת (reuse) הספיקה לחלוטין. אין תהליך push, אין קוד SMS, אין FIDO2 — רק סיסמה. חברת האבטחה שביצעה את החקירה מסרה בפומבי כי אימות דו-שלבי על חשבון ה-VPN היחיד הזה היה עוצר את כל השרשרת בטרם התחילה.

מקרה נוסף רלוונטי הוא הפריצה ל-Cisco באמצע 2022: התוקף השיג גישה לחשבון Google פרטי של עובד שדרכו סונכרנו סיסמאות שמורות בדפדפן, ואז השתמש בהתקפת voice phishing (vishing) כדי לשכנע את העובד לאשר בקשת MFA — אך כאן ההצלחה של ההגנה התבטאה בכך שהתוקף נזקק כלל למאמץ נוסף כדי לעקוף את השכבה השנייה. ברגע שהתוקף עבר את ה-MFA, הוא נרשם למכשירים חדשים ב-Duo וקיבל גישה ל-VPN הארגוני. כלומר: MFA עבד כמצופה, אבל היעדר מדיניות שמגבילה רישום מכשירים חדשים ומתעדת אותם — הרחיב את חלון החשיפה.

למה חשבונות שירות, API Keys ו-SaaS נשארים מחוץ למעגל ההגנה

ארגונים רבים מיישמים MFA היטב על חשבונות אנוש (human accounts) אך משאירים חשבונות שירות (service accounts), אינטגרציות API, וגישת אדמין למערכות SaaS צד שלישי בלי הגנה נוספת. תקרית SolarWinds ב-2020 ניכרת בעיקר בשרשרת האספקה, אבל אחד ההיבטים המזלזלים שנחשפו מאוחר יותר היה שחלק מהחשבונות המנהליים בסביבת Office 365 של הקורבנות לא היו מוגנים ב-MFA, מה שהאפשר לתוקף להנפיק טוקנים ולחתום SAML tokens בעצמו ברגע שהשיג נקודת דריסה ראשונית.

נתון שממחיש את קנה המידה: מיקרוסופט מדווחת שחשבונות עם MFA פעיל חוסמים למעלה מ-99.9% מהתקפות פריצה מבוססות זהות (identity-based attacks), אבל אותו דוח מציין ש-nרוב הפריצות שהתרחשו בכל זאת התרחשו בדיוק בחשבונות שהוגדרו כ”פטורים” מ-MFA — לרוב חשבונות שירות, חשבוני break-glass, או ממשקי legacy authentication (POP/IMAP/SMTP) שלא נתמכים ב-MFA מודרני ונשארו פתוחים “כדי לא לשבור אינטגרציה”.

תרחיש קונקרטי: איך MFA-Everywhere היה עוצר את Twitter Bitcoin Scam

ביולי 2020 השתלט תוקף על עשרות חשבונות טוויטר בעלי פרופיל גבוה (אלון מאסק, ביל גייטס, ברק אובמה ואחרים) לצורך הונאת ביטקוין שגרפה מעל 118,000 דולר בפחות משעה. הדרך פנימה הייתה vishing — שיחת טלפון לעובדי תמיכה שהתחזתה לצוות IT פנימי, ששכנעה אותם למסור פרטי כניסה לכלי ניהול פנימי (admin panel) שנתן שליטה מלאה על חשבונות משתמשים, כולל היכולת לעקוף אימות דו-שלבי של המשתמשים עצמם. הכלי הפנימי הזה — שהיה בעל ההרשאות הגבוהות ביותר בפלטפורמה — לא היה מוגן בעצמו ב-MFA מבוסס מכשיר פיזי (hardware token / FIDO2), רק בסיסמה ואולי קוד שניתן היה למסור בטלפון.

המקרה הזה הוא הדוגמה הטובה ביותר להבנת העיקרון: לא משנה כמה שכבות MFA יש למשתמשי הקצה, אם כלי הניהול שמפעיל את כל המערכת פתוח בלי שכבת הגנה חסינה להנדסה חברתית — כל הבניין קורס. זו הסיבה שגופי אבטחה כמו CISA ו-NIST ממליצים כיום באופן מפורש על MFA מבוסס FIDO2/WebAuthn (מפתחות פיזיים) בדיוק בממשקי הניהול הרגישים ביותר, ולא רק OTP או push notification שניתנים לעקיפה חברתית.

איפה בפועל צריך MFA — רשימת בדיקה מעשית

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

• VPN וגישה מרחוק — כולל חשבונות “ישנים” או לא פעילים שלא הוסרו.
• כלי ניהול פנימיים (admin panels) — בפרט כלים שניתן דרכם לאפס MFA של משתמשים אחרים.
• חשבונות שירות ו-API keys — לפחות rotation קבוע ו-scoping מוגבל, ואם אפשר — client certificates בנוסף לסוד.
• ממשקי legacy authentication — POP/IMAP/SMTP ישנים שמדלגים על מודל אימות מודרני.
• קונסולות ענן (AWS/Azure/GCP) — במיוחד חשבונות root/owner.
• חשבוני break-glass — כן, גם חשבון החירום שנועד “למקרה שה-MFA נופל” צריך שכבת הגנה משלו, לרוב מפתח פיזי שמאוחסן בכספת.

מ-Push ל-Phishing-Resistant: לאן זזה התעשייה

לאור התקפות MFA fatigue כמו זו שקרתה ב-Uber, ארגונים עוברים בהדרגה מ-push notifications פשוטים למנגנוני MFA עמידים בפני פישינג: מפתחות FIDO2/WebAuthn (כמו YubiKey), Windows Hello for Business, ו-number matching (שבו המשתמש צריך להקליד מספר שמוצג במסך ההתחברות ולא רק לאשר לחיצה). Microsoft ו-Google דיווחו שהמעבר ל-number matching הפחית משמעותית תקריות MFA bombing בארגונים שאימצו אותו. הכיוון הזה הוא לא “עוד שכבה” אלא שינוי איכותי: הוא מבטל את האפשרות שהמשתמש “יאשר בטעות” בלי לדעת בכלל למה.

סיכום: MFA הוא לא פרויקט חד-פעמי

הדוגמאות שהובאו כאן — Uber, Colonial Pipeline, Cisco, SolarWinds, Twitter — לא נבחרו כי הן חריגות, אלא כי הן מייצגות תבנית חוזרת: MFA שמכוסה חלקית שווה בערך לחומת מגן עם דלת פתוחה בצד. הצעד המעשי הראשון לכל צוות אבטחה הוא מיפוי מלא של כל נקודות הכניסה לזהות בארגון — לא רק אפליקציית הדוא”ל — ובדיקה כנה: איזה משטחים עדיין “פטורים” מ-MFA, ומדוע.

שאלות נפוצות

מה ההבדל בין MFA מבוסס push לבין MFA עמיד בפני פישינג (phishing-resistant)?

MFA מבוסס push שולח בקשת אישור למכשיר הנייד, אבל ניתן לעקוף אותו בהתקפות MFA fatigue (הצפת בקשות) או vishing. MFA עמיד בפישינג, כמו מפתחות FIDO2/WebAuthn, מבוסס על אימות קריפטוגרפי בין המכשיר לאתר עצמו, כך שאי אפשר “לשכנע” משתמש לאשר בקשה מזויפת — התהליך כלל לא מתרחש אם הדומיין לא תואם.

אם יש לנו כבר MFA על כל משתמשי הקצה, למה חשבונות שירות ו-API keys עדיין מסוכנים?

כי הם לרוב פועלים ללא אינטראקציה אנושית שוטפת, ולכן קשה להגן עליהם באמצעי MFA קלאסי. הפתרון הוא scoping הרשאות מצומצם, rotation תדיר של הסודות, ניטור אנומליות בשימוש, ולעיתים שימוש בתעודות דיגיטליות (mTLS) כתחליף שקול ל-MFA.

איך מתמודדים עם MFA fatigue / MFA bombing כמו שקרה ב-Uber?

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