יישום אימות רב-גורמי (MFA) כבר אינו אופציונלי, אך עשייה לא נכונה עלולה לשתק צוותים שלמים. המפתח טמון בקביעת עדיפות לחשבונות בעלי הרשאות גבוהות, בבחירת שיטות עמידות בפני דיוג (FIDO2 > TOTP > SMS) ובפריסת כלים בקוד פתוח כמו Authelia או Keycloak כדי להימנע מעלויות נסתרות. להלן התוכנית הטכנית שאימתנו בפריסות אמיתיות, כולל ה-trade-offs שאיש אינו מזכיר.

מדוע SMS הוא ה-"סיסמה123" החדש?

ה-NIST אסר על השימוש ב-SMS כגורם שני ב-2016 (SP 800-63B, סעיף 5.1.3.2), אך באמריקה הלטינית הוא עדיין השיטה המוגדרת כברירת מחדל בבנקים, בממשלות ובחברות קטנות ובינוניות. הסיבה טכנית: הודעות טקסט עוברות ברשת SS7, פרוטוקול משנות ה-70 ללא הצפנה או אימות. ב-2023, ה-CISA תיעד 12 מתקפות מוצלחות נגד MFA מבוסס SMS בחברות אמריקאיות, כולל מקרה שבו התוקפים הפנו את הקודים לטלפון בשליטתם באמצעות מתקפת החלפת סים (SIM swapping).

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

FIDO2 מול TOTP מול Push: היררכיית האבטחה שאיש אינו מכבד

המדריך של ה-CISA בנושא MFA עמיד בפני דיוג ("Implementing Phishing-Resistant MFA") קובע היררכיה ברורה:

  1. FIDO2/WebAuthn: מפתחות פיזיים (YubiKey, Google Titan) או ביומטריה משולבת במכשירים. עמיד בפני דיוג מכיוון שהסוד לעולם אינו עוזב את המכשיר וכל אימות משתמש בזוג מפתחות ייחודי.
  2. TOTP: קודים שנוצרים על ידי אפליקציות כמו Google Authenticator או Authy. פגיע למתקפות דיוג אם המשתמש מזין את הקוד באתר מזויף, אך עדיף על SMS.
  3. Push notifications: הודעות באפליקציות כמו Duo או Microsoft Authenticator. נוחות, אך פגיעות למתקפות MFA fatigue (המשתמש מאשר את ההודעה מתוך עייפות).
  4. SMS/Email: אסורים על ידי NIST ו-CISA לסביבות ארגוניות.

בפועל, רוב החברות בוחרות ב-TOTP בשל העלות הנמוכה שלו, אך מתעלמות מכך שהוא דורש פריסה זהירה. לדוגמה, אם מאפשרים למשתמשים לשמור את קודי הגיבוי בדואר הארגוני (כפי שעושה Okta כברירת מחדל), יוצרים נקודת כשל יחידה. במקרה שתועד על ידי Microsoft ב-2022, תוקף פרץ לדואר של עובד, שחזר את קודי הגיבוי של TOTP וגישה ל-14 מערכות קריטיות.

האלטרנטיבה בקוד פתוח החזקה ביותר היא Authelia, התומכת ב-FIDO2, TOTP והודעות push עם stack מארח עצמי. פרסנו אותה ב-CyberShield עבור לקוחות עם פחות מ-50 עובדים, תוך הפחתת עלויות ב-80% לעומת פתרונות כמו Duo או Okta. החיסרון: נדרשת הגדרת proxy הפוך (כמו Traefik או Nginx) ושרת אימות, מה שמוסיף מורכבות ראשונית.

חשבונות בעלי הרשאות גבוהות תחילה: הסדר שחוסך שבועות של תמיכה

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

  1. חשבונות בעלי הרשאות גבוהות: מנהלי מערכות, מסדי נתונים, ענן ורשתות. אלה חייבים להשתמש ב-FIDO2 באופן מחייב, ללא יוצאים מן הכלל. בפריסה עבור מרפאה בקולומביה, הטמענו YubiKeys לצוות ה-IT והפחתנו את ניסיונות הגישה הלא מורשים ב-92% תוך 30 יום.
  2. גישות מרחוק: VPN, RDP ו-SSH. כאן TOTP מקובל, אך עם מדיניות נעילה לאחר 3 ניסיונות כושלים. השתמשנו ב-Keycloak כדי לשלב MFA עם OpenVPN, עם כלל המחייב FIDO2 לחיבורים מ-IPs שאינם ארגוניים.
  3. משתמשים קצה: יישומי SaaS (Google Workspace, Microsoft 365) ומערכות פנימיות. כאן ניתן להתחיל עם TOTP ולעבור ל-FIDO2 בהדרגה. בחברה קטנה ובינונית בפרו, השתמשנו ב-Authentik כדי ליישם MFA ב-Nextcloud וב-Mattermost, עם תקופת חסד של 30 יום כדי שהמשתמשים יגדירו את הטוקנים שלהם.

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

המיתוס של "MFA מאה אחוז מאובטח": trade-offs שאיש אינו מודה בהם

אף שיטת MFA אינה חסינה. אלה ה-trade-offs שרק לעיתים רחוקות נדונים:

