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

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

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

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

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

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

בארכיטקטורת ההפניה הזו, כללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) וכתובות 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 של כל פרויקט שירות נשלטת על ידי כללי תעבורת נתונים נכנסת (ingress) ויוצאת (egress) של 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, האדמינים שלו צריכים להגדיר מדיניות גישה, שהיא מאגר של רמות גישה ושל גבולות שירות. כך עושים זאת:

1. בכלי לבחירת פרויקטים בחלק העליון של מסוף Google Cloud , לוחצים על הכרטיסייה הכול ואז בוחרים את הארגון.
2. כדי ליצור רמת גישה בסיסית, פועלים לפי ההוראות במאמר יצירת רמת גישה בסיסית. מציינים את האפשרויות הבאות:
   1. בקטע Create conditions in, בוחרים באפשרות Basic mode.
   2. בשדה שם רמת הגישה מזינים corp-public-block.
   3. בקטע תנאים, באפשרות כשהתנאי מתקיים, מחזירה, בוחרים באפשרות TRUE.
   4. בקטע IP Subnetworks (רשתות משנה של כתובות IP), בוחרים באפשרות Public 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 , לוחצים על הכרטיסייה הכול ואז בוחרים את הארגון.
2. כדי ליצור רמת גישה בסיסית, פועלים לפי ההוראות במאמר יצירת רמת גישה בסיסית. מציינים את האפשרויות הבאות:
   1. בקטע Create conditions in, בוחרים באפשרות Basic mode.
   2. בשדה שם רמת הגישה מזינים gce-subnet-1.
   3. בקטע תנאים, באפשרות כשהתנאי מתקיים, מחזירה, בוחרים באפשרות TRUE.
   4. בקטע רשתות משנה של כתובות IP, בוחרים באפשרות כתובת IP פרטית.
   5. בוחרים באפשרות VPC Networks (רשתות VPC), מזהים את הפרויקט ובוחרים את שם ה-VPC.
   6. בקטע IP Subnetworks (רשתות משנה של כתובות IP), בוחרים את טווח ה-CIDR שמייצג את רשת המשנה שהפרויקט המארח שיתף עם ph-fm-svc-project-1.

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

1. בכלי לבחירת פרויקטים בחלק העליון של מסוף Google Cloud , לוחצים על הכרטיסייה הכול ואז בוחרים את הארגון.
2. כדי ליצור רמת גישה בסיסית, פועלים לפי ההוראות במאמר יצירת רמת גישה בסיסית. מציינים את האפשרויות הבאות:
   1. בקטע Create conditions in, בוחרים באפשרות Basic mode.
   2. בשדה שם רמת הגישה מזינים gce-subnet-2.
   3. בקטע תנאים, באפשרות כשהתנאי מתקיים, מחזירה, בוחרים באפשרות TRUE.
   4. בקטע רשתות משנה של כתובות IP, בוחרים באפשרות כתובת IP פרטית.
   5. בוחרים באפשרות VPC Networks (רשתות VPC), מזהים את הפרויקט ובוחרים את שם ה-VPC.
   6. בקטע IP Subnetworks (רשתות משנה של כתובות IP), בוחרים את טווח ה-CIDR שמייצג את רשת המשנה שהפרויקט המארח שיתף עם ph-fm-svc-project-2.

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

1. בכלי לבחירת פרויקטים בחלק העליון של מסוף Google Cloud , לוחצים על הכרטיסייה הכול ואז בוחרים את הארגון.
2. כדי ליצור רמת גישה בסיסית, פועלים לפי ההוראות במאמר יצירת רמת גישה בסיסית. מציינים את האפשרויות הבאות:
   1. בקטע Create conditions in, בוחרים באפשרות Basic mode.
   2. בשדה שם רמת הגישה מזינים gce-subnet-3.
   3. בקטע תנאים, באפשרות כשהתנאי מתקיים, מחזירה, בוחרים באפשרות TRUE.
   4. בקטע רשתות משנה של כתובות IP, בוחרים באפשרות כתובת IP פרטית.
   5. בוחרים באפשרות VPC Networks (רשתות VPC), מזהים את הפרויקט ובוחרים את שם ה-VPC.
   6. בקטע IP Subnetworks (רשתות משנה של כתובות IP), בוחרים את טווח ה-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, לוחצים על Dry run mode (מצב הרצה יבשה).

4. לוחצים על היקף חדש.

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

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

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

בחירת המשאבים להגנה

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

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

באדריכלות ההפניה הזו, היקף ממשקי ה-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 (הוספת Compute Engine API).

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

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

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

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

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

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

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

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

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

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

1. בתפריט הימני, לוחצים על מדיניות כניסה.
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, בוחרים את מאפייני TO הבאים של שירותים ומשאבים של Google Cloud:
      1. פרויקט: כל הפרויקטים
      2. שירותים: השירותים שנבחרו
      3. שירותים נבחרים: Compute Engine API
      4. שיטות: כל השיטות

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

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

כלל היציאה הראשון

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

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

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

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

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

יצירת ההיקף

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

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

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

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

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

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

3. בדף VPC Service Controls, לוחצים על Dry run mode (מצב הרצה יבשה).

4. לוחצים על היקף חדש.

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

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

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

בחירת המשאבים להגנה

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

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

באדריכלות ההפניה הזו, היקף ממשקי ה-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 (הוספת Compute Engine API).
5. בחלונית Restricted Services (שירותים מוגבלים), לוחצים על Add services (הוספת שירותים).
6. בתיבת הדו-שיח Specify services to restrict, בוחרים באפשרות Agent Platform API.
7. לוחצים על Add Agent Platform API (הוספת Agent Platform API).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יצירת ההיקף

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

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

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

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

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

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

3. בדף VPC Service Controls, לוחצים על Dry run mode (מצב הרצה יבשה).

4. לוחצים על היקף חדש.

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

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

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

בחירת המשאבים להגנה

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

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

באדריכלות ההפניה הזו, היקף ממשקי ה-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 (הוספת Compute Engine API).
5. בחלונית Restricted Services (שירותים מוגבלים), לוחצים על Add services (הוספת שירותים).
6. בתיבת הדו-שיח Specify services to restrict, בוחרים באפשרות Agent Platform API.
7. לוחצים על Add Agent Platform API (הוספת Agent Platform API).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יצירת ההיקף

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

הגדרת הרשת

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

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

השימוש ב-Private Service Connect מאפשר לכם לבצע את הפעולות הבאות:

• יוצרים כתובת IP פנימית אחת או יותר כדי לגשת לממשקי Google API לתרחישי שימוש שונים.
• כשניגשים לממשקי Google API, אפשר להפנות את התנועה בשרתים המקומיים לכתובות IP ולאזורים ספציפיים.
• יוצרים שם 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 ששווה לשם דומיין שמוגדר במלואו שמשמש לגישה ל-Agent Platform API:‏ LOCATION-aiplatform-restricted.p.googleapis.com.

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

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

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'
   

אימות ההיקף במצב הרצה יבשה

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

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

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