מתן אפשרות גישה למשאבים מוגנים מנקודת קצה פרטית בתוך גבולות גזרה של VPC Service Controls

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

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

במדיניות השירות נעשה שימוש במאפיינים הבאים:

• היקפי האבטחה של VPC Service Controls
• כתובות IP פרטיות ב-Access Context Manager
• כללים לתעבורת נתונים נכנסת (ingress) ויוצאת (egress)

ברכיב הרשת, הארכיטקטורה הזו משתמשת בנקודת קצה (endpoint) של Private Service Connect כדי לגשת לממשקי Google API.

בארכיטקטורה לדוגמה הזו, כללי תעבורת הנתונים הנכנסת והיוצאת וכתובות ה-IP הפרטיות משמשים כדי לשלוט בגישה בין מכונות Compute Engine לבין Agent Platform API, בשביל גבולות הגזרה לשירות והפרויקטים הבאים:

גבולות גזרה	פרויקטים בתוך ההיקף
aiml-host-perimeter	aiml-host-project
high-trust-svc-perimeter	ph-fm-svc-project-1
low-trust-svc-perimeter	ph-fm-svc-project-2, ph-fm-svc-project-3

הגישה ל-Agent Platform API ממכונות Compute Engine של כל פרויקט שירות נשלטת על ידי כללי תעבורת הנתונים הנכנסת והיוצאת של VPC Service Controls. הכללים האלה משתמשים ברמות הגישה של Access Context Manager שמוגדרות עם כתובות IP פרטיות, כדי לאפשר לרשתות המשנה שמשותפות עם כל פרויקט שירות לגשת למתחמי האבטחה שלהן.

אופציונלי: יצירת רמת גישה לתנועה ציבורית של הארגון

אם משתמשי הקצה צריכים גישה ל-Gemini Enterprise Agent Platform דרך מסוףGoogle Cloud , צריך לפעול לפי ההוראות בקטע הזה כדי ליצור רמת גישה לשימוש ב-VPC Service Controls. עם זאת, אם הגישה לממשקי ה-API היא פרוגרמטית בלבד ממקורות פרטיים (כמו מקומית באמצעות גישה פרטית ל-Google למארחים מקומיים או Cloud Workstations), לא צריך את רמת הגישה.

בארכיטקטורה לדוגמה הזו אנחנו משתמשים בטווח CIDR,‏ corp-public-block, כדי לאפשר לתנועה של עובדי הארגון לגשת למסוףGoogle Cloud .

בעזרת Access Context Manager, Google Cloud מנהלי ארגונים יכולים להגדיר בקרת גישה פרטנית שמבוססת על מאפיינים למשאבים ב- Google Cloud.

רמות הגישה מתארות את הדרישות שצריך לעמוד בהן כדי שהבקשות יאושרו. דוגמאות:

• סוג המכשיר ומערכת ההפעלה (נדרש רישיון ל-Chrome Enterprise Premium)
• כתובת IP
• מיקומים גיאוגרפיים
• זהות המשתמש

אם זו הפעם הראשונה שהארגון משתמש ב-Access Context Manager, אדמיני ממחלקת IT שלו צריכים להגדיר מדיניות גישה, שהיא מאגר של רמות גישה וגבולות גזרה לשירות. כך עושים את זה:

1. בבורר הפרויקטים שבחלק העליון של מסוף Google Cloud , לוחצים על הכרטיסייה All ובוחרים את הארגון.
2. יוצרים רמת גישה בסיסית לפי ההוראות בדף יצירת רמת גישה בסיסית. מציינים את האפשרויות הבאות:
   1. בקטע יצירת תנאים ב, בוחרים באפשרות מצב בסיסי.
   2. בשדה Access level title, מזינים corp-public-block.
   3. בקטע Conditions, באפשרות When condition is met, return בוחרים באפשרות TRUE.
   4. בקטע רשתות משנה של כתובות IP, בוחרים באפשרות כתובת IP ציבורית.
   5. בטווח של כתובות ה-IP, מציינים את טווח ה-CIDR החיצוני שצריך גישה להיקף של VPC Service Controls.

בניית גבולות הגזרה לשירות של VPC Service Controls

