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

התכונה "זהות הסוכן" מספקת זהות קריפטוגרפית מאומתת לכל סוכן, שמבוססת על תקן 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:

• ‫Gemini Enterprise Agent Platform Runtime ‏(Agent Runtime)
• Gemini Enterprise
• Cloud Run

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

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

ארכיטקטורה של הקצאת זהויות

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

• זהות המשתמש: הזהות של משתמש הקצה שהתחיל את הפעולה, מאומתת באמצעות OAuth 2.0 או OpenID Connect (OIDC) סטנדרטי עם Google Identity או ספק זהויות (IdP) מאוחד של כוח עבודה.
• זהות הסוכן: זהות SPIFFE ייחודית ומאומתת קריפטוגרפית של הסוכן שנפרס, ואישור X.509 שהוקצה אוטומטית, שמייצגים את הסוכן שפועל בסמכותו.
• זהות מואצלת: הקשר הסמכות המשולב כשהנציג פועל בשם המשתמש האנושי שיזם את הפעולה, באמצעות פרטי כניסה של OAuth תלת-רגלי (3LO) בהיקף מוגדר, שמתווכים על ידי מנהל האימות של Agent Identity.

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

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

רכיבי ליבה

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

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

אישורי ה-X.509 האלה מקושרים לרשות אישורי בסיס (CA) שמנוהלת על ידי Google. אפשר לראות את אישורי ה-CA הציבוריים שמוגדרים כברירת מחדל בנקודות הקצה הבאות:

• כל האזורים: https://www.gstatic.com/gcp_default_ca_certs/default_ca_certs.pem (אישורי CA שמוגדרים כברירת מחדל לכל האזורים)
• לכל אזור: https://www.gstatic.com/gcp_default_ca_certs/REGION/public_cert.pem לאזור נתמך (לדוגמה, אישורי CA שמוגדרים כברירת מחדל ב-us-east1)

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

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

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

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

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

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

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

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

• בקרת גישה מבוססת-הקשר: כברירת מחדל, מדיניות בקרת גישה מבוססת-הקשר שמנוהלת על ידי Google עוזרת לאבטח את פרטי הכניסה של הנציג באמצעות אכיפה של mTLS וקישור אסימוני DPoP. הגישה הזו מבטיחה שלא ניתן יהיה להפעיל מחדש טוקנים שקשורים לאישורים מחוץ לסביבת זמן הריצה המהימנה שלהם.
• שילוב עם IAM: תמיכה בכללי מדיניות ההרשאה והדחייה הרגילים של IAM.
• ‫Principal Access Boundary (PAB): מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) מגבילה את המשאבים שהנציג יכול לגשת אליהם, בלי קשר להרשאות אחרות שיש לנציג. כללי המדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) שחלים על זהות הסוכן נבדקים כחלק מהשיחות היוצאות (egress). זהויות של נציגים שכפופות למדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) יכולות לגשת רק למשאבים שצוינו במדיניות הזו, כך שהנציג מבודד לחלוטין בגבולות שהוגדרו לו.
• thought VPC Service Controls: תמיכה בהגנה על היקף הרשת ובשימוש בחשבון ה-Principal:
  • הגנה על גבולות הגזרה: אתם יכולים להוסיף את 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 Access: הנציג מבקש טוקן גישה מקושר. האסימון הזה קשור באופן קריפטוגרפי לאישור X.509 הייחודי של הנציג, כדי למנוע גניבה של האסימון. למידע נוסף, קראו את המאמר אבטחה ופיקוח.
   • גישה לכלים חיצוניים: כדי לאמת ישירות לשירות חיצוני באמצעות הזהות שלו, הסוכן מבקש טוקן של מזהה מסוג OIDC. כדי לאחזר פרטי כניסה שמורים (כמו מפתחות API או אסימוני OAuth) מספק אימות, הנציג משתמש במנהל האימות של Agent Identity, שתומך גם בהרשאה שהוקצתה למשתמש וגם בהרשאה של הנציג עצמו.

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

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

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

מגבלות

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

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

• מידע נוסף על ארכיטקטורת הקצאת הזהויות

• מידע נוסף על שימוש בזהות הסוכן עם Agent Runtime

• מידע נוסף על ניהול נציגים