דפוסי רשת פרטית עם כמה סוכנים ב-Google Cloud

Last reviewed 2026-04-16 UTC

במסמך הזה מוסבר איך לתכנן תשתית של רשת פרטית שתומכת באפליקציית Gemini Enterprise עם גישה ציבורית, שכוללת כמה סוכנים וחיבורים פרטיים בין סוכנים, סוכני משנה וכלים. תכנון הרשת מספק חיבורים פרטיים לסוכנים שמתארחים ב-Agent Runtime בפלטפורמת הסוכנים של Gemini Enterprise, ב-Cloud Run, ב-Google Kubernetes Engine‏ (GKE), במרכזי נתונים מקומיים או בעננים אחרים. העיצוב תומך גם בקישור לנציגים שפועלים במיקומים באינטרנט.

מערכות AI מרובות סוכנים כוללות לרוב נתונים רגישים או קנייניים של הארגון. רשת פרטית מאפשרת לכם למנוע את החשיפה של התנועה הזו לאינטרנט הציבורי. העיצוב הזה משתמש בתשתית רשת Google Cloud , במשאבי רשת של ענן וירטואלי פרטי (VPC) ובקישוריות פרטית לסביבות מקומיות או לרשתות חוצות ענן.

בתכנון שמתואר במסמך הזה, סוכנים מתקשרים עם סוכנים אחרים ועם כלים באמצעות פרוטוקול Agent2Agent‏ (A2A) ו-Model Context Protocol‏ (MCP). התקשורת מוצפנת על ידי ניתוב שלה דרך רשת VPC. כדי להעביר תעבורת נתונים אל רשת ה-VPC וממנה, נעשה שימוש בשילוב של נקודות קצה (endpoints) של Private Service Connect, ממשקי Private Service Connect ותעבורת נתונים יוצאת (egress) של Direct VPC ב-Cloud Run. ‫Cloud Next Generation Firewall (Cloud NGFW) שולט בתעבורה שעוברת דרך רשת ה-VPC. שכבות אבטחה נוספות מספקות תעבורת נתונים יוצאת (egress) מבוקרת לאינטרנט באמצעות Secure Web Proxy, ומספקות מדיניות גישה לשירותי API באמצעות גבולות גזרה של VPC Service Controls.

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

תבנית עיצוב לכמה סוכנים

אפליקציית Gemini Enterprise מרובת-סוכנים דורשת סוכן מותאם אישית שישמש כסוכן תזמור או כסוכן בסיס לחיבורים לכלים ולסוכני משנה. כדי להטמיע חיבורים פרטיים לכלים ולסוכני משנה שמארחים ב-Google Cloud או בשרת מקומי, התכנון משתמש ברשת VPC עם כתובות IP פרטיות. סוכן הבסיס מאוחסן בתשתית של Google באמצעות Agent Engine,‏ Cloud Run או GKE. תבנית העיצוב מרובת-הסוכנים מדגישה את האינטראקציות הבאות:

  1. אפליקציית Gemini Enterprise באינטראקציה עם סוכני בסיס בהתאמה אישית. ‫ אפליקציות Gemini Enterprise מציגות ממשק משתמש מנוהל עם פונקציות אבטחה מובְנות שחושפות פונקציונליות של סוכן בהתאמה אישית. סוכני שורש בהתאמה אישית רשומים ב-Gemini Enterprise וזמינים באפליקציות למשתמשי קצה. הסוכן המותאם אישית ברמה הבסיסית (root) פועל ככלי לניהול תהליכי עבודה ברמה העליונה, והוא מעביר משימות מיוחדות לסוכני משנה. בארכיטקטורה הזו נעשה שימוש בסוכני בסיס מותאמים אישית שמארחים ב-Agent Runtime ב-Gemini Enterprise Agent Platform, ב-Cloud Run או ב-GKE.
  2. סוכנים ראשיים שמקיימים אינטראקציה עם סוכני משנה וכלים. הליבה של תהליך העבודה והלוגיקה העסקית של מערכת ה-AI נמצאת בסוכן הבסיסי ובסוכני משנה ייעודיים. הגמישות במסגרת הסוכן, בזמן הריצה ובפלטפורמת האירוח מאפשרת אפשרויות שונות לחיבור סוכני הבסיס לסוכני משנה ולכלים דרך רשת ה-VPC. באמצעות רשתות VPC בחלק הזה של הארכיטקטורה, סוכנים יכולים להשתמש בנתיבי רשת פרטיים שאתם מגדירים, שחושפים נקודות קצה פרטיות אחרות, אמצעי אבטחה של Enterprise ונגישות רחבה יותר לרשת.

סקירה כללית של ארכיטקטורת רשת מרובת סוכנים.

הארכיטקטורה כוללת את הרכיבים הבאים:

  • אפליקציית Gemini Enterprise: ממשק הקצה שמאפשר למשתמשים לגשת לממשק צ'אט בתוך האפליקציה ולקיים אינטראקציה עם מערכת ה-AI מרובת הסוכנים. המשתמשים יכולים לגשת לאפליקציות Gemini Enterprise דרך האינטרנט הציבורי או באופן פרטי דרך חיבורים היברידיים.
  • סוכנים בהתאמה אישית: סוכני שורש שנבנים ונרשמים ב-Gemini Enterprise ומאוחסנים ב-Agent Runtime, ב-Cloud Run או ב-GKE. סוכני השורש האלה פועלים כמתאמים שמקצים משימות לסוכני משנה.
  • רשת VPC: משאב שאתם שולטים בו כדי לספק לסוכנים קישוריות לרשת IP לנקודות קצה פרטיות ונגישות רחבה יותר לרשת. רשת ה-VPC מספקת פלטפורמה להטמעה של קישוריות פרטית ואמצעי בקרה לאבטחת רשת עבור בקשות של סוכנים לסוכנים ולכלים אחרים.
  • סוכני משנה: סוכנים עם התמחויות ספציפיות שמופעלים על ידי תהליך העבודה של הסוכן ברמה הבסיסית (root). סוכני משנה מתקשרים באמצעות פרוטוקול A2A, שמאפשר פעולה הדדית בין סוכנים ללא קשר לשפת התכנות ולזמן הריצה.
  • כלים: מערכות מרוחקות שחושפות שירותים כמו ממשקי API, מקורות נתונים ופונקציות של תהליכי עבודה. הכלים האלה מאחזרים נתונים ומבצעים פעולות או טרנזקציות בשביל הסוכנים. הכלים הם חיצוניים לסוכנים, והסוכנים מתחברים לכלים ומקיימים איתם אינטראקציות באמצעות מפרט ה-MCP.

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

VPC משותף

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

בארכיטקטורה של VPC משותף, פרויקט מארח מכיל את משאבי הרשת המשותפים, כולל רשתות VPC,‏ Cloud Routers, רשתות משנה, חומות אש ו-Cloud DNS. אדמינים יכולים להעניק לפרויקטים של שירותים גישה לשימוש במשאבים האלה. פרויקטים של שירותים מכילים את משאבי זמן הריצה של הסוכן, כולל Agent Runtime,‏ Cloud Run,‏ GKE,‏ Gemini Enterprise ומאזני עומסים ספציפיים לאפליקציות.

ב-VPC משותף יש הפרדה ברורה בין תפקידים של אדמינים של רשתות ואבטחה לבין תפקידים של מפתחי אפליקציות AI:

  • אדמינים של רשתות ואבטחה שולטים בתשתית הליבה, כמו ניתוב VPC, רשתות משנה, שיתוף פעולה של DNS ומדיניות חומת אש.
  • מפתחי אפליקציות AI יוצרים סוכנים בפרויקטים של שירותים מצורפים בלי הרשאות לשנות את תשתית הרשת הבסיסית.

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

אפשר לשלב את רשת ה-VPC המשותפת ב רשת חוצת-עננים באמצעות רכזות VPC של Network Connectivity Center ‏ (NCC) כדי להוסיף את רשת ה-VPC המשותפת כרשת VPC של עומס עבודה. ההטמעה הזו מספקת ל-VPC המשותף נגישות מלאה לנתיבים של מרכז NCC וקישוריות לנקודות גישה לשירותים ממרכזי משנה אחרים.

בקשות שמופעלות מסוכני שורש בהתאמה אישית משתמשות ברשת VPC פרטית שמנוהלת על ידי הלקוח כדי לספק נתיבי רשת מאובטחים לסוכני משנה, לכלים ולשירותים. הניתוב ברשת ה-VPC קובע את הנגישות לנקודות קצה פרטיות. מדיניות Cloud NGFW שמוחלת על רשת ה-VPC קובעת את הגישה לרשת.

הסוכנים מקבלים גישה מאובטחת לנתיבים פרטיים ברשת VPC, כולל קישוריות ל:

  • רשתות VPC אחרות באמצעות קישור בין רשתות VPC שכנות, מכשירי multi-NIC או NCC.
  • נקודות קצה של Private Service Connect לגישה לשירותים מנוהלים.
  • שירותים מנוהלים עם כתובות IP פרטיות, כמו Cloud SQL.
  • חזיתות של מאזני עומסים פנימיים ומשאבי Compute Engine.
  • ממשקי Google API דרך גישה פרטית ל-Google או דרך Private Service Connect.
  • האינטרנט, שנשלט באמצעות Secure Web Proxy.
  • יעדים היברידיים וחוצי-ענן באמצעות Cloud Interconnect,‏ Cloud VPN, מכשיר נתב או SD-WAN.
  • כל יעד של נקודת קצה שאפשר להגיע אליו דרך ניתוב IP ברשת VPC.
  • סוכני AI, כלים ושירותים תומכים אחרים.

