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

מדוע SMS הוא שיטת MFA מיושנת (ומה אומר NIST בנושא)

בשנת 2016, NIST SP 800-63B (קווים מנחים לזהות דיגיטלית) המליץ רשמית להימנע משימוש ב-SMS כגורם אימות שני. הסיבה טכנית: הודעות טקסט עוברות ברשתות SS7, פרוטוקול טלפוניה משנות ה-70 שחסר הצפנה ורגיש להתקפות כמו החלפת SIM או יירוט במהלך המעבר. דו"ח של CISA משנת 2023 (MFA עמיד בפני דיוג) אישר כי 80% מההתקפות המוצלחות נגד MFA בשנה האחרונה ניצלו שיטות המבוססות על SMS או התראות push ללא אימות קריפטוגרפי.

באמריקה הלטינית, שם החלפת SIM היא וקטור תקיפה חוזר (מקרים מתועדים במקסיקו ובברזיל בשנת 2022, לפי OEA), הסתמכות על SMS שקולה להשארת הדלת פתוחה. עם זאת, חברות רבות ממשיכות להשתמש בו מתוך אינרציה: זוהי השיטה ש"כולם מכירים". המעבר לאלטרנטיבות בטוחות יותר דורש תוכנית המשלבת טכנולוגיה, תקשורת ותעדוף.

שיטות MFA: TOTP, FIDO2 ו-push עם אימות קריפטוגרפי (והפשרות שלהן)

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

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

הטמעה הדרגתית: מדוע להתחיל עם חשבונות בעלי הרשאות גבוהות (וכיצד לעשות זאת)

