ניהול זהויות ויישום Azure PTA

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

  • תצורת Active Directory נוכחית
  • סוגי הזדהות
  • זהויות משתמשים
  • אפליקציות
  • התקני קצה
  • ניהול הרשאות
  • אוטומציה (Life Cycle)

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

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

  • תשתית ענן – משתמשים מוגדרים רק בשירות הענן ואינם נדרשים לבצע גישה והזדהות מול הסביבה המקומית
  • תשתית מקומיות – משתמשים מוגדרים רק בסביבה מקומית ונדרשים לבצע הזדהות וגישה רק מול הסביבה המקומית
  • תשתית היברידית – משתמשים מוגדרים בסביבה מקומית ומסנוכרנים לענן או לחלופין משתמשים מוגדרים רק בסביבה מקומית וצורכים שירות באמצעות הענן.

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

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

  • הזדהות מבוססת ענן – במצב זה משתמשים מזדהים ישירות מול הענן בלבד וללא גישה מול הסביבה המקומית, לרוב תתבצע הזדהות באמצעות מזהים רגילים בלבד
  • הזדהות מבוססת Azure AD – הזדהות אשר מבוססת על תשתית Azure AD Premium ומטרתה להרחיב את האפשרויות הקיימות באמצעות הזדהות חזקה, על גבי תנאים (Conditional Access), פרסום גישה מותנה וכן הלאה.
  • הזדהות מבוססת ADFS – מצב שבו ישנה תשתית היברידית ובו הזדהות עוברת מול שרתים מקומיים בלבד, כל השאילות מתבצעות ע"י המשתמש וברוב המקרים תשתית ADFS מיושמת בגלל היבטי אבטחת מידע
  • הזדהות מבוססת Azure PTA – תרחיש נוסף שבו הזדהויות מבוססות מול מנגנון מקומי אך הגישה נעשית מתוך הענן עצמו ולא מתוך המשתמש עצמו, כמו בתרחיש ADFS גם כאן הבחירה בתשתית Azure PTA היא על סמך היבטי אבטחת מידע
  • הזדהות מול תשתית זהויות צד שלישי (כדוגמת OneLogin) – הזדהות נעשית מול מגנון נוסף שאינו שייך ישירות לאותו ספק ענן והזדהות נעשית מול תשתית זהויות צד שלישי. במצבים כאלה הבחירה נעשית בגלל סיבות שונות שך היבטי אבטחת מידע, אפליקציות צד שלישי וכן הלאה.

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

ניהול זהויות באמצעות Azure PTA

מרבית הארגונים אשר נמצאים בענן עובדים בתצורה היברידית אשר מתבססת על Active Directory מקומי, לעומת זאת ישנם ארגונים אשר עובדים עם Directory מבוסס ענן בלבד אך מדובר על אחוז קטן מאוד.

אותם ארגונים שעובדים בתצורה היברידית על גבי Active Directory מבצעים סנכרון של אובייקטים מסוימים אל הענן, וכתוצאה מכך מבצעים סנכרון סיסמאות (ליתר דיוק Password HASH) של אותם אובייקטים המסוכרנים אל הענן.

בתוך אותם ארגונים אשר עובדים בתצורה היברידית מול הענן, ישנם גם ארגונים אשר עובדים עם הזדהות אחרת המבוססת על תשתית ADFS או על תשתית Azure PTA. מדובר על אחזו קטן מאוד מסך הארגונים שעובדים בתצורה היברידית.

מה הסיבה ליישום תשתית המבוססת על ADFS או על Azure PTA? ברוב המקרים מדובר על היבטי אבטחת מידע והצורך לבצע הזדהות מול תשתית Active Directory מקומית גם כאשר ניגשים לשירותי הענן השונים.

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

ליישום הזדהות מול מנגנון מקומי ישנם שתי תצורות:

  • תצורת ADFS – תצורה עם שרתים מקומיים שמבצעים פדרציה מול שירותי הענן, ולמעה כל גישה של משתמש מול הענן צריכה לעבור דרך שרתי ADFS ורק לאחר מכן השמתשמ מאומת מול הענן.
  • תצורת Azure PTA – כמו תצורת ADFS גם כאן הזדהות מתבצעת מול רכיבים מקומיים, אך בשונה מתצורת ADFS, חלק מהבקשות של המשתמש נעשות בין Azure PTA לבין הרכיב המקומי.

ניהול זהויות באמצעות Azure PTA

ניהול זהויות באמצעות Azure PTA מפשט את הפתררון של יישום זהויות מול מנגנון Active Directory מקומי בגלל הצורך ברכיבים (Pass-through authentication Agent) מקומיים שמבצעים את התקשורת מול שירות Azure AD.

אם אפשר לתאר בקצרה את Azure PTA אפשר לומר: מנגנון Azure PTA מאפשר ביצוע פרוקסי של האוטנטיקציה החיצונית מול שרתי Active Directory חד-כיווני ועל גבי SAML.

