הערה: חבילת המסמכים הזו מיועדת למהדורות Standard,‏ Plus,‏ תשלום לפי שימוש ו-Frontline של Gemini Enterprise. לעיון במסמכי התיעוד של מהדורת Business, אפשר להיכנס אל מרכז העזרה של Gemini Enterprise – מהדורת Business.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הגדרת ServiceNow

בדף הזה מוסבר איך להגדיר תצורה של צד שלישי לפני שיוצרים את מאגר הנתונים של ServiceNow.

דרישות מוקדמות

כדי להשלים את ההגדרה, צריך [אתר ServiceNow ל-Personal Developer Instance (PDI)]. המופע הזה מספק סביבה ייעודית להגדרת OAuth והרשאות.

כתובת ה-URL של המכונה: צריכה להיות לכם כתובת URL ספציפית לסביבה שלכם. לדוגמה, https://your-instance.service-now.com.
פרטי כניסה: צריכה להיות לכם הרשאת אדמין למכונה.

יצירת חשבון ServiceNow

אם עדיין אין לכם חשבון או PDI, בצעו את השלבים הבאים כדי להגדיר אותם:

כדי ליצור חשבון ServiceNow באתר המפתחים:
1. עוברים אל פורטל המפתחים של ServiceNow ולוחצים על כניסה.
2. לוחצים על משתמשים חדשים? מקבלים מזהה ServiceNow.
3. ממלאים את הפרטים ולוחצים על הרשמה. משתמשים בכתובת האימייל ומאמתים את החשבון באמצעות קישור האישור שנשלח לתיבת הדואר הנכנס.
כדי ליצור מופע מפתח אישי (PDI):
1. נכנסים לחשבון בפורטל המפתחים של ServiceNow באמצעות פרטי הכניסה לחשבון.
2. אחרי שנכנסים לחשבון, פועלים לפי ההנחיות בפורטל כדי לבקש מכונה. אחרי ההקצאה, תוצג תיבת דו-שיח לאישור: "Your instance is ready!‎".
3. שמירת פרטי הכניסה: כשהמכונה מוכנה, בפורטל מופיעים כתובת ה-URL של המכונה, שם המשתמש של האדמין והסיסמה של האדמין. שמרו את הפרטים האלה לשלבי ההגדרה הבאים.
4. כדי לגשת לסביבה החדשה, לוחצים על הכפתור Start Building (התחלת הפיתוח) בכותרת של אתר המפתחים. הפעולה הזו תפתח את המכונה בכרטיסייה חדשה.

ממשק ServiceNow Developer Instance — מכונה למפתחים

הגדרת התצורה

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

כדי לראות את שלבי ההגדרה של המחבר, בוחרים אותו מהתפריט הבא:

הגדרת OAuth למחבר מאוחד

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

כדי ליצור פרטי כניסה ב-OAuth למחבר מאוחד:

עוברים אל All > System OAuth > Application registry.
לוחצים על New (חדש) > Inbound integration experience (חוויית שילוב נכנסת) > New integration (שילוב חדש).
ממלאים את שדות החובה:
1. שם השילוב: מזינים שם ייחודי לפרטי הכניסה של OAuth, למשל "פעולות Gemini Enterprise OAuth".
2. פעיל: מסמנים את התיבה.
3. סוג grant: בוחרים באפשרות קוד הרשאה של OAuth.
4. כתובת URL להפניה אוטומטית: מזינים https://vertexaisearch.cloud.google.com/console/oauth/default_oauth.html,https://vertexaisearch.cloud.google.com/oauth-redirect
5. מדיניות הגישה להיקף ול-API: מוודאים שהתיבה Allow access only to APIs in selected scope לא מסומנת. בנוסף, אל תבחרו היקף הרשאות. אם משאירים את השדה הזה ריק, השילוב יהיה בהיקף רחב.
לוחצים על Submit כדי ליצור את פרטי הכניסה.
אחרי השליחה, לוחצים על שם הרשומה כדי לראות את מזהה הלקוח ולחשוף את סוד הלקוח. שמרו אותם לשימוש מאוחר יותר.

דרישות הגישה ל-Table API

כדי שה-LLM יוכל לאחזר תוצאות, למשתמשי הקצה צריך להיות תפקיד מערכת (בדרך כלל snc_internal או תפקיד REST בהתאמה אישית) שמאפשר להם לגשת לנקודות קצה ל-API של Table.

