מ-Gatekeeper ל-Watcher: גישור בין אבטחה לפני אימות לאבטחה אחרי אימות

By Mirko Peters · 2026-08-11

ברוכים השבים לפודקאסט ולהעמקה הטכנולוגית שלנו! אם אי פעם הרגשתם שלאסטרטגיית אבטחת הזהויות שלכם יש נקודה עיוורת מיד לאחר שמשתמש…

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

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

הרעיון המרכזי (TL;DR)

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

• Conditional Access (CA) הוא השומר שעל הדלת. הוא מצטיין מאוד בקבלת החלטות לפני אימות, על סמך מי שמנסה להיכנס, ממאיזה מקום הוא מתחבר ומצב המכשיר שלו.
• Defender for Identity (DfI) הוא מערכת המצלמות שלכם יחד עם אבטחת הקומה. הוא מצטיין בניטור התנהגות אחרי אימות, תנועה רוחבית וחריגות פנימיות.
• הגנה אמיתית מתרחשת רק כאשר סיכון שנוצר אחרי אימות מעלה את החיכוך לפני אימות באופן אוטומטי ודינמי, ממש שם, בתוך הסשן.

מודל מנטלי

בואו נדייק את המודל המנטלי של אופן הפעולה ההדדית של הרכיבים במערכת שלכם:

• Gatekeeper (CA): בודק מי נכנס, מאיפה, מצב המכשיר, סיכון בזמן הכניסה, ואוכף בקרות סשן מיידיות.
• Watcher (DfI + M365 Defender): מחפש תנועה רוחבית, דפוסי גישה חריגים למשאבים, Kerberoasting, שימוש לרעה ב-NTLM והסלמות הרשאות בלתי צפויות.
• לולאת משוב: ה-Watcher מסמן התנהגות חשודה, שבתורה מעלה את ציון סיכון המשתמש או סיכון הסשן. כך ה-Gatekeeper מוכרח להדק מיד את הבקרות, על ידי דרישת MFA נוסף, חסימה מלאה של הגישה או הגבלת הסשן הפעיל.

שרטוט אינטגרציה (מה להפעיל, ובאיזה סדר)

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

1. CA מודע לסיכון (בסיס)
   • Entra ID Protection: הפעילו הערכה של User risk ו-Sign-in risk.
   • צרו מדיניות CA:
     • חסימה כאשר User risk = High (או דרישה לשינוי סיסמה, אם תהליכי מוקד התמיכה שלכם תומכים בכך).
     • דרישת MFA כאשר Sign-in risk ≥ Medium.
     • דרישת מכשיר תואם עבור אפליקציות ברגישות בינונית עד גבוהה; השתמשו ב-device filters עבור נקודות קצה לא מנוהלות כדי להעביר אותן ישירות לבקרות סשן מוגבלות.
2. אפשרו ל-watcher לדבר עם ה-gatekeeper
   • ודאו ש-DfI מזרים התראות באופן פעיל ל-Microsoft 365 Defender ול-Sentinel (אם אתם משתמשים בו ל-SIEM/SOAR).
   • הפעילו אוטומציה של פעולות "Confirm compromised" על משתמשים בהתראות DfI בחומרה גבוהה. פעולה זו מגדירה User risk = High ב-Entra ID Protection, וגורמת למדיניות ה-CA שלכם להגיב מיד.
   • מסלול אוטומציה: Incident ב-M365 Defender ← Logic App או Power Automate ← Graph Security/Identity Protection API (/riskDetections, /riskyUsers:confirmCompromised) ← אופציונלי: Force sign-out.
   • הפעילו Continuous Access Evaluation (CAE) בכל האפליקציות הנתמכות (Exchange, SharePoint, Graph), כדי ששינויים במדיניות ינתקו בפועל אסימונים פעילים.
3. בקרת סשן לצורך הכלה
   • עבור סשנים לא מנוהלים או מסוכנים, פרסו את Defender for Cloud Apps (session proxy) ישירות מתוך CA:
     • CA ← Use Conditional Access App Control (קודם מעקב, ואז חסימה של הוצאת נתונים כמו הורדות, העתקה והדבקה, הדפסה וסנכרון).
   • שלבו זאת עם MDE device risk → Intune compliance → CA "Require compliant device" עבור כל היישומים הרגישים.
4. מעקות בטיחות לזהויות בעלות הרשאות
   • PIM חייב לאכוף גישה Just-in-Time. יש לדרוש MFA + מכשיר תואם + מצב משתמש ללא סיכון לפני שמתירים העלאת הרשאות.
   • הטמיעו מדיניות CA כדי לחסום תפקידים בעלי הרשאות מיוחדות אם user risk ≥ Low (כן, גם סיכון נמוך), כך שיתבצע מיון מיידי לפני שניתן לאמץ תפקיד ניהולי.

