בהמשך לדיון הקודם שלנו על יסודות הטוקנים, המאמר הזה מציג אסטרטגיות מתקדמות לחיזוק אבטחת הטוקנים ב-Microsoft Entra ID. נתמקד בהפעלת Continuous Access Evaluation (CAE) ב-Strict Mode ובהרחבת CAE ל-workload identities. כל שלב תיקון כולל את פרטי הרישוי הנדרשים, כדי לעזור בתכנון וביישום.
בקצרה (TL;DR):
הגנה על טוקנים ב-Microsoft Entra ID דורשת צעדים יזומים וטכניים:
- אכפו מדיניות Conditional Access שמגבילה סשנים לפי רמת סיכון.
- הפעילו Continuous Access Evaluation (CAE) ב-Strict Mode לביטול סשנים מהיר.
- הרחיבו את ההגנות של CAE ל-workload identities (service principals).
- חזקו את ה-endpoints עם Microsoft Defender for Endpoint ואכפו תאימות באמצעות Intune.
- השתמשו ב-Token Binding כדי למנוע התקפות replay, על ידי קישור הטוקנים למכשירים.
- נטרו risky workload identities ואוטומטו את התיקון.
רישוי במבט מהיר:
- Conditional Access ➔ Microsoft Entra ID P1
- מדיניות CA מבוססת סיכון, CAE, Token Protection ➔ Microsoft Entra ID P2
- Defender for Endpoint ו-Intune ➔ רישיונות נפרדים של Defender for Endpoint Plan 1/2 ושל Intune Plan 1
כל שלב מקטין משמעותית את הסיכון לגניבת טוקנים, חטיפת סשנים וגישה לא מורשית.
1. אכפו מדיניות Conditional Access להגנה על טוקנים
מטרה: הגדירו מדיניות Conditional Access (CA) שאוכפת הגנה על טוקנים, כך שהטוקנים קשורים למכשירים תואמים והסשנים מבוטלים כשמזוהה סיכון.
שלבי יישום: יצירת מדיניות Conditional Access
- היכנסו ל-Microsoft Entra admin center.
- עברו אל Entra ID > Conditional Access > Policies.
- לחצו על New policy והגדירו שם למדיניות.
- תחת Assignments, בחרו את המשתמשים או הקבוצות שייכללו.
- תחת Cloud apps or actions, בחרו את האפליקציות שהמדיניות תחול עליהן.
- תחת Conditions, הגדירו לפי הצורך את sign-in risk, device platforms ו-locations.
- תחת Access controls, בחרו Grant וסמנו Require compliant device ו/או Require Hybrid Azure AD joined device.
- הפעילו את המדיניות.
דרישת רישוי: Microsoft Entra ID P1 נדרש עבור Conditional Access. למדיניות מבוססת סיכון נדרש Microsoft Entra ID P2.
2. הפעילו Continuous Access Evaluation (CAE) ב-Strict Mode
מטרה: השתמשו ב-CAE ב-Strict Mode כדי לאכוף ביטול סשן מהיר כשכתובת ה-IP של משתמש משתנה למיקום לא מהימן.
שלבי יישום: הגדרת CAE ב-Strict Mode
- ב-Microsoft Entra admin center, עברו אל Entra ID > Conditional Access > Named locations.
- הגדירו מיקומים מהימנים על ידי ציון טווחי IP.
- צרו מדיניות Conditional Access שמיועדת לכל המשתמשים ולכל ה-cloud apps.
- תחת Conditions, הגדירו ב-Locations שייכללו כל המיקומים ויוחרגו המיקומים המהימנים.
- תחת Access controls, בחרו Block access.
- הפעילו Strict enforcement תחת Session controls.
דרישת רישוי: Microsoft Entra ID P1 נדרש עבור Conditional Access.
3. הרחיבו את CAE ל-workload identities
מטרה: החילו CAE על workload identities (service principals), כדי להבטיח אכיפה מהירה של מדיניות גישה וביטול טוקנים.
שלבי יישום: הפעלת CAE עבור workload identities
- ודאו שהאפליקציה רשומה ב-Microsoft Entra ID והיא אפליקציית single-tenant.
- שנו את קוד האפליקציה כך שיבקש את ה-claim בשם xms_cc עם הערך cp1 בבקשת ה-access token.
- הגדירו מדיניות Conditional Access שמיועדת ל-service principal, עם תנאים על בסיס מיקום וסיכון.
- נטרו את ה-sign-in logs כדי לוודא שה-CAE נאכף עבור workload identities.
דרישת רישוי: Microsoft Entra ID P1 נדרש עבור Conditional Access. למדיניות מבוססת סיכון נדרש Microsoft Entra ID P2.
4. חזקו מכשירים מפני גניבת טוקנים
מטרה: חזקו את אבטחת ה-endpoints כדי למנוע גניבת טוקנים והתקפות replay.
שלבי יישום: פריסת Microsoft Defender for Endpoint
- ודאו שכל המכשירים מחוברים (onboarded) ל-Microsoft Defender for Endpoint.
- הפעילו Real-time protection, Cloud-delivered protection ו-Tamper protection.
- הגדירו כללי attack surface reduction כדי למנוע גניבת אישורים.
הטמעת מדיניות תאימות של Intune:
- הגדירו מדיניות תאימות שדורשת ש-Microsoft Defender for Endpoint יהיה מופעל ותקין במכשירים.
- השתמשו ב-Conditional Access כדי להגביל גישה למכשירים תואמים בלבד.
דרישת רישוי: נדרשים Microsoft Defender for Endpoint Plan 1 או Plan 2 ו-Microsoft Intune Plan 1.
5. השתמשו ב-Token Binding
מטרה: קשרו טוקנים למכשירים ספציפיים כדי למנוע replay של טוקנים במכשירים לא מורשים.
שלבי יישום: הפעלת Token Protection
- ב-Microsoft Entra admin center, עברו אל Entra ID > Conditional Access > Policies.
- צרו מדיניות חדשה שמיועדת למשתמשים ולאפליקציות.
- תחת Session, הפעילו Token protection.
- הגדירו את המדיניות כך שתדרוש קישור הטוקן למכשיר (token binding).
דרישת רישוי: Microsoft Entra ID P2 נדרש עבור יכולות Token protection.
6. נטרו risky workload identities והגיבו להן
מטרה: זהו ותקנו workload identities שנפרצו באמצעות Microsoft Entra ID Protection.
שלבי יישום: הפעלת Microsoft Entra ID Protection
- ב-Microsoft Entra admin center, עברו אל Entra ID Protection > Risky workload identities.
- עברו על הסיכונים שזוהו והגדירו תגובות אוטומטיות, כמו השבתת ה-service principal או דרישה לאימות מחדש.
- הגדירו התראות והודעות על זיהויים ברמת סיכון גבוהה.
דרישת רישוי: Microsoft Entra ID P2 נדרש עבור Conditional Access מבוסס סיכון וגישה לדוחות סיכון מפורטים.
סיכום
יישום האסטרטגיות המתקדמות האלה משפר את מצב האבטחה של הארגון שלכם, כי הוא מבטיח שהטוקנים מוגנים מפני גניבה ושימוש לרעה. בעזרת יכולות כמו CAE ב-Strict Mode והרחבת ההגנות ל-workload identities, אפשר לאכוף בקרות גישה מהירות ולהקטין את הסיכון לגישה לא מורשית.
לקבלת הכוונה ותמיכה נוספות, שקלו להתייעץ עם נציג Microsoft שלכם או עם שותף מוסמך של Microsoft, כדי להתאים את היישומים לצרכים הספציפיים של הארגון.
רוצים לדעת איפה הטננט שלכם עומד? Griffin31 בודק את הגדרות האבטחה של Microsoft 365 אצלכם באופן רציף ומראה מה לתקן קודם.