כשיוצרים גבולות גזרה לשירות, אחת מהדרכים לאפשר גישה לשירותים מוגנים מחוץ לגבולות הגזרה היא ליצור רמות גישה (באמצעות כתובות IP, בדוגמה שלנו). בארכיטקטורה לדוגמה הזו, נוצרים כמה גבולות גזרה לשירות שמשתמשים בכללי כניסה ויציאה כדי לשלוט בגישה לתקשורת של Agent Platform API ו-Compute Engine API, באופן הבא:

• לרשת המשנה של משאבי המחשוב ששייכים לפרויקט השירות ph-fm-svc-project-1 יש גישה ל-Agent Platform API ול-Compute Engine API ב-ph-fm-svc-project-1 מ-aiml-host-project.
• לרשת המשנה של משאבי המחשוב ששייכים לפרויקטים של השירות ph-fm-svc-project-2 ו-ph-fm-svc-project-3 יש גישה ל-Agent Platform API ול-Compute Engine API בפרויקט ph-fm-svc-project-2 ובפרויקט ph-fm-svc-project-3 מ-aiml-host-project.

לכל פרויקט שירות יש גישה ל-Compute Engine API בפרויקט המארח (כי מתרחשים תהליכים דו-כיווניים בין הפרויקט המארח לפרויקטי השירות כשנוצרים משאבי מחשוב בפרויקט שירות נתון).

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

יצירה של רמת הגישה gce-subnet-1

1. בבורר הפרויקטים שבחלק העליון של מסוף Google Cloud , לוחצים על הכרטיסייה All ובוחרים את הארגון.
2. יוצרים רמת גישה בסיסית לפי ההוראות בדף יצירת רמת גישה בסיסית. מציינים את האפשרויות הבאות:
   1. בקטע יצירת תנאים ב, בוחרים באפשרות מצב בסיסי.
   2. בשדה Access level title, מזינים gce-subnet-1.
   3. בקטע Conditions, באפשרות When condition is met, return בוחרים באפשרות TRUE.
   4. בקטע IP Subnetworks, בוחרים באפשרות Private IP.
   5. בוחרים באפשרות רשתות VPC, מזהים את הפרויקט ובוחרים את שם ה-VPC.
   6. בשדה IP Subnetworks, בוחרים את טווח ה-CIDR שמייצג את רשת המשנה שהפרויקט המארח שיתף עם ph-fm-svc-project-1.

יצירה של רמת הגישה gce-subnet-2

1. בבורר הפרויקטים שבחלק העליון של מסוף Google Cloud , לוחצים על הכרטיסייה All ובוחרים את הארגון.
2. יוצרים רמת גישה בסיסית לפי ההוראות בדף יצירת רמת גישה בסיסית. מציינים את האפשרויות הבאות:
   1. בקטע יצירת תנאים ב, בוחרים באפשרות מצב בסיסי.
   2. בשדה Access level title, מזינים gce-subnet-2.
   3. בקטע Conditions, באפשרות When condition is met, return בוחרים באפשרות TRUE.
   4. בקטע IP Subnetworks, בוחרים באפשרות Private IP.
   5. בוחרים באפשרות רשתות VPC, מזהים את הפרויקט ובוחרים את שם ה-VPC.
   6. בשדה IP Subnetworks, בוחרים את טווח ה-CIDR שמייצג את רשת המשנה שהפרויקט המארח שיתף עם ph-fm-svc-project-2.

יצירה של רמת הגישה gce-subnet-3

1. בבורר הפרויקטים שבחלק העליון של מסוף Google Cloud , לוחצים על הכרטיסייה All ובוחרים את הארגון.
2. יוצרים רמת גישה בסיסית לפי ההוראות בדף יצירת רמת גישה בסיסית. מציינים את האפשרויות הבאות:
   1. בקטע יצירת תנאים ב, בוחרים באפשרות מצב בסיסי.
   2. בשדה Access level title, מזינים gce-subnet-3.
   3. בקטע Conditions, באפשרות When condition is met, return בוחרים באפשרות TRUE.
   4. בקטע IP Subnetworks, בוחרים באפשרות Private IP.
   5. בוחרים באפשרות רשתות VPC, מזהים את הפרויקט ובוחרים את שם ה-VPC.
   6. בשדה IP Subnetworks, בוחרים את טווח ה-CIDR שמייצג את רשת המשנה שהפרויקט המארח שיתף עם ph-fm-svc-project-3.

שלבי ההגדרה של aiml-host-perimeter

בוחרים את סוג ההגדרה של המתחם החדש.

