כיצד Conditional Access משתמש באותות של Defender כדי להגן על סביבות Microsoft

By Mirko Peters · 2026-04-26

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

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

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

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

הבנת השילוב בין Entra Conditional Access לאותות של Defender

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

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

לאורך המאמר הזה תראו דרכים מעשיות שבהן Conditional Access משתמש באותות האלה כדי ליצור שער חכם יותר, לעצור פעילות חשודה ולתמוך באבטחה אדפטיבית מבוססת Zero Trust. אם תהיתם פעם מה הופך את הגישה לענן גם לבטוחה וגם לנוחה לשימוש (בלי לנעול את האנשים שלכם בחוץ), כאן הכול מתחבר יחד. להעמקה בנושא של פערי אמון והתאמת מדיניות להטמעה חלקה, עיינו במדריך זה על בעיות אמון במדיניות Conditional Access, או האזינו לדיון של מומחים על סיכוני זהות בפודקאסט זה על Entra ID ומעגלי אבטחה.

מהו Entra Conditional Access ואיך הוא פועל?

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

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

כיצד Microsoft Defender מספק אותות סיכון ל-Conditional Access

Microsoft Defender משמש כמערכת ההתרעה המוקדמת של Conditional Access. Defender for Endpoint ו-Defender for Cloud Apps שולחים אותות סיכון בזמן אמת על בריאות המכשירים, איומים פעילים והתנהגויות חשודות ישירות אל מנוע Conditional Access.

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

אותות מרכזיים שמניעים החלטות Conditional Access

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

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

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

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

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

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

מינוף אותות זהות ואיומים מ-Microsoft Defender

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

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

בניית מדיניות Conditional Access חזקה עם שילוב Defender

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

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

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

מדיניות חיונית ל-Azure Conditional Access

1. חסימת אימות מדור קודם: פרוטוקולים ישנים כמו IMAP ו-POP אינם תומכים ב-MFA והם מועדפים על תוקפים. אכפו מדיניות שחוסמת שיטות אימות מדור קודם, כדי לצמצם משמעותית וקטור סיכון מהסביבה שלכם. זהו הבסיס לכל פריסה מאובטחת של Microsoft 365 או Azure.
2. דרישת MFA למשתמשים ולמנהלים: אימות רב-שלבי עוצר את רוב גניבות האישורים בשלב מוקדם. אכפו MFA לכל המשתמשים, ודרשו אימות נוסף (עמיד להתחזות לפישינג, אם אפשר) בתרחישים בעלי הרשאות גבוהות או סיכון גבוה. כך מונעים תנועה רוחבית בסביבה לאחר פריצה.
3. דרישה למכשיר מסומן כתואם: ודאו שרק נקודות קצה מנוהלות ותקינות, שנבדקות באמצעות מדיניות תאימות מכשירים ב-Intune, יוכלו לגשת ליישומים רגישים כמו Exchange Online או SharePoint. כך מגנים על המידע fמפני מכשירים נגועים או לא מנוהלים שחודרים דרך תרחישי עבודה מרחוק.
4. אכיפת בקרות מיקום גישה: הגבילו גישה ליישומים קריטיים על בסיס מיקומי רשת מהימנים, והפעילו אימות נוסף כאשר משתמשים מתחברים ממקומות חריגים או לא צפויים. זה מתיישב היטב עם עקרונות Zero Trust: אל תניחו אמון רק משום שהשם המשתמש והסיסמה נכונים.
5. שימוש במדיניות בקרת יישומים והפעלה: חברו בקרות הפעלה דרך Defender for Cloud Apps כדי לנהל מה המשתמשים יכולים לעשות לאחר הכניסה. אפשר להגביל הורדות, לסרוק הוצאת מידע, או אפילו לחסום פעולות מסוכנות תוך מתן גישת קריאה בלבד, במיוחד במכשירים לא מנוהלים.

אם אתם מתקדמים לעבר Zero Trust, כדאי לתכנן את המדיניות בתיאום, כפי שמודגש בפודקאסט הזה על Zero Trust by Design, שמכסה מדיניות גישה אדפטיבית והערכה מתמשכת ב-Microsoft 365 וב-Dynamics 365.

אכיפת MFA ואימות עמיד להתחזות לפישינג למשתמשים

