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

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

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

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

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

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

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

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

הרשות שיטת אימות המשאב שאליו תינתן גישה תרחיש שימוש ופתרון
הרשאה שהועברה למשתמש ‫OAuth 2.0 (תלת-רגלי) כלים ושירותים חיצוניים כשסוכן פועל בשם משתמש ספציפי (לדוגמה, כדי לגשת למשימות Jira או למאגרי GitHub של משתמש). מגדירים ספק אימות OAuth תלת-רגלי במנהל האימות של Agent Identity כדי לנהל את הסכמת המשתמשים ואת הטוקנים. מידע נוסף מופיע במאמר אימות באמצעות OAuth תלת-רגלי עם מנהל ההרשאות.
הסמכות של הסוכן עצמו זהות מבוססת-ענן (Agent Identity) שירותיGoogle Cloud כשסוכן שמארח ב- Google Cloud צריך לגשת לשירותים אחרים של Google Cloud באמצעות הזהות שלו. מידע נוסף זמין במאמר אימות ל- Google Cloud באמצעות הזהות של הסוכן.
זהות מבוססת-ענן (אסימונים מזהים של OIDC) כלים ושירותים חיצוניים כשסוכן שמתארח ב- Google Cloud צריך לבצע אימות לשרתי קצה עורפיים חיצוניים, לממשקי API בהתאמה אישית או לפלטפורמות ענן של צד שלישי באמצעות הזהות שלו ואיחוד הזהויות של OpenID Connect‏ (OIDC). מידע נוסף זמין במאמר בנושא אימות לשירותים חיצוניים באמצעות הזהות של הסוכן.
‫OAuth 2.0 (דו-רגלי) כלים ושירותים חיצוניים מומלץ לאימות בין מכונות עם שירותים חיצוניים שתומכים ב-OAuth. מגדירים ספק אימות OAuth עם 2 רגליים במנהל האימות של Agent Identity כדי לטפל בפרטי הכניסה של הלקוח ובטוקנים של הגישה. מידע נוסף זמין במאמר בנושא אימות באמצעות OAuth דו-רגלי עם מנהל אימות.
מפתח API כלים ושירותים חיצוניים לשירותים חיצוניים שנדרש בהם מפתח קריפטוגרפי או סיסמה לצורך אימות. אתם מגדירים ספק אימות של מפתח API במנהל האימות של Agent Identity כדי לאחסן ולנהל את המפתחות בצורה מאובטחת. מידע נוסף זמין במאמר בנושא אימות באמצעות מפתח 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
  • ‫Vertex AI Agent Engine (פרויקט ללא ארגון): principal://agents.global.proj-9876543210.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: מתחם האמון (trust domain) של היררכיית המשאבים:
    • לפרויקטים בארגון: agents.global.org-ORGANIZATION_ID.system.id.goog
    • בפרויקטים ללא ארגון: agents.global.proj-PROJECT_NUMBER.system.id.goog
  • ‫SERVICE: השם המקוצר של שירות Google Cloud (לדוגמה, aiplatform או discoveryengine).
  • ‫RESOURCE_PATH: הנתיב המלא למשאב שמארח את הסוכן.

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

מחזור החיים של זהויות והרשאות

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

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

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

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

כברירת מחדל, זהויות של סוכנים משתמשות ב-TLS הדדי (mTLS) עם אישורי X.509 כשהן מתקשרות ישירות עם Google Cloud ממשקי API. כשסוכנים מבצעים אינטראקציה דרך Agent Gateway, הם גם משתמשים ב-DPoP (הוכחת בעלות), ויוצרים פרטי כניסה עם הצפנה כפולה לאבטחה מקצה לקצה. המשמעות של הקישור הכפול הזה היא שהסוכנים מאומתים באמצעות mTLS לגישה של צד ראשון לשער, ומשתמשים ב-DPoP לאינטראקציות מעבר לשער.

מנהל האימות של Agent Identity

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

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

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

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

אבטחה ומשילות

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

  • בקרת גישה מבוססת-הקשר: כברירת מחדל, מדיניות בקרת גישה מבוססת-הקשר שמנוהלת על ידי Google עוזרת לאבטח אישורים של סוכנים על ידי אכיפה של mTLS וקישור של אסימון DPoP. הגישה הזו מבטיחה שלא ניתן להפעיל מחדש טוקנים שקשורים לאישור מחוץ לסביבת זמן הריצה המהימנה שלהם.
  • שילוב IAM: תמיכה במדיניות הרשאה ובמדיניות דחייה רגילות של IAM.
  • גבולות גישה לישויות מורשות (PAB): גבולות גישה לישויות מורשות מגבילים את המשאבים שלסוכן יכולה להיות גישה אליהם, ללא קשר להרשאות אחרות.
  • ‫VPC Service Controls: תמיכה בהגנה על היקף השימוש ובשימוש של בעלי הרשאות:
    • הגנה על היקף האבטחה: אפשר להוסיף את Agent Identity API‏ (agentidentity.googleapis.com) ואת Agent Identity Credentials API‏ (agentidentitycredentials.googleapis.com) לגבולות גזרה לשירות כדי לשלוט בגישה לממשקי ה-API האלה. כדי להשתמש בממשקי ה-API האלה בתוך גבולות גזרה לשירות, הלקוחות צריכים לנתב בקשות דרך ה-VIP המוגבל (restricted.googleapis.com).
    • כללים לתעבורת נתונים נכנסת ויוצאת: תמיכה בשימוש בזהויות של סוכנים כגורמים ראשיים בכללים לתעבורת נתונים נכנסת ויוצאת כדי לאפשר גישה למשאבים שמוגנים על ידי גבולות גזרה לשירות.

איך פועל אימות הזהות של נציגים

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

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

היתרונות של Agent Identity

Agent Identity משפר את האבטחה בהשוואה לחשבונות שירות רגילים.

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

מגבלות

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

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