בקטע הזה תיצרו גבולות גזרה לשירות של VPC Service Controls (aiml-host-perimeter) במצב פרימטר לבדיקות. במצב פרימטר לבדיקות, הפרימטר מתעד הפרות כאילו הפרימטרים נאכפים, אבל לא מונע גישה לשירותים מוגבלים. מומלץ להשתמש במצב פרימטר לבדיקות לפני שעוברים למצב אכיפה.

1. בתפריט הניווט במסוף Google Cloud , לוחצים על Security ואז על VPC Service Controls.

   מעבר אל "אבטחה"

2. אם צריך, בוחרים את הארגון, התיקייה או הפרויקט.

3. בדף VPC Service Controls, לוחצים על מצב פרימטר לבדיקות.

4. לוחצים על New perimeter.

5. בכרטיסייה New VPC Service Perimeter, בתיבה Perimeter Name, מקלידים שם להיקף, לדוגמה aiml-host-perimeter.

   שם של מתחם יכול להכיל עד 50 תווים, חייב להתחיל באות ויכול להכיל רק אותיות לטיניות ב-ASCII‏ (a-z, A-Z), מספרים (0-9) וקווים תחתונים (_). השם של המתחם הוא תלוי אותיות רישיות (case-sensitive) וחייב להיות ייחודי במדיניות הגישה.

6. מאשרים את הגדרות ברירת המחדל של המתחם.

בחירת המשאבים שרוצים להגן עליהם

1. לוחצים על Resources to protect.
2. כדי להוסיף פרויקטים או רשתות VPC שרוצים לאבטח בתוך ההיקף:
   1. לוחצים על הוספת מקורות מידע.
   2. כדי להוסיף פרויקטים למתחם, בחלונית Add resources לוחצים על Add project.
      1. בוחרים את הפרויקט שרוצים להוסיף, במקרה הזה aiml-host-project.
      2. לוחצים על הוספת המשאבים שנבחרו. הפרויקטים שנוספו מופיעים בקטע Projects.

בחירת השירותים המוגבלים

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

הערה: הדוגמה הזו מציגה דפוס להטמעה בסיסית של Gemini Enterprise Agent Platform. אם אתם משתמשים בשירותים נוספים של Gemini Enterprise Agent Platform או Gemini, הוסיפו את השירותים האלה לרשימת השירותים המוגבלים.

כדי לבחור את השירותים שרוצים לאבטח בתוך המתחם:

1. לוחצים על שירותים מוגבלים.
2. בחלונית Restricted Services, לוחצים על Add services.
3. בתיבת הדו-שיח Specify services to restrict, בוחרים באפשרות Compute Engine API.
4. לוחצים על Add Compute Engine API.

אופציונלי: בחירת השירותים הנגישים ל-VPC

ההגדרה שירותים נגישים ל-VPC מגבילה את קבוצת השירותים שאפשר לגשת אליהם מנקודות קצה ברשת בתוך גבולות הגזרה לשירות. בארכיטקטורה לדוגמה הזו, אנחנו משאירים את הגדרת ברירת המחדל All Services.

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

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

1. לוחצים על רמות גישה.

2. לוחצים על התיבה בחירת רמת הגישה.

   אפשר גם להוסיף רמות גישה אחרי שיוצרים את ההיקף.

3. מסמנים את התיבה שמתאימה לרמת הגישה. (בארכיטקטורה הזו, זהו corp-public-block.)

הגדרת מדיניות הכניסה

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

1. בתפריט הימני, לוחצים על Ingress policy.
2. לוחצים על הוספת כלל.
3. בחלונית Ingress rule:
   1. בקטע FROM attributes, בוחרים את מאפייני ה-FROM הבאים של לקוח ה-API:
      1. זהות: כל זהות
      2. מקור: פרויקטים (ph-fm-svc-project-1,‏ ph-fm-svc-project-2,‏ ph-fm-svc-project-3)
   2. בקטע TO attributes, בוחרים את מאפייני היעד הבאים של השירותים והמשאבים ב- Google Cloud:
      1. ‫Project: כל הפרויקטים
      2. שירותים: השירותים שנבחרו
      3. Selected services: Compute Engine API
      4. שיטות: כל השיטות

הגדרת מדיניות תעבורת הנתונים היוצאת

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

כלל ראשון לתעבורת נתונים יוצאת (egress)

