סקירה כללית של זהות הסוכן

זהות הסוכן מספקת זהות קריפטוגרפית מאומתת לכל סוכן שמבוססת על תקן SPIFFE. בעזרת Agent Identity, הסוכן יכול לעבור אימות מאובטח לשרתי MCP, למשאבי ענן, לנקודות קצה ולסוכנים אחרים, ולפעול בשמו או בשם משתמש קצה. בשיטה 'זהות הסוכן' נעשה שימוש בפרטי הכניסה של הסוכן ובמנהל ההרשאות של זהות הסוכן. אפשר להשתמש במנהל ההרשאות כדי ליצור ולנהל ספקי אימות, שהם ההגדרות הספציפיות שמשמשות להשגת מפתחות API, מזהי לקוח של OAuth, סודות לקוח של OAuth ואסימוני OAuth של משתמשי קצה שהוקצו להם הרשאות, ולניהול ולאבטחה שלהם.

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

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

השירותים הבאים תומכים בזהות של סוכן:

מודלים של אימות

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

הרשות שיטת אימות המשאב שאליו תינתן גישה תרחיש שימוש ופתרון
הרשאה שהוקצתה למשתמש ‫OAuth 2.0 (תלת-רגלי) (תצוגה מקדימה) כלים ושירותים חיצוניים כשסוכן פועל בשם משתמש ספציפי (לדוגמה, כדי לגשת למשימות Jira או למאגרי GitHub של משתמש). אתם מגדירים ספק אימות OAuth תלת-רגלי במנהל האימות של זהויות סוכנים כדי לנהל את הסכמת המשתמשים ואת הטוקנים. מידע נוסף מופיע במאמר אימות באמצעות OAuth תלת-רגלי עם מנהל ההרשאות.
הסמכות של הסוכן זהות מבוססת-ענן (זהות הסוכן) Google Cloud שירותים כשסוכן שמארח ב- Google Cloud צריך לגשת לשירותים אחרים של Google Cloud באמצעות הזהות שלו. מידע נוסף זמין במאמר אימות באמצעות הזהות של הסוכן.
‫OAuth 2.0 (דו-רגלי) (תצוגה מקדימה) כלים ושירותים חיצוניים מומלץ לאימות בין מכונה למכונה עם שירותים חיצוניים שתומכים ב-OAuth. מגדירים ספק אימות OAuth דו-רגלי במנהל האימות של זהות הסוכן כדי לטפל בפרטי הכניסה של הלקוח ובטוקנים של הגישה. מידע נוסף זמין במאמר בנושא אימות באמצעות OAuth דו-רגלי עם מנהל אימות.
מפתח API (תצוגה מקדימה) כלים ושירותים חיצוניים לשירותים חיצוניים שנדרש בהם מפתח קריפטוגרפי או סיסמה לאימות. אתם מגדירים ספק אימות של מפתח API במנהל האימות של זהות הסוכן כדי לאחסן ולנהל את המפתחות בצורה מאובטחת. מידע נוסף זמין במאמר בנושא אימות באמצעות מפתח API עם auth manager.
אימות בסיסי של HTTP כלים ושירותים חיצוניים משתמש בסיסמאות בטקסט פשוט. לא מומלץ להשתמש בשיטה הזו. אפשר לאחסן סיסמאות באופן דומה למפתח API. מידע נוסף זמין במאמר אימות באמצעות מפתח API עם מנהל ההרשאות.

רכיבי ליבה

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

זהות מבוססת SPIFFE

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

הזהות היא בפורמט הבא:

spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

לדוגמה:

  • spiffe://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent

כשמשתמשים בזהות של סוכן במדיניות הרשאות ב-IAM, מזהה חשבון המשתמש הוא בפורמט הבא:

principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

דוגמאות:

  • ‫Vertex AI Agent Engine: principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • ‫Gemini Enterprise: principal://agents.global.org-123456789012.system.id.goog/resources/discoveryengine/projects/9876543210/locations/global/collections/default_collection/engines/my-test-agent

