אבטחה של סוכן בקרת גישה מבוססת-הקשר

במסמך הזה מוסבר איך גישה מודעת-הקשר תומכת באבטחה מקצה לקצה ב-Gemini Enterprise Agent Platform על ידי אכיפת TLS הדדי (mTLS) והצגת הוכחת בעלות (DPoP) לאימות והרשאה ב-Gemini Enterprise Agent Platform.

ב-Gemini Enterprise Agent Platform, ‏ Agent Gateway (בגרסת Preview) יכול לנהל את אמצעי בקרת הגישה המוטמעים לכל האינטראקציות בין סוכנים ובין סוכנים לכל מקום.

בקרת הגישה מבוססת-הקשר מופעלת כברירת מחדל, והיא מחייבת שאמצעי בקרה שכפופים ל-Agent Gateway ישתמשו בשיטות הבאות לאימות (authn) ולאישור (authz) אבטחה:

  • Mutual TLS (mTLS): כדי לאבטח את הגישה של סוכנים ל-Agent Gateway, ‏ בקרת גישה מבוססת-הקשר ו-IAP אוכפים על הסוכנים להשתמש ב-mTLS על ידי אימות של שיוך אסימון שמבוסס על אישור.

  • הצגת הוכחת בעלות (DPoP): כדי לאבטח סוכנים שניגשים לשירותים מעבר ל-Agent Gateway, הגישה מודעת-ההקשר אוכפת את התוקף של זהויות הסוכנים באמצעות DPoP.

כש-Agent Gateway מושבת, נציגים יכולים לגשת ישירות לממשקי API באמצעות mTLS. Google Cloud אבל כש-Agent Gateway מופעל, השער מסיים את mTLS, ולכן צריך להשתמש ב-DPoP.

על ידי אכיפת mTLS ו-DPoP, בקרת הגישה מבוססת-הקשר מספקת אבטחה בסיסית מקצה לקצה ועוזרת להגן מפני גניבת פרטי כניסה והשתלטות על החשבון (ATO). האכיפה של מדיניות בקרת הגישה מבוססת-הקשר עוזרת לוודא שאסימונים שנפרצו לא יהיו שימושיים מחוץ לסביבות זמן הריצה המיועדות והמהימנות שלהם. האכיפה של קישור פרטי הכניסה בבקרת גישה מבוססת-הקשר עוזרת להבטיח בידוד של פרטי הכניסה בין דיירים שונים של סביבת זמן הריצה של Gemini Enterprise Agent Platform.

מושגים מרכזיים

המושגים הבאים חשובים להבנת האופן שבו בקרת הגישה מבוססת הקשר אוכפת אבטחה לאינטראקציות של סוכנים עם משאבים באמצעות mTLS ו-DPoP.

  • מאגר זהויות של סוכנים: קיבוץ של משאבים והגדרות שמנהל את פרטי הכניסה והמפתחות של אבטחה עבור קבוצה ספציפית של סוכנים.

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

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

  • הוכחת בעלות (DPoP): הפרוטוקול שבו הסוכנים צריכים להשתמש אחרי שהם עוברים דרך Agent Gateway כדי לבצע אימות ולגשת למשאבים דרך ממשקי API של Google Cloud . השוואה ל-TLS הדדי. פרוטוקול DPoP מבוסס על RFC 9449.

  • ניהול מפתחות DPoP: מאגרי זהויות הבסיסיים של הסוכנים מוקצים עם צמדי המפתחות הציבוריים/פרטיים הדרושים לתמיכה בפעולות DPoP.

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

  • אימות TLS בו-זמני (mTLS): פרוטוקול האימות שזהויות הסוכן משתמשות בו כדי לגשת ל-API‏Google Cloud , כולל גישה ל-Agent Gateway. השוואה ל-DPoP.

  • הוכחת DPoP של משאב: הוכחה קריפטוגרפית שנוצרת על ידי Agent Gateway ומסופקת לממשקי API של Google Cloud.

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

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

אכיפה של בקרת גישה מבוססת-הקשר דרך Agent Gateway

Agent Platform משתמשת בבקרת גישה מבוססת-הקשר כדי לאכוף אבטחה מוטמעת מזהות של סוכן אל Agent Gateway ומשער הסוכנים אל המשאב. בקרת גישה מבוססת-הקשר היא חלק מתהליכי העבודה הבאים.

פריסת סוכנים

  1. סוכן נפרס בזמן ריצה של Gemini Enterprise Agent Platform.

  2. התכונה 'זהות הסוכן' מקצה באופן אוטומטי את ההרשאות הבאות:

    • מאגר זהויות של סוכנים שמכיל זוג מפתחות

    • עומס עבודה של סוכן במאגר עם המאפיינים הבאים:

      • זהות SPIFFE ייחודית

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

גישה ל-Agent-to-Agent Gateway באמצעות mTLS

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

  2. בקרת הגישה מבוססת-הקשר מאמתת שהסוכן הוקצה עם אסימונים שקשורים לאישור ושהוא משתמש ב-mTLS.

  3. Agent Gateway בודק אם לסוכן יש הרשאה לגשת למשאב.

    ‫Agent Gateway משתמש ב-IAP כדי לבדוק את מדיניות ההרשאות של הסוכן ב-IAM. אם ניסיון הגישה של הסוכן מורשה על ידי מדיניות ההרשאות של IAM במשאב היעד, Agent Gateway מאפשר לסוכן לקרוא לממשקי API של Google Cloud.

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

גישת סוכן לשער למשאב באמצעות DPoP

  1. כדי להפעיל DPoP, Agent Gateway משתמש ב-IAP כדי ליצור הוכחת DPoP של משאב. ‫Agent Gateway מעביר את הוכחת DPoP של המשאב אל Google Cloud ממשקי ה-API.

  2. הסוכן מנסה לגשת לממשקי API של Google Cloud .

  3. בקרת הגישה מבוססת-הקשר מאמתת באופן קריפטוגרפי שהוכחת ההרשאה של DPoP והוכחת המשאב של DPoP נוצרו באמצעות אותו מפתח פרטי במאגר הזהויות של הסוכן.

  4. אם בקרת הגישה מבוססת-הקשר מאמתת את שני אישורי ה-DPoP, לסוכן מותר לגשת למשאב דרך ממשקי ה-API של Google Cloud .

השבתת אכיפת המדיניות של CAA

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

כדי להשבית את האכיפה של מדיניות CAA, מגדירים את משתנה הסביבה הבא:

GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES=False

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