תרחישי עקיפה של Conditional Access: הבנה ומניעה של איומי זהות מודרניים

By Mirko Peters · 2026-04-26

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

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

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

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

מבוא לסיכוני עקיפה של Conditional Access ולנוף האיומים

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

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

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

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

כיצד תוקפים משיגים אישורי גישה ומנצלים פעילות דפדפן זדונית

1. Phishing והנדסה חברתית: תוקפים מתחילים לעיתים קרובות בהודעות דוא"ל דיוגים או בדפי כניסה מזויפים כדי לגנוב את אישורי הגישה של המשתמש. בין אם מדובר בהודעה מתוחכמת ובין אם בקישור גנרי כמו "אפס את הסיסמה שלך", דיוג הוא עדיין הדרך הקלה ביותר פנימה.
2. ניחוש סיסמאות בהתזה והתקפות כוח גס: לפעמים הרעים פשוט מפזרים סיסמאות נפוצות על פני חשבונות רבים, בתקווה למצוא חוליה חלשה. שיטה זו בודקת מספר רב של חשבונות עם מעט ניסיונות לכל אחד, כדי להימנע מנעילות ולהישאר מתחת לרדאר.
3. חטיפת הפעלה באמצעות דפדפנים זדוניים: תוקפים מתקדמים מדביקים את דפדפן המשתמש בתוספים או בתוכנות זדוניות. לאחר שהשתילו את ה-hooks שלהם, הם עוקבים אחר הפעלות אימות וגונבים אסימוני אבטחה ישירות מהדפדפן. כך הם יכולים לעקוף MFA ו-Conditional Access, ולהיראות למערכת העורפית של Microsoft בדיוק כמו המשתמש הלגיטימי.
4. גניבת אסימונים ו-Consent Phishing: במקום סיסמאות מסורתיות, חלק מהקמפיינים משתמשים ב-OAuth consent phishing כדי לגרום למשתמש לאשר אפליקציה זדונית. אפליקציות אלה אוספות אסימוני הרשאה, שלעיתים קרובות חומקים מעל Conditional Access ו-MFA, ומעניקים לתוקפים גישה מתמשכת בלי שיצטרכו את הסיסמה שלכם כלל.
5. ניצול יחסי אמון: ניצול גישת אורחים, שיתוף פעולה B2B או הגדרות פדרציה זהות מדור קודם מעניקים לתוקפים לגיטימיות מיידית. אם המדיניות שלכם אינה מכסה משתמשי אורח בצורה יסודית, התוקפים יכולים לרכב על הנחות האמון האלה ולעבור ישירות על שער הגישה שלכם.
6. הדלפת פרטי התחברות (Credential Stuffing) ממאגרי מידע שדלפו: תוקפים לוקחים שמות משתמש וסיסמאות ממאגרי פרצות ישנים ומנסים אותם בכניסות לשירותי הענן של Microsoft, מתוך הנחה שהסיסמאות חוזרות על עצמן. אם מוסיפים לכך ארכיטקטורה של גישה מותנית שאינה מתוחזקת כראוי, השיטה הופכת מסוכנת מהר מאוד.

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

תצורות שגויות נפוצות שמאפשרות עקיפה של גישה מותנית

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

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

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

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

תצורות שגויות של MFA וסיכוני עקיפה לפי היקף

1. חריגים רחבים מדי במדיניות: חשבונות, קבוצות או אפליקציות שהוחרגו מאכיפת MFA יוצרים פערים שקטים. תוקפים יודעים לכוון לחריגים האלה, שלעיתים קרובות נשארים ללא זיהוי במהלך ביקורות.
2. אכיפת MFA לא אחידה: מדיניות שמוגבלת לאפליקציות, פלטפורמות או מיקומי כניסה מסוימים מפספסת משתמשים שפועלים מחוץ לגבולות האלה. תוקפים מנצלים הגדרות נוקשות אלה כדי לקבל גישה מבלי להפעיל בקשת MFA.
3. אימות מדור קודם שנשאר פעיל: פרוטוקולים ישנים (כמו IMAP, POP או SMTP) יכולים לעקוף גישה מותנית מודרנית, ולאפשר לתוקפים להתחבר עם סיסמה בלבד. נקודות קצה אלו הן מוקד למתקפות כוח גס.
4. חשבונות עקיפה זמניים או לחירום: חשבונות מנהל של "break glass" או חריגים זמניים נשכחים לעיתים קרובות לאחר שהמשבר חלף. החשבונות האלה הופכים ליעדים בעלי ערך גבוה עד שנעולים מחדש כראוי.

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