מכיוון שפרויקט המארח הוא הבעלים של רשת המשנה שמשותפת עם ph-fm-svc-project-1, נדרש כלל תעבורת נתונים יוצאת כדי לאפשר לרשת המשנה הזו לגשת להיקף של ph-fm-svc-project-1 מההיקף של פרויקט המארח. רמת הגישה הארגונית מאפשרת את התקשורת הדו-כיוונית שנדרשת ליצירת מכונה, כשמשתמש קצה יוצר משאבי מחשוב בפרויקט שירות באמצעות רמת הגישה שהוגדרה.

1. בתפריט הימני, לוחצים על Egress policy.
2. לוחצים על הוספת כלל.
3. בחלונית Egress rule:
   1. בקטע FROM attributes, בוחרים את מאפייני ה-FROM הבאים של לקוח ה-API:
      1. זהות: כל זהות
      2. בוחרים באפשרות Enable access level egress sources.
      3. רמות הגישה corp-public-block ו-gce-subnet-1.
   2. בקטע TO attributes, בוחרים את מאפייני היעד הבאים של השירותים והמשאבים ב- Google Cloud:
      1. ‫Project: הפרויקטים שנבחרו
      2. הוספת פרויקט: ph-fm-svc-project-1
      3. ‫Services: כל השירותים

כלל שני לתעבורת נתונים יוצאת (egress)

מכיוון שהפרויקט המארח הוא הבעלים של רשתות המשנה שמשותפות עם ph-fm-svc-project-2 ו-ph-fm-svc-project-3, נדרש כלל תעבורת נתונים יוצאת כדי לאפשר לרשתות המשנה האלה לגשת להיקף של פרויקטי השירות מההיקף של הפרויקט המארח. רמת הגישה הארגונית מאפשרת תקשורת דו-כיוונית שנדרשת ליצירת מכונה, כשמשתמש קצה יוצר משאבי מחשוב בפרויקט שירות באמצעות רמת הגישה שהוגדרה.

1. בתפריט הימני, לוחצים על Egress policy.
2. לוחצים על הוספת כלל.
3. בחלונית Egress rule:
   1. בקטע FROM attributes, בוחרים את מאפייני ה-FROM הבאים של לקוח ה-API:
      1. זהות: כל זהות
      2. בוחרים באפשרות Enable access level egress sources.
      3. רמות הגישה corp-public-block,‏ gce-subnet-2 ו-gce-subnet-3.
   2. בקטע TO attributes, בוחרים את מאפייני היעד הבאים של השירותים והמשאבים ב- Google Cloud:
      1. ‫Project: הפרויקטים שנבחרו
      2. הוספת פרויקט: ph-fm-svc-project-2, ph-fm-svc-project-3
      3. ‫Services: כל השירותים

יצירת ההיקף

אחרי שביצעתם את שלבי ההגדרה הקודמים, לוחצים על Create perimeter כדי ליצור את ההיקף.

שלבי ההגדרה של high-trust-svc-perimeter

בוחרים את סוג ההגדרה של המתחם החדש.

1. בתפריט הניווט במסוף Google Cloud , לוחצים על Security ואז על VPC Service Controls.

   מעבר אל "אבטחה"

2. אם צריך, בוחרים את הארגון, התיקייה או הפרויקט.

3. בדף VPC Service Controls, לוחצים על מצב פרימטר לבדיקות.

4. לוחצים על New perimeter.

5. בכרטיסייה New VPC Service Perimeter, בתיבה Perimeter Name, מקלידים שם להיקף, לדוגמה high-trust-svc-perimeter.

   שם של מתחם יכול להכיל עד 50 תווים, חייב להתחיל באות ויכול להכיל רק אותיות לטיניות ב-ASCII‏ (a-z, A-Z), מספרים (0-9) וקווים תחתונים (_). השם של המתחם הוא תלוי אותיות רישיות (case-sensitive) וחייב להיות ייחודי במדיניות הגישה.

6. מאשרים את הגדרות ברירת המחדל של המתחם.

בחירת המשאבים שרוצים להגן עליהם

1. לוחצים על Resources to protect.
2. כדי להוסיף פרויקטים או רשתות VPC שרוצים לאבטח בתוך ההיקף:
   1. לוחצים על הוספת מקורות מידע.
   2. כדי להוסיף פרויקטים למתחם, בחלונית Add resources לוחצים על Add project.
      1. בוחרים את הפרויקט שרוצים להוסיף, במקרה הזה ph-fm-svc-project-1.
      2. לוחצים על הוספת המשאבים שנבחרו. הפרויקטים שנוספו מופיעים בקטע Projects.

