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

Last reviewed 2026-11-09 UTC

במסמך הזה מוסבר איך לתכנן תשתית של רשת פרטית שתומכת באפליקציה עם כמה סוכנים ב-Gemini Enterprise, שנגישה לכולם וכוללת חיבורים פרטיים בין סוכנים, סוכני משנה וכלים. עיצוב הרשת מספק חיבורים פרטיים לסוכנים שמתארחים ב-Agent Runtime ב-Gemini Enterprise Agent Platform, ב-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 ו-Direct VPC egress ב-Cloud Run. ‫Cloud Next Generation Firewall‏ (Cloud NGFW) מנהל את התנועה שעוברת ברשת ה-VPC. שכבות אבטחה נוספות מספקות תעבורת נתונים מבוקרת לאינטרנט באמצעות Secure Web Proxy, ומדיניות גישה לשירותי API באמצעות היקף של VPC Service Controls.

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

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

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

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

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

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

  • אפליקציית 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, רשתות משנה, קישור בין רשתות שכנות (peering) ב-DNS ומדיניות חומת אש.
  • מפתחי אפליקציות AI יוצרים סוכנים בפרויקטים מצורפים של שירותים בלי הרשאות לשינוי תשתית הרשת הבסיסית.

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

אתם יכולים לשלב את רשת ה-VPC המשותפת ב-Cross-Cloud Network באמצעות שימוש ב-VPC spokes של 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 APIs דרך גישה פרטית ל-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 באמצעות אפליקציה מבוססת-דפדפן ששולחת בקשות לממשקי API ולשירותים של Google. כדי לאפשר קישוריות פרטית של משתמשים, אתם יכולים להגדיר את כתובות ה-URL של Google API כך שיפנו לטווחי כתובות IP פרטיות שמנותבות דרך רשת ה-VPC. מידע נוסף זמין במאמר הגדרת גישה פרטית לממשק המשתמש.

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

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

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

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

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

  • סוכנים בהתאמה אישית ב-GKE: אפליקציות Gemini Enterprise משתמשות בזהות של סוכן השירות Agent Platform Discovery Engine כדי לבצע קריאות לכתובת ה-URL שרשומה בכרטיס הסוכן. שרת ה-DNS הציבורי צריך להיות מסוגל לתרגם את שם המארח לכתובת IP חיצונית שמנוהלת על ידי השער. מומלץ להשתמש במאזן העומסים של gke-l7-regional-external-managed או במאזן העומסים של gke-l7-global-external-managed. כדי לשפר את האבטחה, מומלץ ש-Gemini Enterprise יקרא לסוכן A2A שמתארח ב-GKE באמצעות שרת proxy לאימות זהויות (IAP). כדי ש-IAP יאשר את הקריאות האלה, צריך להקצות לסוכן השירות של Discovery Engine את התפקיד "משתמש באפליקציית אינטרנט שמאובטחת באמצעות IAP"‏ (roles/iap.httpsResourceAccessor) ב-IAM. רשת הייצור של 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: תעבורת נתונים יוצאת (egress) ישירה של VPC ב-Cloud Run מחברת את המכונות של שירות Cloud Run לרשת ה-VPC. רשת ה-VPC שמצוינת כשפורסים שירות Cloud Run יכולה להיות מהפרויקט של שירות Cloud Run או מהפרויקט המארח של ה-VPC המשותף. תעבורת הנתונים שנשלחת מ-Cloud Run מופיעה ברשת ה-VPC כאילו היא הגיעה מכתובת ה-IP של רשת המשנה של תעבורת הנתונים היוצאת של Direct VPC. לאחר מכן, רשת ה-VPC מנתבת את התנועה לכתובת ה-IP המתאימה של היעד.
  • סוכנים בהתאמה אישית ב-GKE: אשכולות GKE נמצאים ישירות ברשת ה-VPC ומשתמשים בכתובות IP של רשתות משנה מקומיות. כברירת מחדל, תעבורת הנתונים היוצאת של GKE משתמשת בכתובת ה-IP של ה-Pod ככתובת ה-IP של המקור. אם מגדירים הסוואה, תנועת הנתונים היוצאת ב-GKE משתמשת בכתובת ה-IP של הצומת ככתובת ה-IP של המקור. כל תעבורת הנתונים היוצאת של GKE מנותבת על ידי רשת ה-VPC.

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

רשתות ב-Agent Runtime

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

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

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

תעבורת נתונים יוצאת מ-Agent Runtime לרשת ה-VPC

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

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

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

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

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

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

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

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

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