80% מאירועי האבטחה מתחילים עם פגיעה בחשבון בעל הרשאות גבוהות (דו"ח IBM Cost of a Data Breach 2023). לכן, הצעד הראשון אינו להפעיל MFA לכולם, אלא עבור:

  1. מנהלי מערכות (גישה לשרתים, מסדי נתונים, לוחות בקרה).
  2. מפתחים (גישה למאגרי קוד, סביבות staging/production).
  3. מנהלים (דואר אלקטרוני תאגידי, מסמכים רגישים).

גישה מוכחת היא כדלקמן:

  1. שבועות 1-2: פיילוט עם צוות ה-IT.
    • בחירת 5-10 משתמשים טכניים לבדיקת שיטת ה-MFA הנבחרת (למשל: FIDO2).
    • תיעוד בעיות (למשל: "ה-YubiKey אינה פועלת בלינוקס עם Firefox").
    • יצירת מדריך פנימי עם צילומי מסך וצעדים מפורטים.
  2. שבועות 3-4: הרחבה לחשבונות בעלי הרשאות גבוהות.
  3. שימוש בכלים כמו pam_u2f (לינוקס) או Windows Hello for Business לשילוב FIDO2 בהתחברות למערכת ההפעלה.
  4. עבור שירותי ענן (AWS, Azure), הפעלת MFA מותנה: הגורם השני יידרש רק אם הגישה מגיעה מכתובת IP לא מוכרת.
  5. שבועות 5-8: שאר הארגון.
  6. עבור צוותים לא טכניים, שימוש ב-TOTP או push (פחות חיכוך).
  7. הדרה זמנית של משתמשים עם תפקידים תפעוליים קריטיים (למשל: תמיכה טכנית המטפלת בשיחות 24/7) עד לפתרון מקרי קצה.

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

כלי MFA: Authelia, Keycloak ו-Authentik מול Okta/Duo (ומתי לבחור כל אחד)

השוק מציע פתרונות MFA לכל התקציבים והצרכים. להלן ניתוח השוואתי:

כלי סוג שיטות נתמכות יתרונות מגבלות עלות (עסקים קטנים ובינוניים באמריקה הלטינית)
Authelia קוד פתוח TOTP, WebAuthn, push (עם שילוב) אירוח עצמי, קל משקל, אידיאלי לסביבות עם תשתית עצמית. שילוב עם Traefik/Nginx. דורש הגדרה טכנית. אין תמיכה רשמית במפתחות חומרה מתקדמים (למשל: YubiKey עם PIV). חינם (רק עלות תשתית).
Keycloak קוד פתוח TOTP, WebAuthn, push, SMS (לא מומלץ) תומך ב-OIDC/OAuth2, ניתן להרחבה, תיעוד טוב. בשימוש חברות כמו Red Hat. עקומת למידה תלולה. ממשק הניהול מורכב עבור מי שאינו טכני. חינם (גרסה קהילתית).
Authentik קוד פתוח TOTP, WebAuthn, push, Duo, SMS ממשק מודרני, זרימת רישום הניתנת להתאמה אישית, שילוב טוב עם LDAP/Active Directory. קהילה קטנה יותר מ-Keycloak. חלק מהתכונות המתקדמות דורשות את הגרסה הארגונית. חינם (גרסה קהילתית).
Okta SaaS TOTP, WebAuthn, push, SMS, ביומטריה חוויית משתמש מלוטשת, שילוב עם מאות אפליקציות. תמיכה 24/7. עלות גבוהה עבור עסקים קטנים ובינוניים (מ-3 דולר למשתמש לחודש). תלות בספק. מ-3 דולר למשתמש לחודש.
Duo Security SaaS push, TOTP, WebAuthn, SMS, שיחת טלפון קל ליישום, שילוב טוב עם Cisco. Universal Prompt מפחית חיכוך. תלות בספק חיצוני. מחיר למשתמש עלול לעלות במהירות. מ-3 דולר למשתמש לחודש.

המלצות לפי תרחיש:

כיצד להתמודד עם התנגדות לשינוי (ולמנוע מהצוות "לפרוץ" את ה-MFA)

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

האסטרטגיות להתמודדות איתן:

  1. התמקדות ב"למה":
    • הצגת מקרים אמיתיים של התקפות באזור (למשל: הפריצה להסופרינטנדנסיה לתעשייה ומסחר של קולומביה בשנת 2021, שהתחילה עם מייל דיוג לפקיד ללא MFA).
    • הסבר כי MFA אינו גחמה של ה-IT, אלא דרישת ביטוחים סייבריים (יותר ויותר מבטחים דורשים MFA לכיסוי אירועים).
  2. הפחתת החיכוך:
    • עבור צוותים מרוחקים, שימוש בשיטות שאינן דורשות חומרה (למשל: TOTP עם Authy, המאפשרת גיבוי קודים בענן).
    • יישום MFA מותנה: הגורם השני יידרש רק אם הגישה מגיעה מכתובת IP לא מוכרת או ממכשיר חדש.
    • אפשרות "זכור מכשיר" למשך 30 יום למשתמשים מהימנים.
  3. ציפייה לכשלים:
    • יצירת תהליך ברור לשחזור גישה (למשל: קוד גיבוי מודפס המאוחסן במעטפה חתומה במשאבי אנוש).
    • עבור מפתחות חומרה, רכישת 10% נוספים כגיבוי ואחסונם במקום בטוח.
    • מינוי "משתמשי-על" שיכולים לפתוח חשבונות במצבי חירום (עם ביקורת חובה).
  4. גיימיפיקציה של האימוץ:
    • יצירת "לוח מנהיגים" עם הצוותים המשתמשים ביותר ב-MFA (ללא חשיפת נתונים רגישים).
    • הצעת פרס סמלי (למשל: יום חופש) לצוות שיסיים את המעבר ראשון.

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

מה לעשות כאשר ה-MFA נכשל: תוכניות מגירה ושחזור

אף מערכת אינה חסינה. גם עם MFA, עלולים להתרחש כשלים:

תוכנית מגירה צריכה לכלול:

  1. קודי גיבוי:
    • יצירת 10 קודים חד-פעמיים למשתמש ואחסונם במקום בטוח (למשל: מנהל סיסמאות כמו Bitwarden או במעטפה פיזית).
    • רוטציה של הקודים כל 6 חודשים.
  2. שיטה חלופית זמנית:
    • לאפשר למשתמשים להגדיר שיטת MFA שנייה (למשל: TOTP + push) לשימוש כגיבוי.
    • עבור מפתחות חומרה, רישום שני מפתחות למשתמש (ראשי וגיבוי).
  3. תהליך שחזור:
    • הגדרת זרימה ברורה לשחזור גישה (למשל: אימות זהות עם מנהל + קוד גיבוי).
    • תיעוד התהליך ב-runbook נגיש לצוות ה-IT.
  4. ניטור התקפות:
    • התראה על ניסיונות MFA כושלים (למשל: יותר מ-3 תוך 5 דקות).
    • חסימה זמנית של חשבונות עם דפוסים חשודים (למשל: מספר התראות push שנדחו ולאחריהן אושרה אחת).

דוגמה קונקרטית: בשנת 2022, לקוח של CyberShield בארגנטינה סבל מהתקפת עייפות MFA נגד המנכ"ל. התוקף שלח 50 התראות push תוך שעה עד שהמנהל, עייף, אישר אחת. הפתרון היה הטמעת מגבלה של 3 התראות לשעה ודרישת קוד TOTP נוסף לגישות מכתובות IP לא מוכרות. ההתקפה נעצרה מבלי להשפיע על הפרודוקטיביות.

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

בסביבה שבה 61% מפרצות הנתונים כוללות אישורים שנפרצו (דו"ח Verizon DBIR 2023), MFA אינו אופציה, אלא הכרח. השאלה אינה אם ליישם אותו, אלא כיצד לעשות זאת מבלי לשתק את הצוות – והתשובה טמונה בשילוב של טכנולוגיה מתאימה, תעדוף חכם וניהול שינוי. הכלים קיימים; האתגר הוא להשתמש בהם בתבונה.

מקורות

  1. NIST Special Publication 800-63B (2017). Digital Identity Guidelines: Authentication and Lifecycle Management. URL: https://pages.nist.gov/800-63-3/sp800-63b.html.
  2. CISA (2023). Implementing Phishing-Resistant MFA. URL: https://www.cisa.gov/resources-tools/services/phishing-resistant-mfa.
  3. IBM Security (2023). Cost of a Data Breach Report 2023. URL: https://www.ibm.com/reports/data-breach.
  4. Verizon (2023). 2023 Data Breach Investigations Report. URL: https://www.verizon.com/business/resources/reports/dbir.
  5. OEA-CICTE (2022). Informe de Ciberseguridad en América Latina y el Caribe. URL: https://www.oas.org/es/sms/cicte/docs/Informe-Ciberseguridad-2022.pdf.
  6. Authelia Documentation (2024). Multi-Factor Authentication. URL: https://www.authelia.com/docs/configuration/authentication/.
  7. Keycloak Documentation (2024). Two-Factor Authentication. URL: https://www.keycloak.org/docs/latest/server_admin/#_two_factor.
  8. מקרה ציבורי: הסופרינטנדנסיה לתעשייה ומסחר של קולומביה (2021). הודעה על אירוע אבטחה. URL: https://www.sic.gov.co/noticias/sic-informa-sobre-incidente-de-seguridad-informatica.