בחירת השירותים המוגבלים

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

הערה: הדוגמה הזו מציגה דפוס להטמעה בסיסית של Gemini Enterprise Agent Platform. אם אתם משתמשים בשירותים נוספים של Gemini Enterprise Agent Platform או Gemini, הוסיפו את השירותים האלה לרשימת השירותים המוגבלים.

כדי לבחור את השירותים שרוצים לאבטח בתוך המתחם:

1. לוחצים על שירותים מוגבלים.
2. בחלונית Restricted Services, לוחצים על Add services.
3. בתיבת הדו-שיח Specify services to restrict, בוחרים באפשרות Compute Engine API.
4. לוחצים על Add Compute Engine API.
5. בחלונית Restricted Services, לוחצים על Add services.
6. בתיבת הדו-שיח Specify services to restrict, בוחרים באפשרות Agent Platform API.
7. לוחצים על Add Agent Platform API.

אופציונלי: בחירת השירותים הנגישים ל-VPC

ההגדרה שירותים נגישים ל-VPC מגבילה את קבוצת השירותים שאפשר לגשת אליהם מנקודות קצה ברשת בתוך גבולות הגזרה לשירות. בארכיטקטורה לדוגמה הזו, אנחנו משאירים את הגדרת ברירת המחדל All Services.

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

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

1. לוחצים על רמות גישה.

2. לוחצים על התיבה בחירת רמת הגישה.

   אפשר גם להוסיף רמות גישה אחרי שיוצרים את ההיקף.

3. מסמנים את התיבה שמתאימה לרמת הגישה. (בארכיטקטורה הזו, זהו corp-public-block.)

הגדרת מדיניות הכניסה

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

1. בתפריט הימני, לוחצים על Ingress policy.
2. לוחצים על הוספת כלל.
3. בחלונית Ingress rule:
   1. בקטע FROM attributes, בוחרים את מאפייני ה-FROM הבאים של לקוח ה-API:
      1. זהות: כל זהות
      2. מקור: רמת הגישה
      3. רמת הגישה: gce-subnet-1
   2. בקטע TO attributes, בוחרים את מאפייני היעד הבאים של השירותים והמשאבים ב- Google Cloud:
      1. ‫Project: כל הפרויקטים
      2. ‫Services: כל השירותים

הגדרת מדיניות תעבורת הנתונים היוצאת

מכיוון שהפרויקט המארח הוא הבעלים של רשת המשנה שמשותפת עם ph-fm-svc-project-1, נדרש כלל תעבורת נתונים יוצאת כדי לאפשר את התקשורת הדו-כיוונית שמתרחשת בין פרויקט השירות לבין הפרויקט המארח שלו כשנוצרים משאבי מחשוב בפרויקט השירות.

1. בתפריט הימני, לוחצים על Egress policy.
2. לוחצים על הוספת כלל.
3. בחלונית Egress rule:
   1. בקטע FROM attributes, בוחרים את מאפייני ה-FROM הבאים של לקוח ה-API:
      1. זהות: כל זהות
   2. בקטע TO attributes, בוחרים את מאפייני היעד הבאים של השירותים והמשאבים ב- Google Cloud:
      1. ‫Project: הפרויקטים שנבחרו
      2. הוספת פרויקט: aiml-host-project
      3. שירותים: השירותים שנבחרו
      4. Selected services: Compute Engine API
      5. שיטות: כל השיטות

יצירת ההיקף

אחרי שביצעתם את שלבי ההגדרה הקודמים, לוחצים על Create perimeter כדי ליצור את ההיקף.

שלבי ההגדרה של low-trust-svc-perimeter

בוחרים את סוג ההגדרה של המתחם החדש.

1. בתפריט הניווט במסוף Google Cloud , לוחצים על Security ואז על VPC Service Controls.

   מעבר אל "אבטחה"

2. אם צריך, בוחרים את הארגון, התיקייה או הפרויקט.

3. בדף VPC Service Controls, לוחצים על מצב פרימטר לבדיקות.

4. לוחצים על New perimeter.