נקודת קצה (endpoint)	טבלת ServiceNow	הנתונים אוחזרו
`/api/now/table/incident`	אירוע	כרטיסי תמיכה, עדכוני סטטוס ופרטים על פתרון הבעיה.
`/api/now/table/sc_catalog`	קטלוג	הגדרות ומבנים של קטלוגי השירותים הזמינים.
`/api/now/table/sc_cat_item`	פריט בקטלוג	מוצרים או שירותים ספציפיים שאפשר לבקש.
`/api/now/table/sys_attachment`	הקובץ המצורף	מטא-נתונים של קבצים שמצורפים לרשומות (שמות קבצים, גדלים).
`/api/now/table/kb_knowledge`	ידע	מאמרים, נהלים ומדריכים לפתרון בעיות שפורסמו.

אבטחה ופרטיות נתונים: אימות משתמשי קצה

המחבר של ServiceNow משתמש בפרטי הכניסה של משתמשי הקצה כדי לבצע שאילתות באמצעות Table API. שימוש בפרטי הכניסה של משתמשי הקצה מבטיח שחוויית החיפוש תשמור על שוויון אבטחה קפדני של 1:1 עם ממשק המשתמש של ServiceNow.

מודל אבטחה

כששאילתה נשלחת ל-ServiceNow Table API, המחבר מריץ אותה בהקשר האבטחה של המשתמש המאומת:

זהות שווה: מכיוון שהמחבר משתמש בפרטי הכניסה של המשתמש, המערכת מתייחסת לבקשת ה-API כמו לשאילתה בשורת החיפוש הגלובלית של ServiceNow.
רשימות ACL שעוברות בירושה: מערכת ServiceNow בודקת את כל הרשימות של בקרת הגישה (ACL) ברמת מסד הנתונים. אם למשתמש אין הרשאת קריאה לרשומה, ה-Table API מחזיר תוצאה ריקה או שגיאה 403 עבור הרשומה הזו.
אכיפת קריטריונים של משתמשים: ServiceNow מחיל קריטריונים של משתמשים על פריטים של Knowledge (kb_knowledge) ו-Catalog (sc_cat_item). ה-API מסנן באופן אוטומטי פריטים שבהם המשתמש לא עומד בדרישות של "זמין עבור".

הגדרת OAuth למחבר הטמעה

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

קבלת פרטי כניסה לאימות

כדי ליצור פרטי כניסה ל-OAuth למחבר הטמעת נתונים באמצעות השילוב הנכנס, צריך ליצור שתי קבוצות של פרטי כניסה:

פרטי כניסה להטמעה: משתמשים בסוג ה-grant של פרטי הכניסה לסיסמה של בעלי המשאבים ב-OAuth.
פרטי כניסה של פעולות: משתמשים בסוג grant של Authorization Code Grant של OAuth.

1. יצירת פרטי כניסה להטמעה

נכנסים למכונה של PDI ServiceNow באמצעות פרטי הכניסה של האדמין.
עוברים אל All > System OAuth > Application registry.
לוחצים על חדש.
לוחצים על New inbound integration experience (חוויית שילוב נכנסת חדשה) > New integration (שילוב חדש) > OAuth resource owner password credential grant type (סוג grant של פרטי כניסה עם סיסמה של בעלי משאבים ב-OAuth).
ממלאים את שדות החובה:
1. שם: מזינים שם ייחודי.
2. שם הספק: מזינים את שם הספק.
3. פעיל: מסמנים את התיבה.
4. אבטחת היקף ההרשאות וה-API: מוודאים שהתיבה אפשר גישה רק לממשקי API בהיקף ההרשאות שנבחר לא מסומנת.
לוחצים על שליחה.
לוחצים על שם הרשומה כדי לראות את מזהה הלקוח ולחשוף את סוד הלקוח. שמרו אותם לשימוש מאוחר יותר.

2. יצירת פרטי כניסה ל-Actions

עוברים אל All (הכול) > System OAuth (מערכת OAuth) > Application registry (רישום אפליקציות) ולוחצים על New (חדש).
לוחצים על ממשק חדש לשילוב נתונים נכנסים > שילוב חדש.
ממלאים את שדות החובה:
1. שם השילוב: מזינים שם ייחודי לפרטי הכניסה של OAuth, למשל "פעולות Gemini Enterprise OAuth".
2. פעיל: מסמנים את התיבה.
3. סוג grant: בוחרים באפשרות קוד הרשאה של OAuth.
4. Redirect URL (כתובת URL להפניה אוטומטית): מזינים את https://vertexaisearch.cloud.google.com/oauth-redirect.
5. מדיניות הגישה להיקף ול-API: מוודאים שתיבת הסימון לא מסומנת ולא בוחרים היקף אימות.
לוחצים על Submit כדי ליצור את פרטי הכניסה.
לוחצים על שם הרשומה כדי לראות את מזהה הלקוח ולחשוף את סוד הלקוח. שמרו אותם לשימוש מאוחר יותר.

