במסמך הזה מוצגות ארכיטקטורות אופייניות שאפשר להשתמש בהן כהפניה לניהול זהויות ארגוניות. שני עקרונות מרכזיים של ניהול זהויות ארגוניות הם:
מקור מהימן לזהויות, שהוא המערכת היחידה שבה אתם משתמשים כדי ליצור, לנהל ולמחוק זהויות של העובדים. יכול להיות שהזהויות שמנוהלות במערכת המקורית המוסמכת יועברו למערכות אחרות.
ספק זהויות (IdP) מרכזי שהוא המערכת היחידה לאימות, ומספק לעובדים חוויית כניסה יחידה (SSO) שמתפרסת על פני אפליקציות.
כשמשתמשים ב- Google Cloud או בשירותים אחרים של Google, צריך להחליט באיזו מערכת להשתמש כספק הזהויות ובאיזו מערכת להשתמש כמקור המוסמך.
שימוש ב-Google כספק זהויות (IdP)
אתם יכולים להשתמש ב-Cloud Identity Premium או ב-Google Workspace כדי להגדיר את Google כספק הזהויות הראשי שלכם. Google מספקת מבחר גדול של שילובים מוכנים לשימוש עבור אפליקציות פופולריות של צד שלישי, ואפשר להשתמש בפרוטוקולים סטנדרטיים כמו SAML, OAuth ו-OpenID Connect כדי לשלב את האפליקציות המותאמות אישית שלכם.
Google כ-IdP ומקור מידע מהימן
אתם יכולים להשתמש ב-Cloud Identity Premium או ב-Google Workspace גם כספק זהויות וגם כמקור סמכותי, כמו בתרשים הבא.
- אתם משתמשים ב-Cloud Identity Premium או ב-Google Workspace כדי לנהל משתמשים וקבוצות.
- כל השירותים של Google משתמשים ב-Cloud Identity Premium או ב-Google Workspace כספק הזהויות (IdP).
- אתם מגדירים אפליקציות ארגוניות ושירותי SaaS אחרים לשימוש ב-Google כספק הזהויות (IdP).
חוויית משתמש
בהגדרה הזו, חוויית הכניסה של העובד נראית כך:
- כשעובד מבקש משאב מוגן או גישה לאפליקציה ארגונית, הוא מופנה למסך הכניסה לחשבון Google, שבו הוא מתבקש להזין את כתובת האימייל והסיסמה שלו.
- אם האימות הדו-שלבי מופעל, העובד מתבקש לספק אמצעי אימות נוסף, כמו מפתח USB או קוד.
- אחרי שהעובד מאומת, הוא מופנה בחזרה למשאב המוגן.
יתרונות
לשימוש ב-Google כספק הזהויות וכמקור המוסמך יש את היתרונות הבאים:
- אתם יכולים ליהנות מכל היתרונות של התכונות אימות רב-שלבי וניהול מכשירים ניידים של Google.
- לא צריך ספק זהויות נוסף, מה שיכול לחסוך לכם כסף.
מתי כדאי להשתמש בארכיטקטורה הזו
כדאי להשתמש ב-Google כספק זהויות (IdP) וכמקור מהימן בתרחישים הבאים:
- אתם כבר משתמשים ב-Google Workspace כפתרון לשיתוף פעולה ולפרודוקטיביות.
- אין תשתית מקומית או ספק זהויות (IdP) שקיימים כבר ושצריך לשלב איתם, או שאתם רוצים להפריד אותם מכל המשאבים שלכם ב-Google (ב- Google Cloud, ב-Google Ads וכו').
- אתם לא צריכים לשלב את המערכת עם מערכת מידע לניהול משאבי אנוש (HRIS) כדי לנהל זהויות.
Google כספק זהויות (IdP) עם מערכת HRIS כמקור מוסמך
אם אתם משתמשים במערכת מידע לניהול משאבי אנוש (HRIS) כדי לנהל את תהליך הצירוף והסרת הגישה של העובדים, אתם עדיין יכולים להשתמש ב-Google כספק הזהויות (IdP). Cloud Identity ו-Google Workspace מספקים ממשקי API שמאפשרים למערכות HRIS ולמערכות אחרות לנהל את המשתמשים והקבוצות, כמו שמוצג בתרשים הבא.
- אתם משתמשים במערכת HRIS הקיימת כדי לנהל משתמשים וקבוצות (אופציונלי). מערכת ה-HRIS נשארת מקור המהימנות לניהול זהויות, והיא מקצה באופן אוטומטי משתמשים ל-Cloud Identity או ל-Google Workspace.
- כל השירותים של Google משתמשים ב-Cloud Identity Premium או ב-Google Workspace כספק הזהויות (IdP).
- אתם מגדירים אפליקציות ארגוניות ושירותי SaaS אחרים לשימוש ב-Google כספק הזהויות (IdP).
חוויית משתמש
עבור העובדים, חוויית המשתמש בכניסה שווה לשימוש ב-Google כספק זהויות (IdP) ומקור מהימן.
יתרונות
לשימוש ב-Google כספק זהויות (IdP) וכמקור סמכותי יש את היתרונות הבאים:
- כדי לצמצם את התקורה הניהולית, אתם יכולים להשתמש מחדש בתהליכי העבודה הקיימים של מערכת ה-HRIS.
- אתם יכולים ליהנות מכל היתרונות של התכונות אימות רב-שלבי וניהול מכשירים ניידים של Google.
- לא צריך ספק זהויות נוסף, מה שיכול לחסוך לכם כסף.
מתי כדאי להשתמש בארכיטקטורה הזו
כדאי להשתמש ב-Google כספק הזהויות (IdP) עם מערכת HRIS כמקור מהימן בתרחישים הבאים:
- יש לכם מערכת HRIS קיימת או מערכת אחרת שמשמשת כמקור מהימן לזהויות.
- אתם כבר משתמשים ב-Google Workspace כפתרון לשיתוף פעולה ולפרודוקטיביות.
- אין תשתית מקומית או ספק זהויות (IdP) שקיימים כבר ואתם צריכים לשלב איתם או שאתם רוצים להפריד אותם מהנכסים שלכם ב-Google.
שימוש ב-IdP חיצוני
אם הארגון שלכם כבר משתמש בספק זהויות כמו Active Directory, Microsoft Entra ID (לשעבר Azure AD), ForgeRock, Okta או Ping Identity, אתם יכולים לשלב Google Cloud את ספק הזהויות החיצוני הזה באמצעות איחוד.
איחוד חשבון Cloud Identity או Google Workspace עם ספק זהויות חיצוני מאפשר לעובדים להשתמש בזהות ובפרטי הכניסה הקיימים שלהם כדי להיכנס לשירותי Google כמו Google Cloud, Google Marketing Platform ו-Google Ads.
שימוש ב-IDaaS חיצוני כ-IdP וכמקור סמכותי
אם אתם משתמשים בספק זהויות כשירות (IDaaS) כמו ForgeRock, Okta או Ping Identity, אתם יכולים להגדיר איחוד שירותי אימות זהויות כמו שמוצג בתרשים הבא.
- Cloud Identity או Google Workspace משתמשים ב-IDaaS כספק הזהויות (IdP) לכניסה יחידה (SSO).
- פתרון ה-IDaaS מקצה אוטומטית משתמשים וקבוצות ל-Cloud Identity או ל-Google Workspace.
- אפליקציות ארגוניות קיימות ושירותי SaaS אחרים יכולים להמשיך להשתמש ב-IDaaS שלכם כספק זהויות (IdP).
מידע נוסף על איחוד של Cloud Identity או Google Workspace עם Okta, אפשר למצוא במאמר הקצאת הרשאות למשתמשים ב-Okta וכניסה יחידה (SSO).
חוויית משתמש
כך נראית חוויית המשתמש של העובד בכניסה:
- כשעובד מבקש משאב מוגן, הוא מופנה למסך הכניסה של Google, שבו הוא מתבקש להזין את כתובת האימייל שלו.
- הכניסה באמצעות חשבון Google מפנה אתכם לדף הכניסה של IDaaS.
- אתם עוברים אימות באמצעות IDaaS. יכול להיות שתצטרכו לספק גורם אימות נוסף, כמו קוד, בהתאם ל-IDaaS.
- אחרי האימות, המערכת מפנה אתכם בחזרה למשאב המוגן.
היתרונות
לשימוש ב-IDaaS חיצוני בתור ספק זהויות ומקור מהימן יש את היתרונות הבאים:
- אתם יכולים לאפשר לעובדים שלכם להיכנס לחשבון פעם אחת ולקבל גישה לכל שירותי Google ולאפליקציות אחרות שמשולבות עם פלטפורמת ה-IDaaS שלכם.
- אם הגדרתם את IDaaS כך שידרוש אימות רב-שלבי, ההגדרה הזו חלה אוטומטית על Google Cloud.
- אין צורך לסנכרן סיסמאות או פרטי כניסה אחרים עם Google.
- אפשר להשתמש בגרסה החינמית של Cloud Identity.
מתי כדאי להשתמש בארכיטקטורה הזו
כדאי להשתמש ב-IDaaS חיצוני כספק זהויות (IdP) וכמקור מהימן בתרחישים הבאים:
- אתם כבר משתמשים בספק IDaaS כמו ForgeRock, Okta או Ping Identity בתור ספק הזהויות שלכם.
שיטות מומלצות
שיטות מומלצות לאיחוד Google Cloud עם ספק זהויות חיצוני
Active Directory כספק IdP ומקור סמכותי
אם אתם משתמשים ב-Active Directory כמקור האמת לניהול זהויות, אתם יכולים להגדיר איחוד כמו שמוצג בתרשים הבא.
- אתם משתמשים ב-Google Cloud Directory Sync (GCDS) כדי להקצות הרשאות למשתמשים ולקבוצות מ-Active Directory באופן אוטומטי עבור Cloud Identity או Google Workspace. Google Cloud Directory Sync הוא כלי חינמי ש-Google מספקת, שמבצע את תהליך הסנכרון. אפשר להריץ אותו ב Google Cloud או בסביבה המקומית שלכם. הסנכרון הוא חד-כיווני כדי ש-Active Directory יישאר המקור הקובע.
- Cloud Identity או Google Workspace משתמשים ב-Active Directory Federation Services (AD FS) לכניסה יחידה (SSO).
- אפליקציות ארגוניות קיימות ושירותי SaaS אחרים יכולים להמשיך להשתמש ב-AD FS כספק זהויות.
כדי להשתמש בווריאציה של התבנית הזו, אפשר גם להשתמש ב-Active Directory Lightweight Directory Services (AD LDS) או בספריית LDAP אחרת עם AD FS או עם ספק IdP אחר שתואם ל-SAML.
מידע נוסף על הגישה הזו זמין במאמר בנושא איחוד Google Cloud עם Active Directory.
חוויית משתמש
- כשעובד מבקש לגשת למשאב המוגן, הוא מופנה למסך הכניסה לחשבון Google, שבו הוא מתבקש להזין את כתובת האימייל שלו.
- הכניסה באמצעות חשבון Google מפנה את העובד לדף הכניסה של AD FS.
- בהתאם להגדרות של AD FS, יכול להיות שיוצג לעובד מסך כניסה שבו הוא יתבקש להזין את שם המשתמש והסיסמה שלו ב-Active Directory. לחלופין, יכול להיות שמערכת AD FS תנסה להכניס את העובד באופן אוטומטי על סמך פרטי הכניסה שלו ל-Windows.
- אחרי ש-AD FS מאמת את העובד, הוא מופנה בחזרה למשאב המוגן.
יתרונות
לשימוש ב-Active Directory כספק זהויות (IdP) ומקור סמכותי יש את היתרונות הבאים:
- אתם מאפשרים לעובדים ליהנות מחוויה של כניסה יחידה (SSO) לשירותי Google ולסביבה המקומית שלכם.
- אם הגדרתם ב-AD FS אימות רב-שלבי, ההגדרה הזו חלה באופן אוטומטי על Google Cloud.
- אין צורך לסנכרן סיסמאות או פרטי כניסה אחרים עם Google.
- אפשר להשתמש בגרסה החינמית של Cloud Identity.
- ממשקי ה-API שבהם משתמש GCDS נגישים לכולם, ולכן אין צורך להגדיר קישוריות היברידית בין הרשת המקומית לבין Google Cloud.
מתי כדאי להשתמש בארכיטקטורה הזו
כדאי להשתמש ב-Active Directory כספק הזהויות (IdP) וכמקור המוסמך בתרחישים הבאים:
- יש לכם תשתית קיימת של Active Directory.
- אתם רוצים לספק חוויית כניסה חלקה למשתמשי Windows.
שיטות מומלצות
שיטות מומלצות שכדאי ליישם:
- ל-Active Directory ול-Cloud Identity יש מבנה לוגי שונה. חשוב להבין את ההבדלים ולבחור את השיטה הכי מתאימה למיפוי הדומיינים, הזהויות והקבוצות במצב שלכם. מידע נוסף זמין במדריך שלנו בנושא איחוד Google Cloud עם Active Directory.
- סנכרון קבוצות בנוסף למשתמשים. בגישה הזו, אתם יכולים להגדיר את IAM כך שתוכלו להשתמש בחברות בקבוצות ב-Active Directory כדי לקבוע למי יש גישה למשאבים ב-Google Cloud.
- פורסים את AD FS כך שמשתמשים בארגון יוכלו לגשת אליו, אבל לא חושפים אותו יותר מהנדרש. למרות שמשתמשים ארגוניים צריכים להיות מסוגלים לגשת ל-AD FS, אין דרישה שיהיה אפשר להגיע ל-AD FS מ-Cloud Identity או מ-Google Workspace, או מכל אפליקציה שנפרסה ב- Google Cloud.
- כדאי להפעיל את אימות Windows משולב (IWA) ב-AD FS כדי לאפשר למשתמשים להיכנס אוטומטית על סמך פרטי הכניסה שלהם ל-Windows.
- אם AD FS לא יהיה זמין, יכול להיות שהמשתמשים לא יוכלו להשתמש במסוףGoogle Cloud או בכל משאב אחר שמשתמש ב-Google כספק IdP. לכן חשוב לוודא ש-AD FS ובקרי הדומיין ש-AD FS מסתמך עליהם נפרסו וגודלם מתאים ליעדי הזמינות שלכם.
אם אתם משתמשים ב- Google Cloud כדי להבטיח את המשכיות העסקית, הסתמכות על AD FS מקומי עלולה לפגוע במטרה של שימוש ב-Google Cloud כעותק עצמאי של הפריסה שלכם. במקרה כזה, כדאי לפרוס רפליקות של כל המערכות הרלוונטיות ב- Google Cloudבאחת מהדרכים הבאות:
- הרחבת הדומיין הקיים של Active Directory אל Google Cloud ופריסת GCDS להפעלה ב-Google Cloud.
- הפעלת שרתי AD FS ייעודיים ב- Google Cloud. השרתים האלה משתמשים בבקרי הדומיין של Active Directory שפועלים ב-Google Cloud.
- מגדירים את Cloud Identity כך שישתמש בשרתי AD FS שנפרסו ב- Google Cloud לכניסה יחידה (SSO).
למידע נוסף, תוכלו לקרוא את השיטות המומלצות לאיחוד Google Cloud עם ספק זהויות חיצוני.
שימוש ב-Entra ID כספק זהויות (IdP) עם Active Directory כמקור מהימן
אם אתם לקוחות של Microsoft 365 או Azure, יכול להיות שחיברתם את Active Directory המקומי ל-Entra ID. אם כל חשבונות המשתמשים שאולי יזדקקו לגישה ל- Google Cloud כבר מסונכרנים עם Entra ID, אפשר לעשות שימוש חוזר בשילוב הזה על ידי איחוד של Cloud Identity עם Entra ID, כמו שמוצג בתרשים הבא.
- אתם משתמשים ב-Entra ID כדי להקצות הרשאות למשתמשים ולקבוצות באופן אוטומטי ב-Cloud Identity או ב-Google Workspace. יכול להיות ש-Entra ID עצמו משולב עם Active Directory מקומי.
- Cloud Identity או Google Workspace משתמשים ב-Entra ID לכניסה יחידה (SSO).
- אפליקציות ארגוניות קיימות ושירותי SaaS אחרים יכולים להמשיך להשתמש ב-Entra ID כספק זהויות (IdP).
למידע מפורט יותר על הגישה הזו, אפשר לקרוא את המאמר בנושא איחוד Google Cloud עם Microsoft Entra ID.
חוויית משתמש
- כשעובד מבקש גישה למשאב המוגן, הוא מופנה למסך הכניסה לחשבון Google, שבו הוא מתבקש להזין את כתובת האימייל שלו.
- הכניסה באמצעות חשבון Google מפנה אותם לדף הכניסה של AD FS.
- בהתאם לאופן שבו Active Directory המקומי שלהם מחובר ל-Entra ID, יכול להיות ש-Entra ID יבקש מהם שם משתמש וסיסמה, או שהוא יפנה אותם ל-AD FS מקומי.
- אחרי שהעובד עובר אימות באמצעות Entra ID, הוא מופנה בחזרה למשאב המוגן.
היתרונות
יש כמה יתרונות לשימוש ב-Entra ID כספק הזהויות (IdP) עם Active Directory כמקור מהימן:
- אתם יכולים להפעיל כניסה יחידה לעובדים שלכם, שתהיה תקפה לשירותי Google, ל-Entra ולסביבה המקומית שלכם.
- אם הגדרתם ב-Entra ID אימות רב-שלבי, ההגדרה הזו חלה באופן אוטומטי על Google Cloud.
- אין צורך להתקין תוכנה נוספת בפריסה המקומית.
- אם Active Directory המקומי שלכם משתמש בכמה דומיינים או יערות, והגדרתם הגדרה מותאמת אישית של Entra ID Connect כדי למפות את המבנה הזה לדייר Entra ID, תוכלו להשתמש בשילוב הזה.
- אין צורך לסנכרן סיסמאות או פרטי כניסה אחרים עם Google.
- אפשר להשתמש בגרסה החינמית של Cloud Identity.
- אפשר להציג את המסוף כאריח בפורטל של Office 365. Google Cloud
- ממשקי ה-API שבהם נעשה שימוש ב-Entra ID נגישים לציבור, ולכן אין צורך להגדיר קישוריות היברידית בין Entra לבין Google Cloud.
מתי כדאי להשתמש בארכיטקטורה הזו
כדאי להשתמש ב-Entra ID כספק זהויות (IdP) עם Active Directory כמקור מהימן בתרחישים הבאים:
- אתם כבר משתמשים ב-Entra ID ושילבתם אותו עם תשתית קיימת של Active Directory.
- אתם רוצים לספק למשתמשים חוויית כניסה חלקה ב-Entra וב- Google Cloud.
שיטות מומלצות
כדאי לפעול לפי השיטות המומלצות הבאות:
- מכיוון ש-Entra ID ו-Cloud Identity משתמשים במבנה לוגי שונה, חשוב להבין את ההבדלים. כדאי להעריך איזו שיטה למיפוי דומיינים, זהויות וקבוצות מתאימה למצב שלכם. מידע מפורט יותר זמין במאמר בנושא איחוד Google Cloud עם Microsoft Entra ID.
- סנכרון קבוצות בנוסף למשתמשים. בגישה הזו, אתם יכולים להגדיר את IAM כך שתוכלו להשתמש בחברות בקבוצות ב-Entra ID כדי לשלוט בגישה למשאבים ב-Google Cloud.
- אם אתם משתמשים ב- Google Cloud כדי להבטיח את המשכיות העסקית, הסתמכות על Entra ID לאימות עלולה לפגוע במטרה של השימוש ב-Google Cloud כעותק עצמאי של הפריסה.
למידע נוסף, תוכלו לקרוא את השיטות המומלצות לאיחוד Google Cloud עם ספק זהויות חיצוני.
המאמרים הבאים
- מידע נוסף על איחוד עם Active Directory
- איך מגדירים איחוד עם Entra ID
- מומלץ לעיין בשיטות המומלצות לתכנון חשבונות וארגונים ובשיטות המומלצות לאיחוד Google Cloud עם ספק זהויות חיצוני.