• MFA לכל המשתמשים: הפכו MFA לברירת מחדל, וכסו כל חשבון, לא רק מנהלים. השתמשו במדיניות Conditional Access מובנית כדי להתחיל במהירות.
• אפשרויות עמידות להתחזות לפישינג: הטמיעו מפתחות אבטחה FIDO2 ו-Windows Hello for Business כגורמי אימות עיקריים, כדי להפחית את הסיכון מפישינג והתקפות שימוש חוזר באסימונים.
• קבוצות מנהלים וסיכון גבוה: דרשו תמיד אימות נוסף לחשבונות מנהל ולמשתמשים שניגשים ליישומים רגישים, שכן הם יעדים מובילים להתקפות.
• חשבונות Break-Glass: השאירו חשבון חריג מאובטח ומנוטר לשחזור חירום, אך הגבילו אותו בחוזקה ובצעו ביקורת מלאה כדי למנוע שימוש לרעה.

מכשירים מהימנים ותואמים כדרישות גישה

• דרישת מכשירים תואמים: הגבילו את הגישה כך שרק מכשירים התואמים ל-Intune ולמדיניות יקבלו אישור לגשת למידע עסקי רגיש.
• אכיפת Hybrid Join או Entra ID Join: בתרחישים מתקדמים, אפשרו גישה רק ממכשירים שהם Hybrid joined או רשומים במלואם ב-Entra ID, שהם שכבת זיהוי נוספת.
• שילוב סיכון מכשיר וסיכון משתמש: שלבו בדיקת תאימות מכשיר עם אותות סיכון של המשתמש, כך שגם מכשיר תואם ייחסם אם המשתמש או הסשן החשודים פתאום נראים חריגים.

שיטות עבודה מומלצות וטעויות נפוצות בפריסת Conditional Access

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

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

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

איך להימנע מטעויות ומהתנגשויות נפוצות במדיניות גישה מותנית

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

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

דרישות מוקדמות לפריסה ומגבלות שירות

1. הרשאות ניהול: תזדקקו להרשאות מספקות, בדרך כלל Global Administrator או Security Administrator ב-Entra ID, כדי ליצור ולנהל מדיניות גישה מותנית.
2. דרישות רישוי: רוב התכונות של מדיניות הגישה המותנית דורשות לפחות רישוי של Microsoft Entra ID P1 או P2, ואינטגרציות של Defender עשויות להוסיף שכבות רישוי נוספות. יש לתכנן זאת מההתחלה.
3. דרישות תשתית: ודאו שההתקנים שלכם רשומים ב-Intune, שהזהויות נקיות (ללא כפילויות או חשבונות ישנים), ושהדירקטוריון מוכן לסנכרון ולניטור.
4. מגבלות שירות: לא כל האפליקציות המדור קודם או של צד שלישי תומכות באכיפת מדיניות גישה מותנית, וחשבונות שירות ו-managed identities דורשים לעיתים טיפול מיוחד. קראו את התיעוד בעיון כדי שדבר לא יתגלגל בין הסדקים.

בקרות מתקדמות ושילוב כלי אבטחה

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

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

גם בקרה רציפה ובקרות מסתגלות עוזרות למנוע סחיפה של ציות (compliance drift), תוך שימוש ב-Defender for Cloud וכלים כמו Power BI. לקבלת אסטרטגיות מעשיות לאוטומציה מתמשכת של ציות ולתצוגה מאוחדת, כדאי לעיין במדריך מהשטח לניטור עם Defender for Cloud. עכשיו, בואו נפרק את הבקרות המרכזיות ואסטרטגיות האינטגרציה למקסום האבטחה וחוויית המשתמש גם יחד.

שימוש בבקרות סשן ובהגנת טוקנים במכשירים מנוהלים

• תדירות כניסה (Sign-In Frequency): קבעו באיזו תדירות המשתמשים נדרשים לאמת את זהותם מחדש. מרווחים קצרים יותר עבור אפליקציות רגישות מצמצמים את חלון הסיכון אם טוקן נגנב.
• מדיניות הגנה לאפליקציות (App Protection Policies): הגבילו פעולות כמו העתקה והדבקה, שמירה בשם או שיתוף כאשר משתמשים ניגשים לנתונים ממכשירים ניידים או ממכשירים לא תואמים, כך שמידע רגיש לא ידלוף החוצה.
• הגנת טוקנים (Token Protection): קשרו טוקנים לאימות לתוך מכשירים מסוימים ומאומתים. כך נמנעת השימוש החוזר בטוקן על מכשירים אחרים על ידי תוקפים, גם אם הטוקן נגנב.
• איזון בין שימושיות לאבטחה: בדקו את הבקרות עם משתמשים אמיתיים כדי לא להעמיס עליהם יתר על המידה. החמירו בהדרגה לפי הצורך והסיכון, ולא לפי ניחוש.