מידע נוסף על VPC משותף זמין במקורות המידע הבאים:

רשתות ב-Gemini Enterprise

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

שיחות של משתמשים עם ממשקי Gemini Enterprise

משתמשים מנהלים שיחות עם אפליקציית Gemini Enterprise באמצעות אפליקציה מבוססת-דפדפן ששולחת בקשות לממשקי Google APIs ולשירותים של Google. כדי לאפשר קישוריות פרטית של משתמשים, אפשר להגדיר את כתובות ה-URL של Google API כך שיפנו לטווחים של כתובות IP פרטיות שמנותבות דרך רשת ה-VPC. מידע נוסף זמין במאמר בנושא הגדרת גישה פרטית לממשק המשתמש.

אפליקציות Gemini Enterprise לסוכנים מותאמים אישית

אתם רושמים סוכנים מותאמים אישית בשירות הגילוי של Gemini Enterprise. כשרושמים סוכן, Gemini Enterprise ממפה את השם של הסוכן ליעד ספציפי, שהוא ה-URI של משאב Agent Runtime או הכתובת של סוכן A2A. לאפליקציות Gemini Enterprise יש ממשק צ'אט מובנה שנקרא העוזר הדיגיטלי. כשמשתמש מציין סוכן באמצעות @agent_name, או כשהעוזר הדיגיטלי מחליט להעביר את הפנייה לסוכן, האפליקציה מחפשת את הסוכן במרשם כדי למצוא את נקודת הקצה המשויכת.

כשרושמים סוכן ראשי ב-Gemini Enterprise, אפשר לפרוס את הסוכן הזה בכל מקום כסוכן מותאם אישית. סוכנים בהתאמה אישית ב-Agent Runtime וב-Cloud Run יכולים להשתמש בנתיבים קיימים ברשת פרטית בלי להגדיר משאבי רשת נוספים. כדי לפרוס סוכן בהתאמה אישית ב-GKE, צריך לחשוף את השירות באמצעות שער חיצוני. מידע על הגדרת שער חיצוני מאובטח יותר מופיע בהמשך המאמר בקטע רשתות GKE.

כדי לשלוח בקשות לסוכנים מותאמים אישית, Gemini Enterprise משתמש בזהות של חשבון Discovery Engine Service ב-Gemini Enterprise Agent Platform. נתיב הרשת ומנגנוני ההרשאה משתנים בהתאם לפלטפורמת האירוח שבה אתם משתמשים:

  • סוכנים מותאמים אישית ב-Agent Runtime: סוכן השירות Agent Platform Discovery Engine כולל את התפקידים הנדרשים לניהול זהויות והרשאות גישה (IAM) ב-Agent Platform כדי להפעיל משאבי Agent Runtime כתכונה מובנית. המערכת מעבירה בקשות שמוגשות לשירות Agent Platform API ברשת Google כקריאה פנימית ל-API.
  • סוכנים בהתאמה אישית ב-Cloud Run: אפליקציות Gemini Enterprise משתמשות בזהות של סוכן שירות Discovery Engine של Agent Platform כדי לבצע קריאות לכתובת ה-URL היציבה run.app שרשומה בכרטיס הסוכן. כדי ששירות סוכן ה-AI של Cloud Run יאשר את הקריאות האלה, צריך להעניק לסוכן השירות של Discovery Engine את תפקיד ה-IAM של Cloud Run Invoker ‏ (roles/run.invoker). בקשות ל-Cloud Run מנותבות דרך רשת הייצור של Google אל ממשק הקצה של Google‏ (GFE) לכניסה ל-Cloud Run.

  • סוכנים בהתאמה אישית ב-GKE: אפליקציות Gemini Enterprise משתמשות בזהות של סוכן השירות Agent Platform Discovery Engine כדי לבצע קריאות לכתובת ה-URL שרשומה בכרטיס הסוכן. מערכת DNS ציבורית צריכה להיות מסוגלת לתרגם את שם המארח לכתובת IP חיצונית שמנוהלת על ידי השער. מומלץ להשתמש בgke-l7-regional-external-managed מאזן העומסים או במאזן העומסים gke-l7-global-external-managed. מטעמי אבטחה, מומלץ להשתמש בשרת proxy לאימות זהויות (IAP) כדי ש-Gemini Enterprise יתקשר עם סוכן A2A שמארח GKE. כדי ש-IAP יאשר את הקריאות האלה, צריך להעניק לסוכן השירות של Discovery Engine את תפקיד IAM של משתמש באפליקציית אינטרנט שמוגנת באמצעות IAP ‏(roles/iap.httpsResourceAccessor). רשת הייצור של Google מנתבת בקשות ל-GKE אל GFE עבור תעבורת נכנסת של מאזן עומסים של אפליקציות (ALB) חיצוני.

    כדי לאבטח את GKE Ingress מ-Gemini Enterprise, אפשר לעיין בקטעים IAP ו-Google Cloud Armor בהמשך המאמר הזה.

רשת פרטית לפלטפורמות אירוח של נציגים

אחרי שמשתמש שולח בקשה לאפליקציית Gemini Enterprise, בקשות נשלחות מסוכני הבסיס המותאמים אישית לסוכני משנה ולכלים. פלטפורמות האירוח של הסוכנים המותאמים אישית מספקות את הממשק בין Gemini Enterprise לבין רשתות ה-VPC שלכם. פלטפורמות האירוח של הסוכנים והכלים שמופעלים בקונטיינרים הן Agent Runtime,‏ Cloud Run ו-GKE.

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

אתם יוצרים קישוריות פרטית ל-VPC באמצעות מנגנונים שונים, בהתאם לפלטפורמת אירוח הסוכן שבה אתם משתמשים:

  • סוכנים מותאמים אישית ב-Agent Runtime: ממשקי Private Service Connect מחברים את זמני הריצה של Agent Runtime לרשת ה-VPC. אתם יוצרים קובץ מצורף לרשת ברשת משנה של רשת ה-VPC ומעניקים ל-Agent Runtime הרשאה לצרף אותו. התנועה שנשלחת מ-Agent Runtime מופיעה ברשת ה-VPC כאילו היא הגיעה מכתובת ה-IP של רשת המשנה של הקובץ המצורף. לאחר מכן, רשת ה-VPC מנתבת את התנועה לכתובת ה-IP המתאימה של היעד.
  • סוכנים מותאמים אישית ב-Cloud Run: Direct VPC egress מקשר את מופעי השירות של Cloud Run לרשת ה-VPC. רשת ה-VPC שצוינה כשפורס שירות Cloud Run יכולה להיות מפרויקט השירות של Cloud Run או מפרויקט המארח של ה-VPC המשותף. תעבורת הנתונים שנשלחת מ-Cloud Run מופיעה ברשת ה-VPC כאילו היא הגיעה מכתובת ה-IP של תת-הרשת של Direct VPC egress. לאחר מכן, רשת ה-VPC מנתבת את תעבורת הנתונים לכתובת ה-IP המתאימה של היעד.
  • סוכנים מותאמים אישית ב-GKE: אשכולות GKE נמצאים ישירות ברשת ה-VPC והם משתמשים בכתובות IP של רשתות משנה מקומיות. כברירת מחדל, תעבורת היציאה של GKE משתמשת בכתובת ה-IP של ה-Pod ככתובת ה-IP של המקור. אם מגדירים מיסוך, תעבורת היציאה של GKE משתמשת בכתובת ה-IP של הצומת ככתובת ה-IP של המקור. כל תעבורת היציאה של GKE מנותבת על ידי רשת ה-VPC.

בקטעים הבאים מפורטות הנחיות נוספות לניהול בקשות תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) לרשת ה-VPC וממנה לכל פלטפורמת אירוח של סוכן. שיקולי הרשת רלוונטיים גם לפונקציונליות של סוכן הבסיס וגם לפונקציונליות של הסוכן המשני.

Agent Runtime networking

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

Agent Runtime מארח קונטיינרים בתשתית של Google מחוץ לרשת ה-VPC שלכם. כדי להפעיל קישוריות פרטית לסוכנים אחרים, אתם יכולים לחבר את הסוכן לרשת ה-VPC באמצעות השיטות הבאות:

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

תעבורת יציאה (egress) של Agent Runtime לרשת VPC

‫Agent Runtime משתמש בפרויקט דיירים שמנוהל על ידי Google לצורך תעבורת נתונים יוצאת מהרשת. רשת הדיירים מספקת קישוריות לסוכנים לממשקי Google API וליציאה לאינטרנט הציבורי, אבל היא לא מחוברת ישירות לרשתות VPC של לקוחות כברירת מחדל.

כדי לחבר סוכנים למשאבים שנמצאים בתוך רשת ה-VPC, ‏ Agent Runtime משתמש ב ממשקי Private Service Connect.‏ Agent Runtime פורס ממשק רשת בפרויקט הדייר שמתחבר למשאב network attachment בפרויקט שלכם. החיבור הזה יוצר נתיב נתונים מאובטח בין Agent Runtime לבין רשת ה-VPC. כשמגדירים ממשק Private Service Connect בפרויקט Agent Runtime, המערכת מנתבת את כל תנועת הסוכנים שלא מיועדת ל-Google APIs לרשת ה-VPC.

כדי לפרוס תעבורת נתונים יוצאת (egress) ברשת VPC של Agent Runtime, אפשר לעיין במקורות המידע הבאים:

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

תעבורת נכנסת של Agent Runtime מרשת ה-VPC

בקשות לסוכנים שפועלים ב-Agent Runtime נשלחות באמצעות נקודת קצה ל-API של Agent Platform ‏ (aiplatform.googleapis.com). כדי להגיע לנקודות קצה של Google API באמצעות נתיבי רשת פרטיים מרשת ה-VPC, צריך להשתמש בגישה פרטית ל-Google או בנקודות קצה של Private Service Connect ל-Google APIs.

