בסביבות זהות מבוססות ענן של היום, הבנה של אופן הפעולה של טוקני אימות, וניהול נכון שלהם, קריטיים לשמירה על אבטחה חזקה וליישום עקרונות Zero Trust.
Microsoft Entra ID משתמש בכמה סוגים של טוקנים כדי להעניק גישה מאובטחת וחלקה בין מערכות.
במאמר הזה נבחן מהם הטוקנים האלה, איך הם פועלים, מהן המלכודות הנפוצות, ומהם הצעדים המעשיים לטפל בהם בצורה מאובטחת.
מהם טוקנים ב-Microsoft Entra ID?
טוקנים הם רכיבים דיגיטליים שמונפקים אחרי אימות מוצלח, ומאפשרים למשתמש או להתקן לגשת למשאבים מוגנים בלי להזין שוב ושוב פרטי גישה.
יש שלושה סוגים עיקריים:
- Access Token
משמש לאישור גישה ל-APIs כמו Microsoft Graph, SharePoint Online ושירותים אחרים.
בדרך כלל תקף למשך שעה אחת כברירת מחדל.
הערה טכנית:
- קצר טווח ומכיל claims כמו מזהה משתמש, תפקידים ו-scopes.
- ה-claim מסוג audience (aud) מגדיר את המשאב שהטוקן מעניק גישה אליו.
- Refresh Token
מאפשר ללקוח לקבל Access Token חדש בלי אינטראקציה של המשתמש.
- כברירת מחדל, ל-Refresh Tokens יש חלון תפוגה של 90 ימים, אבל אפשר לבטל אותם מוקדם יותר.
- צריך לבצע rotation נכון ל-Refresh Tokens ולנטר את השימוש בהם.
- ID Token
משמש בעיקר אפליקציות כדי לאמת את זהות המשתמש אחרי ההתחברות.
- מכיל מידע כמו שם משתמש, מייל ושיטת האימות.
- לא נועד לשמש לגישה ל-API.
אתגרים וסיכונים ידועים בטוקנים
גם עם הגנות חזקות על זהויות, הטוקנים עצמם מכניסים סיכונים מסוימים אם לא מנהלים אותם כראוי:
- גניבת טוקנים
תוקפים יכולים לגנוב טוקנים באמצעות נוזקה, חטיפת סשנים, מתקפות פישינג או פגיעויות בדפדפן.
- Token replay
אפשר להשתמש בטוקן גנוב כדי לגשת למשאבים מוגנים בלי צורך לבצע אימות מחדש.
- ניצול לרעה של Refresh Token
אם Refresh Token נפרץ, אפשר להשתמש בו כדי לשמר גישה לתקופות ארוכות, תוך עקיפת תפוגת הסשן הרגילה.
- היעדר מנגנוני ביטול
טוקנים תקפים לרוב עד לתפוגה, אלא אם נאכפים מנגנוני ביטול פעילים (כמו CAE).
שיטות עבודה מומלצות לניהול טוקנים
כדי לנהל טוקנים בצורה מאובטחת, ארגונים צריכים ליישם את השיטות הבאות:
- הגדירו מדיניות טוקנים ב-Conditional Access (CA):
חייבו אימות מחדש או רענון טוקן כשמופיעים אותות סיכון קריטיים (למשל שינויי מיקום, זיהויי סיכון).
- השתמשו באימות עמיד בפני פישינג:
יישמו שיטות חזקות כמו מפתחות אבטחה FIDO2 או Certificate-Based Authentication (CBA) כדי למזער את הסיכוי לגניבת טוקנים.
- הפעילו Continuous Access Evaluation (CAE):
CAE מאפשר לבטל טוקנים כמעט מיידית בהתבסס על אירועי סיכון כמו השבתת חשבון, שינויי סיסמה או ביטול סשנים.
- ניהול טווח חיים של טוקנים:
סקרו והתאימו את הגדרות טווח החיים של הטוקנים.
לאפליקציות רגישות או לתפקידים בעלי הרשאות מורחבות:
- הגדירו טווחי חיים קצרים יותר ל-Access Token (למשל 30 דקות).
- השתמשו בזהירות ב-max inactivity ובטווח חיים מוחלט של Refresh Token.
- ניהול התקנים וסשנים:
העדיפו להנפיק טוקנים רק להתקנים תואמים ומנוהלים, דרך Conditional Access.
נטרו את תקינות ההתקנים ואכפו אימות מחדש כשהתאימות משתנה.
דוגמה מעשית: הגדרת מדיניות טוקנים מאובטחת
מדיניות טווח חיים ל-Access Token (דוגמה):
New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"00:30:00"}}') `
-DisplayName "AccessToken30MinPolicy" `
-IsOrganizationDefault $false `
-Type "TokenLifetimePolicy"הפעלת Continuous Access Evaluation:
- CAE מופעל כברירת מחדל ב-tenants שנוצרו אחרי ינואר 2022.
- ב-tenants קיימים:
סקרו את מדיניות ה-Conditional Access וכללו אפליקציות ענן שתומכות ב-CAE (למשל Exchange Online, SharePoint Online, Teams).
הגדרת MFA עמיד בפני פישינג:
- אכפו רישום ל-MFA באמצעות מדיניות authentication strength.
- הגבילו את ה-MFA לשיטות שמסווגות כעמידות בפני פישינג (למשל FIDO2, Windows Hello for Business).
סיכום
הבנת היסודות של אופן הפעולה של Access Tokens, Refresh Tokens ו-ID Tokens היא הצעד הראשון לבניית סביבה עמידה שמאובטחת ברמת הטוקנים.
טוקנים שמנוהלים בצורה לא נכונה יכולים בקלות להפוך לדרך הכניסה של תוקף אל הארגון שלכם. אבל עם שיטות עבודה מומלצות כמו Conditional Access, CAE, אימות חזק וניהול הדוק של טווחי החיים, אפשר להפחית את הסיכון הזה משמעותית.
במאמר הבא (חלק 2) נצלול לעומק אל שיטות הגנה מתקדמות ואסטרטגיות יישום כדי לחזק עוד את אבטחת הטוקנים שלכם.
למידע נוסף על יסודות הטוקנים:
https://learn.microsoft.com/en-us/entra/identity/devices/concept-tokens-microsoft-entra-id
רוצים לדעת איפה הטננט שלכם עומד? Griffin31 בודק את הגדרות האבטחה של Microsoft 365 אצלכם באופן רציף ומראה מה לתקן קודם.