תעבורת נתונים יוצאת מ-Agent Runtime שמשתמשת בממשקי Private Service Connect יכולה לנתב רק לטווחי כתובות IP מסוג RFC 1918 ברשת ה-VPC. במאמר דרישות לטווח כתובות IP של רשת משנה מפורטים טווחי יעדים ספציפיים שאי אפשר לנתב באמצעות תעבורת נתונים יוצאת של Agent Runtime. כדי להגיע ליעדים בטווח של כתובות 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. יוצרים רשומת DNS ב-Cloud DNS לשם המארח של Secure Web Proxy.
  3. מגדירים קישור בין רשתות שכנות (peering) ב-DNS ל-Agent Runtime כדי לתמוך בפתרון שאילתות DNS של הסוכן לכתובת הפרטית של Secure Web Proxy ברשת ה-VPC.
  4. כשפורסים סוכנים, צריך לבצע את הפעולות הבאות:
    1. מגדירים משתני סביבה לשימוש בשרת ה-proxy המפורש, על ידי ציון שם המארח והיציאה של Secure Web Proxy.
    2. אם אתם ניגשים ליעד פרטי, הגדירו תחום DNS פרטי ליעד הזה.

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

רשתות ב-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 לממשקי Google API אחרים דרך הרשת הפנימית של Google.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

רשתות ב-GKE

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

‫GKE ו-Gemini Enterprise

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

אשכולות GKE הם צומתי VM של 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, כולל מישור הבקרה, הקצאת הצמתים, הקשחת האבטחה וההתאמה לעומס.
  • Standard: Google מנהלת את מישור הבקרה. אתם אחראים באופן מלא על ההגדרות של מאגרי הצמתים, כמו בחירת סוגי המכונות, ניהול קובצי האימג' של מערכת ההפעלה ושינוי ידני של קנה המידה.
הקשחת התשתית ומישור הבקרה
  • אשכולות GKE פרטיים: הקצאת צמתים ללא כתובות IP ציבוריות, כדי לוודא שסביבת זמן הריצה מבודדת מחשיפה ישירה לאינטרנט.
  • רשתות מורשות של מאסטר: הגבלת הגישה הניהולית ל-Kubernetes API לטווחי כתובות IP ספציפיים ומהימנים, כדי להקשיח את מישור הבקרה מפני שינויים לא מורשים בהגדרות. אבטחת נקודת הקצה של ה-DNS ל-Kubernetes API באמצעות IAM ו-VPC Service Controls של Google Cloud.
זהות וגישה (אפס אמון)
  • ‫IAP: פועל כשומר סף ברמת מאזן העומסים. הוא מבטיח שרק משתמשים מאומתים עם הרשאות IAM מתאימות יוכלו לגשת ל-Agent Endpoint. הגישה הזו מעבירה למעשה את היקף האבטחה מהרשת למשתמש הספציפי ולהקשר של המכשיר שלו.
הגנה על הקצה וניהול תנועה
  • ‫Cloud Armor: מספק אבטחה חזקה בקצה, כולל כללים של חומת אש ליישומי אינטרנט (WAF) שעוזרים לחסום מטענים ייעודיים זדוניים, הגנה מפני מתקפות DDoS שעוזרת להבטיח זמן פעולה תקינה והגבלת קצב של יצירת בקשות שעוזרת למנוע ניצול יתר של השירות.
  • הגנה מוגברת על המודל: כלי שנועד במיוחד לשמירה על הבטיחות של מודלי LLM. הוא בודק ומסנן פרומפטים ותשובות בזמן אמת כדי למנוע החדרת פרומפטים וזליגת נתונים.
בידוד רשת פנימית
  • מדיניות רשת ב-Kubernetes: אכיפת תקשורת מפורטת עם הרשאות מינימליות בין מיקרו-שירותים (microservices). כברירת מחדל, כללי המדיניות דוחים את כל התנועה, אלא אם מאשרים אותה באופן מפורש, וכך נמנעת תנועה רוחבית בתוך האשכול.

תעבורת נתונים יוצאת מ-GKE לרשת ה-VPC

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

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

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

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

תעבורת נתונים נכנסת ל-GKE מרשת ה-VPC

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

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

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

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

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

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

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

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

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

Cloud NGFW

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

‫Cloud NGFW הוא שירות חומת אש מבוזר שמובנה במארג של רשת ה-VPC. הוא מציע את רמות התכונות הבאות, שפועלות בשכבות שונות של מקבץ הרשת (network stack):

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

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

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

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

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

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

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

  • יצירת מדיניות וכללים של חומת אש ברשת: יוצרים מדיניות חומת אש גלובלית או אזורית ומשייכים אותה לרשת ה-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 או בתת-הרשת של תעבורת הנתונים היוצאת (egress) של Direct VPC ב-Cloud Run, אל היעדים הרצויים.
  • כלל DENY כללי: כדי לוודא שהכלל יהיה אחרון בסדר ההערכה, משתמשים במספר העדיפות הגבוה ביותר, למשל 2147483647. הכלל הזה דוחה תנועה לכל יעד (--dest-ip-ranges=0.0.0.0/0) שלא תואם לאף אחד מ-ALLOW הכללים הקודמים.

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

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

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

  • התכונות של Cloud NGFW Standard:
    • אובייקטים של 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: לסוכנים שמטפלים במידע רגיש או שחשופים לסיכונים גבוהים יותר, בדקו את המטען הייעודי (payload) של החבילות כדי לאתר איומים כמו תוכנות זדוניות, רוגלות וניצול לרעה שלא מנותחים על ידי כללי חומת האש של שכבת הרשת.
    • בדיקת TLS: כדי לאפשר למנוע הבדיקה לנתח תנועה מוצפנת, מפעילים את בדיקת ה-TLS. השימוש בבדיקת TLS הוא חיוני כי רוב המתקפות המודרניות ותקשורת C2 מוצפנות.

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

