הגדרת VPC Service Controls (דור ראשון)

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

למידע על מגבלות בשילוב הזה, ראו מסמכי VPC Service Controls.

הגדרה ברמת הארגון

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

הגדרת היקף אבטחה של VPC Service Controls

כדי להגדיר גבולות גזרה לשירות, צריך את התפקידים Organization Viewer (roles/resourcemanager.organizationViewer) וAccess Context Manager Editor (roles/accesscontextmanager.policyEditor).

פועלים לפי המדריך לתחילת העבודה עם VPC Service Controls כדי:

1. יוצרים גבולות גזרה לשירות.

   הערה: פונקציות Cloud Run משתמשות ב-Cloud Build, ב-Artifact Registry, ב-Container Registry (יצא משימוש) וב-Cloud Storage כדי ליצור ולנהל את קוד המקור בקונטיינר שניתן להפעלה. אם השירותים האלה מוגבלים על ידי גבולות גזרה לשירות, VPC Service Controls חוסם את הבנייה של פונקציות Cloud Run, גם אם פונקציות Cloud Run לא נוספו כחלק מהשירותים המוגבלים בגבולות הגזרה. כדי להשתמש בפונקציות Cloud Run בתוך גבולות גזרה לשירות, צריך להגדיר כלל כניסה לחשבון השירות של Cloud Build בגבולות הגזרה לשירות. בנוסף, Cloud Build משתמש ב-Cloud Logging, אבל יכול להיות שהרישום ביומן לא יתבצע בצורה תקינה אם הוא מוגבל על ידי מתחם היקפי של VPC-SC. הפעולה הזו לא תגרום לגרסאות ה-build להיכשל, אבל מומלץ להעניק ל-Cloud Build גישה למתחם השירות באמצעות כלל כניסה כדי להבטיח רישום תקין ביומן.

2. מוסיפים פרויקט אחד או יותר לגבולות הגזרה.

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

3. מגבילים את Cloud Functions API.

אחרי שמגדירים את גבולות הגזרה לשירות, כל הקריאות ל-API המוגבל נבדקות כדי לוודא שהן מגיעות מתוך אותם גבולות גזרה.

אופציונלי: הפעלת גישה היקפית למכונות פיתוח

בגלל שבדיקות של VPC Service Controls נאכפות ב-Cloud Functions API, קריאות ל-Cloud Functions API נכשלות אלא אם הן מגיעות מתוך גבולות גזרה לשירות. לכן, כדי לנהל פונקציות באמצעות Cloud Functions API, ממשק המשתמש של Cloud Run functions במסוף Google Cloud או Google Cloud CLI, צריך לבחור באחת מהאפשרויות הבאות:

• משתמשים במכונה בתוך גבולות הגזרה של VPC Service Controls. לדוגמה, אתם יכולים להשתמש במכונה וירטואלית של Compute Engine או במכונה מקומית שמחוברת לרשת ה-VPC שלכם באמצעות VPN.

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

הגדרה של מדיניות הארגון

כדי לנהל את מדיניות הארגון, צריך להיות לכם התפקיד אדמין של מדיניות הארגון (roles/orgpolicy.policyAdmin).

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

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

הגבלת ההגדרות המותרות של תעבורת נתונים נכנסת (ingress)

מדיניות הארגון cloudfunctions.allowedIngressSettings שולטת בהגדרות הכניסה שמפתחים יכולים להשתמש בהן בפונקציות של Cloud Run. מגדירים את מדיניות הארגון הזו כך שמפתחים יחויבו להשתמש בערך ALLOW_INTERNAL_ONLY:

המסוף

1. עוברים לדף המדיניות Allowed ingress settings במסוףGoogle Cloud :

   מעבר למדיניות הארגון

2. לוחצים על ניהול המדיניות.

3. בדף עריכת מדיניות, בוחרים באפשרות התאמה אישית.

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

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

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

7. בקטע ערכים מותאמים אישית, מזינים ALLOW_INTERNAL_ONLY.

