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

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

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

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

סוג ספק הזהויות מתי משתמשים
Google Identity ספק הזהויות המומלץ ל-Gemini Enterprise הוא Google Identity.

‫Google Identity תומך ב:
  • כל מקורות הנתונים מאינטראקציה ישירה (First-Party) של Google שמשתמשים בהעברת נתונים או באיחוד נתונים. כשמתחברים למקורות נתונים של Google Workspace, צריך להשתמש ב-Google Identity.
  • כל מקורות הנתונים של צד שלישי שמשתמשים באיחוד נתונים, שבהם המשתמשים מבצעים אימות ישירות בשירות של הצד השלישי באמצעות OAuth.
  • כל מקורות הנתונים של צד שלישי שמשתמשים בהעברת נתונים, למעט מקורות נתונים של Microsoft 365, כמו SharePoint,‏ OneDrive או Outlook, שנדרשים להם Microsoft Entra ID ופדרציית זהויות של כוח העבודה.
לפני שמגדירים את Google Identity, צריך לקבוע את מאפיין המשתמש הייחודי שבו הארגון משתמש, שהוא בדרך כלל כתובת האימייל של המשתמש. אם למשתמשים יש יותר מכתובת אימייל אחת, צריך להוסיף כתובת אימייל חלופית.
ספק זהויות של צד שלישי אם אתם מחברים את Gemini Enterprise רק למקורות נתונים של צד שלישי, ואתם כבר משתמשים בספק זהויות של צד שלישי שתומך ב-OIDC או ב-SAML 2.0, כמו Microsoft Entra ID, ‏ Okta או AD FS, אתם יכולים להשתמש בGoogle Identity או באיחוד שירותי אימות הזהות של כוח העבודה. ‫Google ממליצה להשתמש ב-Google Identity בהגדרות חדשות. לקוחות קיימים שכבר משתמשים באיחוד שירותי אימות הזהות של כוח העבודה יכולים להמשיך להשתמש בו. מידע נוסף זמין במאמר איחוד שירותי אימות הזהות של כוח עבודה.

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

בקרת גישה למחברים של Google Workspace

כשמשתמשים בהארקה ובחיפוש של נתונים ארגוניים באמצעות מחברים של Google Workspace (כמו אנשים מ-Google Workspace או קבוצות Google), Gemini Enterprise מכבד באופן מלא את רשימות בקרת הגישה (ACL) וההרשאות של מערכת המקור.

עיקרון מרכזי: אין הסלמת הרשאות

משתמש שמתקשר עם Gemini Enterprise יכול רק לראות תשובות ולהצמיד אותן למידע שיש לו כבר הרשאה לגשת אליו ישירות באפליקציית המקור של Google Workspace. ‫Gemini Enterprise אף פעם לא עוקף את אמצעי בקרת הגישה למערכת המקורית או מעניק הרשאות נוספות.

  • אנשים מ-Google Workspace (ספרייה): תוצאות החיפוש וההארקה של המשתמשים מכבדות את הגדרות החשיפה של הספרייה בארגון. לדוגמה, אם הנראות של משתמש בספרייה של Google Workspace מוגבלת למחלקה או ליחידה הארגונית שלו, הוא יכול למצוא עמיתים רק בתוך המחלקה הזו באמצעות Gemini Enterprise. הם לא יכולים לראות פרופילים של עובדים במחלקות מוגבלות.

  • קבוצות Google: גילוי התוכן וההתבססות על נתונים מתבצעים בהתאם לחברות בקבוצה ולהגדרות הגישה. משתמש יכול לחפש ולראות תוכן רק מקבוצות Google שהוא חבר בהן ויש לו הרשאה לראות את התוכן. משתמשים שלא חברים בקבוצות פרטיות לא יכולים לראות את הדיונים בהן או למצוא אותם דרך Gemini Enterprise.

איפה מנהלים את ההרשאות

אתם לא מגדירים את הגדרות בקרת הגישה והחשיפה בהגדרות של מחבר Gemini Enterprise במסוף Google Cloud . במקום זאת, אדמין ב-Google Workspace מגדיר את ההרשאות, החברות והגדרות החשיפה במערכת המקור:

  • חשיפה של פרופיל המשתמש: אדמינים ב-Google Workspace מגדירים את החשיפה של פרופיל המשתמש במסוף Google Admin. מידע נוסף זמין במאמר בנושא הגדרה של שיתוף ספרייה.

  • גישה לקבוצות וחברות בהן: האדמין ב-Google Workspace מגדיר את הגישה לקבוצות ואת החברות בהן בקבוצות Google או במסוף Google Admin. מידע נוסף מופיע במאמר בנושא הגדרה וניהול של קבוצות.

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

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

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

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

ספק הזהויות משאבים
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 ‫
    בדוגמה הזו נעשה שימוש בטענת הנכונות של הנושא ב-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. מפעילים את יומני הביקורת Data Access.
      1. במסמכי התיעוד בנושא Logging מפורטים השלבים להפעלת יומני ביקורת.
      2. ב-Security Token Service API, בוחרים את סוג יומן הביקורת Admin Read. מידע נוסף זמין במאמר יומנים לדוגמה של איחוד שירותי אימות הזהות של כוח העבודה.

  2. מפעילים רישום מפורט ביומן במאגר כוח העבודה. התכונה 'קבוצות מורחבות' של איחוד שירותי אימות הזהות של כוח העבודה ב-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 Workspace יכולים לכלול את כל המשתמשים בארגון בקבוצת Google. כדי לעשות זאת, צריך לפעול לפי השלבים במאמר איך מצרפים את כל המשתמשים בארגון לקבוצה.
  • מקצים למשתמשים את התפקיד Gemini Enterprise User (roles/discoveryengine.agentspaceUser). מידע נוסף על הוספת התפקיד זמין במאמר מתן הרשאות למשתמשים.
ספק זהויות של צד שלישי

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

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

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

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

שינויים בזהות המשתמש

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

principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE

ההשפעה של שינוי ערך של נושא

אם הערך שממופה ל-google.subject משתנה אצל משתמש, Gemini Enterprise מתייחס למשתמש כמשתמש חדש. לדוגמה, זה קורה כששם המשתמש הראשי (UPN) או כתובת האימייל של המשתמש משתנים ב-Microsoft Entra ID, ומיפוי המאפיינים שלכם משתמש במאפיין הזה. המזהים של חשבונות המשתמשים הם תלויי-אותיות רישיות, ולכן שינוי באותיות הרישיות נחשב גם הוא לשינוי.

אחרי השינוי, התנאים הבאים חלים:

  • למשתמש אין גישה להיסטוריית הצ'אט, לנוטבוקים או לסוכנים שמשויכים למזהה החשבון הראשי הקודם.
  • ‫Gemini Enterprise לא מעביר נתונים מהמזהה הראשי הקודם למזהה הראשי החדש.
  • רישיונות ותפקידי IAM שניתנו למזהה החשבון הראשי הקודם לא חלים על מזהה החשבון הראשי החדש.

הכנה לשינוי ערך של נושא

כדי לצמצם את ההשפעה של שינוי ערך הנושא:

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

פתרון בעיות שקשורות לשגיאות אימות

אם המשתמשים מקבלים שגיאות HTTP 401 שמדווחות על פרטי כניסה לאימות לא תקינים כשהם ניגשים ל-Gemini Enterprise, כדאי לבדוק את הדברים הבאים.

בדיקות בסיסיות

  • מצב הדפדפן: מבקשים מהמשתמש למחוק את קובצי ה-Cookie ואת הנתונים ששמורים במטמון הדפדפן, או להיכנס לחשבון דרך חלון גלישה פרטית.
  • החשבון שאליו נכנסים: מוודאים שהמשתמש נכנס לחשבון שתצורת ספק הזהויות מצפה לו. אם אתם משתמשים באיחוד שירותי אימות הזהות של כוח העבודה, הזהות של המשתמש צריכה להתאים למיפוי המאפיינים שלכם.
  • השעון במכשיר: צריך לוודא שהשעון במכשיר מסונכרן, למשל באמצעות פרוטוקול Network Time Protocol ‏ (NTP). הבדלים בשעון במכשיר יכולים לגרום לכשל באימות.

מדיניות של ספק הזהויות ושל הרשת

  • שרתי Proxy וחומות אש: שרתי Proxy, חומות אש או שערים מאובטחים לאינטרנט שבודקים את תעבורת ה-TLS יכולים להסיר או לשנות את הכותרת Authorization. חשוב לוודא שהמכשירים האלה לא משנים בקשות לדומיינים של Google.
  • מדיניות גישה של ספק הזהויות: בודקים אם מדיניות הגישה בספק הזהויות, כמו מדיניות גישה מותנית ב-Microsoft Entra ID, חוסמת את הכניסה לחשבון בגלל תאימות המכשיר, טווחי כתובות IP או מיקום.
  • בקרת גישה מבוססת-הקשר: אם הארגון שלכם משתמש בבקרת גישה מבוססת-הקשר עם Google Cloud או עם Google Workspace, צריך לבדוק אם רמת גישה מבוססת-IP חוסמת את הבקשות ש-Gemini Enterprise שולח בשם המשתמש. הבקשות האלה מגיעות מהשרתים של Google ולא מהרשת של המשתמש, ולכן הן לא תואמות לטווחים של כתובות IP ארגוניות. מוסיפים רמת גישה שמאפשרת את מזהה הלקוח ב-OAuth 2.0 שמשמש את Gemini Enterprise, בשילוב עם רמת הגישה שמבוססת על כתובת IP, כתנאי OR. בקשות שנדחו מופיעות ביומני הביקורת של הארגון עבור contextawareaccess.googleapis.com.
  • פענוח DNS: מוודאים שפותר ה-DNS שלכם פועל בצורה תקינה כדי לפתור בעיות בדומיינים של Google, כולל *.google.com ו-*.googleapis.com.

איסוף נתוני אבחון

אם השגיאה נמשכת, צריך ליצור קובץ HAR (ארכיון HTTP) ויומני קונסולת הדפדפן בזמן שמשחזרים את השגיאה, ואז לפנות אל Cloud Customer Care. קובצי HAR עשויים להכיל מידע רגיש, כמו קובצי Cookie וטוקנים.

מה השלב הבא?