שילוב כלי אבטחה ושיקולים לגבי לקוחות אפליקציות

• שילוב עם Microsoft Intune: חברו את ניהול המכשירים ישירות ל-Conditional Access כדי לקבל אותות עדכניים על ציות ותקינות נקודות הקצה.
• Defender for Endpoint/Cloud Apps: השתמשו ב-Defender כדי להעביר אותות על איומים ועל סשנים, שאותם Conditional Access יכול לצרוך לצורך מדיניות מסתגלת בזמן אמת.
• כלי אבטחה של צד שלישי: שלבו פתרונות SIEM, CASB או ניהול נקודות קצה לפי הצורך, אך אמתו את התאימות בזהירות.
• תמיכה באפליקציות וביישומי לקוח: ודאו שלקוחות האפליקציות, במיוחד אפליקציות ישנות או ניידות, תומכים במלואם באכיפה של Conditional Access ובדיווח טלמטריה, כדי למנוע נקודות עיוורון.

לתובנות מעמיקות יותר על אבטחת Microsoft Power Platform וניהול סיכוני מחברים, ראו שיטות עבודה מומלצות לממשל Power Platform.

תגובה לאיומים בזמן אמת עם אותות של Defender

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

האוטומציה הזו מקצרת משמעותית את זמן השהייה של התוקפים בתוך הסביבה, חוסמת תנועה רוחבית ומצמצמת אובדן נתונים. אתם לא עושים את זה ידנית: הטלמטריה שנוצרת ב-Defender מזינה ישירות את הערכות הסיכון ב-Entra ID ומעדכנת את רמת הסיכון של המשתמש, המכשיר או הסשן. התוצאה? תגובה טובה יותר לאירועים, עומס קטן יותר על צוות האבטחה וסביבה הרבה יותר קשה לתוקפים לפרוץ לתוכה, וזה חשוב במיוחד במסגרת עקרונות Zero Trust, שבהם כל סשן וכל הקשר נחשבים.

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

התאמת מדיניות דינמית באמצעות Defender for Endpoint

1. איתור תוכנה זדונית מפעיל שינויי גישה: אם Defender for Endpoint מזהה תוכנה זדונית במכשיר, Conditional Access יכול לחסום מיידית את המכשיר מכל המשאבים הארגוניים, או לדרוש אימות נוסף מהמשתמש.
2. תהליכים חשודים או איומים: כאשר מזוהת פעילות תהליכים מסוכנת, כמו ניצול פגיעות ידוע או התנהגות של ransomware, האות מעלה את רמת הסיכון של המכשיר. Conditional Access מגיב על ידי ביטול סשנים פעילים או החלת בקרות מחמירות יותר עד לטיפול בבעיה.
3. ביטול סשנים אוטומטי: במקום לחכות שמנהל ילכוד את הבעיה, התראות חיות של Defender מפעילות אכיפת מדיניות אוטומטית: הכנסה לבידוד, התנתקות, או מעבר של גישת המשתמש לקריאה בלבד, ללא עיכוב.
4. תגובה מיידית ומתואמת: היכולות האלה מאיצות משמעותית את התגובה לאירועים, חוסמות תוקפים בזמן אמת ומצמצמות את הסיכון להתפשטות או לחשיפת נתונים.

העשרת רמות הסיכון של Identity Protection באמצעות Defender Intelligence

Defender לא רק מסמן דגלים אדומים עבור מכשירי קצה; הוא מזין את מנוע הניקוד של סיכוני הזהות ב-Entra Identity Protection בנתוני סיכון במכשיר, בחריגות בסשנים ובאותות איומים. לכל כניסה ולכל סשן מוקצית רמת סיכון עדכנית, שנלקחת בחשבון לצד טלמטריה חיה מ-Defender for Endpoint וממ-Defender for Cloud Apps.

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