משתמשים פרטיים ששולחים שאילתות לסוכנים צריכים לבצע התאמת נתונים (resolve) של שם המארח של נקודת קצה ל-API של Agent Platform לטווח כתובות ה-IP הפרטיות של גישה פרטית ל-Google או לכתובת ה-IP של נקודת הקצה של Private Service Connect לממשקי Google APIs. אזור מנוהל פרטי של Cloud DNS ל-googleapis.com מבצע התאמת נתונים (resolve) של בקשות ל-Agent Platform API. רשת ה-VPC מנתבת את הבקשה ישירות דרך רשת הייצור של Google.

אם אתם משתמשים בגישה פרטית ל-Google או ב-Private Service Connect ל-Google APIs, תוכלו להגן על התנועה מרשת ה-VPC אל Agent Runtime באמצעות המוצרים והתכונות הבאים:

שיקולים נוספים לגבי הרשת של Agent Runtime

תעבורת נתונים יוצאת (egress) של Agent Runtime שמשתמשת בממשקי Private Service Connect יכולה להתבצע רק לטווחים של כתובות IP מסוג RFC 1918 ברשת ה-VPC. למידע על טווחים ספציפיים של כתובות IP ביעד שלא ניתן לנתב באמצעות יציאה של Agent Runtime, אפשר לעיין במאמר דרישות לגבי טווח כתובות IP ברשת משנה. כדי להגיע ליעדים בטווח כתובות IP שלא ניתן לנתב, צריך להשתמש בהגדרת proxy מפורשת בסוכנים ולפרוס משאבי proxy שמשתמשים בכתובת IP שניתנת לניתוב ברשת ה-VPC.

כשפורסים את Agent Runtime ללא ממשק Private Service Connect, יש לו גישה לאינטרנט כברירת מחדל. כדי להגן מפני זליגת מידע, צריך להשבית את הגישה שמוגדרת כברירת מחדל על ידי הפעלת VPC Service Controls.

כשפורסים את Agent Runtime עם ממשק Private Service Connect, תעבורת נתונים יוצאת (egress) ישירה לאינטרנט מושבתת, ללא קשר ל-VPC Service Controls. אם אתם צריכים שהסוכן שלכם יגש ליעד ש-Agent Runtime לא יכול להגיע אליו בדרך כלל, כמו האינטרנט, אתם צריכים לבצע את הפעולות הבאות:

  1. מגדירים את Secure Web Proxy ברשת משנה RFC 1918 של רשת ה-VPC. צריך להגדיר את ה-Proxy במצב ניתוב מפורש של שרת proxy.
  2. יוצרים רשומת Cloud DNS עבור שם המארח של שרת ה-Proxy המאובטח באינטרנט.
  3. מגדירים DNS peering עבור Agent Runtime כדי לתמוך בפענוח של שאילתות DNS של סוכנים לכתובת הפרטית של Secure Web Proxy ברשת ה-VPC.
  4. כשפורסים סוכנים, צריך לבצע את הפעולות הבאות:
    1. מגדירים משתני סביבה כדי להשתמש ב-proxy מפורש על ידי ציון שם המארח והיציאה של Secure Web Proxy.
    2. אם אתם ניגשים ליעד פרטי, צריך להגדיר אזור DNS פרטי עבור היעד הזה.

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

רשתות ב-Cloud Run

בקטע הזה מתואר רישות פרטי לסוכני שורש ולסוכני משנה שמארחים ב-Cloud Run. ‏Cloud Run מארח קונטיינרים בתשתית של Google מחוץ לרשת ה-VPC שלכם. כדי לאפשר קישוריות פרטית לסוכנים אחרים, אתם יכולים לחבר את הסוכן לרשת ה-VPC שלכם באמצעות השיטות הבאות:

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

תעבורה יוצאת (egress) מ-Cloud Run לרשת VPC

כדי ליזום חיבורים של Cloud Run לרשת VPC, מומלץ להשתמש בDirect VPC egress. כשמשתמשים ב-Direct VPC egress, מופעים של Cloud Run מתחברים ישירות לרשת ה-VPC המשותפת באמצעות כתובת IP מרשת המשנה שמציינים כשפורסים Direct VPC egress.

כשמגדירים Direct VPC egress, צריך לבצע את הפעולות הבאות:

  1. מגדירים את רשת המשנה של היעד עם גישה פרטית ל-Google מופעלת.
  2. מגדירים ניתוב תנועה כדי לנתב את כל התנועה לרשת ה-VPC.

ההגדרה הזו שולחת את כל התעבורה דרך רשת ה-VPC כדי לשמור על הפרטיות, והיא שולחת בקשות מ-Cloud Run לממשקי API אחרים של Google דרך הרשת הפנימית של Google.

כל שאילתות ה-DNS מ-Cloud Run משתמשות במדיניות ובאזורים של Cloud DNS שמשויכים לרשת ה-VPC. אין צורך בהגדרות נוספות של שיתוף פעולה בין שרתי DNS. סוכנים שמארחים ב-Cloud Run פותרים את כל התחומים הפרטיים ב-Cloud DNS ואת שמות המארחים הציבוריים.

בהמשך המאמר הזה מוסבר איך לאבטח עוד יותר את הסוכנים ואת רשת ה-VPC עבור תעבורת היציאה של Cloud Run:

תעבורת נתונים נכנסת (ingress) ב-Cloud Run מרשת ה-VPC

‫Cloud Run היא פלטפורמה שמנוהלת על ידי Google ופועלת בסביבה מחוץ לרשת ה-VPC. בסביבה הזו מתארחת נקודת הקצה היציבה של כתובת ה-URL של שירותי Cloud Run שמריצים עומסי עבודה של סוכני AI או כלים.*.run.app נקודות הקצה האלה מוגשות על ידי אותה נקודת כניסה של GFE שמגישה שירותי API של *.googleapis.com. ‫Cloud Run משתמש באותם נתיבי רשת בסיסיים שמאפשרים קישוריות פרטית ל-גישה פרטית ל-Google ול-Private Service Connect ל-Google APIs.

משתמשים פרטיים ברשת VPC שמבצעים שאילתות לסוכנים או לכלים צריכים לפתור את שם המארח run.app לטווח כתובות ה-IP הפרטיות של גישה פרטית ל-Google או לכתובת ה-IP של נקודת הקצה של Private Service Connect עבור Google APIs. אזור פרטי מנוהל של Cloud DNS עבור כתובת ה-URL‏ run.appמפענח בקשות לשירותי Cloud Run. רשת ה-VPC מנתבת את הבקשה ישירות דרך רשת הייצור של Google.

הגדרת תעבורת נתונים נכנסת (ingress) של Cloud Run לפנימית מגבילה את הגישה לשירות, ומאפשרת בקשות רק ממקורות פנימיים מאומתים. מקורות מאושרים כוללים את המקורות הבאים:

  • רשתות VPC של פרויקט השירות Cloud Run.
  • רשת ה-VPC המשותפת שמארחת את נקודת היציאה של Direct VPC.
  • משאבים שנמצאים באותו היקף של VPC Service Controls.
  • מאזני עומסים פנימיים של אפליקציות (ALB) ברשת ה-VPC.
  • שירותי Google כמו Cloud Scheduler ו-Pub/Sub שנמצאים בפרויקט השירות או ב-service perimeter של VPC Service Controls.

אם לא משתמשים בגבול גזרה משותף של VPC Service Controls כדי לכלול גם את השירותים שקוראים לשירותים אחרים וגם את השירותים שנקראים, התנועה שמגיעה מחוץ לפרויקט של שירות Cloud Run או לסביבת ה-VPC המשותף נחשבת לתנועה חיצונית. תנועה כזו כוללת תנועה משירותים אחרים של Google Cloud Cloud Run, כמו Agent Runtime. כדי לעבור את הבדיקה של תעבורת נתונים נכנסת פנימית ב-Cloud Run, צריך לנתב את התעבורה הזו כך שהיא תיראה כאילו היא מגיעה מתוך רשת ה-VPC של שירות היעד.

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

  • אתם יכולים להשתמש בנקודות קצה של Private Service Connect כדי לאפשר לשירותים בפרויקטים או ברשתות VPC אחרות להתחבר לממשקי Google APIs ולשירותים של Google, כולל שירות Cloud Run שלכם, באמצעות כתובת IP פרטית ברשת ה-VPC שלכם.
  • ניתוב תעבורה דרך מאזן עומסים פנימי של אפליקציות (ALB) שמוצב בתוך רשת ה-VPC לפני שירות Cloud Run. מאזן העומסים מעביר בקשות משירותים אחרים דרך רשת ה-VPC, כדי שהן יעמדו בקריטריונים של תעבורת נתונים פנימית.

מאזני עומסים פנימיים של אפליקציות עם קצוות עורפיים של קבוצת נקודות קצה ברשת (NEG) בלי שרת (serverless) יוצרים משאב VPC שממופה ישירות לשירות Cloud Run. בדגם הזה, מאזן העומסים סוגר את חיבורי ה-TLS של הלקוח באמצעות אישור מהימן. מאזני עומסים פנימיים של אפליקציות תומכים באמצעי בקרה נוספים לאבטחה, כולל כללי מדיניות לאבטחת קצה עורפי של Cloud Armor וכללי מדיניות נוספים להרשאה.

כברירת מחדל, כדי לגשת לכל שירותי Cloud Run נדרש אימות IAM. מומלץ להשתמש בזהות לכל שירות בנפרד ולהקצות לחשבון המשתמש את תפקיד ה-IAM‏ Cloud Run Invoker‏ (roles/run.invoker).

