במסמך הזה מוצגות ארכיטקטורות אופייניות שאפשר להשתמש בהן כחומר עזר לניהול זהויות ארגוניות. שני העקרונות המרכזיים של ניהול זהויות בארגון הם:
מקור מוסמך לזהויות, שהוא המערכת היחידה שבה אתם משתמשים כדי ליצור, לנהל ולמחוק את הזהויות של העובדים שלכם. יכול להיות שהזהויות שמנוהלות במערכת המקור המהימנה יופצו למערכות אחרות.
ספק זהויות (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 לאימות רב-שלבי ולניהול מכשירים ניידים.
- אתם לא צריכים IdP נוסף, מה שיכול לחסוך לכם כסף.
מתי כדאי להשתמש בארכיטקטורה הזו
כדאי להשתמש ב-Google כספק זהויות וכמקור מוסמך בתרחישים הבאים:
- אתם כבר משתמשים ב-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 לאימות רב-שלבי ולניהול מכשירים ניידים.
- אתם לא צריכים IdP נוסף, מה שיכול לחסוך לכם כסף.
מתי כדאי להשתמש בארכיטקטורה הזו
כדאי להשתמש ב-Google כ-IdP עם HRIS כמקור מוסמך בתרחישים הבאים:
- יש לכם מערכת HRIS קיימת או מערכת אחרת שמשמשת כמקור המוסמך לזהויות.
- אתם כבר משתמשים ב-Google Workspace כפתרון לשיתוף פעולה ולפרודוקטיביות.
- אין תשתית מקומית קיימת או IdP שצריך לשלב או שרוצים להפריד מהנכסים ב-Google.
שימוש ב-IdP חיצוני
אם הארגון שלכם כבר משתמש ב-IdP כמו Active Directory, Microsoft Entra ID (לשעבר Azure AD), ForgeRock, Okta או Ping Identity, אתם יכולים לשלב את Google Cloud עם ה-IdP החיצוני הזה באמצעות איחוד.
באמצעות איחוד של חשבון Cloud Identity או Google Workspace עם IdP חיצוני, אתם יכולים לאפשר לעובדים להשתמש בזהות ובפרטי הכניסה הקיימים שלהם כדי להיכנס לשירותי 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 זמין במאמר הקצאת משתמשים וכניסה יחידה (SSO) ב-Okta.
חוויית המשתמש
כך נראית חוויית המשתמש של העובד בכניסה לחשבון:
- כשהעובד מבקש משאב מוגן, הוא מופנה למסך הכניסה באמצעות חשבון Google, שבו הוא מתבקש להזין את כתובת האימייל שלו.
- הכניסה באמצעות חשבון Google מפנה אתכם לדף הכניסה של ה-IDaaS.
- אתם מבצעים אימות באמצעות IDaaS. בהתאם ל-IDaaS, יכול להיות שתצטרכו לספק גורם שני, כמו קוד.
- אחרי האימות, תופנו בחזרה למשאב המוגן.
יתרונות
לשימוש ב-IDaaS חיצוני כספק זהויות וכמקור מוסמך יש את היתרונות הבאים:
- אתם מאפשרים לעובדים שלכם חוויית כניסה יחידה (SSO) שמתפרסת על פני שירותי 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 כספק הזהויות וכמקור המוסמך בתרחישים הבאים:
- יש לכם תשתית 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 כמקור מוסמך יש כמה יתרונות:
- אתם מאפשרים לעובדים שלכם חוויית כניסה יחידה (SSO) שמתפרסת על פני שירותי Google, Entra והסביבה המקומית שלכם.
- אם הגדרתם ב-Entra ID דרישה לאימות רב-שלבי, ההגדרה הזו חלה באופן אוטומטי על Google Cloud.
- אין צורך להתקין תוכנה נוספת באופן מקומי.
- אם אתם משתמשים בכמה דומיינים או קבוצות של דומיינים ב-Active Directory המקומי, והגדרתם תצורה מותאמת אישית של Entra ID Connect כדי למפות את המבנה הזה לדייר ב-Entra ID, אתם יכולים לנצל את היתרונות של השילוב הזה.
- אתם לא צריכים לסנכרן סיסמאות או פרטי כניסה אחרים עם Google.
- אתם יכולים להשתמש בגרסה החינמית של Cloud Identity.
- אפשר להציג את מסוף Google Cloud כמשבצת בפורטל של Office 365.
- ממשקי ה-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 לספק זהויות חיצוני.