תהליך הלוגין של משתמש בתצורת Azure PTA נעשה באופן הבא:

  • משתמש חיצוני מבצע לוגין (בקשה ראשונית) מול שירות Office 365
  • הבקשה נשלחת מתוך Azure AD אל רכיב AAD Connect (על גבי Tunnel מתוך הסביבה המקומית בלבד)
  • רכיב AAD Connect מבצע תשאול ונותן תוקף לבקשה מול Active Directory מקומי
  • שרתי Active Directory מחזירים את הבקשה אל רכיב AAD Connect
  • רכיב AAD Connect מחזיר את הבקשה אל שירות Azure AD
  • שירות Azure AD מחזיר את הבקשה אל המשתמש ומאפשר לו לבצע לוגין

Pass-through Authentication

הקונקטור עובד באופן מוצפן ומאפשר גישה אך ורק מתוך הסביבה המקומית אל סביבת הענן ועל גבי פורט 443 בלבד, כאשר אותו קונקטור מבצע בקשה מול Azure AD הוא למעשה מבצע בקשה אקטיבית מול Azure AD ולכן בשונה מתצורת ADFS אנו לא נדרשים להכין תצורה עם תעודות דיגיטליות, שינוי פדרציה בענן, רשומות DNS ייעודיות וכן הלאה.

כאשר מתבצעת אוטנטיקציה בין הקונקטור (Pass-through authentication Agent) המקומי לבין שרת Active Directory מקומי ייעשה שימוש על גבי Kerberos ולכן נקבל חווית שימוש של SSO עם מחשבים המחוברים לדומיין. (גם כאשר מדובר על גישה חיצונית)

הגדרת Azure PTA נעשית על שרת AAD Connect או כל שרת אחר ולכן אם השרת אינו זמין לא תהיה אפשרות לבצע אוטנטיקציה ובתרחיש כזה ניתן להגדיר קונקטור נוסף בשרת אחר בכדי שנוכל לקבל שרידות מול Azure AD.

באיזה תרחישים Azure PTA יכול התאים לארגונים

תרחיש ויישום של Azure PTA יכול להיעשות במצבים מסוימים:

  • תשתית היברידית מבוססת Active Directory
  • תחליף ליישום תשתית ADFS
  • הקשחת הגישה מול Active Directory מקומי
  • ביצוע SSO מול תשתיות הארגון בגישה חיצונית
  • שילוב מול מנגוניים נוספים בענן כדוגמת Azure AD Conditional Access

דרישות להגדרת Azure PTA

כמו בכל תשתית גם בתצורת Azure PTA ישנם דרישות שונות ובכדי לעבוד עם Azure PTA יש לוודא את הדרישות הבאות:

  • שרת בגרסת Windows Server 2012 ומעלה
  • גרסת Azure AD Connect 1.1.371 ומעלה
  • גישה לטווחי כתובות ודומיינים מול Azure AD
  • תעבורת מול שירות Azure AD ללא SSL Inspection
  • מומלץ – שרת נוסף להתקנת רכיב Pass-through authentication Agent
  • מומלץ – אפליקציות מבוססות Modern Authentication
  • הגדרות Firewall עם הפורטים הבאים: 443, 9090, 9091, 9352, 5671, 10100-101200

התקנה והגדרת Azure PTA

התקנה והגדרת Azure PTA אינה תהליך מסובך ובכדי להתקין ולהגדיר Azure PTA יש לבצע את השלבים הבאים.

  • לוודא ולהכין דרישות סף (גרסאות שרתים, עדכוני AAD Connect וכן הלאה)
  • לוודא שאין הגדרת פדרציה נוספת, כדוגמת ADFS
  • שינוי תצורת הזדהות מתוך שרת AAD Connect לפי השלבים הבאים:

2018-12-01_19h08_392018-12-01_19h09_172018-12-01_19h09_392018-12-01_19h10_002018-12-01_19h10_132018-12-01_19h10_21

לאחר סיום הגדרות Azure PTA בשרת AAD Connect ניגש לפורטל Azure ונבצע בדיקה של הגדרת Pass-through authentication.

2018-12-01_19h21_282018-12-01_19h21_35
בסיום ביצוע הגדרות נוכל לבדוק את האופן שבו משתמשים מבצעים לוגין מול שירותי הענן. בנוסף לכך ניתן לבדוק רכיבים שהתווספו אל שרת AAD Connect מקומי, כגון:

  • אובייקט מסוג Computer שנקרא AZUREADSSOACC ומבצע אימות Kerberos
  • שירות service חדש שנקרא AzureADConnectAuthenticationAgent

לסיכום

בודדים הארגונים שעובדים עם תשתית זהויות מבוססת ADFS או Azure PTA, לכל אחד מהם ישנם יתרונות וחסרונות ומגבלות. באופן אישי מעדיף תשתית זהויות שמתבססת על תשתית זהויות בענן בלבד. למרות הכל ישנם מצבים בהם צריך ליישם Azure PTA, ולכן ישנם דגשים שונים ביישום שלמעשה הפך להיות פשוט.



:קטגוריותIdentity

תגים: , , ,

להשאיר תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת /  לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת /  לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת /  לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת /  לשנות )

מתחבר ל-%s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d בלוגרים אהבו את זה: