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

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

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

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

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

‫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) ולהרשאות של מערכת המקור.

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

משתמשים שמקיימים אינטראקציה עם 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 משמש למיפוי מאפיינים, להקצאת רישיונות ולשיתוף תיקיות Notebook. מומלץ למפות את 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. במסוף Google Cloud , נכנסים לדף יומני ביקורת:

      נכנסים לדף Audit Logs.

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

    2. בוחרים פרויקט, תיקייה או ארגון שקיימים ב- Google Cloud .
    3. מפעילים את יומני הביקורת של הגישה לנתונים.
      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. בקטע Providers, לוחצים על Sign in URL של הספק ונכנסים למסוף Google Cloud כמשתמשים במאגר של כוח העבודה.

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

    1. נכנסים לדף Workforce Identity Pools:

      כניסה לדף Workforce Identity Pools

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

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

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

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

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

  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 קוראים לכל מסמך. כל חשבון משתמש נספר כקורא, ויכול להיות קבוצה או משתמש בודד.

  • אתם יכולים לבחור סוג אחד של ספק זהויות לכל מיקום (global,‏ us או eu) שנתמך ב-Gemini Enterprise. כשמשתמשים באיחוד שירותי אימות הזהות של כוח העבודה, צריך ליצור את מאגר הזהויות של כוח העבודה עצמו במיקום global (locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>), ואפשר לשייך אותו לכל מיקום נתמך של Gemini Enterprise.

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

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

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

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

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

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

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

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

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

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

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

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

    Gemini Enterprise

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

  3. לוחצים על הוספת ספק זהויות במיקום של Gemini Enterprise‏ (global,‏ us או eu) שרוצים לעדכן.

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

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

מתן הרשאות למשתמשים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • לפני שמשנים את ה-UPN או את כתובת האימייל של משתמש בספק הזהויות, צריך להודיע למשתמש ולבקש ממנו לשתף את כל הסוכנים הפרטיים או ה-notebooks שהוא רוצה לשמור.
  • מקצים רישיון ל-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 וטוקנים.

מה השלב הבא?