מידע על הגדרת אמצעי בקרה לכניסה ב-Cloud Run זמין במקורות המידע הבאים:

אם אתם משתמשים בגישה פרטית ל-Google או בנקודות קצה (endpoints) של Private Service Connect ל-Google APIs כדי לשלוח תנועה מרשת ה-VPC שלכם אל Cloud Run, אתם יכולים להשתמש במוצרים ובתכונות הבאים כדי להגן על התנועה הזו:

אם אתם משתמשים במאזן עומסים של אפליקציות (ALB) פנימי כדי לשלוח תעבורת נתונים מרשת ה-VPC אל Cloud Run, תוכלו להשתמש במוצרים ובתכונות הבאים כדי להגן על תעבורת הנתונים הזו:

GKE networking

בקטע הזה מתואר ה-Networking של סוכנים שמבוססים על GKE.

‫GKE ו-Gemini Enterprise

‫GKE מארח סוכני AI וכלים, ומציע פלטפורמה שניתנת להתאמה אישית גבוהה לצורך בקרה על הרשת והאבטחה. מערכת AI מרובת סוכנים שנפרסת ב-GKE יכולה לספק יעילות תפעולית בהיקף נרחב. הוא יכול להשתלב בצורה חלקה עם אפליקציות אחרות של Kubernetes ועם ארכיטקטורות גדולות יותר של מיקרו-שירותים.

אשכולות GKE הם צמתים של מכונות וירטואליות ב-Compute Engine שפועלים בתוך רשת משנה של רשת ה-VPC. אפליקציות Gemini Enterprise הן משאבים מנוהלים שפועלים בסביבה מתארחת מחוץ לרשת ה-VPC. כדי לאפשר לאפליקציות Gemini Enterprise לקרוא לסוכנים מותאמים אישית שמתארחים ב-GKE, צריך לחשוף בצורה מאובטחת שער חיצוני עם כתובת IP ציבורית ושם DNS. תעבורת הנתונים יוצאת מ-Gemini Enterprise לרשת הקצה של Google, שם היא עוברת בנתיב ממוטב למאזן העומסים החיצוני של GKE.

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

מצב הפעולה של GKE

‫GKE מציע את מצבי הפעולה הבאים כדי לאזן בין ניהול ובקרה:

  • ‫Autopilot: ‏ Google מבצעת אוטומציה של כל תשתית אשכולות GKE, כולל מישור הבקרה, הקצאת צמתים, חיזוק האבטחה והתאמת קנה מידה.
  • רגיל: Google מנהלת את מישור הבקרה. אתם שומרים על אחריות מלאה להגדרות של מאגר הצמתים, כמו בחירת סוגי מכונות, ניהול תמונות של מערכת ההפעלה ושינוי גודל ידני.
הגברת האבטחה של התשתית ומישור הבקרה
  • אשכולות GKE פרטיים: הקצאת צמתים ללא כתובות IP ציבוריות, כדי להבטיח שסביבת זמן הריצה מבודדת מחשיפה ישירה לאינטרנט.
  • רשתות מורשות ראשיות: הגבלת גישת אדמין לממשק Kubernetes API לטווחי כתובות IP ספציפיים ומהימנים, כדי להקשיח את מישור הבקרה מפני שינויי הגדרה לא מורשים. מאבטחים את נקודת הקצה של DNS עבור Kubernetes API באמצעות IAM ו-VPC Service Controls של Google Cloud.
זהות וגישה (אפס אמון)
  • ‫IAP: פועל כשומר סף ברמת מאזן העומסים. הוא מבטיח שרק משתמשים מאומתים עם הרשאות IAM מתאימות יוכלו לגשת לנקודת הקצה של הסוכן. הגישה הזו מעבירה את ההיקף של האבטחה מהרשת למשתמש הבודד ולהקשר של המכשיר שלו.
הגנה על קצה הרשת וניהול תנועה
  • ‫Cloud Armor: מספק אבטחה חזקה בקצה הרשת, כולל כללים של חומת אש ליישומי אינטרנט (WAF) שעוזרים לחסום תכנים זדוניים, הגנה מפני DDoS שעוזרת להבטיח זמן פעולה רציף והגבלת קצב העברת הנתונים שעוזרת למנוע ניצול יתר של שירותים.
  • ‫הגנה מוגברת על המודל: תכונה שנועדה במיוחד לאבטחת מודלים גדולים של שפה (LLM). היא בודקת ומסירה הנחיות ותגובות בזמן אמת כדי למנוע החדרת הנחיות וזליגת נתונים.
בידוד של רשת פנימית
  • כללי מדיניות של רשת Kubernetes: אכיפה של תקשורת מפורטת עם הרשאות מינימליות בין מיקרו-שירותים. כברירת מחדל, כללי המדיניות דוחים את כל התנועה, אלא אם מאשרים אותה באופן מפורש. כך נמנעת תנועה לרוחב בתוך האשכול.

תעבורה יוצאת (egress) מ-GKE לרשת VPC

רשת ה-VPC מנתבת חיבורים יוצאים מסוכנים שמארחים ב-GKE. מצב הרשת של אשכול GKE שמוגדר כברירת מחדל הוא VPC-native, והוא מספק את המאפיינים הבאים:

  • אשכול GKE משתמש בטווחי כתובות IP חלופיות.
  • כתובות ה-IP של ה-Pod שמורות על ידי ציון טווח כתובות ה-IP של ה-Pod.
  • אפשר להגדיר ניתוב של כתובות ה-IP של הפודים באופן מקורי ברשת ה-VPC של האשכול וברשתות VPC אחרות שמקושרות אליה.

אם Pod של סוכן מתקשר עם Pod של סוכן משנה באותו צומת, התעבורה מנותבת באופן מקומי במרחב השמות של רשת הצומת. אם Pod הסוכן של היעד נמצא בצומת אחר באותו אשכול, התעבורה מנותבת באמצעות טבלת הניתוב של רשת ה-VPC. כדי ש-Pod של סוכן יוכל לתקשר עם משאבי VPC אחרים, כמו מאזני עומסים או נקודות קצה של Private Service Connect, הוא יכול להגיע ליעד באמצעות אותו ניתוב VPC רגיל, בכפוף לכללי חומת האש.

כדי להגן על התנועה שיוצאת מאשכול GKE, אפשר להשתמש במוצרים ובשירותים הבאים:

GKE ingress מרשת ה-VPC

שירותי Kubernetes מספקים גישה למשאבי GKE. למערכת AI מרובת סוכנים, מומלץ להשתמש ב-GKE Gateway או ב- GKE Inference Gateway. ה-Gateway מספק יכולות משופרות של בקרת תעבורה, הפרדה תפעולית של משאבים ושילובי אבטחה. עם זאת, יש אפשרויות אחרות לשירותי כניסה בהתאם לדרישות המערכת.

משאב השער יוצר מאזן עומסים של אפליקציות ומקצה את כל רכיבי איזון העומסים הנדרשים. קבוצות נקודות הקצה ברשת בקצה העורפי של השירות מחוברות כדי לספק איזון עומסים ישירות למאגרי נתונים. כדי לחשוף שירות באופן פנימי לתנועה שמגיעה מרשת ה-VPC, משתמשים במחלקות השער למאזן עומסים פנימי אזורי של אפליקציות (gke-l7-rilb) או למאזן עומסים פנימי חוצה אזורים של אפליקציות (gke-l7-cross-regional-internal-managed-mc).

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

  • ‫Cloud Armor: מגן על שירותים על ידי צירוף של כללי מדיניות האבטחה של Cloud Armor לשירותי ה-Backend שמנוהלים על ידי השער. הוא מספק סינון WAF, סינון לפי כתובת IP ומיקום גיאוגרפי, הגנה מפני DDoS והגבלת קצב לפני שהתנועה מגיעה לאשכול GKE או ל-IAP.
  • ‫IAP: מופעל בשירות לקצה העורפי כדי לשלוט בגישה לאפליקציות באמצעות פרטי כניסה ל-IAM. ‏IAP אוכף מדיניות גישה של אפס אמון. שרת IAP מאמת ומאשר את סוכני ה-AI שמקבלים גישה למשאבי האשכול, כולל אפליקציות Gemini Enterprise, סוכנים בהתאמה אישית ומשאבים חיצוניים. כדי להשתמש בו, למי שמבצע את הקריאה צריכה להיות זהות שאומתה על ידי IAM והרשאה לגשת לשירות העורפי.

אם אתם שולחים תנועה מרשת ה-VPC לשירות GKE דרך שער, אתם יכולים להגן על התנועה הזו באמצעות המוצרים והתכונות הבאים:

אם אתם לא משתמשים בשער כדי לשלוח תנועה מרשת ה-VPC לשירות GKE, אתם יכולים להשתמש במוצרים ובשירותים הבאים כדי להגן על התנועה הזו:

מידע נוסף על אבטחת GKE זמין במאמרים שיטות מומלצות לאבטחת רשת והסבר על אבטחת רשת ב-GKE.

אבטחת רשת של סוכנים

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

Cloud NGFW

‫Cloud NGFW פועל כשומר הסף ברמת הרשת כדי לאבטח תקשורת A2A ו-MCP. חומת האש מוודאת שרק תעבורה מורשית יכולה להגיע לנקודות הקצה של הנציגים. לשם כך, היא מאמתת כל חיבור נכנס או יוצא אל נציגים וכלים אחרים וממנו.

