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

כדי לאכוף את בקרת הגישה למקורות נתונים ולאבטח את הנתונים ב-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 לכתובת האימייל של המשתמש באותיות קטנות, כי הקצאת הרישיונות תלוית אותיות רישיות. אל תמפו את google.subject למזהה האובייקט (GUID) של Microsoft Entra ID, כי זה גורם לשגיאות כניסה ל-403 ולצריכת רישיונות כפולה כשמקצים רישיונות מראש לפי אימייל.

  • ב-Microsoft Entra ID, הטוקנים לא כוללים מזהי קבוצות אם המשתמש שייך ליותר מ-150 קבוצות (SAML) או 200 קבוצות (OIDC). כדי למנוע שגיאות מסוג 403 Permission Denied, צריך להגביל את ההצהרות על קבוצות ב-Microsoft Entra ID לקבוצות שהוקצו לאפליקציה או להחיל מסנן קבוצות.

  • אם לארגון שלכם יש יותר ממזהה ייחודי אחד, אתם יכולים למפות את המאפיינים הארגוניים הייחודיים האלה באמצעות המאפיין 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) שרוצים לעדכן. למרות שמאגרי זהויות כוח העבודה ב-IAM הם global, האימות ב-Gemini Enterprise מוגדר לכל אזור בנפרד.

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

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

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

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

סוג ספק הזהויות תיאור
Google Identity
  • אם אתם משתמשים ב-Google Identity, מומלץ ליצור קבוצה ב-Google שכוללת את כל העובדים שמשתמשים באפליקציה.
  • אם אתם אדמינים ב-Google Workspace, אתם יכולים לכלול את כל המשתמשים בארגון בקבוצה ב-Google, לפי השלבים שמפורטים במאמר איך מצרפים את כל המשתמשים בארגון לקבוצה.
  • מקצים למשתמשים את התפקיד "משתמש ב-Gemini Enterprise" (roles/discoveryengine.agentspaceUser). למידע נוסף על הוספת התפקיד, קראו את המאמר מתן הרשאות למשתמשים.
ספק זהויות של צד שלישי
  • מקצים את התפקיד Gemini Enterprise User‏ (roles/discoveryengine.agentspaceUser) למשתמשים בגרסה הארגונית ולמשתמשים במאגר כוח העבודה בכללי מדיניות IAM, באחד מהפורמטים הבאים של ישויות מורשות:
    • כל המשתמשים במאגר (גישה בכמות גדולה): principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*
    • קבוצה ספציפית: principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
    • משתמש יחיד: principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/USER_EMAIL
    • התאמה של מאפיין מותאם אישית: principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/VALUE
    למידע נוסף על הוספת התפקיד, קראו את המאמר מתן הרשאות למשתמשים.
  • ‫Google ממליצה להגדיר הצהרות על קבוצות לזהויות של צד שלישי.

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

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

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

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

מה השלב הבא?