במסמך הזה מוצגות השוואות בין ארבעה דפוסי ארכיטקטורה לאיחוד עם ספק זהויות חיצוני (IdP). Google Cloudהוא גם מספק הנחיות שיעזרו לכם לבחור ארכיטקטורה מתאימה לתרחיש לדוגמה שלכם.
אלה ארבעת דפוסי הארכיטקטורה:
- איחוד ב-Cloud Identity או ב-Google Workspace
- איחוד שירותי אימות הזהות של כוח עבודה, ללא סנכרון
- איחוד שירותי אימות הזהות של כוח עבודה באמצעות SCIM
- איחוד שירותי אימות הזהות של כוח עבודה ו-Cloud Identity היברידי
גורמים שמשפיעים על ההחלטה
כדי לבחור דפוס ארכיטקטורה שמתאים לארגון שלכם, כדאי להביא בחשבון כמה גורמים, כולל:
- חבילת השירותים: חבילת שירותי Google שלכם, והאם היא כוללת את Google Workspace ושירותים נוספים מעבר ל-Google Cloud, כמו Google Ads, מפות Google או Chrome Enterprise.
- מיקום הנתונים: הדרישות שלכם לגבי מיקום הנתונים והריבונות עליהם.
- Gemini Enterprise בשילוב עם Microsoft 365: השימוש שלכם ב-Gemini Enterprise או ב-NotebookLM Enterprise, והאם אתם מתכננים לשלב את Gemini Enterprise עם שירותי Microsoft 365.
חבילת שירותים
שירותי Google מנהלים את האימות וההרשאה בצורה שונה. ההגדרה הזו משפיעה על האופן שבו מגדירים איחוד זהויות. שני גורמים קובעים את ההבדלים האלה: מודל השירות SaaS לעומת PaaS ו-IaaS, ומודל ההרשאות IAM לעומת מודל ספציפי לשירות.
מודלים של שירות
- תוכנה כשירות (SaaS): Google מנהלת באופן מלא שירותים כמו Gmail, Google Ads או אפליקציית Gemini Enterprise. השירותים האלה לא דורשים מאמצי פיתוח ומוכנים לשימוש. שירותי SaaS מיועדים לקהל רחב, ולכן יכול להיות שרוב המשתמשים שלכם יצטרכו גישה אליהם.
- פלטפורמה כשירות (PaaS) או תשתית כשירות (IaaS): רוב השירותים הם PaaS או IaaS.Google Cloud השירותים האלה מאפשרים למשתמשים טכניים לפתח, לפרוס ולהפעיל עומסי עבודה בהתאמה אישית. השירותים האלה מיועדים לקהל טכני, ולכן רק קבוצת משנה של המשתמשים שלכם צריכה גישה אליהם.
מודלים של הרשאות
שירותי Google מיישמים הרשאה באחת משתי דרכים:
- IAM: רוב השירותים של Google Cloud משתמשים ב-IAM כדי לאפשר לאדמינים לנהל גישה פרטנית למשאבים.
- הרשאה ספציפית לשירות: שירותים כמו Google Ads, Looker או Google Workspace לא משתמשים ב-IAM. במקום זאת, אדמינים מנהלים את הגישה באמצעות כלים שספציפיים לכל שירות.
הגורמים האלה מובילים לקבוצות השירות הבאות:
| SaaS | PaaS או IaaS | |
|---|---|---|
| הרשאה מבוססת-IAM | Google Cloud שירותי SaaS כמו אפליקציית Gemini Enterprise ו-NotebookLM Enterprise | Google Cloud שירותי PaaS ו-IaaS כמו BigQuery או Compute Engine |
| הרשאה ספציפית לשירות | שירותי Google שאינם מבוססי-ענן, כמו Google Ads, Google Workspace ומפות Google | ללא |
כדי לבחור דפוס ארכיטקטורה שמתאים לארגון שלכם, צריך להבין אילו קבוצות שירותים רלוונטיות לארגון.
מיקום הנתונים
מערכות Cloud Identity, Google Workspace ואיחוד שירותי אימות הזהות של כוח עבודה מעבדות מידע אישי של משתמשים כדי לאמת אותם ולנהל את הסשנים שלהם. פרטי המשתמשים האלה יכולים לכלול את הפרטים הבאים:
- שמות משתמשים או כתובות אימייל
- מאפייני משתמשים כמו שמות פרטיים ושמות משפחה
- שמות הקבוצות והחברות בהן
Cloud Identity, Google Workspace ואיחוד שירותי אימות הזהות של כוח העבודה מעבדים את הנתונים האלה בהתאם לתנאים של נתוני שירות, ויכול להיות שהם יישמרו מחוץ למיקומים של הארגון או של המשתמשים:
- Cloud Identity ו-Google Workspace מאחסנים נתוני שירות במרכזי הנתונים של Google, ויכול להיות שהם ישוכפלו בכל מרכזי הנתונים. הנתונים המאוחסנים עשויים לכלול מידע שלא חיוני לאימות, כמו שמות מחלקות, כתובות או מספרי טלפון.
- איחוד שירותי אימות הזהות של כוח העבודה מאחסן נתוני שירות באזוריGoogle Cloud ויכול לשכפל אותם בכל האזורים.
אם מעניקים למשתמש גישה למשאב, מערכת IAM מאחסנת את מזהה הישות שלו בקשירת תפקיד. Google Cloud מעבדת קשירות תפקידים בהתאם לתנאים של נתוני שירות, ועשויה לאחסן אותם בכל האזורים של Google Cloud .
הארכיטקטורות שמתוארות בדף הזה מחייבות אחסון של פרטי משתמשים, אבל הן שונות במשך הזמן שבו פרטי המשתמשים נשמרים:
- שירותי אימות הזהות של כוח העבודה ללא SCIM שומרים את פרטי המשתמש רק עד שתוקף הסשן של המשתמש פג.
- באיחוד שירותי אימות הזהות של כוח העבודה עם SCIM, פרטי המשתמש נשמרים עד שמוחקים את חשבון המשתמש או את הדייר, ועד שתקופת השמירה מסתיימת.
- ב-Cloud Identity וב-Google Workspace נשמרים פרטי המשתמשים עד למחיקת חשבון המשתמש ועד שחולפת תקופת השמירה.
הרבה ספקי זהויות מאפשרים לבצע אוטומציה של השעיה או מחיקה של חשבונות משתמשים כשהסטטוס של חשבון המשתמש התואם משתנה בספק הזהויות. יכול להיות שספק ה-IdP יעכב את מחיקת חשבון המשתמש עד שתסתיים תקופת החסד, וזה תלוי בספק ה-IdP ובהגדרות שלו. כך יכול להיות ש- Google Cloudיאחסן את פרטי המשתמש למשך זמן ארוך יותר.
שילוב של Gemini Enterprise עם Microsoft 365
Gemini Enterprise מאפשר לכם להתחבר לשירותי Microsoft 365 באמצעות שני סוגים של מחברים:
- מחברים שמבוססים על הטמעת נתונים: המחברים האלה סורקים את Microsoft 365 כדי ליצור אינדקס חיפוש ב- Google Cloud. כשמשתמש שולח הנחיה, Gemini Enterprise משתמש באינדקס הזה כדי לחפש תוכן, ומבצע בדיקות גישה באופן מקומי על ידי הערכה של רשימות בקרת הגישה (ACL) שהתקבלו מ-Microsoft 365.
- מחברים מאוחדים: המחברים האלה שולחים שאילתה ל-Microsoft 365 עבור כל הנחיה. הם משתמשים בהרשאה מוקצית כדי לאפשר ל-Microsoft 365 לבצע את בדיקות הגישה ישירות.
מחברים שמבוססים על הטמעה של נתונים מציגים דרישות ספציפיות לאיחוד משתמשים:
- הכרה בחברות בקבוצה: רשימות ACL ב-Microsoft 365 יכולות לכלול רשומות של קבוצות וגם של משתמשים. כדי להעריך אם למשתמש יש גישה לתוכן, מחברי הנתונים צריכים להתייחס לכל הקבוצות שהמשתמש שייך אליהן. אם המחבר מודע רק לחלק מקבוצות המשתמשים, יכול להיות שהוא יאפשר או יחסום גישה באופן שגוי.
- המרת מזהים: כדי להעריך את רשימות בקרת הגישה, המחבר צריך להמיר בין מזהי המשתמש והקבוצה שמשמשים את Microsoft 365 לבין המזהים שמשמשים את Google Cloud.
כשמשתמשים באיחוד שירותי אימות הזהות של כוח עבודה, Gemini Enterprise יכול להמיר מזהים ולהעריך רשימות ACL באופן מהימן אם מגדירים מיפויים של מאפיינים כך שיהיו תואמים ל-Gemini Enterprise.
כשמשתמשים באיחוד של Cloud Identity או Google Workspace, מערכת Microsoft Entra ID שולטת במיפוי המאפיינים של הקצאת הרשאות למשתמשים ולקבוצות, ולא Google Cloud. מערכת Entra קובעת את כללי ההמרה למזהים של משתמשים וקבוצות, שיכולים לכלול טרנספורמציות מורכבות. כדי להעריך ACL, מחבר Gemini Enterprise צריך להחיל את אותם כללי המרה, אבל למחבר אין גישה להגדרות של Entra. לכן, כשמשתמשים באיחוד של Cloud Identity או באיחוד של Google Workspace, Gemini Enterprise לא יכול להמיר בצורה מהימנה מזהים של משתמשים וקבוצות, ולא יכול להעריך בצורה מהימנה רשימות ACL.
כדי לקבוע איזה דפוס ארכיטקטורה מתאים לארגון שלכם, צריך להביא בחשבון את השימוש שלכם ב-Gemini Enterprise ואם אתם מתכננים להשתמש במחברים שמבוססים על העברת נתונים.
תבניות ארכיטקטורה
בתרשים הזרימה הבא מוצג האופן שבו הגורמים האלה קובעים איזה דפוס עונה על הדרישות של הארגון:
האם חלק משמעותי מהארגון שלכם משתמש ב-Google Workspace?
- אם התשובה היא כן, צריך להשתמש בדפוס האיחוד של Cloud Identity או Google Workspace.
- אם התשובה היא לא, עוברים להחלטה 2.
האם אתם משתמשים בשירותים נוספים מעבר ל- Google Cloud , כמו Google Ads או מפות Google?
- אם התשובה היא כן, עוברים להחלטה 3.
- אם התשובה היא לא, עוברים להחלטה 4.
האם אתם מתכננים להשתמש ב-Gemini Enterprise ולשלב אותו עם Microsoft 365?
- אם התשובה היא כן, צריך להשתמש בתבנית של איחוד שירותי אימות הזהות של כוח העבודה ושל זהויות בענן היברידי.
- אם התשובה היא לא, צריך להשתמש בדפוס האיחוד של Cloud Identity או Google Workspace.
האם אתם מתכננים להשתמש ב-Gemini Enterprise?
- אם התשובה היא כן, צריך להשתמש בתבנית של איחוד שירותי אימות הזהות של כוח העבודה עם SCIM.
- אם התשובה היא לא, עוברים להחלטה 5.
האם יש לך דרישות לגבי מיקום הנתונים שמחייבות אותך לצמצם את האחסון של פרטי המשתמשים?
- אם התשובה היא כן, צריך להשתמש בדפוס של איחוד שירותי אימות הזהות של כוח העבודה ללא סנכרון.
- אם התשובה היא לא, צריך להשתמש בדפוס האיחוד של Cloud Identity או Google Workspace.
איחוד של Cloud Identity או Google Workspace
בוחרים בדפוס הזה אם הארגון שלכם עומד באחד מהקריטריונים הבאים:
- חלק משמעותי מהארגון שלכם כבר משתמש ב-Google Workspace.
- אתם משתמשים בשירותי Google מעבר ל- Google Cloud כמו Google Ads או מפות Google, אבל אתם לא מתכננים לשלב את Gemini Enterprise עם Microsoft 365 באמצעות מחברים שמבוססים על הכנסת נתונים.
- אתם משתמשים רק בשירותים, לא מתכננים להשתמש ב-Gemini Enterprise ואין לכם דרישות מחמירות לגבי מיקום הנתונים כדי לצמצם את נפח האחסון של נתוני המשתמשים. Google Cloud
בדפוס הזה לא משתמשים באיחוד שירותי אימות הזהות של כוח העבודה. במקום זאת, אתם יכולים לבצע פדרציה של חשבון Cloud Identity או חשבון Google Workspace עם ספק הזהויות שלכם, ולהשתמש בהקצאת הרשאות למשתמשים ולקבוצות מראש.
בדפוס הזה, צריך להקצות משתמשים וקבוצות לפני שהמשתמשים יכולים להיכנס לחשבון. אחרת, ניסיון הכניסה שלהם ייכשל:
- הקצאת הרשאות: עוזרת להבטיח קליטה מהירה של משתמשים חדשים וביטול מהיר של הרשאות של משתמשים שעוזבים.
- הקצאת הרשאות לקבוצות: מאפשרת להשתמש בקבוצות כדי לנהל את הגישה לשירותי Google ולמשאבי Google Cloud Google.
אם רק חלק מהמשתמשים בארגון שלכם צריכים Google Workspace, תוכלו להוסיף לחשבון גם מינוי ל-Google Workspace וגם מינוי ל-Cloud Identity, ולהקצות רישיונות ל-Google Workspace רק למשתמשים שצריכים אותם.
יתרונות
- המשתמשים יכולים לבצע אימות לשירותי Google, בלי קשר לשאלה אם השירותים האלה משתמשים ב-IAM או לא. בחשבון Cloud Identity או בחשבון Google Workspace, קובעים באילו שירותי Google מותר למשתמשים להשתמש.
- אתם יכולים להגביל את הכניסה היחידה (SSO) ואת הקצאת ההרשאות מראש לקבוצת משנה של משתמשים, ולהמשיך לנהל משתמשים ספציפיים, כמו משתמשים עם גישת חירום, ישירות ב-Cloud Identity או ב-Google Workspace.
- אתם יכולים להקצות קבוצות מספק הזהויות החיצוני, לנהל קבוצות באופן מקומי בחשבון Cloud Identity או בחשבון Google Workspace, או לשלב בין שתי הגישות.
מגבלות
- הקצאת חשבונות משתמשים מראש מוסיפה עומס, והקצאה כזו עלולה להאט את תהליך ההצטרפות.
אי אפשר לשלוט במיקומים שבהם Cloud Identity או Google Workspace משתמשים כדי לאחסן נתוני משתמשים ונתוני קבוצות, או להגביל את המיקומים האלה. Google מעבדת ומאחסנת נתוני משתמשים ונתוני קבוצות בהתאם לתנאים של נתוני שירות, ולכן אמצעי הבקרה של האזור הגיאוגרפי לאחסון נתונים לא חלים על הנתונים האלה, ו-Google עשויה לשכפל את הנתונים האלה במיקומים של מרכזי נתונים של Google.
Gemini Enterprise מספק תמיכה מוגבלת בחיבור למקורות נתונים של מיקרוסופט כשמשתמשים באיחוד של Cloud Identity או באיחוד של Google Workspace.
איחוד שירותי אימות הזהות של כוח העבודה, ללא סנכרון
בוחרים בדפוס הזה אם הארגון עומד בקריטריונים הבאים:
- אתם משתמשים רק בשירותים Google Cloud .
- אתם משתמשים ב-Gemini Enterprise, אבל רוצים להישאר במסגרת המגבלות של הקבוצה שהוגדרו על ידי ספק הזהויות.
- יש לכם דרישות לגבי מיקום הנתונים שדורשות צמצום של אחסון מידע אישי של משתמשים.
בדפוס הזה, אתם משתמשים באיחוד שירותי אימות הזהות של כוח העבודה כדי לאחד אתGoogle Cloud הארגון שלכם עם ספק הזהויות החיצוני.
הדפוס הזה לא דורש הקצאת הרשאות למשתמשים או לקבוצות. בכל פעם שמשתמש נכנס לחשבון, ספק ה-IdP מעביר אל Google CloudGoogle Cloud את המידע הנדרש על המשתמש, כולל חברות בקבוצות ומאפיינים מותאמים אישית, ושומר את המידע הזה רק למשך סשן המשתמש.
יתרונות
- אין צורך לאחסן או לנהל חשבונות או קבוצות משתמשים ב-Google Cloud.
- התבנית מאפשרת לכם להשתמש במחברים מבוססי-הזנה כדי לשלב את Gemini Enterprise עם Microsoft 365.
מגבלות
- איחוד שירותי אימות הזהות של כוח עבודה הוא תכונה של IAM, והוא מאפשר למשתמשים לגשת רק לשירותים שמשתמשים ב-IAM. משתמשים שעוברים אימות באמצעות איחוד שירותי אימות הזהות של כוח עבודה לא יכולים לגשת לשירותי Google כמו Google Ads, Looker או Google Marketing Platform.
- משתמשים שמבצעים אימות באמצעות איחוד שירותי אימות הזהות של כוח העבודה לא יכולים לגשת לחלק מהתכונות Google Cloud . פרטים נוספים זמינים במאמר איחוד שירותי אימות הזהות: מוצרים ומגבלות.
- ספקי זהויות רבים מגבילים את מספר החברויות בקבוצות שהם יכולים להעביר לאיחוד שירותי אימות הזהות של כוח העבודה בטענת נכוֹנוּת ב-SAML או באסימון מזהה. כדי לא לחרוג מהמגבלות האלה, יכול להיות שתצטרכו לחזק את ניהול הקבוצות ולהגביל את סוגי הקבוצות שייכללו בהצהרות או באסימונים.
- כשמשתפים משאבים כמו מחברת NotebookLM Enterprise, אי אפשר לחפש קבוצה לפי שם. במקום זאת, המשתמשים צריכים להזין את המזהים שלהם באופן ידני.
אם אתם משתמשים ב-Microsoft Entra ID, אתם יכולים להשתמש בווריאציה של התבנית הזו על ידי הגדרת מאפיינים נוספים. כשמגדירים מאפיינים נוספים, איחוד שירותי אימות הזהות של כוח העבודה מבצע קריאה חוזרת ל-Microsoft Graph API במהלך אימות המשתמש כדי לאחזר את חברות בקבוצות. ההגדרה הזו מאפשרת לכם לעקוף את המגבלות של Entra על חברות בקבוצות עבור הצהרות SAML וטוקנים של מזהים, ולהשתמש בעד 999 חברויות בקבוצות לכל משתמש.
איחוד שירותי אימות הזהות של כוח העבודה באמצעות SCIM
בוחרים בדפוס הזה אם הארגון עומד בקריטריונים הבאים:
- אתם משתמשים רק בשירותים Google Cloud . כלומר, אתם לא משתמשים בשירותי Google חיצוניים כמו Google Ads או מפות Google.
- אתם מתכננים להשתמש ב-Gemini Enterprise או ב-NotebookLM Enterprise, ואתם צריכים לתמוך בעד 2,000 חברויות בקבוצות לכל משתמש, או ביכולת לחפש קבוצות לפי שם כשמשתפים משאבים.
בדפוס הזה, משתמשים באיחוד שירותי אימות הזהות של כוח העבודה כדי לאחד אתGoogle Cloud הארגון. כדי להגדיל את מספר הקבוצות שאפשר להשתמש בהן ב-Gemini Enterprise, צריך גם להגדיר את SCIM כדי להקצות מראש מידע על חברות בקבוצות.
יתרונות
- התבנית מאפשרת לכם להשתמש במחברים מבוססי-הזנה כדי לשלב את Gemini Enterprise עם Microsoft 365.
- אתם יכולים להשתמש בעד 2,000 חברויות בקבוצות לכל משתמש כדי לשלוט בגישה ל-Gemini Enterprise ול-NotebookLM Enterprise, ולאפשר למחברים מבוססי-הטמעה של נתונים ב-Gemini Enterprise לבצע בדיקות גישה.
- כשמשתפים מקורות מידע כמו מחברת ב-NotebookLM Enterprise, אפשר לחפש קבוצות לפי שם כדי לשפר את חוויית המשתמש הכוללת.
מגבלות
- התמיכה בקבוצות שהוקצו באמצעות SCIM מוגבלת ל-Gemini Enterprise ול-NotebookLM Enterprise. שירותים אחרים יכולים להשתמש רק בחברויות בקבוצות שה-IdP מעביר בטענת הנכונות של SAML או באסימון המזהה.
- איחוד שירותי אימות הזהות של כוח עבודה הוא תכונה של IAM, והוא מאפשר למשתמשים לגשת רק לשירותים שמשתמשים ב-IAM. משתמשים שעוברים אימות באמצעות איחוד שירותי אימות הזהות של כוח עבודה לא יכולים לגשת לשירותי Google כמו Google Ads, Looker או Google Marketing Platform.
- משתמשים שמאומתים באמצעות איחוד שירותי אימות הזהות של כוח העבודה לא יכולים לגשת לחלק מהתכונות של Google Cloud . פרטים נוספים זמינים במאמר איחוד זהויות: מוצרים ומגבלות.
Cloud Identity היברידי ואיחוד זהויות כוח עבודה
בוחרים בדפוס הזה אם הארגון עומד בקריטריונים הבאים:
- אתם משתמשים בשירותי Google מעבר ל- Google Cloud (כמו Google Ads או מפות Google).
- אתם מתכננים להשתמש ב-Gemini Enterprise ולשלב אותו עם Microsoft 365.
הדפוס הזה משלב שניים מהדפוסים הקודמים:
- אתם משתמשים באיחוד שירותי אימות הזהות של כוח העבודה (ללא סנכרון או עם SCIM) כדי לנהל את הגישה ל-Gemini Enterprise ול-NotebookLM Enterprise.
- אתם משתמשים באיחוד של Cloud Identity או Google Workspace כדי לנהל גישה לשירותים אחרים, כולל Google Cloud ושירותי Google שאינם בענן.
יתרונות
הדפוס הזה מאפשר לכם לשלב את היתרונות של שני הדפוסים הקודמים:
- אתם יכולים לקשר את Gemini Enterprise למקורות נתונים של מיקרוסופט ללא הגבלות על התכונות.
- המשתמשים יכולים לבצע אימות לשירותי Google, בלי קשר לשאלה אם השירותים האלה משתמשים ב-IAM או לא.
- שימוש בכל התכונות של Google Cloud
מגבלות
- אתם צריכים לשמור על שתי הגדרות נפרדות של צד נסמך ב-IdP החיצוני: אחת ל-Cloud Identity ואחת לאיחוד שירותי אימות הזהות של כוח עבודה.
- חוויית הכניסה של המשתמשים עשויה להיות שונה, בהתאם להגדרה שלהם לשימוש ב-Cloud Identity או באיחוד שירותי אימות הזהות של כוח העבודה.
- כשמנהלים מדיניות הרשאה ב-IAM, צריך להשתמש במזהים שונים של חשבונות משתמשים בהתאם לאופן שבו המשתמש מאומת. לדוגמה, משתמש שמופיע בתור
bob@example.comבספק הזהויות החיצוני שלכם יכול להיות בעל מזהה ראשיbob@example.comאוprincipal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_IDב-IAM, בהתאם לאופן שבו המשתמש מאומת – באמצעות איחוד זהויות ב-Cloud Identity או באמצעות איחוד שירותי אימות הזהות של כוח עבודה. - אי אפשר ליצור קבוצות שמכילות שילוב של משתמשי Cloud Identity וחשבונות משתמשים של איחוד שירותי אימות הזהות של כוח העבודה. קבוצות ב-Cloud Identity יכולות להכיל רק משתמשים ב-Cloud Identity, וקבוצות של איחוד שירותי אימות הזהות של כוח העבודה יכולות להכיל רק חשבונות משתמשים שמחוברים באמצעות איחוד שירותי אימות הזהות של כוח העבודה.
- כדי להשתמש באיחוד שירותי אימות הזהות של כוח העבודה גם בשירותים אחרים מלבד Gemini Enterprise, יכול להיות שהמשתמשים יצטרכו לעבור בין זהויות או שלא ידעו איך לבצע אימות.