‫Cloud NGFW הוא שירות חומת אש מבוזרת שמוטמעת במבנה של רשת ה-VPC. הוא מציע את רמות התכונות הבאות שפועלות בשכבות שונות של מחסנית הרשת:

  • ‫Cloud Next Generation Firewall Essentials: מספק סינון מנות בחומת אש עם שמירת מצב. כללי המדיניות מוגדרים על סמך כתובות IP‏ (L3), פרוטוקולים ויציאות (L4).
  • ‫Cloud Next Generation Firewall Standard: מספק אכיפה מבוססת-IP עם אובייקטים של שם דומיין שמוגדר במלואו (FQDN), אובייקטים של מיקום גיאוגרפי ופידים מ-Google Threat Intelligence כדי לחסום כתובות זדוניות מוכרות.
  • ‫Cloud Next Generation Firewall Enterprise: מספק יכולות בדיקה אמיתיות של אפליקציות (L7) עם פענוח TLS ויכולות של מערכת לגילוי ולמניעת חדירות (IDPS) לניתוח של מטען ייעודי בהשוואה לחתימות של איומים מתקדמים.

אפשר להחיל את Cloud NGFW על רשת ה-VPC כדי לאכוף את מדיניות חומת האש על סמך הכללים שנדרשים לטירגוט פלטפורמת אירוח הסוכן שבה השתמשתם.

  • ‫Agent Runtime: סוכנים שפועלים ב-Agent Runtime מתחברים לרשת ה-VPC באמצעות קבצים מצורפים של Private Service Connect. הקבצים המצורפים האלה גורמים לממשק הרשת של הסוכן להופיע ברשת משנה ברשת ה-VPC. מדיניות חומת האש של Cloud NGFW חלה על רשת ה-VPC. המדיניות מסננת את התנועה על סמך כתובות ה-IP של המקור מרשת המשנה שמוקדשת לקובץ המצורף של Private Service Connect. כדי להתאים את התנועה, אפשר להשתמש בכתובות ה-IP של המקור ובטווחים של כתובות ה-IP של היעד.
  • ‫Cloud Run: שירותי Cloud Run שמשתמשים ב-Direct VPC egress שולחים תעבורת נתונים ישירות ממופעים שפועלים ברשת משנה שצוינה ברשת ה-VPC. מדיניות חומת האש של Cloud NGFW חלה על רשת המשנה שבה Cloud Run משתמש כדי לסנן תעבורת נתונים. כדי להתאים תעבורת נתונים, אפשר להשתמש בכתובת ה-IP של המקור ובטווחים של כתובות ה-IP של היעד.
  • ‫GKE: אשכולות GKE מקוריים של VPC מקצים ל-Pods כתובות IP ישירות מטווחי כתובות IP משניים של רשת ה-VPC. כללי מדיניות של חומת אש ברשת יכולים לסנן תנועה על סמך טווחי כתובות IP של צמתי GKE ו-Pods, והם יכולים להשתמש בתגים מאובטחים ובחשבונות שירות. תגים מאובטחים מוצמדים למכונות הווירטואליות שמשמשות כצומתי GKE. אחרי כן, כללי חומת האש יכולים לטרגט תנועה מצמתים עם תגים ספציפיים או להפנות תנועה לצמתים כאלה. כללי חומת האש יכולים גם לכוון תנועה או להפיק תנועה מצמתי GKE על סמך הזהות של חשבון השירות שמשויך למאגר הצמתים.

מדיניות ברירת מחדל לדחיית תעבורת נתונים יוצאת

הטמעה של אסטרטגיית דחייה כברירת מחדל היא שיטת אבטחה מומלצת שמתבססת על העיקרון של הרשאות מינימליות. האסטרטגיה הזו מבטיחה שרק תנועת רשת שאושרה במפורש תותר, ושכל שאר התנועה תיחסם כברירת מחדל. ההטמעה הזו מתבצעת על ידי מבנה של כללי חומת אש עם כללי ALLOW בעדיפות גבוהה לזרימות מוכרות ולגיטימיות, וכלל DENY בעדיפות נמוכה שכולל את כל השאר. בכל הרמות של Cloud NGFW אפשר להגדיר כללים שמבוססים על טווחי כתובות IP של המקור והיעד.

כללים במדיניות חומת האש יכולים להתאים ביעילות לתעבורת נתונים ממקורות שונים: מתת-הרשת של רשת החיבור של Agent Runtime ומתת-הרשת של יציאה ישירה מ-VPC ב-Cloud Run.

דוגמה למדיניות ברירת מחדל של תעבורת נתונים יוצאת (egress) חסומה:

  • יצירת מדיניות וכללים של חומת אש ברשת: יוצרים מדיניות של חומת אש גלובלית או אזורית ומשייכים אותה לרשת ה-VPC. יוצרים כללים של מדיניות חומת אש שמטרתם תעבורת נתונים בכיוון היציאה (--direction=EGRESS) על סמך טווחי כתובות ה-IP של המקור (--src-ip-ranges=SRC_IP_RANGES) וטווחי כתובות ה-IP של היעד (--dest-ip-ranges=DEST_IP_RANGES).
  • כללים ספציפיים ALLOW: משתמשים במספרי עדיפות נמוכים יותר, למשל 100-1000. הכללים האלה מאפשרים בדיוק את תנועת הרשת שנדרשת כדי שהסוכנים מבוססי ה-AI יפעלו. התנועה הזו כוללת תקשורת עם שירותים פנימיים אחרים, מאזני עומסים, ממשקי Google API נדרשים או נקודות קצה חיצוניות לגיטימיות. יוצרים כלל שתואם לתעבורת נתונים ממקור מתת-הרשת של החיבור לרשת של Agent Runtime או מתת-הרשת של Direct VPC egress ב-Cloud Run ליעדים הרצויים.
  • כלל DENY כללי: כדי לוודא שהכלל יהיה האחרון בסדר ההערכה, צריך להשתמש במספר העדיפות הגבוה ביותר, למשל 2147483647. הכלל הזה דוחה תנועה לכל יעד (--dest-ip-ranges=0.0.0.0/0) שלא תואם לאף אחד מ-ALLOW הכללים הקודמים.

מדיניות ברירת מחדל של דחיית תעבורת נתונים יוצאת (egress) מונעת מסוכני AI ליצור חיבורים לרשת שלא אושרו במפורש, וחוסמת חדירה פוטנציאלית של נתונים או גישה לאתרים זדוניים. המדיניות מגבילה את הסוכנים המתארחים כך שהם יוכלו לתקשר רק עם נקודות קצה מאושרות, וזה חיוני לשמירה על שליטה בעומסי עבודה אוטונומיים.

שיקולים נוספים לגבי מדיניות Cloud NGFW

בנוסף לאסטרטגיית הדחייה שזמינה בכל הרמות של Cloud NGFW, אפשר להקשיח עוד יותר את אבטחת הרשת של ה-AI מרובה הסוכנים באמצעות תכונות של רמות בתשלום:

  • תכונות רגילות של Cloud NGFW:
    • אובייקטים של FQDN לנקודות קצה דינמיות: סוכני AI מתקשרים לעיתים קרובות עם ממשקי API חיצוניים, נקודות קצה של מודלים או מקורות נתונים שכתובות ה-IP שלהם עשויות להשתנות. כדי להבטיח גישה עקבית לשירותים הדרושים לפי שם הדומיין, צריך להשתמש באובייקטים של FQDN בכללי ALLOW.
    • אמצעי בקרה למיקום גיאוגרפי: אם לסוכני AI יש דרישות תאימות או שאסור להם ליצור אינטראקציה עם שירותים באזורים גיאוגרפיים ספציפיים, אפשר להשתמש באובייקטים של מיקום גיאוגרפי (--src-region-codes=SRC_COUNTRY_CODES) בכללי חומת האש כדי להגביל את התנועה אל המיקומים האלה או מהם.
    • ‫Google Threat Intelligence: אפשר להשתמש ב-Google Threat Intelligence במסנני יציאה כדי לחסום באופן אוטומטי סוכנים להתחברות ליעדים זדוניים מוכרים, כמו שרתי שליטה ובקרה (C2), אמצעים להסתרת זהות כמו Tor ואתרים להפצת תוכנות זדוניות. השימוש ב-Google Threat Intelligence עוזר לצמצם את ההשפעה של סוכן שנפרץ. מומלץ לכלול את המסננים האלה של יעדים בכללים עם מספר העדיפות הגבוה יותר (סדר ההערכה הנמוך יותר) DENY.
  • תכונות של Cloud NGFW Enterprise:
    • בדיקה בשכבה 7: לסוכנים שמטפלים במידע אישי רגיש או שחשופים לסיכונים גבוהים יותר, בדיקת מטעני נתונים של מנות לאיתור איומים כמו תוכנות זדוניות, תוכנות ריגול וניצול לרעה שלא מנותחים על ידי כללי חומת האש בשכבת הרשת.
    • בדיקת TLS: כדי לאפשר למנוע הבדיקה לנתח תנועה מוצפנת, צריך להפעיל בדיקת TLS. השימוש בבדיקת TLS הוא חיוני כי רוב המתקפות המודרניות והתקשורת של C2 מוצפנות.

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

IAP

‫IAP מאבטח בקשות כניסה לאשכולות GKE על ידי מתן שכבת אימות והרשאה מרכזית לאפליקציות AI. ‫IAP מיירט את כל בקשות ה-HTTPS שמיועדות לשער, ובודק את הזהות וההרשאות של המתקשר. ‫IAP מאפשר רק לבקשות מאומתות ומורשות לעבור לעומס העבודה של שירות לקצה העורפי. התכונה IAP במאזן העומסים של שער הכניסה מגנה רק על תעבורה שמגיעה מחוץ לאשכול. התקשורת בתוך האשכול לא עוברת דרך IAP.

