הגדרת ספק הזהויות

כדי לאכוף את בקרת הגישה למקורות נתונים ולאבטח את הנתונים ב-Gemini Enterprise, צריך להגדיר ספק זהויות. הפעולה הזו כוללת הגדרה של ספק הזהויות וניהול הרשאות למקורות הנתונים. ‫Google משתמשת בספק הזהויות כדי לזהות את משתמש הקצה שמבצע חיפוש ולקבוע אם יש לו גישה למסמכים שמוחזרים כתוצאות.

בחירת סוג ספק הזהויות

סוג ספק הזהויות שתבחרו תלוי במקורות הנתונים שמחוברים לאפליקציית Gemini Enterprise. Gemini Enterprise תומך באפשרויות הבאות:

סוג ספק הזהויות מתי משתמשים
Google Identity כשמקשרים את Gemini Enterprise למקורות נתונים של Google Workspace, צריך להשתמש ב-Google Identity.

לפני שמגדירים את זהות Google, צריך לקבוע את מאפיין המשתמש הייחודי שבו הארגון משתמש, בדרך כלל כתובת האימייל של המשתמש. אם למשתמשים יש יותר מכתובת אימייל אחת, צריך להוסיף כתובת אימייל חלופית.
ספק זהויות של צד שלישי אם אתם מחברים את Gemini Enterprise רק למקורות נתונים של צד שלישי, ואתם כבר משתמשים בספק זהויות של צד שלישי שתומך ב-OIDC או ב-SAML 2.0, כמו Microsoft Entra ID,‏ Active Directory Federation Services ‏ (AD FS),‏ Okta ואחרים, אתם צריכים להשתמש באיחוד שירותי אימות הזהות של כוח העבודה. מידע נוסף זמין במאמר איחוד שירותי אימות הזהות של כוח עבודה.

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

איחוד שירותי אימות הזהות של כוח העבודה לספקי זהויות של צד שלישי

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

הגדרת איחוד שירותי אימות הזהויות של כוח העבודה

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

ספק הזהויות משאבים
Entra ID
‫Okta
OIDC או SAML 2.0

הגדרת מיפוי מאפיינים

מיפוי מאפיינים עוזר לכם לקשר את פרטי הזהות של הצד השלישי עם Google באמצעות איחוד שירותי אימות הזהות של כוח עבודה.

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

  • המאפיין google.subject משמש למיפוי מאפיינים, להקצאת רישיונות ולשיתוף נוטבוקים. מומלץ למפות את google.subject לכתובת האימייל של המשתמש באותיות קטנות, כי הקצאת רישיונות היא תלוית-רישיות.

  • אם לארגון שלכם יש יותר ממזהה ייחודי אחד, צריך למפות את המאפיינים הארגוניים הייחודיים האלה באמצעות המאפיין attribute.as_user_identifier_number between 1 and 50.

    לדוגמה, אם הארגון שלכם משתמש גם באימייל וגם בשם העיקרי כמזהי משתמשים באפליקציות שונות, והשם העיקרי מוגדר כ-preferred_username בספק הזהויות של צד שלישי, אתם יכולים למפות אותו ל-Gemini Enterprise באמצעות מיפוי מאפיינים של איחוד שירותי אימות הזהות של כוח העבודה (לדוגמה, attribute.as_user_identifier_1=assertion.preferred_username).

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

  • Entra ID עם פרוטוקול OIDC
    בדוגמה הזו נעשה שימוש בכתובת האימייל כדי לזהות משתמשים באופן ייחודי.

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups
google.display_name=assertion.given_name

  • ‫Entra ID עם פרוטוקול SAML
    בדוגמה הזו נעשה שימוש בכתובת האימייל כדי לזהות משתמשים באופן ייחודי.

    google.subject=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'][0].lowerAscii()
google.groups=assertion.attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/groups']
google.display_name=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname'][0]

  • ‫Okta עם פרוטוקול OIDC
    בדוגמה הזו נעשה שימוש בכתובת האימייל כדי לזהות משתמשים באופן ייחודי.

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups

  • ‫Okta עם פרוטוקול SAML
    בדוגמה הזו נעשה שימוש בטענת הנכונות (assertion) של הנושא ב-JWT כדי לזהות משתמשים באופן ייחודי.

    google.subject=assertion.subject.lowerAscii()
