למה MFA לא מופעל כשהוא אמור להיות פעיל בסביבות Microsoft

By Mirko Peters · 2026-04-22

אימות מרובה גורמים (MFA) אמור לשמש רשת ביטחון שלכם ב-Microsoft 365 וב-Azure, ולעצור תוקפים גם אם הם גונבים סיסמה. אבל מה קורה כאשר הרשת הזו פשוט לא קיימת, גם במקום שבו היא אמורה להיות…

Automatically translated with AI from the original post. Read the English original

אימות מרובה גורמים (MFA) אמור לשמש רשת ביטחון שלכם ב-Microsoft 365 וב-Azure, ולעצור תוקפים גם אם הם גונבים סיסמה. אבל מה קורה כאשר הרשת הזו פשוט לא קיימת, גם במקום שבו היא אמורה להיות? “אמורה” מתייחס לאותם רגעים קריטיים: כניסות מסוכנות, התחברות של חשבונות מנהל, או גישה ממיקומים חריגים מהרגיל. אם MFA לא מופעל בהם, יש לכם חשיפה, פשוט וברור.

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

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

הבנת המקומות שבהם MFA לא מופעל, והסיבות לכך

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

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

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

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

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

מימוש שיטות MFA עמידות לפישינג לאימות מאובטח

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

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

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

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

יישום MFA ללא עלות לעסקים קטנים באמצעות Microsoft Entra ID

אם אתם מנהלים עסק קטן, אתם לא צריכים תקציב גדול או רישיונות מיוחדים כדי להטמיע MFA חזק. ל-Microsoft Entra ID (לשעבר Azure AD) יש ברירות מחדל לאבטחה, שכל עסק יכול להפעיל בכמה לחיצות בלבד.

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

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

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

MFA לעסקים: שיטות עבודה מומלצות לאכיפת מדיניות ולהפחתת סיכונים

1. החילו MFA על כל המשתמשים, בלי יוצאים מן הכלל לטובת נוחות. ודאו שכל חשבונות המשתמשים (לא רק מנהלים) מכוסים במדיניות MFA, כולל חשבונות של עובדים זמניים, ספקים והנהלה בכירה. החרגות צריכות להיות נדירות, תמיד מוגבלות בזמן, ומבוססות על הצדקה עסקית חזקה.
2. אבטחו חשבונות שירות וחשבונות שאינם אנושיים באמצעות פתרונות מודרניים. חשבונות שירות מסורתיים יכולים להיות פערי MFA משמעותיים. שדרגו אותם באמצעות כלים כמו Entra Workload Identities לאימות מנוהל, עם ניהול מחזור חיים ויכולת ביקורת. לפירוט נוסף על הגישה הזו, ראו הסבר מפורט על סיכוני חשבונות שאינם אנושיים.
3. הטמיעו משתמשים עם הכשרה ותמיכה מתאימות. עזרו למשתמשים להגדיר אפליקציות מאמתות או אסימונים פיזיים, והסבירו למה MFA חשוב. ספקו תמיכת מוקד במהלך ההטמעה, ובמיוחד למשתמשים שאינם מכירים בקשות MFA חדשות, כמו התאמת מספרים.
4. נטרו ניסיונות לעקוף MFA וכניסות חריגות. הגדירו התראות ויומנים שיזהו מצבים שבהם MFA חסר בתרחישים בסיכון גבוה הצפויים, או מקרים שבהם פרוטוקולים מדור קודם חומקים דרך. אוטומטו את תגובת האירועים ככל האפשר, למשל איפוס סיסמאות או הפעלת אימות נוסף בכניסות מסוכנות.
5. בצעו ביקורת קבועה על כיסוי MFA ועל התאמה למדיניות. אל תניחו שהכיסוי "מוגדר ונעול". השתמשו בלוחות בקרה ובדוחות זהות ב-Microsoft 365, וגם בפלטפורמות אחרות אם אתם פועלים במספר ענני מחשוב. תרגמו את הממצאים לדוחות ברורים, כדי ש-IT והנהלה יוכלו לראות איפה הסיכון נותר. ממשל יעיל חורג מעבר ללחצנים ולמתגים. להבנה מעמיקה יותר, כדאי לעיין בלקחים מכשלים בממשל של M365.

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