הגדרת הגנה על זהויות ו-MFA ב-Azure AD

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

בעזרת תצורה נכונה, ניתן לשלב MFA, גישה מותנית, הגנה על זהויות ושיטות אימות מודרניות (כולל אסימוני OATH ומפתחות FIDO2; ראה מבוא לקריפטוגרפיה ) כדי להשיג איזון בין אבטחה חזקה לחוויית משתמש סבירה . לאורך מאמר זה, נפרט את כל האפשרויות המרכזיות בפירוט רב: התראות על פעילות חשודה, שימוש באסימוני OATH, תצורת שיחות טלפון, כתובות IP מהימנות, שיטות אימות, מדיניות גישה מותנית, תרחישים היברידיים עם Active Directory ויכולות אימות אדפטיביות מבוססות סיכון.

אימות רב-גורמי הוא תהליך שבו, במהלך התחברות, המשתמש מתבקש להזין גורם אימות נוסף אחד או יותר מלבד הסיסמה שלו. זה יכול להיות קוד שנשלח למכשיר נייד, הודעת דחיפה ב-Microsoft Authenticator, אסימון חומרה של OATH, מפתח FIDO2, או אפילו נתונים ביומטריים כגון טביעת אצבע (דרך Windows Hello for Business).

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

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

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

הודעה על פעילות חשודה ומשתמשים בסיכון גבוה

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

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

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

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

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

ניהול סיכונים עם רישיונות מיקרוסופט. הזן מזהה P1

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

אמצעי הפחתה בתרחיש זה הם בדרך כלל ידניים או חצי אוטומטיים: צוות ה-IT או שירות התמיכה יכולים לדרוש ממשתמשים לבצע איפוס סיסמה באמצעות SSPR (איפוס סיסמה בשירות עצמי) או לשנות את הסיסמה בשמם. ניתן גם להפוך זרימות עבודה לאוטומטיות באמצעות Microsoft Graph או PowerShell כדי לאלץ שינויי סיסמה, לבטל הפעלות פעילות או אפילו להשבית זמנית את החשבון בזמן שהבעיה נבדקת.

בסביבות ללא P2, ניתן גם למנף אירועי סיכון באמצעות ממשקי API של Graph כדי לבנות זרימות עבודה משלכם לתגובה , לשלב אותן עם מערכות כרטוס או פתרונות SIEM/SOAR, וכך להשיג תזמור מקצועי יותר של אירועי זהות.

תיקון סיכונים אוטומטי עם Microsoft Enter ID P2

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

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

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

אסימוני OATH וקודי TOTP ב-Azure AD

בנוסף לאפליקציית Microsoft Authenticator הקלאסית, Entra ID תומך באסימוני חומרה של OATH TOTP המייצרים קודים חד-פעמיים (OTP) מבוססי זמן, בדרך כלל כל 30 או 60 שניות, באמצעות SHA-1. אפשרות זו מתאימה היטב לארגונים המעדיפים מכשירים פיזיים ייעודיים עבור MFA עקב מדיניות פנימית, מגזרים מוסדרים או משתמשים ללא טלפון חכם ארגוני.

אסימונים אלה מגיעים בדרך כלל עם מפתח סודי (seed) שתוכנת על ידי היצרן. כדי להשתמש בהם עם Azure AD, יש להזין מפתח זה לתוך הדייר באמצעות קובץ CSV. ישנן מספר מגבלות חשובות: המפתח הסודי מוגבל ל -128 תווים מקודדים ב-Base32 , יכול להכיל רק את האותיות a-z ו-a-Z ואת הספרות 1 עד 7, וחייב לדבוק בפורמט הצפוי כדי שהמערכת תקבל אותו.

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

תהליך העלאת הטוקן מתבצע באמצעות קובץ CSV עם עמודות כגון UPN, מספר סידורי, מפתח סודי, מרווח זמן, יצרן ודגם. לאחר העלאתו מ- Enter ID > Multi-Factor Authentication > OATH tokens , השירות מעבד את הקובץ ומאפשר לך לצפות בשגיאות עיצוב בקובץ CSV להורדה.

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

הגדרות שיחת טלפון והודעות קוליות

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

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

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

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

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

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

תצורת שירות MFA מתקדמת וכתובות IP מהימנות

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

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

בדיירים מנוהלים, ניתן להגדיר עד 50 טווחי IP בסימון CIDR הנחשבים מהימנים. בדיירים מאוחדים, ניתן גם להפעיל את האפשרות "כל המשתמשים המאוחדים" כך שמשתמשים שאומתו דרך AD FS מהאינטראנט יעקפו את MFA, בתנאי ש-AD FS ינפיק את ההודעה המתאימה (insidecorporatenetwork), שתצורתה נקבעה באמצעות כלל הנפקת תביעות.

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

הדרך המומלצת לניהול מיקומים מהימנים כיום היא באמצעות גישה מותנית עם מיקומים בעלי שם . מתוך מזהה כניסה > גישה מותנית > מיקומים בעלי שם, ניתן ליצור מיקום חדש, לסמן אותו כאמין ולהגדיר טווחי IP (לדוגמה, 40.77.182.32/27). לאחר מכן, מיקומים אלה משמשים במדיניות גישה מותנית כדי לקבוע מתי נדרשת גישה מותנית (MFA).

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

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

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

שיטות אימות זמינות וניהולן

Azure AD מציעה מגוון רחב של שיטות אימות בהן ניתן להשתמש הן עבור MFA והן עבור SSPR, בהתאם לתצורה שלך. שיטות אימות רב-גורמיות נתמכות כוללות: Microsoft Authenticator, Authenticator Lite (ב-Outlook), Windows Hello for Business, מפתחות אבטחה FIDO2, אסימוני חומרה של OATH, אסימוני תוכנה של OATH, SMS ושיחות קוליות.

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

מיקרוסופט ממליצה להשתמש במדיניות שיטות אימות כדי לנהל את כל השיטות הללו . מדיניות זו נגישה תחת מזהה כניסה > אבטחה > שיטות אימות > מדיניות. קונסולה מאוחדת זו מאפשרת לך להפעיל או להשבית שיטות עבור קבוצות משתמשים שונות, להגדיר פרמטרים נוספים (כגון הגדרת אימות ללא סיסמה כאשר Microsoft Authenticator מציג מיקום ושם אפליקציה), ולשלוט הן ב-MFA והן ב-SSPR ממיקום יחיד.

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

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

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

זכרו להשתמש באימות רב-גורמי ובמכשירים מהימנים.

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

כל עוד קובץ ה-cookie נשאר בתוקף (לא נמחק או פג תוקפו), והמשתמש משתמש באותו דפדפן, לא יתבקש MFA שוב בהקשר ספציפי זה. אם הם מחליפים דפדפנים באותו מכשיר או מנקים את קובצי ה-cookie שלהם, יתבקש אימות שוב. אפשרות זו זמינה רק בזרימות מבוססות דפדפן, לא ביישומים שאינם דפדפנים , אם כי ביישומים אלה Azure AD עדיין בודק את גיל האימות הרב-גורמי האחרון בעת ​​אימות אסימוני רענון.

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

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

הפעלת MFA עם מדיניות גישה מותנית

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

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

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

דוגמה קלאסית לבדיקות היא החלת המדיניות על קבוצת הבדיקות ועל משאב כמו "Windows Azure Services Management API" או מרכז הניהול של Microsoft Entra עצמו. פעולה זו תראה לכם כיצד, בעת גישה למשאבים אלה, מתבקשת MFA או שהמשתמש מתבקש להירשם ל-MFA אם עדיין לא עשה זאת.

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

תרחישים היברידיים עם Active Directory ו-MFA

בסביבות רבות, Active Directory מקומי נותר ליבת תשתית הזהויות , בעוד ש-Azure AD מספק את ממשק האימות עבור Microsoft 365 ויישומי ענן. במקרים אלה, פריסת MFA באופן עקבי הן מקומי והן בענן מהווה אתגר משמעותי.

Active Directory עצמו מציע תמיכה מקורית ב-MFA רק באמצעות אימות כרטיס חכם , שאין לבלבל אותו עם MFA עבור AD FS. כדי לחזק כניסות אינטראקטיביות או RDP בשרתים ובמחשבים אישיים, ארגונים רבים משלבים פתרונות כגון Windows Hello for Business או ספקי MFA של צד שלישי (למשל, Duo) ישירות בנקודות קצה או בשרתי קפיצה; חוסן זהויות וזמינות גבוהה הם שיקולים חשובים בעיצובים אלה.

בעת שימוש בספקי שירותי זהות מבוססי ענן כמו Entra ID, מקובל להסתמך על כלים כמו Microsoft Entra Connect (לשעבר Azure AD Connect) כדי לסנכרן זהויות בין Active Directory מקומי לבין דייר הענן. משם, MFA, גישה מותנית והגנה על זהויות נאכפים בשכבת Entra ID עבור כל היישומים המאמתים ישירות מולה.

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

לעומת זאת, עם תוכניות כמו רישיונות Microsoft 365 Business, E3, E5 או Entra ID P1/P2, מדיניות גישה מותנית אינה פתוחה וניתן לשלב אותה עם MFA לכל משתמש בעת הצורך. גם Microsoft 365 וגם Office 365 תומכים ב-MFA באמצעות SMS, שיחות קוליות ו-Microsoft Authenticator, בעוד ש-Entra ID מוסיף אפשרויות נוספות כגון FIDO2, Windows Hello, אסימוני OATH ועוד.

יישומים המשתמשים באימות מודרני (כגון OpenID Connect או OAuth2) ומשתלבים ישירות עם Entra ID יכולים למנף בצורה חלקה את כל תכונות הגישה המותנית הללו. עבור יישומים מדור קודם או מקומיים שאינם מתקשרים ישירות עם Entra, ניתן להשתמש ב-Azure AD Application Proxy או באינטגרציה עם Network Policy Server (NPS) כדי להכניס MFA לזרימת האימות.

אימות אדפטיבי והגנה על זהות

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

Entra ID Protection מנתחת באופן רציף את הסיכון הקשור הן למשתמש והן לתהליך ההתחברות: מיקומים יוצאי דופן, מכשירים לא ידועים, דפוסים הקשורים לבוטים או להתקפות Brute-Force, אישורים שנמצאו ברשימות גנובות וכו'. כאשר הסיכון גבוה, הוא יכול להפעיל פעולות מתקנות כגון דרישה מהמשתמש לאפס את הסיסמה שלו או חסימה ישירה של הגישה עד להתערבות מנהל מערכת.

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

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

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