כדי לאכוף גבולות אמון בין משתמשים אנושיים, עומסי עבודה אוטונומיים וכלים חיצוניים בלי להסתמך על התחזות לחשבון שירות, Agent Identity משתמשת במסגרת הקצאה של שלוש זהויות. המסגרת הזו מפרידה ומתאמת בין שלושה הקשרים שונים של זהויות בסביבה שלכם:
- זהות המשתמש: הזהות של משתמש הקצה שהתחיל את הפעולה, מאומתת באמצעות OAuth 2.0 או OpenID Connect (OIDC) סטנדרטי עם Google Identity או ספק זהויות (IdP) מאוחד של כוח עבודה.
- זהות הסוכן: זהות ה-SPIFFE הייחודית של הסוכן שנפרס, שמאומתת באופן קריפטוגרפי, ואישור X.509 שהוקצה באופן אוטומטי, שמייצגים את הסוכן שפועל בסמכות עצמית.
- זהות מואצלת: הקשר הסמכות המשולב כשהנציג פועל בשם המשתמש האנושי שיזם את הפעולה, באמצעות פרטי כניסה של OAuth תלת-רגלי (3LO) בהיקף מוגדר, שמתווכים על ידי מנהל האימות של Agent Identity.
התרשים הבא ממחיש איך זהות המשתמש, זהות הנציג והזהות שהוקצתה פועלות יחד בגבולות האמון של תעבורת הנתונים הנכנסת, זמן הריצה ותעבורת הנתונים היוצאת:
בארכיטקטורה הזו, זהות המשתמש קובעת את ההקשר של מבצע הקריאה במהלך הכניסה, זהות הנציג מאמתת את עומס העבודה בתוך גבולות זמן הריצה, והזהות שהוקצתה משלבת את שתי הרשויות כשהנציג ניגש לשירותים במורד הזרם בשם המשתמש.
איך זהויות מופצות בין גבולות אמון
כשהבקשה עוברת בין גבולות האמון האלה, הפלטפורמה מעריכה ומפיצה כל שכבת זהות:
- גבול כניסה מלקוח לסוכן (זהות המשתמש): המשתמש האנושי מאמת את הזהות שלו באפליקציית הלקוח באמצעות אסימון OAuth 2.0 או OIDC.
כשתעבורת הנתונים נכנסת דרך Agent Gateway (במצב Ingress של
CLIENT_TO_AGENT), כללי מדיניות ההרשאה שמצורפים ל-Agent Gateway מאמתים את זהות המשתמש כדי לוודא שיש לו הרשאה להפעיל את הסוכן המטורגט, ומעבירים את ההקשר של המשתמש המאומת לסביבת זמן הריצה. - Agent Runtime ותיווך פרטי כניסה (Agent Identity): בתוך סביבת זמן הריצה המבודדת, הסוכן פועל תחת זהות סוכן SPIFFE משלו עם אישור X.509 שמתחלף אוטומטית כל 24 שעות. כשהנציג צריך פרטי כניסה לכלים במורד הזרם, הוא מאמת את הזהות שלו מול מנהל האימות של Agent Identity.
- נתיב תעבורת נתונים יוצאת אוטונומי (זהות הסוכן): כשהסוכן קורא ל- Google Cloud APIs או לנקודות קצה (endpoints) של מכונה למכונה (M2M) בסמכות שלו, הוא מאמת באמצעות טוקנים שקשורים לאישורים שנאכפים על ידי Mutual TLS (mTLS) ו-Demonstrating Proof of Possession (DPoP), טוקנים של מזהה OIDC או פרטי כניסה של OAuth דו-רגלי (2LO) ממנהל האימות. מדיניות ההרשאות והדחיות של IAM, המדיניות לקביעת הגישה לישויות מורשות (PAB) והמדיניות של בקרת גישה מבוססת-הקשר בודקות את הבקשה רק מול זהות הנציג.
- נתיב תעבורת נתונים יוצאת בהקצאת משתמש (זהות מוקצית): כשהנציג קורא לשרתי Model Context Protocol (MCP) ברמת המשתמש או לממשקי API של צד שלישי בשם המשתמש האנושי, מנהל האימות מתווך טוקן משתמש 3LO בהסכמה שמייצג את הזהות המוקצית. השיחות היוצאות כפופות גם למדיניות התעבורה היוצאת של הנציג וגם להרשאות ולהיקפי ההרשאות ב-OAuth שהמשתמש המאציל הסכים להם. ביומני הביקורת מתועדות גם הזהות של הנציג וגם הזהות של המשתמש.
השוואה בין שכבות הזהות
בטבלה הבאה מוסבר איך שלוש שכבות הזהות מנהלות את הגישה ואת יכולת הביקורת:
| שכבת הזהות | סוג חשבון המשתמש ופרטי הכניסה | גבולות האמון ואכיפת המדיניות | שיוך של יומן ביקורת |
|---|---|---|---|
| זהות המשתמש | משתמש הקצה שיוזם את הבקשה (חשבון Google או חשבון משתמש של כוח עבודה) מאומת באמצעות אסימון OAuth 2.0 או OIDC. | מהלקוח לסוכן (ingress): כללי מדיניות ההרשאה של Agent Gateway מאמתים אם המשתמש יכול להפעיל את הסוכן ולהתחיל סשן. | מתעדת את זהות המשתמש האנושי כגורם שמפעיל את נקודת הקצה של הסוכן. |
| זהות הסוכן | עומס עבודה של סוכן אוטונומי (ישות מורשית של זהות הסוכן) מאומת באמצעות אישור SPIFFE X.509 (mTLS ו-DPoP), טוקן של מזהה OIDC, או פרטי כניסה של 2LO או מפתח API ממנהל האימות. | Agent-to-Anywhere (egress): כללי המדיניות של IAM (הרשאה, דחייה, בקרת גישה לישויות מורשות (PAB) ובקרת גישה מבוססת-הקשר) אוכפים את Google Cloud המשאבים, ספקי האימות ונקודות הקצה החיצוניות שהנציג יכול להגיע אליהם בסמכותו. | מתעד את חשבון המשתמש הייחודי של הסוכן ב-SPIFFE בתור הזהות הפועלת. |
| זהות מואצלת | זהות הסוכן שפועל בשם המשתמש האנושי שהביע הסכמה (חשבון Google או חשבון משתמש ב-Workforce Identity) באמצעות טוקן גישה 3LO ברמת היקף ההרשאות, שמתווך על ידי מנהל האימות של Agent Identity. | מסוכן לכל מקום (תעבורת נתונים יוצאת): אכיפת הצומת של הרשאות מינימליות – הקריאה חייבת לעמוד גם בכללי המדיניות של הסוכן בנושא ניהול תעבורת נתונים יוצאת וגם בהרשאות ובהיקפי ההרשאות ב-OAuth שהמשתמש המאציל הסכים להם. | מתעד שיוך כפול, ומתעד גם את זהות ה-SPIFFE של הסוכן וגם את המשתמש האנושי שהעביר את ההרשאה. |