5. בכרטיסייה New VPC Service Perimeter, בתיבה Perimeter Name, מקלידים שם להיקף, לדוגמה low-trust-svc-perimeter.

   שם של מתחם יכול להכיל עד 50 תווים, חייב להתחיל באות ויכול להכיל רק אותיות לטיניות ב-ASCII‏ (a-z, A-Z), מספרים (0-9) וקווים תחתונים (_). השם של המתחם הוא תלוי אותיות רישיות (case-sensitive) וחייב להיות ייחודי במדיניות הגישה.

6. מאשרים את הגדרות ברירת המחדל של המתחם.

בחירת המשאבים שרוצים להגן עליהם

1. לוחצים על Resources to protect.
2. כדי להוסיף פרויקטים או רשתות VPC שרוצים לאבטח בתוך ההיקף:
   1. לוחצים על הוספת מקורות מידע.
   2. כדי להוסיף פרויקטים למתחם, בחלונית Add resources לוחצים על Add project.
      1. בוחרים את הפרויקט שרוצים להוסיף. בארכיטקטורה לדוגמה הזו, בוחרים את האפשרויות הבאות:
         • ph-fm-svc-project-2
         • ph-fm-svc-project-3
      2. לוחצים על הוספת המשאבים שנבחרו. הפרויקטים שנוספו מופיעים בקטע Projects.

בחירת השירותים המוגבלים

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

הערה: הדוגמה הזו מציגה דפוס להטמעה בסיסית של Gemini Enterprise Agent Platform. אם אתם משתמשים בשירותים נוספים של Gemini Enterprise Agent Platform או Gemini, הוסיפו את השירותים האלה לרשימת השירותים המוגבלים.

כדי לבחור את השירותים שרוצים לאבטח בתוך המתחם:

1. לוחצים על שירותים מוגבלים.
2. בחלונית Restricted Services, לוחצים על Add services.
3. בתיבת הדו-שיח Specify services to restrict, בוחרים באפשרות Compute Engine API.
4. לוחצים על Add Compute Engine API.
5. בחלונית Restricted Services, לוחצים על Add services.
6. בתיבת הדו-שיח Specify services to restrict, בוחרים באפשרות Agent Platform API.
7. לוחצים על Add Agent Platform API.

אופציונלי: בחירת השירותים הנגישים ל-VPC

ההגדרה שירותים נגישים ל-VPC מגבילה את קבוצת השירותים שאפשר לגשת אליהם מנקודות קצה ברשת בתוך גבולות הגזרה לשירות. בארכיטקטורה לדוגמה הזו, אנחנו משאירים את הגדרת ברירת המחדל All Services.

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

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

1. לוחצים על רמות גישה.

2. לוחצים על התיבה בחירת רמת הגישה.

   אפשר גם להוסיף רמות גישה אחרי שיוצרים את ההיקף.

3. מסמנים את התיבה שמתאימה לרמת הגישה. (בארכיטקטורה הזו, זהו corp-public-block.)

הגדרת מדיניות הכניסה

מכיוון שהפרויקט המארח הוא הבעלים של רשת המשנה שמשותפת עם ph-fm-svc-project-2 ו-ph-fm-svc-project-3, נדרש כלל תעבורת נתונים נכנסת כדי לתת לרשתות המשנה האלה גישה להיקף של פרויקט השירות מהפרויקט המארח. כך המכונות של פרויקטי השירות האלה יכולות לגשת לשירות המנוהל ב-ph-fm-svc-project-2 וב-ph-fm-svc-project-3.

1. בתפריט הימני, לוחצים על Ingress policy.
2. לוחצים על הוספת כלל.
3. בחלונית Ingress rule:
   1. בקטע FROM attributes, בוחרים את מאפייני ה-FROM הבאים של לקוח ה-API:
      1. זהות: כל זהות
      2. מקור: רמת הגישה
      3. רמת גישה: gce-subnet-2, gce-subnet-3
   2. בקטע TO attributes, בוחרים את מאפייני היעד הבאים של השירותים והמשאבים ב- Google Cloud:
      1. ‫Project: כל הפרויקטים
      2. ‫Services: כל השירותים

הגדרת מדיניות תעבורת הנתונים היוצאת

מכיוון שפרויקט המארח הוא הבעלים של רשת המשנה שמשותפת עם ph-fm-svc-project-２ ו-ph-fm-svc-project-3, נדרש כלל תעבורת נתונים יוצאת כדי לאפשר את התקשורת הדו-כיוונית שמתרחשת בין פרויקטי השירות לפרויקט המארח שלהם כשנוצרים משאבי מחשוב בפרויקטי השירות.

1. בתפריט הימני, לוחצים על Egress policy.
2. לוחצים על הוספת כלל.
3. בחלונית Egress rule:
   1. בקטע FROM attributes, בוחרים את מאפייני ה-FROM הבאים של לקוח ה-API:
      1. זהות: כל זהות
   2. בקטע TO attributes, בוחרים את מאפייני היעד הבאים של השירותים והמשאבים ב- Google Cloud:
      1. ‫Project: הפרויקטים שנבחרו
      2. הוספת פרויקט: aiml-host-project
      3. שירותים: השירותים שנבחרו
      4. Selected services: Compute Engine API
      5. שיטות: כל השיטות

יצירת ההיקף

אחרי שביצעתם את שלבי ההגדרה הקודמים, לוחצים על Create perimeter כדי ליצור את ההיקף.

הגדרת הרשת

שימוש בנקודת קצה של Private Service Connect כדי לגשת לממשקי Google API

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

באמצעות Private Service Connect אפשר:

• יוצרים כתובת IP פנימית אחת או יותר כדי לגשת לממשקי Google API בתרחישים שונים לדוגמה.
• הפניית התנועה המקומית לכתובות IP ולאזורים ספציפיים כשניגשים ל-Google APIs.
• יוצרים שם DNS של נקודת קצה בהתאמה אישית, שישמש לפתרון של ממשקי Google API.

בארכיטקטורה לדוגמה, נקודת קצה ל-Google API של Private Service Connect בשם restricted עם כתובת ה-IP‏ 192.168.10.2 נפרסת עם היעד VPC Service Controls, ומשמשת ככתובת IP וירטואלית (VIP) כדי לגשת לשירותים מוגבלים שמוגדרים בהיקף של VPC Service Controls. נקודת הקצה של Private Service Connect נפרסת בפרויקט המארח, aiml-host-project.

גישה ל-Gemini Pro ממכונות Compute Engine

כשיוצרים נקודת קצה (endpoint) של Private Service Connect, ‏Service Directory יוצר רשומות DNS באזור פרטי של p.googleapis.com. הרשומות מפנות לכתובת ה-IP של נקודת הקצה, ומשתמשות בפורמט SERVICE-ENDPOINT.p.googleapis.com ששווה לשם הדומיין שמוגדר במלואו (FQDN) שמשמש לגישה ל-Agent Platform API: ‏LOCATION-aiplatform-restricted.p.googleapis.com.

אימות הגדרות הרשת

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

1. מאתחלים את משתני הסביבה של Python באופן הבא:

   PROJECT_ID="ph-fm-svc-project-1"
   LOCATION_ID="us-central1"
   API_ENDPOINT="us-central1-aiplatform-restricted.p.googleapis.com"
   MODEL_ID="gemini-2.0-flash-exp"
   GENERATE_CONTENT_API="streamGenerateContent"
   

2. באמצעות כלי לעריכת טקסט, יוצרים קובץ request.json שמכיל את ה-JSON הבא:

   {
     "contents": [
       {
         "role": "user",
         "parts": [
           {
             "text": "what weight more 1kg feathers vs 1kg stones"
           }
         ]
       }
     ],
     "generationConfig": {
       "temperature": 1,
       "maxOutputTokens": 8192,
       "topP": 0.95,
       "seed": 0
     },
     "safetySettings": [
       {
         "category": "HARM_CATEGORY_HATE_SPEECH",
         "threshold": "OFF"
       },
       {
         "category": "HARM_CATEGORY_DANGEROUS_CONTENT",
         "threshold": "OFF"
       },
       {
         "category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
         "threshold": "OFF"
       },
       {
         "category": "HARM_CATEGORY_HARASSMENT",
         "threshold": "OFF"
       }
     ]
   }
   

3. שולחים את בקשת ה-cURL הבאה ל-Gemini API של Gemini Enterprise Agent Platform:

   curl \
   -X POST \
   -H "Content-Type: application/json" \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://${API_ENDPOINT}/v1/projects/${PROJECT_ID}/locations/${LOCATION_ID}/publishers/google/models/${MODEL_ID}:${GENERATE_CONTENT_API}" -d '@request.json'
   

אימות של גבולות הגזרה במצב פרימטר לבדיקות

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

כדי ללמוד איך לאמת את גבולות הגזרה במצב פרימטר לבדיקות, צפו בסרטון ב-YouTube‏ VPC Service Controls dry run logging.

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