במסמך הזה מוצגות ארכיטקטורות אופייניות שאפשר להשתמש בהן כהפניה לניהול זהויות ארגוניות. שני עקרונות מרכזיים של ניהול זהויות ארגוניות הם:
מקור מהימן לזהויות, שהוא המערכת היחידה שבה אתם משתמשים כדי ליצור, לנהל ולמחוק זהויות של העובדים שלכם. יכול להיות שהזהויות שמנוהלות במערכת המקורית המוסמכת יועברו למערכות אחרות.
ספק זהויות (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 גם כ-IdP וגם כמקור סמכותי, כמו בתרשים הבא.
- אתם משתמשים ב-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 וכו').
- אתם לא צריכים לשלב את Google Workspace עם מערכת מידע לניהול משאבי אנוש (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 כ-IdP.
כדי להשתמש בדפוס הזה בגרסה שונה, אפשר גם להשתמש ב-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) ומקור סמכותי יש את היתרונות הבאים:
- אתם יכולים להפעיל כניסה יחידה לעובדים שלכם, שתפעל גם בשירותי 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 עם ספק זהויות חיצוני.