פגיעויות בתאימות ורישום מכשירים בתרחישי עקיפה

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

טכניקות עקיפה של מדיניות גישה מותנית – מתועדות ונמצאות בשטח

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

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

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

עקיפה באמצעות החרגת משאבים ושיטות ציבוריות ידועות

1. החרגות של נקודות קצה של אימות מדור קודם: השארת נקודות קצה כמו POP3, IMAP או SMTP AUTH מחוץ למדיניות הגישה המותנית מציעה לתוקפים מטרות קלות. שירותים ישנים אלה מתעלמים לעיתים מ-MFA, ומאפשרים לתוקפים לנסות סיסמאות בכוח גס מבלי להפעיל את ההגנות המודרניות.
2. החרגות של Graph API ושל אפליקציות: מדיניות גישה מותנית מכוונת לעיתים קרובות לאפליקציות המשתמש המרכזיות, אך לעיתים API קריטיים בצד השרת (כמו Graph API) נשארים מוחרגים בשוגג. תוקפים מנצלים פערים אלה כדי לאסוף נתונים או להעלות הרשאות. ניתן לקרוא עוד על התקפות API מבוססות הסכמה כאן.
3. חשבונות שירות שאינם אינטראקטיביים: חשבונות מערכת או אוטומציה עם החרגות גורפות ממדיניות הגישה המותנית יוצרים נקודות כניסה סמויות, ולעיתים עוקפים לחלוטין את MFA ואת בדיקות ההתקן.

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

ניצול לרעה של תהליכי אימות והשגת קודי הרשאה

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

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

עקיפה מתקדמת של גישה מותנית: הרחבות דפדפן וסיכוני סביבות היברידיות

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

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

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

הרחבות דפדפן זדוניות וביצוע גישה חלקה

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

טכניקות עקיפה בהטמעות היברידיות וב-Global Secure Access

1. ניצול גשר ADFS: פדרציה מדור קודם, כמו ADFS, לעיתים אינה אוכפת עדכוני מדיניות בענן. תוקפים שעוברים דרך הגשר עלולים להימנע ממדיניות גישה מותנית שניתנת לאכיפה, במיוחד אם כללי הטוקנים אינם מסונכרנים בהדוק.
2. שרשור אמון B2B ובין דיירים: משתמשים חיצוניים או שותפים שהוזמנו דרך Azure AD B2B עשויים לעקוף מדיניות מחמירה יותר, אם חשבונות האורחים או החשבונות המאוחדים אינם כפופים לאותו סטנדרט. תוקפים מנצלים את הקשרים "המהימנים" האלה לתנועה רוחבית.
3. עקיפה באמצעות מכשירים לא מנוהלים: בסביבות היברידיות, פערים ברישום מכשירים, סחיפה בתאימות Intune או הנחות של "מהימנות" למערכת ההפעלה יכולים לפתוח דרך למכשירי קצה לא מנוהלים שחומקים פנימה.
4. בעיות אמון במכשירים בין פלטפורמות: מדיניות שבודקת רק תאימות ל-Windows עלולה בטעות לאשר גישה ממכשירי macOS, ממכשירים ניידים או מסביבות מעורבות, שלכל אחת מהן מאפיינים וחולשות משלה. להעמקה בהשגת הגנה מאוחדת מבוססת אפס אמון, ראו this Zero Trust by Design resource.

זיהוי, הפחתה ותיקון לאסטרטגיות עקיפה

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

זיהוי אפקטיבי נשען על שילוב של ניתוח אבטחה, רישום מפורט והבנה ברורה של האופן שבו התעבורה אמורה להיראות בארגון. שילוב כלי SIEM, שימוש בתכונות המקוריות של Microsoft 365 והתאמה למסגרות כמו MITRE ATT&CK יכולים לעזור לזהות טקטיקות חדשות ומשתנות לפני שהן גורמות נזק.

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

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

הפחתה, חיזוק מדיניות והגנה על מידע רגיש

1. ביקורות מדיניות קבועות: תזמנו סקירות תכופות של היקפי מדיניות הגישה המותנית ושל ההחרגות. זהו כללים מדור קודם והיקפים רחבים מדי שהצטברו עם הזמן.
2. אכיפת MFA עקבי: אל תסתפקו בהטמעה חלקית. החילו אימות רב-שלבי בכל מקום שבו הוא נתמך, במיוחד עבור חשבונות מנהל ואינטגרציות של צד שלישי.
3. צמצום וניטור של חריגים: כל חריג, בין אם הוא למשתמש, לאפליקציה או למכשיר, צריך להיות מצומצם, מוגבל בזמן ומנוטר באופן פעיל לזיהוי שימוש לרעה או סטייה. ”מגדירים ושוכחים” לא עובד כאן.
4. מתן עדיפות לתאימות מכשירים: אפשרו גישה רק למכשירים שעומדים בתקני התאימות העדכניים. השתמשו בכלי תאימות אוטומטיים כדי לשמור על מצב התאימות מעודכן, ואל תסתמכו רק על הרישום הראשוני.
5. מדיניות מניעת אובדן מידע (DLP): בנו שכבות על בקרות הגישה שלכם באמצעות אסטרטגיות DLP מנוהלות היטב, כדי להגביל חשיפה של מידע רגיש, במיוחד בסביבות ברירת מחדל או שיתופיות.
6. איזון בין אבטחה לשימושיות: הימנעו מקצוות. שאפו להרשאות ”מינימום הנדרש” (least privilege) יציבות ולהטמעה הדרגתית ומותאמת של מדיניות. לייעוץ תכנוני מעשי ראו את הדיון הזה על חופש משתמש מול Zero Trust.

איתור איומים וזיהוי באמצעות Graph API וכיסוי MITRE Att&ck

• שימוש ביומני Microsoft Graph API: השתמשו ב-Graph API כדי לשלוף יומני אימות, הסכמה והערכת מדיניות, לצורך ניתוח יזום ולזיהוי אירועים חריגים או אירועים שעקפו את הבקרות.
• שילוב עם SIEM (Microsoft Sentinel, Splunk וכדומה): נתבו יומני זהות, אימות וגישה מותנית ל-SIEM לצורך קורלציה, התראות ובדיקה פורנזית.
• מיפוי לטקטיקות MITRE ATT&CK: יישרו את כללי הזיהוי ושאילתות הניטור שלכם למסגרת של MITRE, תוך כיסוי טכניקות כמו גישה ראשונית, גניבת טוקנים ותנועה רוחבית (lateral movement), כדי לקבל תוכנית תגובה מובנית.
• ביקורת על פעילות משתמשים באמצעות Purview: Microsoft Purview Audit מספק מעקב אחר משתמשים ברחבי הדייר. שדרגו לשכבות פרימיום לשמירה ארוכה יותר ולאותות עשירים יותר, אם אתם מטפלים במידע מוסדר או במידע בסיכון גבוה.

מחקר נוסף, חומרי קריאה וטבלת שיטות עקיפה מתועדות

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

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

• ניצול הסכמת OAuth: תוקפים משיגים התמדה באמצעות הרשאת אפליקציה זדונית. (קראו איך זה עובד)
• פערים באימות מדור קודם: החרגת IMAP/POP מובילה לעקיפת MFA ולסיכון של התקפות ריסוס סיסמאות (password spray).
• ניצול אמון בין דיירים (B2B/Cross-Tenant): חוסר יישור במדיניות משתמשי אורח פותח סיכוני תנועה רוחבית חדשים.
• השמעה חוזרת של טוקנים ב-ADFS/היברידי: ions מקומיים או הגדרות שגויות של סנכרון לענן עלולים ליצור סטיית אכיפה.

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

סיכום ועיקרי הדברים האסטרטגיים להגנה מפני עקיפה של Conditional Access

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

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

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