המזהים כוללים את הרכיבים הבאים:

  • ‫TRUST_DOMAIN: הדומיין המהימן של הארגון (לדוגמה, agents.global.org-123456789012.system.id.goog).
  • ‫SERVICE: השם המקוצר של שירות Google Cloud (לדוגמה, aiplatform או discoveryengine).
  • ‫RESOURCE_PATH: הנתיב המלא למשאב שמארח את הסוכן.

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

פרטי הכניסה של הסוכן

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

מנהל אימות הזהות של הסוכן

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

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

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

מידע נוסף זמין במאמר סקירה כללית על מנהל האימות של זהות הסוכן.

אבטחה וניהול

זהות הסוכן משולבת באופן מלא עם מערכות המדיניות של Google, כמו IAM,‏ Principal Access Boundary ‏ (PAB) ו-VPC Service Controls, שמאפשרות אבטחה וניהול משופרים. הוא גם משתלב עם יומני ביקורת כדי להבטיח אחריות ולספק יומני ביקורת ברורים גם כשהסוכן פועל בעצמו וגם כשהוא פועל בשם משתמש קצה.

  • בקרת גישה מבוססת-הקשר: כברירת מחדל, מדיניות של בקרת גישה מבוססת-הקשר שמנוהלת על ידי Google עוזרת לאבטח את פרטי הכניסה של זהות הסוכן. מעבר ל-Agent Gateway, המדיניות אוכפת הוכחה ניתנת להצגה של בעלות (DPoP) על ידי אימות אסימון הגישה של הסוכן. המדיניות גם מחייבת שימוש ב-mTLS כדי לגשת ל-Agent Gateway. כך אפשר לוודא שאפשר להשתמש בטוקנים שמשויכים לאישור רק בסביבת זמן הריצה המיועדת והמהימנה שלהם.
  • שילוב IAM: תמיכה במדיניות הרשאה ובמדיניות דחייה רגילות של IAM.
  • גבול גישה לחשבונות משתמשים (PAB): גבול גישה לחשבונות משתמשים מגביל את המשאבים שלסוכן יכולה להיות גישה אליהם, ללא קשר להרשאות אחרות.
  • ‫VPC Service Controls: תמיכה בשימוש בזהויות של סוכנים (בגרסת Preview) בכללים לתעבורת נתונים נכנסת ויוצאת כדי לאפשר גישה למשאבים שמוגנים על ידי גבולות גזרה לשירות.

איך פועלת הזהות של הסוכן

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

  1. הקצאת זהות: כשפורסים סוכן, Google Cloudמקצה לו זהות SPIFFE ייחודית ואישור X.509. כל אישור X.509 תקף למשך 24 שעות, והוא מתעדכן אוטומטית כדי לשמור על האבטחה. Google Cloud
  2. קבלת פרטי כניסה: השיטה שבה סוכנים משתמשים כדי לקבל פרטי כניסה תלויה בגישה שהם מנסים לקבל. הנה כמה דוגמאות:
    • גישה Google Cloud לשירותים: הסוכן מבקש אסימון גישה קשור. האסימון הזה קשור באופן קריפטוגרפי לאישור X.509 הייחודי של הסוכן, כדי למנוע גניבת אסימונים. מידע נוסף זמין במאמר בנושא אבטחה וממשל.
    • גישה לכלים חיצוניים: הסוכן משתמש במנהל האימות של זהות הסוכן כדי לאחזר את פרטי הכניסה הנדרשים (כמו מפתחות API או טוקנים מסוג OAuth) מספק אימות. כלי ניהול ההרשאות תומך גם בהרשאה שהוקצתה למשתמש וגם בהרשאה של הסוכן עצמו.

היתרונות של זהות הסוכן

זהות הסוכן משפרת את האבטחה בהשוואה לחשבונות שירות רגילים.

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

מגבלות

  • תפקידים מדור קודם בקטגוריות של Cloud Storage: אי אפשר להעניק זהויות של סוכנים תפקידים מדור קודם בקטגוריות (לדוגמה, storage.legacyBucketReader).

המאמרים הבאים