IAP

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

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

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

VPC Service Controls

VPC Service Controls מצמצם את הסיכונים לזליגת נתונים על ידי שליטה קפדנית בגישה ל-Google APIs. מומלץ לפרוס היקף מאקרו אחד שכולל את כל השירותים הנתמכים. הגישה הזו מספקת את ההגנה החזקה ביותר מפני זליגת נתונים. כדי להבטיח אכיפה עקבית של המדיניות בארכיטקטורות של 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) בשירות היעד. התפקיד נבדק על ידי אימות של טוקן מהכותרת Authorization (או מהכותרת X-Serverless-Authorization כש-Gemini Enterprise קורא לכתובת URL של .run.app כברירת מחדל). כדי לשלוח קריאה לשירות Cloud Run, צריך לתת לחשבונות השירות, כמו אלה שמשמשים את Gemini Enterprise, גם את התפקיד "מפעיל Cloud Run".

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

  • יש תמיכה ב-Ingress של Cloud Run all כששני התנאים הבאים מתקיימים (true):
    • ‫VPC Service Controls לא מופעל.
    • ‫Cloud Run ו-Gemini Enterprise לא נמצאים באותו פרויקט.
  • בכל שאר ההגדרות, יש תמיכה רק בתעבורת הנתונים הנכנסת internal של Cloud Run.

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

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

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

Model Armor

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

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

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

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

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

מידע נוסף על הפעלת Model Armor זמין במקורות המידע הבאים:

Cloud Armor

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

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

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

Secure Web Proxy

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

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

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

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

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

כדי שהסוכנים יוכלו להגיע ליעדים באינטרנט או לטווחי כתובות IP שלא ניתנים לניתוב ברשת ה-VPC, צריך להגדיר במפורש שרת proxy לתעבורת הנתונים היוצאת של Agent Runtime. כדי לאפשר יכולת פעולה הדדית של 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. יוצרים רשומת Cloud DNS לשם המארח של Secure Web Proxy (לדוגמה, swp.example.com) שמפנה לכתובת ה-IP של המשאב של Secure Web Proxy.
  3. כדי לאפשר יכולת פעולה הדדית של Agent Runtime, צריך להגדיר קישור בין רשתות שכנות (peering) ב-DNS מ-Agent Runtime לאזור הפרטי של Cloud DNS שמשויך לרשת ה-VPC. כשהסוכנים שולחים בקשות ל-Secure Web Proxy, ‏Cloud DNS מבצע פענוח DNS של בקשות שם המארח לכתובת ה-IP של המשאב של Secure Web Proxy ברשת ה-VPC. השלב הזה לא נדרש לנציגים שמתארחים ב-Cloud Run וב-GKE.

הגדרות שרת ה-Proxy של הסוכן

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

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

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

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

import agentplatform

client = agentplatform.Client(
    project="PROJECT_ID",
    location="LOCATION",
)

## 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 = client.runtimes.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 יוצר וחותם על אישור ליעד הזה. כשהתנועה המוצפנת ליעד האמיתי מגיעה ל-Secure Web Proxy או ל-Cloud NGFW, המערכת מפענחת את החבילה, בודקת אותה ואז אוכפת את כללי המדיניות. אם המדיניות מאפשרת את חבילת הנתונים, השירות מצפין מחדש את חבילת הנתונים ליעד הסופי. אפשר גם להשתמש בשירות CA כדי לספק אישורים לשירותים מנוהלים אחרים של Google.

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

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

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

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

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

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

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

אבטחת החיבור של A2A

סוכני הבסיס מתקשרים עם מגוון רחב של סוכני משנה ושרתי 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 (קבוצת נקודות קצה ללא שרת)
GKE
אינטרנט דרך רשת VPC

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

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

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

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

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

סוכן היעד (נתיב הנתונים) אמצעי בקרה לאבטחה
‫Cloud Run (‏Private Service Connect לממשקי Google APIs)
גישה ל-Cloud Run (קבוצת נקודות קצה ללא שרת)
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 (קבוצת נקודות קצה ללא שרת)
GKE
אינטרנט דרך רשת VPC
‫Agent Runtime (‏Private Service Connect לממשקי Google API)

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

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

  • אינטרנט:
    • VPC Service Controls
    • Model Armor
    • Cloud NGFW
    • Secure Web Proxy
  • Google MCP:
    • VPC Service Controls
    • Model Armor

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

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

מחברים:

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