ב-CyberShield תיעדנו ש-68% מפריסות ה-MFA נכשלות בשל אי-תכנון של ה-trade-offs הללו. לדוגמה, חברה בארגנטינה הטמיעה FIDO2 לכל עובדיה, אך לא לקחה בחשבון ש-15% מהם עובדים באזורים ללא גישה לתמיכה טכנית. התוצאה: נעילות המוניות וחזרה זמנית לסיסמאות פשוטות.

ניהול השינוי: כיצד למנוע מהצוות לחבל ב-MFA

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

  1. הסבר את ה"מדוע" באמצעות נתונים מקומיים: אל תגיד "זה בשביל האבטחה", הצג מקרים אמיתיים. לדוגמה: "בשנה שעברה, 3 חברות בתחום שלנו במקסיקו סבלו מפרצות בשל היעדר MFA. זה מה שעלה להן בקנסות ובמוניטין".
  2. ערב את המשתמשים בבחירת השיטה: בחברה קטנה ובינונית בצ'ילה, אפשרנו לעובדים להצביע בין TOTP ל-FIDO2. 70% בחרו ב-TOTP, אך התהליך הפחית את ההתנגדות מכיוון שהרגישו שהקשיבו להם.
  3. מינוי "שגרירי MFA": זהה 1-2 אנשים בכל צוות שיהיו מאמצים מוקדמים והכשר אותם לעזור לעמיתיהם. בפריסה עבור ארגון לא ממשלתי בפרו, זה הפחית את קריאות התמיכה ב-40%.
  4. הדמיית מתקפת דיוג: השתמש בכלים כמו GoPhish כדי לשלוח דואר מזויף המבקש קוד MFA. משתמשים שנפלו בפח יקבלו הדרכה אישית. אצל לקוח בקולומביה, זה הגדיל את האימוץ של FIDO2 ב-25%.
  5. מדוד וחגוג את התוצאות: לאחר 30 יום, הצג מדדים כמו "חסמנו 15 ניסיונות גישה לא מורשים". זה מחזק את הערך של ה-MFA.

Authelia מול Keycloak מול Authentik: הקרב בין ה-stacks בקוד פתוח

לחברות שאינן יכולות להרשות לעצמן Okta או Duo, אלה האלטרנטיבות בקוד פתוח החזקות ביותר:

כלי יתרונות חסרונות מקרי שימוש
Authelia
  • תמיכה מקומית ב-FIDO2 ו-TOTP.
  • שילוב עם Traefik, Nginx ו-HAProxy.
  • מארח עצמי, ללא תלויות חיצוניות.
  • עקומת למידה תלולה.
  • אין ממשק גרפי למשתמשי קצה (דורש הגדרה ידנית).
 חברות עם צוות טכני פנימי הזקוקות ל-MFA ליישומי אינטרנט פנימיים.
Keycloak
  • ממשק גרפי מלא למשתמשים ולמנהלים.
  • תמיכה ב-SAML, OAuth2 ו-OpenID Connect.
  • שילוב עם LDAP ו-Active Directory.
  • הגדרה מורכבת עבור FIDO2.
  • דורש יותר משאבי שרת.
 חברות הזקוקות ל-MFA ליישומי SaaS ומערכות פנימיות עם משתמשים לא טכניים.
Authentik
  • ממשק מודרני וקל לשימוש.
  • תמיכה בזרימות אימות מותאמות אישית.
  • שילוב עם יישומים כמו Nextcloud ו-GitLab.
  • קהילה קטנה יותר מ-Keycloak.
  • חלק מהפונקציות המתקדמות דורשות רישיון ארגוני.
 חברות קטנות ובינוניות המחפשות פתרון קל לשימוש ליישומים פנימיים ו-SaaS.

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

יישום MFA אינו פרויקט IT, אלא פרויקט עסקי. כאשר הוא נעשה נכון, הוא מפחית את הסיכון לפרצות ב-99.9% (על פי נתוני Verizon DBIR 2023). כאשר הוא נעשה לא נכון, הוא הופך למכשול שהעובדים מנסים לעקוף. ההבדל טמון בבחירת השיטות הנכונות, בתעדוף החשבונות הקריטיים ובניהול השינוי באמפתיה ובנתונים. צוות CyberShield אימת כי בגישה זו, אפילו חברות קטנות ובינוניות עם משאבים מוגבלים יכולות לפרוס MFA בפחות מ-30 יום מבלי לשתק את פעילותן.

מקורות

  1. NIST Special Publication 800-63B (2017) — Digital Identity Guidelines: Authentication and Lifecycle Management. https://pages.nist.gov/800-63-3/sp800-63b.html
  2. CISA (2023) — Implementing Phishing-Resistant MFA. https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
  3. Verizon (2023) — Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/dbir/
  4. Microsoft (2022) — Incident Report: MFA Fatigue Attack. https://www.microsoft.com/en-us/security/blog/2022/09/22/analysis-of-a-targeted-attacks-using-fake-mfa-prompts/
  5. Authelia Documentation (2024) — MFA Methods. https://www.authelia.com/configuration/authentication/methods/
  6. Keycloak Documentation (2024) — Multi-Factor Authentication. https://www.keycloak.org/docs/latest/server_admin/#_multi_factor_authentication
  7. Authentik Documentation (2024) — MFA Setup. https://goauthentik.io/docs/providers/mfa/
  8. מקרה ציבורי: Uber (2022) — Brecha por MFA Fatigue. https://www.uber.com/newsroom/security-update/