8. לוחצים על הגדרת מדיניות.

gcloud

משתמשים בפקודה gcloud resource-manager org-policies allow:

gcloud resource-manager org-policies allow \
  cloudfunctions.allowedIngressSettings ALLOW_INTERNAL_ONLY \
  --organization ORGANIZATION_ID

כאשר ORGANIZATION_ID הוא מזהה הארגון.

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

נדרש מחבר VPC

מדיניות הארגון cloudfunctions.requireVPCConnector קובעת אם נדרש מחבר של Serverless VPC Access לפונקציות. מגדירים את מדיניות הארגון הזו כדי לאכוף את האילוץ הזה:

המסוף

1. נכנסים לדף המדיניות Require VPC Connector במסוףGoogle Cloud :

   מעבר למדיניות הארגון

2. לוחצים על ניהול המדיניות.

3. בדף עריכת מדיניות, בוחרים באפשרות התאמה אישית.

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

5. לוחצים על הגדרת מדיניות.

gcloud

משתמשים בפקודה gcloud resource-manager org-policies enable-enforce:

gcloud resource-manager org-policies enable-enforce \
  cloudfunctions.requireVPCConnector \
  --organization ORGANIZATION_ID

כאשר ORGANIZATION_ID הוא מזהה הארגון.

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

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

cloudfunctions.allowedVpcConnectorEgressSettings מדיניות הארגון קובעת את הגדרות היציאה שמפתחים יכולים להשתמש בהן בפונקציות של Cloud Run. מגדירים את מדיניות הארגון כך שתאפשר רק את הערך ALL_TRAFFIC:

המסוף

1. עוברים לדף המדיניות Allowed VPC Connector egress settings במסוףGoogle Cloud :

   מעבר למדיניות הארגון

2. לוחצים על ניהול המדיניות.

3. בדף עריכת מדיניות, בוחרים באפשרות התאמה אישית.

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

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

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

7. בקטע ערכים מותאמים אישית, מזינים ALL_TRAFFIC.

8. לוחצים על הגדרת מדיניות.

gcloud

משתמשים בפקודה gcloud resource-manager org-policies allow:

gcloud resource-manager org-policies allow \
  cloudfunctions.allowedVpcConnectorEgressSettings ALL_TRAFFIC \
  --organization ORGANIZATION_ID

כאשר ORGANIZATION_ID הוא מזהה הארגון.

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

בצירוף מדיניות הארגון cloudfunctions.requireVPCConnector, ההגדרה הזו מאלצת את כל תעבורת הנתונים היוצאת לעבור דרך רשת ה-VPC, שבה היא כפופה לחומת האש ולכללי הניתוב שהוגדרו.

הגדרה ברמת הפרויקט

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

הגדרת רשתות VPC

כדי לגשת ל-Google APIs ולשירותים של Google תוך צמצום הסיכונים של גניבת נתונים, צריך לשלוח בקשות לטווח כתובות ה-IP הווירטואליות (VIP) המוגבל,‏ 199.36.153.4/30 (restricted.googleapis.com).

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

1. מגדירים כללי חומת אש כדי למנוע יציאת נתונים מרשת ה-VPC:

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

   • יוצרים כלל לדחיית תעבורת נתונים יוצאת שחוסם את כל התעבורה היוצאת.

     הערה: חשוב לוודא שהעדיפות של כלל חומת האש שחוסם את כל התנועה היוצאת היא מעל 1,000. אחרת, התנועה מהמחבר Serverless VPC Access אל הפונקציה תיחסם.

   • יוצרים כלל שמאפשר תעבורת נתונים יוצאת (egress) אל 199.36.153.4/30 ביציאת TCP ‏443. חשוב לוודא שהיא מופיעה בעדיפות לפני כלל תעבורת הנתונים היוצאת (egress) שזה עתה יצרתם – כך תתאפשר יציאה רק לטווח ה-VIP המוגבל.

2. הגדרת DNS כדי ליצור רזולוציה של *.googleapis.com ל-restricted.googleapis.com.

3. הגדרת DNS עם מיפוי רשומת A‏ *.cloudfunctions.net לטווח כתובות ה-IP‏ 199.36.153.4/30. אפשר לעשות את זה באמצעות Cloud DNS:

   gcloud dns managed-zones create ZONE_NAME \
   --visibility=private \
   --networks=https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/VPC_NAME \
   --description=none \
   --dns-name=cloudfunctions.net
   
   gcloud dns record-sets transaction start --zone=ZONE_NAME
   
   gcloud dns record-sets transaction add --name=*.cloudfunctions.net. \
   --type=A 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 \
   --zone=ZONE_NAME \
   --ttl=300
   
   gcloud dns record-sets transaction execute --zone=ZONE_NAME
   

   הערה: הערך של ZONE_NAME צריך להיות שונה מהשם שבו השתמשתם כדי להגדיר את כללי *.googleapis.com בשלב 2.
   הערה: במסופים מסוימים, יכול להיות שתצטרכו להוסיף מירכאות כפולות סביב הערך של האפשרות --name (למשל, --name="\*.cloudfunctions.net.") שמועבר לפקודה gcloud record-sets transaction add.

4. מפעילים גישה פרטית ל-Google לרשת המשנה של מחבר ה-VPC.

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

בשלב הזה, בקשות שמקורן בתוך רשת ה-VPC:

• לא יכולים לצאת מרשת ה-VPC, ולכן לא יכולים לצאת מגבולות הגזרה של השירות.
• יכולים לגשת רק לממשקי API ולשירותים של Google שבודקים את VPC Service Controls, וכך למנוע זליגת מידע דרך ממשקי API של Google.

נותנים לחשבון השירות ב-Cloud Build גישה למערך של VPC Service Controls

פונקציות Cloud Run משתמשות ב-Cloud Build כדי ליצור קוד מקור בקונטיינר שניתן להפעלה. כדי להשתמש בפונקציות Cloud Run עם VPC Service Controls, צריך להגדיר לחשבון השירות של Cloud Build גישה לגבולות גזרה לשירות:

הערה: יכול להיות שחשבון השירות שמוגדר כברירת מחדל ב-Cloud Build השתנה החל ממאי 2024. לפני שממשיכים, כדאי לעיין במאמר בנושא השינוי בחשבונות השירות שמשמשים כברירת מחדל ב-Cloud Build כדי לוודא מהו חשבון השירות שמוגדר כברירת מחדל בפרויקט שלכם.

חיפוש השם של חשבון השירות

1. משתמשים בדף IAM במסוף Google Cloud כדי למצוא את חשבון השירות של Cloud Build.

   פתיחת IAM

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

3. חיפוש של cloudbuild.gserviceaccount.com. כתובת האימייל בפורמט [e-mail] היא השם של חשבון השירות.

מעניקים לחשבון השירות גישה לגבולות גזרה לשירות

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

פריסת פונקציות שתואמות ל-VPC Service Controls

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

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

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

ביקורת על פונקציות קיימות כדי לוודא שהן תואמות ל-VPC Service Controls

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

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

שימוש ב-VPC Service Controls עם פונקציות מחוץ לגבולות הגזרה

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

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

1. נותנים לחשבון השירות ב-Cloud Build גישה למתחם ההיקפי של VPC Service Controls.
2. מעניקים לחשבון השירות של זמן הריצה של הפונקציה גישה להיקף. אפשר לעשות את זה על ידי יצירת רמת גישה והוספת רמת הגישה לגבולות גזרה לשירות, או על ידי יצירת מדיניות תעבורת נתונים נכנסת בגבולות הגזרה.
3. חיבור הפונקציה לרשת VPC.
4. ניתוב כל התנועה היוצאת מהפונקציה דרך רשת ה-VPC. מידע נוסף מופיע במאמר בנושא הגדרות יציאה.

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