כדי לגשת לאפליקציות AI שמתארחות ב-GKE ומוגנות על ידי IAP, צריך להקצות לזהויות של ישויות מורשות את תפקיד ה-IAM 'משתמש באפליקציית אינטרנט מאובטחת באמצעות IAP' (roles/iap.httpsResourceAccessor) במשאב של שירות לקצה העורפי שמוגן באמצעות IAP. מומלץ להגדיר חשבון שירות בהתאמה אישית כזהות של סוכנים שנפרסו. שימוש בחשבון שירות בהתאמה אישית מאפשר להקצות הרשאות בצורה מדויקת יותר בהתאם לעקרון של הרשאות מינימליות.

כדאי להקצות את התפקיד 'משתמש באפליקציית אינטרנט מאובטחת באמצעות IAP' ב-IAM ישירות לחשבונות השירות של סוכנים שיש להם הרשאה לגשת לסוכנים ולכלים אחרים שמארחים במשאב המותאם אישית של GKE‏ BackendConfig. כדי לאפשר גישה לאפליקציות של Gemini Enterprise, צריך להקצות הרשאות על ידי קישור תפקיד ה-IAM‏ Discovery Engine Service Account‏ (roles/discoveryengine.serviceAgent) לפרויקט של Gemini Enterprise.

VPC Service Controls

VPC Service Controls מצמצם את הסיכונים לזליגת נתונים על ידי שליטה קפדנית בגישה לממשקי API של Google. מומלץ לפרוס גבולות גזרה יחידים של מאקרו שכוללים את כל השירותים הנתמכים. הגישה הזו מספקת את ההגנה החזקה ביותר מפני גניבת נתונים. כדי להבטיח אכיפה עקבית של המדיניות בארכיטקטורות של VPC משותף, חשוב לכלול את הפרויקט המארח ואת כל פרויקטי השירות המשויכים באותם גבולות גזרה לשירות.

כדי לאבטח את האינטראקציה בין Gemini Enterprise לבין Cloud Run מעבר לגבולות הפרויקט, כדאי לפעול לפי ההמלצות הבאות:

  • פריסת גבול גזרה יחיד של VPC Service Controls שכולל את הפרויקטים של Gemini Enterprise ו-Cloud Run.
  • מוסיפים לרשימת השירותים המוגבלים את כל השירותים הנתמכים של VPC Service Controls. הגישה הזו עוזרת למנוע שינויים אדמיניסטרטיביים לא מורשים.
  • אכיפה של הגדרות כניסה והרשאה פנימיות כדי לחסום את כל הגישה לאינטרנט הציבורי לשירותי Cloud Run.

שירותי Cloud Run מאובטחים באמצעות IAM. למי שמבצע את הקריאה צריך להיות אימות, וצריך להיות לו תפקיד Cloud Run Invoker ב-IAM‏ (roles/run.invoker) בשירות היעד. התפקיד נבדק על ידי אימות של טוקן מכותרת ההרשאה. כדי לבצע קריאה לשירות Cloud Run, צריך להעניק לחשבונות שירות, כמו אלה שמשמשים את Gemini Enterprise, גם את התפקיד Cloud Run Invoker.

כשפורסים את Gemini Enterprise ואת Cloud Run בפרויקטים שונים, צריך להגדיר אזור של VPC Service Controls כדי להגדיר את תעבורת הנתונים הנכנסת (ingress) של Cloud Run כפנימית. בלי גבולות גזרה אלה, קריאות חוצות-פרויקטים מ-Gemini נחשבות לתעבורת נתונים חיצונית, ולכן צריך להגדיר את תעבורת הנתונים הנכנסת (ingress) ל-Cloud Run ל'הכול' – מה שחושף את השירות לאינטרנט הציבורי.

  • ‫Cloud Run ingress all נתמך אם שני התנאים הבאים מתקיימים:
    • השירות VPC Service Controls לא מופעל.
    • ‫Cloud Run ו-Gemini Enterprise לא נמצאים באותו פרויקט.
  • רק Cloud Run ingress internal נתמך בכל שאר התצורות.

שיקולים נוספים לגבי VPC Service Controls

כשפורסים את Cloud Run בתוך היקף של VPC Service Controls, מומלץ להטמיע את אמצעי ההגנה הבאים כדי להבטיח הגנה מקיפה:

  • הגבלת הגדרות הכניסה המותרות: כדי למנוע ממפתחים לפרוס בטעות נקודות קצה שפתוחות לציבור, צריך להגדיר את האילוץ run.allowedIngress של מדיניות הארגון. האילוץ הזה חל רק על פריסות חדשות. יכול להיות שפריסות קודמות לא יעמדו בדרישות. מומלץ לבדוק את כל שירותי Cloud Run הקיימים בתוך ההיקף ולפרוס מחדש או לעדכן את השירותים שלא עומדים בהגדרות הכניסה והיציאה הנדרשות.
    • כדי לאפשר רק בקשות פנימיות, מגדירים את הערך internal.
    • כדי לאפשר בקשות דרך מאזן עומסים חיצוני של אפליקציות, מגדירים את הערך ל-internal-and-cloud-load-balancing.
  • הגבלת ההגדרות של תעבורת נתונים יוצאת (egress) מ-VPC: כדי לנתב את כל הבקשות היוצאות דרך ה-VPC כך שניתן יהיה לבדוק אותן באמצעות כללים של חומת אש היקפית, צריך להגדיר את ערך האילוץ של מדיניות הארגון run.allowedVPCEgress ל-all-traffic. ההגדרה הזו מחייבת שכל עדכון של Cloud Run ישתמש בתעבורת נתונים יוצאת (egress) ישירה מ-VPC או במחבר Serverless VPC Access. האילוץ הזה חל רק על פריסות חדשות. יכול להיות שפריסות קודמות לא יעמדו בדרישות. מומלץ לבדוק את כל שירותי Cloud Run הקיימים בהיקף ולפרוס מחדש או לעדכן את אלה שלא עומדים בהגדרות הנדרשות של תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress).
  • מיקום משותף של קובצי אימג' של קונטיינרים ושירותים: מאגר Artifact Registry שמכיל את קובצי האימג' של הקונטיינרים צריך להיות באותו היקף כמו שירות Cloud Run. משיכת קובצי אימג' מחוץ להיקף נחסמת אוטומטית, אלא אם מגדירים כללי כניסה ויציאה מפורשים.
  • ניהול רמות גישה: לא ניתן להשתמש בכללי מדיניות תעבורת נתונים נכנסת (ingress) של VPC Service Controls וברמות גישה שמסתמכות על זהויות של חשבונות משתמשים ב-IAM להפעלת Cloud Run. במקום זאת, צריך לנהל את הגישה באמצעות קריטריונים מבוססי-רשת או רמות גישה מבוססות-מכשיר.

הגנה מוגברת על המודל

‫Model Armor הוא שירות מבוסס-API שמספק אבטחה משופרת לאפליקציות AI. סוכני AI מקיימים אינטראקציה עם Model Armor על ידי ביצוע קריאות לניקוי הנחיות של משתמשים לפני שהן נשלחות ל-LLM, וגם לניקוי תשובות של מודלים לפני שהן מוחזרות למשתמש. ‫Model Armor בודק באופן פעיל את ההנחיות והתשובות של מודלי LLM, וכך מספק נקודת בדיקה חשובה לזיהוי סיכונים מתפתחים ונקודת בקרה ליישום תקנים של AI אחראי. מומלץ להשתמש בהגנה מוגברת על המודל כדי לוודא עמידה בדרישות של שמירת נתונים במדינה מסוימת ובתקנות המשפטיות בנושא ריבונות הנתונים. כדי להשתמש ב-Model Armor בתוך גבולות גזרה של Service Controls בענן וירטואלי פרטי (VPC), צריך להגדיר נקודת קצה (endpoint) של Private Service Connect (PSC) עבור נקודת הקצה האזורית של Model Armor בתוך רשת ה-VPC.

‫הגנה מוגברת על המודל הוא שירות אזורי שאפשר לגשת אליו באופן פרטי דרך נקודות קצה אזוריות של Private Service Connect ברשת VPC. לדוגמה, השירות us-central1 נקרא באמצעות נקודת הקצה האזורית modelarmor.us-central1.rep.googleapis.com. נקודות קצה אזוריות עוזרות להבטיח את מיקום הנתונים.

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

  1. יוצרים או מאתרים תת-רשת RFC 1918 באזור של רשת ה-VPC שבו נמצא שירות הגנה מוגברת על המודל.
  2. יוצרים נקודת קצה אזורית בתת-הרשת RFC 1918.
  3. יוצרים אזור פרטי ב-Cloud DNS ורשומת A עבור שם המארח של נקודת הקצה האזורית של הגנה מוגברת על המודל (לדוגמה, modelarmor.us-central1.rep.googleapis.com) שמפנה לכתובת ה-IP של נקודת הקצה האזורית.
  4. כדי להשיג יכולת פעולה הדדית של Agent Runtime, צריך ליצור קישור DNS מ-Agent Runtime לאזור הפרטי של Cloud DNS שמשויך לרשת ה-VPC. כשסוכנים שולחים בקשות להגנה מוגברת על המודל, ‏ Cloud DNS מבצע התאמת נתונים (resolve) של בקשות לשם מארח לכתובת ה-IP של נקודת הקצה האזורית של Private Service Connect ברשת ה-VPC. השלב הזה לא נדרש לסוכנים שמארחים ב-Cloud Run וב-GKE.

כדי לשלב את Gemini Enterprise עם Model Armor, צריך ליצור תבנית Model Armor באותו פרויקט שבו נמצא Gemini Enterprise. המיקום של התבנית ושל אפליקציית Gemini Enterprise חייב להיות זהה.