google.groups=assertion.attributes['groups']

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

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

  1. מפעילים יומני ביקורת עבור Security Token Service API של פעילות הגישה לנתונים.

    1. נכנסים לדף Audit Logs במסוף Google Cloud :

      עוברים אל יומני ביקורת

      אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שמופיע בה הכותרת המשנית IAM & Admin.

    2. בוחרים פרויקט, תיקייה או ארגון קיימים ב- Google Cloud .
    3. מפעילים את יומני הביקורת של גישה לנתונים.
      1. במסמכי התיעוד בנושא Logging מפורטים השלבים להפעלת יומני ביקורת.
      2. ב-Security Token Service API, בוחרים את סוג יומן הביקורת Admin Read. מידע נוסף זמין במאמר יומנים לדוגמה של איחוד שירותי אימות הזהות של כוח העבודה.

  2. מפעילים רישום מפורט ביומן במאגר כוח העבודה. התכונה 'קבוצות מורחבות' של Workforce Identity Federation ב-Microsoft Entra ID לא יוצרת מידע מפורט של רישום ביומני הביקורת.

    1. עוברים לדף Workforce Identity Pools:

      כניסה לדף Workforce Identity Pools

    2. בטבלה, בוחרים את המאגר.

    3. לוחצים על המתג Enable detailed audit logging (הפעלת רישום מפורט ביומן ביקורת) כדי להפעיל אותו.

    4. לוחצים על שמירת המאגר.

  3. בקטע ספקים, לוחצים על כתובת ה-URL לכניסה של הספק ונכנסים למסוף Google Cloud כמשתמשים במאגר זהויות של כוח העבודה.

  4. תוכלו לראות את יומני הביקורת שנוצרו כשנכנסתם לחשבון.

    1. עוברים לדף Workforce Identity Pools:

      כניסה לדף Workforce Identity Pools

    2. בטבלה, בוחרים את מאגר הכתובות שאליו נרשמתם.

    3. לוחצים על הצגה לצד יומנים.

    4. בדף יומן הביקורת, מסירים את המסנן protoPayload.resourceName מהשאילתה.

    5. לוחצים על Run query.

  5. בודקים ביומני הביקורת אם יש רשומה עם google.identity.sts.SecurityTokenService.WebSignInmethod שתואמת לחותמת הזמן של הכניסה לחשבון.

  6. מוודאים שהשדה metadata.mapped_attributes ביומן תואם למאפיין שבו השתמשתם כשקבעתם את ההגדרה של איחוד שירותי אימות הזהות של כוח עבודה עבור ספקי זהויות של צד שלישי.

    לדוגמה:

    "metadata": {
  "mapped_attributes": {
    "attributes.as_user_identifier_1": "alex@admin.altostrat.com"
    "google.subject": "alex@altostrat.com"
    "google.groups": "[123abc-456d, efg-h789-ijk]"
  }
},

מגבלות

כשמשתמשים במחבר כדי לקשר את מקורות הנתונים וליצור מאגרי נתונים, חלות המגבלות הבאות:

  • אפשר להוסיף עד 3,000 קוראים לכל מסמך. כל חשבון משתמש נספר כקורא, כאשר חשבון משתמש יכול להיות קבוצה או משתמש בודד.

  • אפשר לבחור סוג אחד של ספק זהויות לכל מיקום שנתמך ב-Gemini Enterprise.

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

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

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

התחברות לספק הזהויות

בקטע הבא מוסבר איך להתחבר לספק הזהויות באמצעות מסוףGoogle Cloud .

לפני שמתחילים

לפני שמקשרים את ספק הזהויות, צריך:

  • מתן הרשאות לאדמינים

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

חיבור ספק זהויות

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

  1. נכנסים לדף Gemini Enterprise במסוף Google Cloud .

    ‫Gemini Enterprise

  2. לוחצים על הגדרות > אימות.

  3. לוחצים על הוספת ספק זהויות למיקום שרוצים לעדכן.

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

  5. לוחצים על שמירת השינויים.

הענקת הרשאות למשתמשים

כדי לגשת לאפליקציות, לנהל אותן ולשתף אותן, המשתמשים צריכים את התפקיד 'משתמש ב-Gemini Enterprise' (roles/discoveryengine.agentspaceUser).

סוג ספק הזהויות תיאור
Google Identity
  • אם אתם משתמשים ב-Google Identity, ‏ Google ממליצה ליצור קבוצת Google שכוללת את כל העובדים שמשתמשים באפליקציה.
  • אדמינים של Google Workspace יכולים להוסיף את כל המשתמשים בארגון לקבוצת Google. כדי לעשות זאת, צריך לפעול לפי השלבים במאמר הוספת כל המשתמשים בארגון לקבוצה.
  • מקצים למשתמשים את התפקיד Gemini Enterprise User (roles/discoveryengine.agentspaceUser). מידע נוסף על הוספת התפקיד זמין במאמר מתן הרשאות למשתמשים.
ספק זהויות של צד שלישי
  • מקצים למשתמשים את התפקיד Gemini Enterprise User ‏ (roles/discoveryengine.agentspaceUser) ולמשתמשים במאגר כוח העבודה בכללי מדיניות IAM. מידע נוסף על הוספת התפקיד זמין במאמר מתן הרשאות למשתמשים.
  • ‫Google ממליצה להגדיר טענות לגבי קבוצות עבור הזהויות של הצד השלישי.

השפעה של שינויים בהגדרות של ספק הזהויות על מחברי הטמעה

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

בטבלה הבאה מפורט אילו שינויים בהגדרות הזהות מחייבים יצירה מחדש של מאגר הנתונים:

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

מה השלב הבא?