שני סוגי טוקנים
Microsoft מחלקת את הטוקנים לשתי משפחות. ההבדל ביניהן קובע מה צריך להגן עליו קודם:
| טוקן | למה הוא משמש | כמה זמן הוא תקף | אפשר לבטל אותו? |
|---|---|---|---|
| Primary Refresh Token (PRT) | מבקש טוקנים לכל שירות, ממכשיר רשום | 90 יום, ומתחדש בכל שימוש | כן |
| Refresh Token | מבקש טוקני גישה לשירות מסוים | 90 יום, ומתחדש בכל שימוש | כן |
| Access Token | נותן גישה לשירות עצמו | בין 60 ל-90 דקות (75 בממוצע) | רק אם השירות תומך ב-CAE |
המסקנה של Microsoft עצמה: קודם מגינים על טוקני הסשן (PRT ו-Refresh Token). הם חיים שבועות וחודשים, ותוקף שגונב אותם נשאר בפנים לאורך זמן.
כמה זמן טוקן גישה באמת תקף
- ברירת המחדל: ערך אקראי בין 60 ל-90 דקות, כדי לפזר את העומס על Entra ID.
- בטננט בלי Conditional Access: לטוקני הגישה של לקוחות כמו Teams ו-Microsoft 365 יש ברירת מחדל של שעתיים.
- בסשן שתומך ב-CAE: הטוקן יכול לחיות עד 28 שעות, כי השירות מבטל אותו מיד כשמשהו משתנה. במצב הזה הגדרת זמן חיים מותאמת לא חלה.
חשוב לדעת: אי אפשר יותר לקצר את זמן החיים של Refresh Token וטוקני סשן בהגדרת זמן חיים. Microsoft הוציאה את האפשרות הזו משימוש ב-2021. כדי לחייב התחברות מחודשת משתמשים ב-Sign-in frequency של Conditional Access.
מה קורה כשמבטלים סשנים
ביטול סשנים (Revoke sessions) ואיפוס סיסמה מבטלים את ה-Refresh Token וה-PRT. טוקן גישה שכבר הונפק ממשיך לעבוד עד שהוא פג, אלא אם השירות תומך ב-CAE. לכן בלי CAE, לתוקף יכולה להישאר עד שעה וחצי של גישה גם אחרי שחסמתם אותו.
איך מגינים: חמש שכבות
| הגנה | מה היא עושה | רישוי |
|---|---|---|
| Continuous Access Evaluation (CAE) | Exchange, Teams ו-SharePoint דוחים טוקן מיד כשמשתמש נחסם, משנה סיסמה או עובר למיקום לא מורשה. אירועים קריטיים נאכפים תוך דקות, ושינוי מיקום מיד | Entra ID P1 (Conditional Access) |
| Token Protection | קושר את טוקן הסשן למכשיר שקיבל אותו. טוקן שהועתק למחשב אחר לא עובד | Entra ID P1 |
| מכשיר תואם | מדיניות שדורשת מכשיר מנוהל ב-Intune. גם עם טוקן גנוב, המכשיר של התוקף לא עובר את הבדיקה | Entra ID P1 ו-Intune |
| MFA עמיד לפישינג | passkeys או FIDO2 דרך Authentication strengths. דף פישינג לא מקבל משהו שאפשר להשתמש בו | Entra ID P1 |
| מדיניות לפי רמת סיכון | חסימה או דרישה להתחברות מחדש כשההתחברות או המשתמש נראים חשודים | Entra ID P2 |
שתי מדיניות נוספות שסוגרות דרכים נפוצות להשיג טוקן, ושתיהן ב-P1: חסימת Device Code Flow (כתבנו על תקיפה כזו במאמר על פישינג Device Code), וחסימת Authentication transfer, שמעבירה התחברות ממחשב לטלפון.
מאיפה מתחילים
- ודאו ש-CAE פועל ושאף מדיניות Conditional Access לא מכבה אותו.
- דרשו מכשיר תואם לגישה למידע הארגוני, לפחות מ-Windows ו-macOS.
- הפעילו Token Protection קודם במצב Report-only, כדי לראות אילו אפליקציות לא תומכות. אפליקציות Mail ו-Calendar המובנות של Apple, למשל, לא תומכות בו.
- עברו ל-MFA עמיד לפישינג, קודם לאדמינים ולמחלקת הכספים.
- חסמו Device Code Flow ו-Authentication transfer לכל מי שלא צריך אותם.
- הגדירו Sign-in frequency לאפליקציות ולתפקידים רגישים, במקום לנסות לקצר טוקנים.
רוצים להבין איך תוקפים גונבים טוקנים בפועל, ולמה passkeys לבד לא מספיקים? כתבנו על זה במאמר על פישינג, גניבת טוקנים ו-CAE.
איך Griffin31 עוזר
Griffin31 בודק את הגדרות האבטחה בטננט Microsoft 365 שלכם באופן רציף, כולל מדיניות Conditional Access, ומראה מה לתקן קודם, עם ההוכחה מאחורי התוצאות.
רוצים לדעת אילו הגנות על טוקנים כבר מוגדרות אצלכם? Griffin31 בודק את הגדרות האבטחה ב-Microsoft 365 באופן רציף ומראה מה לתקן קודם.
מקורות
- Microsoft: Understanding tokens in Microsoft Entra ID
- Microsoft: Access tokens in the Microsoft identity platform (token lifetime)
- Microsoft: Continuous access evaluation
- Microsoft: Token protection in Conditional Access
- Microsoft: Token Protection deployment guide for Windows (licensing)
- Microsoft: Conditional Access adaptive session lifetime policies
- Microsoft: Plan a Conditional Access deployment (policies and licenses)
- Microsoft: What is Microsoft Entra ID Protection? (license requirements)