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

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

בניגוד לחשבונות שירות, כברירת מחדל, זהויות של סוכנים לא משותפות בין כמה עומסי עבודה, אי אפשר להתחזות אליהן והן לא מאפשרות למפתחים ליצור מפתחות לחשבונות שירות עם תוקף ארוך. טוקני הגישה שנוצרים בשביל Cloud de Confianceמקושרים באופן קריפטוגרפי לאישורי ה-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
• Google Kubernetes Engine

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

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

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

כדי לאכוף גבולות אמון בין משתמשים אנושיים, עומסי עבודה אוטונומיים וכלים חיצוניים בלי להסתמך על התחזות לחשבון שירות, 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: השם המקוצר של שירות Cloud de Confiance (לדוגמה, aiplatform או discoveryengine).
• ‫RESOURCE_PATH: הנתיב המלא למשאב שמארח את הנציג.

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

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

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

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

פרטי הכניסה של הנציג

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

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

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

כברירת מחדל, זהויות של סוכנים משתמשות ב-Mutual TLS‏ (mTLS) עם אישורי X.509 כשהן מתקשרות ישירות עם ממשקי ה-API של Cloud de Confiance . כשהנציגים מתקשרים דרך 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.
• גבול הגישה לחשבונות משתמשים (PAB): מדיניות לקביעת גבול הגישה לחשבונות משתמשים מגבילה את המשאבים שהנציג יכול לגשת אליהם, בלי קשר להרשאות אחרות שיש לנציג. כללי המדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) שחלים על זהות הסוכן נבדקים כחלק מהשיחות היוצאות (egress). זהויות של סוכנים שכפופות למדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) יכולות לגשת רק למשאבים שצוינו במדיניות הזו, וכך הסוכן מבודד לחלוטין בגבולות שהוגדרו לו.
• thought VPC Service Controls: תמיכה בהגנה על היקף האבטחה ובשימוש בחשבונות משתמשים:
  • הגנה על גבולות הגזרה: אתם יכולים להוסיף את Agent Identity API (agentidentity.googleapis.com) ואת Agent Identity Credentials API (agentidentitycredentials.googleapis.com) לגבולות הגזרה לשירות כדי לשלוט בגישה לממשקי ה-API האלה. כדי להשתמש בממשקי ה-API האלה בתוך גבולות גזרה לשירות, הלקוחות צריכים לנתב את הבקשות דרך ה-VIP המוגבל (restricted.googleapis.com).
  • כללים לתעבורת נתונים נכנסת ויוצאת: תמיכה בשימוש בזהויות של סוכנים כחשבונות משתמשים בכללים לתעבורת נתונים נכנסת ויוצאת, כדי לאפשר גישה למשאבים שמוגנים על ידי גבולות גזרה לשירות.

איך פועל Agent Identity

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

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

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

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

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

מגבלות

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

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

• ארכיטקטורה של הקצאת הרשאות לזהות
• יצירת סוכן עם Agent Identity
• אימות ב- Cloud de Confiance באמצעות הזהות של הסוכן
• אימות מול שירותים חיצוניים באמצעות הזהות של הנציג
• אימות באמצעות OAuth תלת-רגלי עם מנהל אימות
• אימות באמצעות OAuth דו-רגלי עם מנהל אימות
• אימות באמצעות מפתח API עם מנהל אימות
• ניהול ספקי האימות של Agent Identity
• מיקומים של Agent Identity
• thought מושגים ב-SPIFFE