למידע נוסף על הפעלת הגנה מוגברת על המודל, אפשר לעיין במקורות המידע הבאים:

Cloud Armor

‫Cloud Armor הוא שירות מבוזר לאבטחת רשת שמגן על אפליקציות ושירותים מאחורי מאזני עומסים לפני שהבקשות מגיעות לזמני הריצה של שירותי הקצה העורפי. עומסי עבודה של סוכני AI כוללים נפחים גדולים של תקשורת בין שירותים שמשתמשים ב-A2A, ב-MCP ובקריאות API. ההגנה של Cloud Armor מספקת שכבות נוספות של עמידות בתכנון האבטחה עם הגבלת קצב, סינון WAF וכללים מותאמים אישית שתואמים לבקשות צפויות של סוכנים. על ידי צירוף מדיניות אבטחה של Cloud Armor לשירותי קצה עורפי של מאזן עומסים של אפליקציות, אפשר לסנן את התעבורה כדי לזהות בקשות זדוניות ולאכוף אותה באמצעות הגבלות קצב, וגם לצמצם את ההשפעה של מתקפות DDoS.

אפשר לפרוס את Cloud Armor בארכיטקטורת רשת סוכנים בתרחישים הבאים:

  • ‫Cloud Run עם מאזן עומסים פנימי של אפליקציות: כדי להגן על סוכנים וכלים שפועלים ב-Cloud Run, אפשר להשתמש במאזן עומסים פנימי של אפליקציות עם קצה עורפי של NEG ללא שרתים. אפשר להחיל כללי מדיניות אבטחה של קצה עורפי על ה-NEG ללא שרתים כדי לאכוף כללי WAF לתעבורה פנימית ולהגביל את קצב הבקשות. כדי לשלוט בתקשורת של הסוכנים, אפשר להגדיר כללים מותאמים אישית נוספים על סמך כתובות IP וכותרות.
  • שער: כדי להגן על סוכנים וכלים שפועלים ב-GKE, אפשר להשתמש בהגדרת משאב של שער למאזן עומסים גלובלי או אזורי חיצוני של אפליקציות (ALB) עם בק-אנד של NEG אזורי. משתמשים ב-Kubernetes Gateway API כדי להחיל את משאב GCPBackendPolicy עם מדיניות האבטחה המוגדרת של Cloud Armor. אם אתם משתמשים במאזן עומסים חיצוני אזורי של אפליקציות (ALB),‏ Cloud Armor תומך במדיניות אבטחה של קצה עורפי עם כללי WAF, אמצעי בקרה שמבוססים על כתובת IP ומיקום גיאוגרפי והגבלת קצב יצירת הבקשות. מאזני עומסים גלובליים חיצוניים של אפליקציות תומכים בכללי מדיניות לאבטחת קצה העורף (backend) ובכללי מדיניות נוספים לאבטחת קצה באמצעות Google Cloud Armor Adaptive Protection ו- Google Threat Intelligence.

Secure Web Proxy

‫Secure Web Proxy הוא שירות אזורי מנוהל שנפרס ברשת ה-VPC כדי לסנן תעבורת HTTP/S שמקורה ברשת ה-VPC או ברשתות מחוברות כלשהן. הוא פועל כפרוקסי מרכזי וכנקודת אכיפה של אבטחה כדי לספק שליטה וניראות גרנולריות לתעבורת נתונים יוצאת באינטרנט. הוא פועל גם כפרוקסי מפורש לתקשורת פנימית בין שירותים.

‫Secure Web Proxy תומך בשלושה מצבי פריסה: מצב ניתוב של שרת proxy מפורש, מצב של קובץ מצורף עם שירות Private Service Connect ומצב של next hop. מומלץ להשתמש ב-Secure Web Proxy במצב ניתוב מפורש של proxy, שזהו הנושא העיקרי של המסמך הזה. במצב הזה, צריך להגדיר במפורש את לקוחות ה-HTTP כך שיצביעו ישירות על כתובת ה-IP או על שם המארח של ה-Secure Web Proxy.

כדי לפרוס Secure Web Proxy ברשת ה-VPC, צריך להגדיר רשת משנה של קצה קדמי ורשת משנה של פרוקסי בלבד. Secure Web Proxy הוא שירות שמנוהל במלואו. כשפורסים את Secure Web Proxy, הוא פורס ומגדיר באופן אוטומטי את Cloud Router ואת Cloud NAT ברשת ה-VPC, כדי לשלב אותם באופן ספציפי עם משאב השרת proxy. ההגדרה הזו מחייבת שכל הבקשות היוצאות יעברו דרך Secure Web Proxy לפני שהן יוצאות לאינטרנט.

שימוש ב-Secure Web Proxy כשרת proxy מפורש תומך בבקשות של סוכנים שמגיעות מממשקי Private Service Connect של Agent Runtime, מתעבורת נתונים יוצאת (egress) ישירה של VPC ב-Cloud Run ומאשכולות GKE מקוריים של VPC. כשסוכנים שולחים בקשות ל-Secure Web Proxy באמצעות שיטת HTTP CONNECT, תעבורת הנתונים של סשן TCP מועברת בטונל לשרת ה-proxy, שבו מוחלים כללי מדיניות אבטחה. אם התעבורה מותרת, Secure Web Proxy שולח את התעבורה לתעבורת נתונים יוצאת (egress) מבוקרת לאינטרנט או ליעדים ברשת פרטית שאפשר לנתב אליהם דרך רשת ה-VPC.

ניתוב מפורש של שרת proxy

כדי שהסוכנים יוכלו להגיע ליעדים באינטרנט או לטווחים של כתובות IP שלא ניתן לנתב ברשת ה-VPC, תעבורת הנתונים היוצאת של Agent Runtime דורשת שתשתמשו בהגדרת proxy מפורשת. כדי להבטיח יכולת פעולה הדדית של Agent Runtime, מומלץ להגדיר את משאב Secure Web Proxy עם כתובת IP מסוג RFC 1918 מרשת משנה של קצה קדמי ברשת ה-VPC. בהגדרה הזו, אפשר להגיע ישירות ל-Secure Web Proxy מ-Agent Runtime. לאחר מכן, הוא יכול לשמש כ-proxy לכל החיבורים ליעדים של כתובות IP שלא ניתן לנתב שנמצאים ברשת ה-VPC או ברשתות מחוברות.

כדי לתמוך בשימוש בפלטפורמה לאירוח סוכנים ב-Secure Web Proxy במצב ניתוב מפורש, צריך להגדיר את משאבי הרשת הבאים:

  1. יוצרים או מזהים תת-רשת RFC 1918 ברשת ה-VPC כדי לארח את משאב ה-Secure Web Proxy.
  2. יוצרים רשומת DNS של Cloud DNS עבור שם המארח של Secure Web Proxy (לדוגמה, swp.example.com) שמפנה לכתובת ה-IP של משאב Secure Web Proxy.
  3. כדי להשיג יכולת פעולה הדדית של Agent Runtime, צריך ליצור קישור DNS מ-Agent Runtime לאזור הפרטי של Cloud DNS שמשויך לרשת ה-VPC. כשסוכנים שולחים בקשות ל-Secure Web Proxy, ‏ Cloud DNS פותר את בקשות שם המארח לכתובת ה-IP של משאב Secure Web Proxy ברשת ה-VPC. השלב הזה לא נדרש לסוכנים שמארחים ב-Cloud Run וב-GKE.

הגדרות לשרת proxy של הסוכן

