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

כדי לאכוף את בקרת הגישה למקורות נתונים ולאבטח את הנתונים ב-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) וההרשאות של מערכת המקור.

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

      כניסה לדף Audit Logs

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

  • אתם יכולים לבחור סוג אחד של ספק זהויות לכל מיקום שנתמך ב-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" (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 וטוקנים.

מה השלב הבא?