"אם זה, אז that": מיפוי אותות DfI לפעולות CA

מיפוי של אותות זיהוי ספציפיים מ-Defender for Identity לפעולות אוטומטיות של Conditional Access ולפעולות תגובה מגשר על הפער שבין תצפית פסיבית להגנה פעילה:

התחילו בהרצת אלה במצב audit/monitor למשך שבוע עד שבועיים, ואז העבירו את התגובות למצב enforce לפי סוג התראה, ככל שהביטחון שלכם גדל.

דוגמאות למדיניות (מעשיות ומינימליות)

כדי להעביר את האסטרטגיות האלה לייצור, אלה ארבע מדיניות יסוד שכדאי להגדיר:

1. חסימה כאשר user risk = High
   • הקצאה: כל המשתמשים (למעט חשבונות break-glass), כל אפליקציות הענן
   • תנאים: User risk = High
   • הענקה: חסימת גישה
2. Step-up בעת סיכון בכניסה
   • הקצאה: כל המשתמשים, יישומים בעלי ערך גבוה (פורטלים ניהוליים, Exchange, SharePoint, Entra admin center)
   • תנאים: סיכון כניסה ≥ בינוני
   • הענקה: דרישת MFA + דרישת מכשיר תואם (או מכשיר מנוהל)
3. הכלת Session לא מנוהל
   • הקצאה: כל המשתמשים, SharePoint/OneDrive/Teams
   • מצב מכשיר: Hybrid/Compliant = עקיפה; Unmanaged = אכיפה
   • Session: השתמשו ב-Conditional Access App Control (חסימת הורדות)
4. מנגנון הגנה להעלאת הרשאות
   • הקצאה: Directory roles = תפקידים ניהוליים בעלי הרשאות מיוחדות
   • תנאים: סיכון משתמש ≥ נמוך OR סיכון כניסה ≥ בינוני
   • הענקה: דרישת MFA + דרישת מכשיר תואם; חסימה אם הסיכון ≥ High

Playbooks לאוטומציה (מוכנים לחיבור)

אוטומציה היא הנשק הסודי שמקצר את ה-Mean Time to Contain (MTTC) שלכם. הנה שני Playbooks שאפשר לבנות כבר היום:

Playbook A: התראת DfI בחומרה גבוהה → בידוד זהות

• טריגר: אירוע ב-M365 Defender שסומן ב-IdentityThreatHigh
• פעולות:
  1. Graph API – אישור שהמשתמש נפרץ (מגדיר את User risk ל-High)
  2. Entra ID – ביטול refresh tokens מיידית
  3. Intune/MDE – בידוד מכשיר (אם משויך מכשיר ראשי יחיד)
  4. ServiceNow/JSM – יצירת כרטיס אירוע עם ציר הזמן והארטיפקטים שנאספו
  5. הודעה ל-SOC ולבעלים של המשתמש דרך כרטיס אדפטיבי ב-Teams, עם כפתור rollback בלחיצה אחת למקרה של התראות שווא

Playbook B: פרץ גישה חריג ל-SharePoint

• טריגר: התראת Defender “Unusual file download”
• פעולות:
  1. תיוג המשתמש ב-UnderInvestigation באמצעות AAD extension attributes
  2. העברת המשתמש למדיניות CA שמפנה אותו ל-App Control (חוסם הורדות והדפסה)
  3. הפעלת eDiscovery hold על אתרי SharePoint שנפגעו (אופציונלי, בהתאם לצרכי ציות)
  4. ביטול אוטומטי של הכלה לאחר 72 שעות, אלא אם ה-SOC מאריך אותה ידנית

ציד איומים ושאילתות שימושיות

ציד יזום עוזר לכם לתפוס פערים לפני שתוקפים מנצלים אותם. השתמשו בשאילתות האלה ב-M365 Defender Advanced Hunting:

עלייה בגישה של משתמש לאתרי SharePoint לעומת בסיס של 30 יום:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

קפיצות בסיכון כניסה הקשורות מקרוב להתראות DfI מאוחרות יותר:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

מדדים שמוכיחים שזה עובד

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

• זמן ממוצע לבידוד (MTTC) לאירועי זהויות (הזמן מרגע יצירת ההתראה ועד אכיפת CA) ↓
• זמן שהתוקף שוהה במערכת (Attacker dwell time) (הזמן מהפעולה החשודה הראשונה ועד לתיקון מלא) ↓
• סשנים מסוכנים שנחסמו (אירועים שהפעילו מדיניות) ↑ בעוד ששיעור התוצאות החיוביות השגויות ↓
• גיל backlog של משתמשים בסיכון (תיקים פתוחים מעל 24 שעות) ↓
• השהיית ביטול טוקנים (נמדדת בשניות) ↓
• כשלי הסלמת הרשאות מסוג Privileged עקב סיכון (נתפסים מוקדם, לפני שנגרם נזק) ↑ ואז מתייצבים עם הזמן
• Secure Score בתחומי Identity, Devices ו-Apps ↑ ללא זינוק מקביל בפניות לתמיכה הטכנית

אסטרטגיית פריסה של 30/60/90 ימים

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

ימים 0–30 (יסודות)

• הפעילו את הגדרות User and Sign-in risk ב-Entra ופרסו מדיניות בסיס של CA במצב ביקורת (audit), ולאחר מכן עברו למצב אכיפה.
• חברו את Defender for Identity ל-M365 Defender; ודאו שההתראות והמיפויים של הישויות המרכזיות תקינים.
• הפעילו את Continuous Access Evaluation (CAE) עבור אפליקציות נתמכות, והטמיעו את סיכון המכשיר ב-MDE בתאימות של Intune.

ימים 31–60 (משוב והכלה)

• בנו Playbooks A ו-B ב-Logic Apps, ובדקו אותם לעומק במצב dry-run.
• פלטו App Control לסשנים לא מנוהלים עם 2 עד 3 צוותים עסקיים משתפי פעולה.
• הטמיעו את מדיניות ההגנה של PIM להסלמת הרשאות.

ימים 61–90 (אכיפה ומדידה)

• העבירו את ה-playbooks האוטומטיים למצב enforce מלא עבור התראות בעלות ודאות גבוהה.
• הקימו workbook לאבטחת זהויות (ב-Sentinel או ב-Power BI) שעוקב אחרי המדדים שפורטו לעיל.
• קיימו תרגיל purple-team רבעוני כדי לוודא את MTTC, מהירות ביטול הטוקנים והחלפת מדיניות CA בתרחיש של ירי חי.

מלכודות נפוצות (והגדרות ברירת מחדל בטוחות יותר)

היזהרו from המכשולים הנפוצים הבאים במהלך היישום:

• מלכודת: הסתמכות אך ורק על סיכון הכניסה של CA ← תיקון: הגיבו גם לסיכון משתמש ולהתראות DfI שמופיעות לאחר האימות.
• מלכודת: אין CAE מוגדר, ולכן טוקנים מיושנים ממשיכים להחזיק סשנים שנפרצו ← תיקון: הפעילו CAE והטמיעו ביטול טוקנים ישירות בתוך ה-playbooks האוטומטיים.
• מלכודת: חסימה רחבה של הורדת קבצים בכל הארגון, שגורמת למרד משתמשים ← תיקון: החילו את App Control באופן סלקטיבי, רק כאשר הסשנים לא מנוהלים או מסוכנים.
• מלכודת: סערות התראות והתראות שגויות שנגרמות מתהליכי השבתה אוטומטיים אגרסיביים ← תיקון: הפכו את האוטומציות לתלויות ב-אימות מרובה אותות (למשל התראת DfI בדרגת חומרה גבוהה + נפח הורדות חריג + גישה מחוץ לשעות העבודה).
• מלכודת: חשבונות break-glass ננעלים בטעות בגלל מדיניות סיכון אוטומטית ← תיקון: החריגו שני חשבונות break-glass עם ניטור מוגבר, וסובבו את הפרטי ההזדהות שלהם אחת לרבעון.

קטעי Copy/Paste

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

משפט קצר ל-CAB עבור הנהלה:

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

הערת שינוי למנהלים:

• מדיניות Conditional Access חדשה עשויה להפעיל אימות MFA נוסף או לחסום גישה כאשר מזוהה סיכון חריג. טוקנים פעילים של אימות יכולים כעת להתבטל באמצע סשן על בסיס טלמטריה. חשבונות break-glass נותרים מוחרגים באופן מפורש. יש לעקוב אחר ה-workbook של Identity Resilience לצורך ניתוח השפעה.

כרטיס התראה ידידותי לבעלים בערוץ Teams (אוטומטי):

• “שמנו לב לפעילות חריגה בקבצים שמקורה בחשבון שלך. החלנו הגנות זמניות (כגון השבתת הורדות במכשירים לא מנוהלים). אם זה היית אתה, פשוט לחץ על Acknowledge; אם לא, לחץ על Report מיד.”