הדרך הרגילה להגדיר אפליקציות של סוכנים לשימוש ב-proxy של HTTP(S) היא באמצעות הגדרת משתני הסביבה הבאים:

  • ‫HTTP_PROXY: כתובת ה-URL של שרת ה-proxy המפורש לתעבורת HTTP (לדוגמה, http://swp.example.com:8888). בהגדרה הזו נעשה שימוש בשיטת ה-HTTP‏ CONNECT מהלקוח ל-proxy. למרות שצוין HTTP, ההצפנה ב-TLS נשמרת מקצה לקצה דרך ה-proxy, מהזמן שהסוכן פועל ועד לנקודת היעד.
  • ‫HTTPS_PROXY: כתובת ה-URL של שרת ה-proxy המפורש לתעבורת HTTPS (לדוגמה, https://swp.example.com:8888). בדומה להגדרה HTTP_PROXY, ההגדרה HTTPS_PROXY משתמשת ב-TLS כברירת מחדל. עם זאת, אתם יכולים לספק שכבת הצפנה נוספת על ידי הפעלת הצפנת TLS משלכם בנוסף ל-TLS שמוגדר כברירת מחדל. מידע נוסף זמין במאמר בנושא שירות רשות האישורים.
  • ‫NO_PROXY: רשימה מופרדת בפסיקים של שמות מארחים או כתובות IP שלא צריכים לעבור דרך ה-Proxy. לדוגמה, אם מוסיפים את metadata.google.internal ואת 169.254.169.254 לרשימת NO_PROXY, עומסי העבודה יכולים לגשת ישירות לשירות המטא-נתונים לצורך אימות והרשאה לממשקי Google API ולשירותי Google.

כשמשתמשים בארגומנט env_vars כדי להגדיר משתנים במהלך הפריסה, הם זמינים בסביבת זמן הריצה של הסוכן (לדוגמה, כשמשתמשים ב-os.environ ב-Python). רוב ספריות הלקוח הרגילות של HTTP מגדירות ומשתמשות אוטומטית במשתני הסביבה האלה כדי לנתב את התנועה דרך ה-proxy שצוין. הגישה הזו נפוצה באפליקציות Python ובספריות לקוח של HTTP כמו requests. כשפורסים סוכנים, צריך להגדיר משתני סביבה לשימוש ב-Secure Web Proxy לכל הדומיינים הפרטיים שהסוכנים צריכים להגיע אליהם. חשוב לוודא שכל יעדי הדומיין הפרטי כלולים גם ב-Cloud DNS.

בדוגמה הבאה מוצגת פריסה של פרוקסי של Agent Runtime מאובייקט של סוכן:

## specify environment variables (dictionary)
env_vars = {
    "OTHER_VARIABLE": "OTHER_VALUE",
    "HTTP_PROXY": "http://swp.example.com:8888",
    "HTTPS_PROXY": "http://swp.example.com:8888",
    "NO_PROXY": "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"
}

remote_agent = aiplatform.agent_engines.create(
    agent=local_agent,
    config={
        "display_name": "Example agent using proxy",
        "env_vars": env_vars,
        ## ... other configs
    },
)

‫Cloud Run תומך בהגדרת משתני סביבה ברמת עדכון השירות. הגישה הזו מבטלת משתני סביבה עם אותו שם שהוגדרו בקובץ האימג' של הקונטיינר. הגישה הזו שימושית להגדרת פרמטרים תפעוליים כמו משתני proxy כשמופעלים מופעי השירות.

בדוגמה הבאה מוצגת הפקודה להגדרת משתני הסביבה כשפורסים שירות Cloud Run:

gcloud run deploy SERVICE_NAME \
--image=IMAGE_URL \
--set-env-vars="HTTP_PROXY=http://swp.example.com:8888,HTTPS_PROXY=http://swp.example.com:8888,NO_PROXY=localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

כדי להטמיע הגדרה מפורשת של שרת Proxy בתרמילים של GKE, צריך להגדיר משאב ConfigMap שמציין את משתני ה-Proxy:

apiVersion: v1
kind: ConfigMap
metadata:
  name: agent-proxy-config
  namespace: ai-apps
data:
  HTTP_PROXY: "http://swp.example.com:8888"
  HTTPS_PROXY: "http://swp.example.com:8888"

  NO_PROXY: "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: subagent-app
spec:
  template:
    spec:
      containers:
      -   name: my-container
        image: my-agent-app:latest
        envFrom:
        -   configMapRef:
            name: agent-proxy-config

שירות CA

CA Service (שירות רשות האישורים) נדרש כשמגדירים את Secure Web Proxy או את Cloud NGFW לבדיקת TLS. כשבדיקת TLS מופעלת ויעד של עומס עבודה משתמש ב-TLS,‏ CA Service יוצר וחותם על אישור עבור היעד הזה. כשנתוני התנועה המוצפנים של היעד האמיתי מגיעים אל Secure Web Proxy או אל Cloud NGFW, השירות מפשיט את ההצפנה מהמנה, בודק אותה ואז אוכף את המדיניות. אם המדיניות מאפשרת את המנה, השירות מצפין מחדש את המנה עבור היעד הסופי. אפשר גם להשתמש ב-CA Service כדי לספק אישורים לשירותים אחרים שמנוהלים על ידי Google.

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

שירות CA תומך ביכולות האלה כדי לאפשר בדיקת תנועה וניהול אישורים בהיקף נרחב בארכיטקטורת AI מרובת סוכנים:

  • בדיקת TLS: כדי לבצע בדיקת TLS מלאה, צריך להשתמש ברשות אישורים פרטית. כדי לפענח ולנתח באופן מלא את נתוני ה-payload של HTTPS, מכשיר ה-proxy המתווך (Secure Web Proxy או Cloud NGFW) צריך לסיים את סשן ה-TLS עם הלקוח. הפרוקסי חייב להציג אישור תקף שהלקוח מקבל כאישור מהימן עבור הדומיין המבוקש.

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

  • הפצת אישורים: משאבי לקוח פנימיים כמו סוכני AI שפועלים ב-Agent Runtime, ב-Cloud Run או ב-GKE צריכים להוסיף את אישור ה-CA הבסיסי הפרטי למאגרי האישורים המהימנים המקומיים שלהם. אחסון המפתח הציבורי של אישור ה-CA הבסיסי ב-Secret Manager מאפשר לסוכני AI לשלוף את האישור בהפעלה ולהוסיף אותו למאגר האישורים המהימנים של המערכת.

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

למידע נוסף על פעולות שקשורות לאישור, אפשר לעיין במקורות המידע הבאים:

אבטחת החיבור בין אפליקציות

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

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

דפוסי קישוריות Agent2Agent‏ (A2A) בין פלטפורמות אירוח שונות, כולל GKE, ‏ Cloud Run ו-Agent Runtime, וחיבורים לשרתי MCP ולאינטרנט.

בתרשים שלמעלה מוצג סיכום של אפשרויות החיבור האלה:

  • המשתמשים יוצרים אינטראקציה עם המערכת מבוססת הסוכנים באמצעות אפליקציית Gemini Enterprise.
  • אפליקציית Gemini Enterprise משתמשת בתשתית של Google כדי להתחבר לסוכן הבסיסי שפועל ב-GKE, ב-Cloud Run או ב-Agent Runtime.
  • אפליקציית Gemini Enterprise והסוכנים הראשיים משתמשים בתשתית של Google כדי להתחבר ל-Model Armor ול-LLM של Gemini ב-Agent Platform.
  • סוכני הבסיס יכולים להשתמש בתשתית של Google כדי להתחבר לסוכני משנה שפועלים ב-Cloud Run או ב-Agent Runtime.
  • סוכני הבסיס יכולים להשתמש בכתובות IP פרטיות כדי להתחבר לסוכני משנה שפועלים ב-Agent Runtime, ב-Cloud Run וב-GKE. החיבורים האלה צריכים להיות מנותבים דרך רשת VPC.
  • גם סוכני הבסיס וגם סוכני המשנה יכולים להתחבר לשרתי MCP שפועלים ב-Cloud Run או ב-GKE. סוכנים שמתחברים לשרתים של MCP יכולים להשתמש בתשתית של Google או ברשת VPC. שרתי ה-MCP מספקים גישה לכלים שמתארחים ב-Google Cloud, בתשתית מקומית, בענן אחר או באינטרנט.
  • אפשר להגיע ישירות לשירותים שמארחים באינטרנט דרך Secure Web Proxy.

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

סוכן המקור של GKE

בטבלה הבאה מפורטים מקורות מידע שיעזרו לכם להגן על התנועה כש-GKE הוא סוכן המקור. התעבורה הזו עוברת דרך רשת ה-VPC שמארחת את אשכול GKE.

סוכן היעד (נתיב הנתונים) בקרת אבטחה
Agent Runtime (פנימי)
‫Cloud Run (פנימי)
Cloud Run (Private Service Connect ל-Google APIs)
גישה ל-Cloud Run (NEG ללא שרת)
GKE
אינטרנט דרך רשת VPC

סוכן מקור (פנימי) של Agent Runtime

בטבלה הבאה מפורטים משאבים שיעזרו לכם להגן על תעבורת הנתונים כש-Agent Runtime הוא סוכן המקור, ותעבורת הנתונים עוברת ישירות דרך התשתית של Google. בנתיבים האלה, לא מעורבת רשת VPC.

סוכן היעד (נתיב הנתונים) בקרת אבטחה
Agent Runtime (פנימי)
‫Cloud Run (פנימי)

סוכן מקור של Agent Runtime (ממשק Private Service Connect)

בטבלה הבאה מפורטים משאבים שיעזרו לכם להגן על התנועה כש-Agent Runtime הוא סוכן המקור והתנועה עוברת דרך ממשק Private Service Connect ברשת VPC.

סוכן היעד (נתיב הנתונים) בקרת אבטחה
‫Cloud Run (Private Service Connect‏ GoogleAPIs)
גישה ל-Cloud Run (NEG ללא שרת)
GKE
אינטרנט דרך רשת VPC

סוכן מקור (פנימי) של Cloud Run

בטבלה הבאה מפורטים מקורות מידע שיעזרו לכם להגן על התנועה כש-Cloud Run הוא סוכן המקור והתנועה עוברת ישירות דרך התשתית של Google. בנתיבים האלה לא מעורבת רשת VPC.

סוכן היעד (נתיב הנתונים) בקרת אבטחה
Agent Runtime (פנימי)
‫Cloud Run (פנימי)

סוכן מקור של Cloud Run (Direct VPC egress)

בטבלה הבאה מפורטים משאבים שיעזרו לכם להגן על תעבורת הנתונים כש-Cloud Run הוא סוכן המקור ותעבורת הנתונים עוברת דרך רשת VPC באמצעות תעבורת נתונים יוצאת (egress) ישירה של VPC.

סוכן היעד (נתיב הנתונים) בקרת אבטחה
‫Cloud Run (Private Service Connect ל-Google APIs)
גישה ל-Cloud Run (NEG ללא שרת)
GKE
אינטרנט דרך רשת VPC
‫Agent Runtime Private Service Connect ל-Google APIs

אבטחת החיבור ל-MCP

הרשימה הבאה מפרטת את פלטפורמות האירוח ואת אמצעי הבקרה של הגנה לעומק שמשתתפים באבטחת נתיב הנתונים בין זמני הריצה של הסוכן לבין שרתי MCP. עבור סוכני מקור ב-Agent Runtime, ב-Cloud Run או ב-GKE, משתמשים באמצעי האבטחה הבאים בהתאם לשרת היעד של MCP:

  • אינטרנט:
    • VPC Service Controls
    • הגנה מוגברת על המודל
    • Cloud NGFW
    • Secure Web Proxy
  • ‫Google MCP:
    • VPC Service Controls
    • הגנה מוגברת על המודל

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

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים: