שימוש ב-VPC Service Controls‏ (VPC SC)

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

מגבלות והמלצות

• ב-Artifact Registry או ב-Container Registry:

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

• התכונה פריסה רציפה לא זמינה בפרויקטים שנמצאים בתוך היקף של VPC Service Controls.

• כשמפעילים שירותים של Cloud Run, המערכת לא משתמשת בפרטי האימות של הלקוח ב-IAM כדי לאכוף את המדיניות של VPC Service Controls. הבקשות האלה כפופות למגבלות הבאות:

  • אין תמיכה בכללי מדיניות תעבורת נתונים נכנסת (ingress) של VPC Service Controls שמשתמשים בישויות מורשות של IAM.
  • אין תמיכה ברמות גישה לאזורים של VPC Service Controls שמשתמשים בישויות מורשות של IAM.

הגדרת הארגון לתמיכה ב-VPC Service Controls

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

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

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

בשלבים הבאים מוסבר איך להגדיר גבולות גזרה של VPC Service Controls.

1. מוודאים שיש לכם את התפקידים הנדרשים לניהול VPC Service Controls.

2. נכנסים לדף VPC Service Controls במסוף Google Cloud .

   מעבר לדף VPC Service Controls

3. אם מוצגת בקשה לעשות זאת, בוחרים את הארגון.

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

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

6. בוחרים את הפרויקטים שרוצים לאבטח בתוך ההיקף.

   1. לוחצים על פרויקטים.

   2. בחלון Add Projects (הוספת פרויקטים), בוחרים את הפרויקטים שרוצים להוסיף.

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

   3. לוחצים על הלחצן הוספת פרויקטים.

7. בוחרים ב-Cloud Run כשירות שרוצים לאבטח בתוך גבולות הגזרה.

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

   2. לוחצים על הוספת שירותים.

   3. מחפשים את Cloud Run. אחר כך בוחרים באפשרות Cloud Run Admin API. (בוחרים באפשרות Cloud Functions V2 API אם השתמשתם ב-gcloud functions).

   4. לוחצים על Add Cloud Run Admin API (הוספת Cloud Run Admin API) או על Cloud Functions V2 API (אם השתמשתם ב-gcloud functions).

8. הפעלת גישה למפתחים.

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

   1. לוחצים על Ingress Policy (מדיניות כניסה).

   2. מציינים את המקור, הזהות, הפרויקט והשירותים.

   3. לוחצים על הוספת כלל.

   אם הארגון שלכם משתמש ב-Access Context Manager, אתם יכולים גם להגדיר רמות גישה כדי לאפשר גישה למפתחים.

9. לוחצים על יצירת היקף.

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

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

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

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

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

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

מדיניות הארגון run.allowedIngress קובעת את הגדרות הכניסה שמפתחים יכולים להשתמש בהן ב-Cloud Run. כדי לאפשר רק בקשות פנימיות, צריך להגדיר את מדיניות הארגון כך שהמפתחים ישתמשו בערך internal. כדי לאפשר בקשות דרך מאזן עומסים חיצוני של אפליקציות, עם בקרות גישה שמנוהלות על ידי Cloud Load Balancing, צריך להגדיר את מדיניות הארגון כך שהמפתחים ישתמשו בערך internal-and-cloud-load-balancing.

מידע נוסף על ההגדרות האלה זמין במאמר הגבלת תעבורת נתונים נכנסת (ingress) ב-Cloud Run

המסוף

1. נכנסים לדף המדיניות Allowed ingress settings (Cloud Run) במסוףGoogle Cloud :

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

2. לוחצים על Edit.

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

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

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

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

7. בקטע ערכים מותאמים אישית, מזינים internal. אם רוצים לאפשר גם תנועה של Cloud Load Balancing, לוחצים על ערך מדיניות חדש ומזינים internal-and-cloud-load-balancing.

8. לוחצים על Save.

gcloud

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

gcloud resource-manager org-policies allow \
  run.allowedIngress internal \
  --organization ORGANIZATION_ID

כאשר ORGANIZATION_ID הוא מזהה הארגון. אם רוצים לאפשר גם תנועה של Cloud Load Balancing, מחליפים את run.allowedIngress internal ב-run.allowedIngress internal-and-cloud-load-balancing.

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

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

מדיניות הארגון run.allowedVPCEgress שולטת בהגדרות היציאה שמפתחים יכולים להשתמש בהן ב-Cloud Run. מגדירים את מדיניות הארגון כך שתאפשר רק את הערך all-traffic:

המסוף

1. נכנסים לדף המדיניות Allowed VPC egress settings (Cloud Run) במסוףGoogle Cloud :

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

2. לוחצים על Edit.

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

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

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

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

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

8. לוחצים על Save.

gcloud

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

gcloud resource-manager org-policies allow \
  run.allowedVPCEgress all-traffic \
  --organization ORGANIZATION_ID

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

התנהגות אחרי הגדרת מדיניות הארגון

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

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

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

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

הגדרת הפרויקט לתמיכה ב-VPC Service Controls

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

הגדרת רשתות VPC

בקטע הזה מוסבר איך להגדיר את רשת ה-VPC כך שבקשות שנשלחות לדומיינים הרגילים של googleapis.com ינותבו אוטומטית לטווח ה-IP הווירטואלי (VIP) המוגבל, 199.36.153.4/30 (restricted.googleapis.com), שבו שירות Cloud Run שלכם פועל. אין צורך לבצע שינויים בקוד.

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

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

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

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

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

     הערה: חשוב לוודא שהעדיפות של כלל חומת האש שחוסם את כל תעבורת הנתונים היוצאת (egress) היא אחרי 1000. אחרת, התנועה מ-Direct VPC egress או ממחבר הגישה ל-VPC מאפליקציית serverless אל השירות שלכם תיחסם.

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

3. יוצרים מדיניות תגובה ב-Cloud DNS.

   gcloud dns response-policies create RESPONSE_POLICY \
   --networks=NETWORK \
   --description=DESCRIPTION
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫RESPONSE_POLICY: שם למדיניות התגובה.
   • NETWORK: השם של הרשת שאליה רוצים לשייך את המדיניות הזו. כדי לציין כמה רשתות, צריך להפריד בין השמות של כל רשת באמצעות פסיקים, למשל: network1,network2.
   • ‫DESCRIPTION: תיאור מדיניות התגובה, למשל Cloud Run VPC Service Controls response policy

4. מוסיפים כלל למדיניות התגובה כדי לפתור את *.googleapis.com ל-restricted.googleapis.com. טווח כתובות ה-IP של restricted.googleapis.com הוא 199.36.153.4/30.

   gcloud dns response-policies rules create RESPONSE_POLICY_RULE \
   --response-policy=RESPONSE_POLICY \
   --dns-name="*.googleapis.com." \
   --local-data=name="restricted.googleapis.com.",type="A",ttl=300,rrdatas="199.36.153.4|199.36.153.5|199.36.153.6|199.36.153.7"
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫RESPONSE_POLICY_RULE: שם לכלל מדיניות התגובה.
   • ‫RESPONSE_POLICY: השם של מדיניות התגובה שיצרתם בשלב הקודם, במירכאות.

5. מוסיפים כלל למדיניות התגובה כדי לפתור את *.run.app (או *.cloudfunctions.net אם יצרתם את הפונקציה באמצעות gcloud functions deploy) ל-restricted.googleapis.com. טווח כתובות ה-IP של restricted.googleapis.com הוא 199.36.153.4/30.

   gcloud dns response-policies rules create RESPONSE_POLICY_RULE \
   --response-policy=RESPONSE_POLICY \
   --dns-name="*.run.app." \
   --local-data=name="restricted.googleapis.com.",type="A",ttl=300,rrdatas="199.36.153.4|199.36.153.5|199.36.153.6|199.36.153.7"
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫RESPONSE_POLICY_RULE: שם לכלל מדיניות התגובה.
   • ‫RESPONSE_POLICY: השם של מדיניות התגובה שציינתם בשלב הקודם, במירכאות.

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

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

פריסת שירותים ומשימות ב-Cloud Run שתואמים ל-VPC Service Controls

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

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

ביקורת של שירותים קיימים לצורך תאימות ל-VPC Service Controls

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

‫Google ממליצה לבצע ביקורת תקופתית בשירותים כדי לוודא שהגדרות תעבורת הנתונים הנכנסת (ingress) ותעבורת הנתונים היוצאת (egress) תואמות לדרישות, ולעדכן או לפרוס מחדש את השירותים לפי הצורך. לדוגמה, אפשר ליצור סקריפט שמשתמש ב-Cloud Run Admin API כדי להציג רשימה של השירותים שלכם ולהדגיש את השירותים שלא צוינו בהם הגדרות הרשת המתאימות.