הגדרת חשבון משתמש והקצאת הרשאות אדמין

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

הקצאת תפקיד האדמין

כדי לשדרג את התפקיד שלכם ל-security_admin:

נכנסים למופע של ServiceNow כמשתמש עם תפקיד אדמין.
לוחצים על סמל הפרופיל ובוחרים באפשרות שדרוג התפקיד.
בוחרים באפשרות security_admin ולוחצים על Update.

כדי להעניק את security_admin למשתמש אחר:

בוחרים באפשרות All (הכול), ואז באפשרות Users (משתמשים) בקטע User Administration (ניהול משתמשים).
מאתרים את המשתמש שרוצים לשדרג את התפקיד שלו ובוחרים בו.
בכרטיסייה תפקידים, לוחצים על עריכה.
בוחרים באפשרות security_admin מתוך Collection ומוסיפים אותה ל-Roles List.

הערה: המשתמש עם התפקיד security_admin צריך ללחוץ על סמל הפרופיל שלו ולבחור באפשרות Elevate Role כדי להשתמש בו.

הגדרת תפקידים והרשאות של משתמשים

כדי ליצור מאגר נתונים של ServiceNow ב-Gemini Enterprise, צריך לתת למשתמשים את התפקידים וההרשאות המתאימים.

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

יצירת תפקיד בהתאמה אישית עם כללי ACL (מומלץ)
שימוש בתפקיד בהתאמה אישית עם אדמינים של ישויות
שימוש בתפקיד אדמין

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

יצירת תפקיד בהתאמה אישית עם כללי ACL (מומלץ)

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

עוברים אל All (הכול) > User administration (ניהול משתמשים) > Roles (תפקידים).
לוחצים על חדש, מזינים שם ולוחצים על שליחה.
עוברים אל System security (אבטחת מערכת) > Access control (ACL)‎ (בקרת גישה).
לוחצים על חדש כדי ליצור כלל ACL חדש.
חוזרים על השלבים הבאים עד שמעניקים גישה לכל הטבלאות הנדרשות:
1. אפשר להשתמש ב-sys_user_role כדוגמה כדי לראות איך ניתנת גישה לטבלה.
2. לוחצים על שליחה ובוחרים את התפקיד.

גישה נדרשת לטבלה

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

שם טבלה	תיאור
אירוע	הצגת אירועים בתוצאות החיפוש.
sc_cat_item	הצגת פריטים מהקטלוג בתוצאות החיפוש.
sc_cat_item_user_criteria_mtom	להציג משתמשים שיכולים לגשת לפריטים בקטלוג על סמך קריטריונים של משתמשים.
sc_cat_item_user_criteria_no_mtom	הצגת משתמשים שלא יכולים לגשת לפריטים בקטלוג על סמך קריטריונים של משתמשים.
sc_cat_item_user_mtom	להציג אילו משתמשים יכולים לגשת לפריטים בקטלוג.
sc_cat_item_user_no_mtom	הצגת משתמשים שלא יכולים לגשת לפריטים בקטלוג.
kb_knowledge	רשימת המאמרים במאגר המידע שיכולים להופיע בתוצאות החיפוש.
kb_knowledge_base	רשימת מאגרי הידע שיכולים להופיע בתוצאות החיפוש.
kb_uc_can_contribute_mtom	להציג מי יכול להוסיף תוכן למאגרי ידע על סמך קריטריונים של משתמשים.
kb_uc_can_read_mtom	להציג מי יכול לקרוא מאגרי ידע על סמך קריטריונים של משתמשים.
kb_uc_cannot_read_mtom	הצגת המשתמשים שלא יכולים לקרוא מאגרי ידע על סמך קריטריונים של משתמשים.
sys_user_role	רשימת התפקידים שאפשר להקצות למשתמשים.
sys_user_has_role	רשימת התפקידים שמוקצים למשתמשים.
sys_user_group	רשימה של פלחים של קבוצות משתמשים.
sys_user_grmember	רשימת החברים בקבוצות.
sys_user	רשימה של כל המשתמשים.
core_company	רשימה של כל מאפייני החברה.
cmn_location	רשימה של כל מאפייני המיקום.
cmn_department	רשימה של כל מאפייני המחלקה.
user_criteria	רשימה של רשומות קריטריונים של משתמשים.
sp_portal	קישור ל-URI של הפורטל בתוצאות החיפוש.
m2m_sp_portal_knowledge_base	קישור ל-URI של הפורטל למאמרי מידע בתוצאות החיפוש.
m2m_sp_portal_catalog	קישור ל-URI של הפורטל לפריטים בקטלוג בתוצאות החיפוש.

הענקת גישה ל-ACL ואימות שלה

המחבר דורש גישת ACL לשדות של פריטי הקטלוג בטבלה sc_cat_item.

כדי לתת גישה ולאמת אותה:

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

הזנת sc_cat_item.*
מוודאים שרשימות ה-ACL מעודכנות.
עוברים אל sys_security_acl_role_list.do בסרגל החיפוש.
מגדירים את Role לתפקיד שרוצים לאמת.

בחירת התפקיד לאימות
מוודאים שרשימות ה-ACL הנדרשות מוקצות לתפקיד.

שימוש בתפקיד בהתאמה אישית עם אדמינים של ישויות

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

עוברים אל הכול > אבטחת המערכת > משתמשים וקבוצות > תפקידים.
לוחצים על חדש ומזינים שם.
לוחצים על שליחה.
מוצאים את התפקיד שנוצר ברשימה.
עוברים אל מכיל תפקידים > עריכה.
מוסיפים את התפקידים הבאים לתפקיד החדש שנוצר ולוחצים על שמירה:
- catalog_admin
- knowledge_admin
- incident_manager
מוסיפים תפקידים ולוחצים על הכפתור "שמירה"
מאשרים את התפקידים המעודכנים.

אישור התפקידים

שימוש בתפקיד אדמין

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

עוברים אל All > User administration > Users.
יוצרים משתמש חדש.
מפעילים את האפשרות גישה לשירותי אינטרנט בלבד. כשבוחרים באפשרות Web service access only, יוצרים משתמש לא אינטראקטיבי.
- משתמשים אינטראקטיביים יכולים להתחבר לממשק המשתמש ולפורטל השירות של ServiceNow באמצעות פרטי כניסה רגילים או SSO, עם גישה מלאה לדפי ממשק המשתמש ולנקודות הקצה ל-API.
- למשתמשים לא אינטראקטיביים יש גישה מוגבלת לממשק המשתמש, והם יכולים רק לאשר חיבורים פרוגרמטיים ל-API לצורך שילוב בין שירותים.
אחרי שיוצרים את המשתמש, בוחרים אותו מרשימת המשתמשים.
לוחצים על תפקידים > עריכה.
מוסיפים אדמין.
לוחצים על שמירה כדי להוסיף למשתמש רשימה של תפקידים.
לוחצים על הגדרת סיסמה, יוצרים אותה באופן אוטומטי ושומרים אותה.

הקצאת תפקיד למשתמש

עוברים אל All > User administration > Users.
מחפשים משתמש או יוצרים משתמש חדש. אם אין משתמש זמין, עוברים אל System security (אבטחת מערכת) > Users and groups (משתמשים וקבוצות) > Users (משתמשים).
לוחצים על חדש.
יוצרים חשבון שירות חדש בטבלת המשתמשים. חשוב ללחוץ על גישה לשירותי אינטרנט בלבד.
גוללים אל תפקידים ולוחצים על עריכה.
מקצים את התפקיד שיצרתם למשתמש. בהתאם לסוג התפקיד שיצרתם בשלב הקודם, בוחרים את התפקיד המתאים ומקצים אותו למשתמש. לוחצים על Save.
צפייה בתפקיד בהתאמה אישית עם ACL.
מקבלים את שם המשתמש והסיסמה של המשתמש ולוחצים על הגדרת סיסמה.
יוצרים סיסמה שנוצרת אוטומטית ושומרים אותה לשימוש מאוחר יותר.

חשיפה של אירועים ובקרת גישה

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

כחלק מהגישה המגבילה הזו, המחבר לא מכבד הרשאות רחבות שמבוססות על תפקידים לגבי הרשאות הגישה לאירועים. תפקידים רגילים ב-ServiceNow, כמו itil ו-sn_incident_read, עשויים לתת למשתמש גישה לכל האירועים בממשק המשתמש של ServiceNow, אבל לא נותנים את אותה רמת גישה ב-Gemini Enterprise.

משתמשים עם אחד מהתפקידים הבאים יכולים לראות את כל האירועים:

admin
incident_manager
change_manager

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

בקבוצת ההקצאה של האירוע.
המתקשר שקשור לאירוע.
מקבל ההקצאה.
ברשימת צפייה.
ברשימת הערות העבודה.
ברשימה של מקבלי הקצאה נוספים.

כך משתמש ב-Gemini Enterprise לא יכול למצוא אירוע שאין לו גישה אליו. בגלל ההגבלות הנוספות בהשוואה להרשאות הרחבות יותר של ServiceNow, יכול להיות שלפעמים משתמש לא יוכל למצוא ב-Gemini Enterprise אירוע שיש לו גישה אליו ב-ServiceNow.