.jpg)
לאחרונה הוציאה Microsoft מספר יכולות חדשות לניהול ושליטה של טוקנים בשירות Azure AD, האפשרויות החדשות מאפשרות לנו לאכוף שליטה על משך הזמן שבו משתמש יכול להיות מחובר לשירות ולהגביל את פרק הזמן שהוא נדרש לבצע הזדהות חוזרת.
האפשרויות לניהול טוקנים וסשנים יכול להיעשות עם האפשרויות החדשות של 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
בסביבות שונות אנו נדרשים להתאים את הדרישות והתרחישים השונים של האבטחה, הדרישות משתנות בין ארגון לארגון אך העקרון שלהם זהה לפי תרחישים שונים כדוגמת:
• הגבלת גישה מתוך מכשירים לא מנוהלים
• גישה לנכסים רגישים תוך רשתות מסוימות
• גישה ע"י חשבונות בעלי הרשאות גבוהות
• גישה מבוססת אפליקציות מקומיות ואפליקציות ענן
• שילוב תנאי גישה בין אפליקציות, משתמשים, רשתות ודרכי כניסה
ניהול הזדהויות לסשנים באמצעות 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? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
לאחרונה הוציאה Microsoft מספר יכולות חדשות לניהול ושליטה של טוקנים בשירות Azure AD, האפשרויות החדשות מאפשרות לנו לאכוף שליטה על משך הזמן שבו משתמש יכול להיות מחובר לשירות ולהגביל את פרק הזמן שהוא נדרש לבצע הזדהות חוזרת.
האפשרויות לניהול טוקנים וסשנים יכול להיעשות עם האפשרויות החדשות של 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
בסביבות שונות אנו נדרשים להתאים את הדרישות והתרחישים השונים של האבטחה, הדרישות משתנות בין ארגון לארגון אך העקרון שלהם זהה לפי תרחישים שונים כדוגמת:
• הגבלת גישה מתוך מכשירים לא מנוהלים
• גישה לנכסים רגישים תוך רשתות מסוימות
• גישה ע"י חשבונות בעלי הרשאות גבוהות
• גישה מבוססת אפליקציות מקומיות ואפליקציות ענן
• שילוב תנאי גישה בין אפליקציות, משתמשים, רשתות ודרכי כניסה
ניהול הזדהויות לסשנים באמצעות 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? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר