ניהול Session Controls בתשתית Azure AD

ניהול גישה של משתמשי קצה באמצעות תשתית Azure AD מאפשרת ניהול, אכיפה ובקרה של כל גישה ועל גבי Azure AD Conditional Access ניתן לאכוף תנאים וחוקים בכדי בכדי להגביל את תנועת המשתמש בגישה אל משאבים.

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

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

חשוב מכך הגדרות configurable token lifetime לא יהיו זמינות באוקטובר הקרוב ומי ישחליף אותו הוא conditional access authentication session.

סשנים, טוקנים והזדהות

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

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

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

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

Security Token – הבקשות Claims מגיעים לשירות או לאפליקציה דרך Security Tokens מוצפנים וחתומים מתוך issuing authority.

Issuing Authority – גורם מוסמך אשר מנפיק Security Tokens שמכילים Claims עבור המשתמש לפי פורמט ידוע מראש ועבור השירות או האפליקציה הספציפית.

Relaying Party – זוהי למעשה השירות או האפליקציה, והיא מסתמכת על הגורם Issuing authority לקבלת המידע על זהות המשתמש.

Security Token Service – בקצרה STS. גורם מוסמך שאליו עוברים פרטי ההזדהות של המשתמש ובנוסף השירות או האפליקציה סומכת גם כן, בכדי שתוכל לקבל ממנו את security tokens עם claims של אותו משתמש. צורך הענין STS הינו המימוש של Issuing authority.

SAML Token/JWT Token – הגורם המוסמך STS מנפיק security tokens בפורמטים שונים למשל SAML tokens אשר קיים בפורמט XML או JWT.

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

העיקרון מאחורי tokens נקרא TOFU (שהוא למעשה Trust On First Use), ובמקום לשלוח את מפתח הזיהוי בכל בקשה תוך כדי שאנחנו חשופים, נצמצם את החשיפה לתקשורת הראשונה.

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

ניהול Session Controls

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

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

ניהול הזדהויות לסשנים באמצעות Azure AD ובפרט Conditional Access מאפשר לבצע את הדרישות המתוארות מעלה וכן דרישות נוספות וע”י כך מתבצעת ניהול ושליטה של הזדהויות וסשנים.

בהתאם לכך ישנם אאפשרויות שונות ליישום כלל הדרישות על גבי Azure AD Conditional Access:

User sign-in frequency – האפשרות של User sign-in frequency מגדירה את משך הזמן שבו משתמש יכול להיות בסשן מול הענן ולפני שהוא מתבקש לבצע הזדהות חוזרת או נוספת.

כיום הדיפולט בגישה לשירותי הענן הוא 90 יום ובמידה ולא נעשה שינוי של המשתמש ברמת התקן קצה אותו סשן ילווה את המשתמש למשך 90 יום ובשילוב של Access Token ושל Refresh Token.

הגדרת User sign-in frequency היא פעולה פשוטה וניתנת לביצוע ע”י הפעולות וההגדרות הבאות:

מתוך פורל הניהול של Azure AD ניגש לאפשרויות של Conditional Access

לאחר מכן ניגש לתנאי מסוים ומשם לקטגוריה Access Control ולאחר מכן נבחר באפשרות User sign-in frequency

Persistence of browsing – האפשרות של Persistence מאפשרת למשתמש להישאר עם הסשן פתוח גם לאחר סגירה ופתיחה של האפליקציה או הדפדפן ולאורך זמן.

כיום הדיפולט עובד עם Persistence ומאפשר למשתמש לבחור האם להישאר עם סשן פתוח או להיפך, והביחרה נעשית לאחר הזדהות ועם השאלה של Stay Signed in.

הערה: בין אם ישנה הגדרה של Persistent browser session ניתן לשנות את הגדרת Stay Signed in מתוך אפשרות company branding

נחזור להגדרת Persistence of browsing ובכדי לאפשר או להגביל את המשתמש נבצע את הפעולות הבאות בממשק Azure AD ומתוך קטגורית Access Control, ולאחר מכן נבחר באפשרות Persistence of browsing ושם נוכל לבחור אפשרות של Allow או Never.

המלצות

• הגדרת User sign-in frequency מומלצת לביצוע על אפליקציות או גישה לנכסים רגישים ועל כלל המשתמשים
• הגדרת Persistence of browsing נחלקת לשניים וערך Never מומלצת לביצוע מתוך רשתות חיצוניות, ערך Allow לרשתות ארגוניות
• מומלץ להפריד את הגדרות Session עם תנאי נפרד מיתר התנאים האחרים
• הגדרת Persistence of browsing נדרשת לביצוע על כלל האפליקציות ולכן מומלץ לבצע בתנאי נפרד

מאמרים נוספים על Azure AD