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

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

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

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

אפשר להגדיר קבוצות זהויות וזהויות של צד שלישי ותפקידי IAM בכללי תעבורת נתונים נכנסת (ingress) ויוצאת (egress).

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

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

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

1. כללי כניסה ויציאה מאפשרים להחליף נתונים באופן פרטי ויעיל בתוך הארגון ובין ארגונים באמצעות ממשקי API של שירות Google Cloud .
2. כללים לתעבורת נתונים נכנסת ויוצאת מאפשרים לכם לתת גישה למשאבים בתוך גבול הגזרה, על סמך ההקשר של בקשת ה-API: Google Cloud
   1. הגבלת סוגי הזהויות או הזהויות שאפשר להשתמש בהן בהינתן רשת מקור, כתובת IP או מכשיר.
   2. להגביל Google Cloud את ממשקי ה-API והשיטות שאפשר לגשת אליהם בהתאם לרשת המקור, לכתובת ה-IP, למכשיר ולסוג הזהות.
3. כדי לצמצם את הסיכון לזליגת נתונים, אפשר להגביל את השירות, השיטות, הפרויקטים, רשתות ה-VPC והזהויות שמשמשים להעברת הנתונים.Google Cloud
4. הענקת הרשאת קריאה בלבד למערכי נתונים ולתמונות חיצוניים שלא מנוהלים על ידכם.
5. לוודא שללקוחות בפלחים עם פחות הרשאות אין גישה למשאביGoogle Cloud בפלחים עם יותר הרשאות, אבל לאפשר גישה בכיוון ההפוך.
6. לפשט הגדרות שבעבר נדרשו בשבילן גבולות גזרה מגושרים.

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

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

• תעבורת נתונים נכנסת (Ingress): כל גישה של לקוח API מחוץ לגבולות הגזרה לשירות למשאבים שבתוך גבולות הגזרה לשירות. דוגמה:

  • לקוח של Cloud Storage מחוץ לגבולות גזרה לשירות, שקורא לפעולות קריאה, כתיבה או העתקה של Cloud Storage במשאב של Cloud Storage בתוך גבולות הגזרה.

• תעבורת נתונים יוצאת (egress): כל גישה שכוללת לקוח API או משאבים בתוך גבולות הגזרה לשירות ומשאבים מחוץ לגבולות הגזרה לשירות. דוגמאות:

  • לקוח של Compute Engine בתוך גבולות גזרה לשירות, שקורא לפעולת create של Compute Engine שבה משאב התמונה נמצא מחוץ לגבולות הגזרה.
  • לקוח Cloud Storage – בתוך ההיקף או מחוצה לו – שמבצע קריאה לפקודה copy כשקטגוריה אחת נמצאת בתוך ההיקף והקטגוריה השנייה נמצאת מחוצה לו.

הערה: ב-VPC Service Controls אפשר לגשת לכמה משאבים בניהול Google, בלי קשר להגבלות שנאכפות על ידי כללי מדיניות של תעבורת נתונים נכנסת או יוצאת. לדוגמה, Container Registry יכול לגשת למאגר gcr.io/cloud-dataflow לקריאה בלבד שמנוהל על ידי Google, בלי קשר להגבלות שנאכפות על ידי גבולות הגזרה לשירות.

מודל המדיניות

כלל לתעבורת נתונים נכנסת (ingress) או יוצאת (egress) מורכב מבלוקים של from ו-to, כאשר:

• ‫from מפנה למאפיינים של לקוח ה-API.
• ‫to references the attributes of Google Cloud services and resources.

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

• בקשה מלקוח מחוץ להיקף למשאב Google Cloud בתוך ההיקף מותרת אם מתקיימים התנאים של כלל הכניסה הנדרש.
• בקשה מלקוח בתוך גבולות הגזרה ל Google Cloud משאב מחוץ לגבולות הגזרה מורשית אם התנאים של כלל תעבורת הנתונים היוצאת הנדרש מתקיימים.
• קריאה ל-API שכוללת משאב Google Cloud בתוך גבולות ההיקף ומשאב Google Cloud מחוץ לגבולות ההיקף מותרת אם יש כלל תעבורת נתונים נכנסת שהלקוח עומד בו (אם הלקוח לא נמצא בתוך גבולות ההיקף), וכלל תעבורת נתונים יוצאת שהמשאב החיצוני עומד בו.

דוגמאות לבקשות API שמותרות לפי כללי תעבורת הנתונים הנכנסת

• לקוח של Cloud Storage מחוץ להיקף שמוריד אובייקטים מקטגוריה של Cloud Storage בתוך ההיקף למכונה המקומית (לדוגמה, באמצעות הפקודה gcloud storage cp).
• לקוח BigQuery מחוץ להיקף שמשתמש במשימת BigQuery בפרויקט בתוך ההיקף כדי לשלוח שאילתה למערך נתונים של BigQuery בתוך ההיקף (לדוגמה, באמצעות הפקודה bq query).
• מכונה וירטואלית של Compute Engine ברשת VPC שנמצאת מחוץ להיקף, כותבת לקטגוריה של Cloud Storage שנמצאת בתוך ההיקף.

דוגמאות לבקשות API שמותרות על ידי כללי יציאה

• לקוח של Cloud Storage בתוך ההיקף שמעתיק אובייקטים בין קטגוריה של Cloud Storage מחוץ להיקף לבין קטגוריה בתוך ההיקף (לדוגמה, באמצעות הפקודה gcloud storage cp).

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

• לקוח BigQuery בתוך ההיקף שמשתמש במשימת BigQuery בפרויקט מחוץ להיקף כדי לשלוח שאילתה למערך נתונים של BigQuery בתוך ההיקף (לדוגמה, באמצעות הפקודה bq query).

דוגמאות לבקשות API שמותרות על ידי שילוב של כללי תעבורת נתונים נכנסת ויוצאת

• לקוח של Cloud Storage מחוץ להיקף מעתיק אובייקטים בין קטגוריה של Cloud Storage מחוץ להיקף לבין קטגוריה בתוך ההיקף (לדוגמה, באמצעות הפקודה gcloud storage cp).
• לקוח BigQuery מחוץ להיקף שמשתמש במשימת BigQuery בפרויקט מחוץ להיקף כדי לשלוח שאילתה למערך נתונים של BigQuery בתוך ההיקף (לדוגמה, באמצעות הפקודה bq query).
• לקוח של Compute Engine מחוץ להיקף יוצר דיסק של Compute Engine מחוץ להיקף באמצעות מפתח Cloud KMS בתוך ההיקף.

הערה: בדוגמה הזו, צריך ליצור את כלל התעבורה היוצאת בפרימטר שמכיל את הפרויקט עם המפתח של Cloud KMS. כלל היציאה חייב לאפשר גישה לשירות compute.googleapis.com ולשיטה compute.v1.ImagesService.Insert.

בדוגמאות של BigQuery ו-Compute Engine, כלל כניסה לא מספיק כי המשימה ב-BigQuery או הדיסק ב-Compute Engine נמצאים מחוץ להיקף. צריך כלל תעבורת נתונים יוצאת (egress) כדי לאפשר בקשת API שכוללת משאב Google Cloud בתוך ההיקף (מערך הנתונים ב-BigQuery או המפתח ב-Cloud KMS) ומשאב מחוץ להיקף (העבודה ב-BigQuery או הדיסק ב-Compute Engine).

בקשות API שכוללות כמה גבולות גזרה לשירות

כשלקוח ה-API והמשאבים שאליהם ניגשים שייכים לגבולות גזרה שונים לשירות, כללי המדיניות של כל גבולות הגזרה המעורבים צריכים לאפשר את בקשת ה-API. לדוגמה, נניח שיש לקוח Cloud Storage וקטגוריה a בתוך גבולות גזרה לשירות A, וקטגוריה b בתוך גבולות גזרה לשירות B. בדוגמה הזו, כדי שהלקוח של Cloud Storage יעתיק אובייקטים מהקטגוריה a לקטגוריה b ומהקטגוריה b לקטגוריה a, נדרשים כללי הכניסה והיציאה הבאים:

• כלל יציאה בפרימטר A כדי לאפשר גישה לקטגוריה b של Cloud Storage.
• כלל יציאה בפרימטר B כדי לאפשר גישה לקטגוריה a של Cloud Storage.
• כלל של תעבורת נתונים נכנסת (ingress) בהיקף B, שמאפשר גישה ללקוח Cloud Storage שנמצא מחוץ להיקף B.

מסמך עזר בנושא כללים לתעבורת נתונים נכנסת (ingress)

אפשר להגדיר כללי Ingress באמצעות מסוף Google Cloud , קובץ JSON או קובץ YAML. בדוגמה הבאה נעשה שימוש בפורמט .yaml:

- ingressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER
    sources:
    - resource: RESOURCE
      *OR*
    - accessLevel: ACCESS_LEVEL
      *OR*
    - pscEndpoint:
        forwardingRule: PSC_ENDPOINT
  ingressTo:
    operations:
    - serviceName: SERVICE
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    *OR*
    roles:
    - ROLE_NAME
    resources:
    - projects/PROJECT
    *OR*
    - folders/FOLDER
    *OR*
    - organizations/ORGANIZATION
  title: TITLE

• ‫- ingressFrom: – שדה חובה. מתחיל את הבלוק from שמפרט את המקורות והזהויות המותרים מחוץ להיקף.

• identityType: – חובה להשתמש במאפיין הזה או במאפיין identities. המאפיין הזה מגדיר את סוגי הזהויות שאפשר להשתמש בהן מ-sources (מקור הרשת) שצוין. ערכים קבילים: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. הערך ANY_IDENTITY מאפשר בקשות מכל הזהויות, כולל בקשות לא מאומתות. ‫ANY_USER_ACCOUNT מאפשר לכל המשתמשים האנושיים, ו-ANY_SERVICE_ACCOUNT מאפשר לכל חשבונות השירות, אבל גם ANY_USER_ACCOUNT וגם ANY_SERVICE_ACCOUNT לא מאפשרים בקשות לא מאומתות.

  המאפיין הזה לא מגביל את הזהויות על סמך הארגון. לדוגמה, ANY_SERVICE_ACCOUNT מאפשר לחשבון שירות מכל ארגון.

• identities: – צריך להשתמש במאפיין הזה או במאפיין identityType. המאפיין הזה מתחיל רשימה של חשבונות שירות, חשבונות משתמשים, קבוצות ב-Google, זהויות של צד שלישי, ישויות מורשות של איחוד זהויות של עומסי עבודה ל-GKE (בגרסת Preview) וזהויות של סוכנים שיכולים לגשת למשאבים בפרימטר.

• ‫PRINCIPAL_IDENTIFIER – מציינים חשבון משתמש, חשבון שירות, קבוצה ב-Google, זהות של צד שלישי, חשבון משתמש של איחוד זהויות של עומסי עבודה ל-GKE (תצוגה מקדימה) או זהות של נציג שרוצים לתת להם גישה למשאבים שבתוך ההיקף.

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

• ‫sources: – חובה. המאפיין הזה מתייחס לרשימה של מקורות ברשת. כל ערך ברשימה הוא רמת גישה, משאב Google Cloud (כמו פרויקט, תיקייה, ארגון או רשת VPC) או נקודת קצה של Private Service Connect. אם מגדירים את המאפיין accessLevel לערך "*", מדיניות התעבורה הנכנסת מאפשרת גישה מכל מקור ברשת. אם מגדירים את המאפיין הזה לפרויקט, לתיקייה או לארגון, מדיניות התעבורה הנכנסת מאפשרת גישה מכל המשאבים שבהיררכיה של אותו משאב. אם מציינים רשת VPC, מדיניות הכניסה מאפשרת גישה מהרשת הספציפית הזו.

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

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

• - resource: – צריך להשתמש במאפיין הזה או במאפיין accessLevel. מציינים פרויקט, תיקייה, ארגון או רשת VPC מחוץ לגבול הגזרה שרוצים לספק להם גישה. כדי לציין פרויקט, משתמשים בפורמט: projects/PROJECT_NUMBER. כדי לציין תיקייה, משתמשים בפורמט: folders/FOLDER_NUMBER. כדי לציין ארגון, משתמשים בפורמט: organizations/ORGANIZATION_NUMBER. כדי לציין רשת VPC, משתמשים בפורמט: //compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME.

• - accessLevel: – חובה להשתמש במאפיין הזה או במאפיין resource. מציינת את רמת הגישה מחוץ לגבולות הגזרה שאליה ניתנת הגישה. אם מגדירים את המאפיין accessLevel לערך "*", מדיניות הכניסה מאפשרת גישה מכל מקור ברשת.

• - pscEndpoint: – צריך להשתמש במאפיין הזה, במאפיין resource או במאפיין accessLevel. מציין את נקודות הקצה של Private Service Connect שמהן רוצים לאפשר גישה.

• ‫forwardingRule: – מציין את נקודת הקצה של Private Service Connect. כדי לציין נקודת קצה (endpoint) של Private Service Connect, משתמשים בפורמט הבא: //compute.googleapis.com/projects/PROJECT_ID/global/forwardingRules/FORWARDING_RULE_ID.

• ‫ingressTo: – חובה. התחלת הבלוק to שמפרט את פעולות השירות המותרות במשאבי Google Cloud שצוינו בתוך גבולות האבטחה.

• operations: – חובה להשתמש במאפיין הזה או במאפיין roles. מציין את תחילת הרשימה של השירותים והפעולות/השיטות הנגישים שלקוח שעומד בתנאים של הבלוק from רשאי לגשת אליהם.

• ‫- serviceName: – שדה חובה. השדה הזה יכול להיות שם שירות תקין או להיות מוגדר ל-"*" כדי לאפשר גישה לכל השירותים. לדוגמה, bigquery.googleapis.com הוא serviceName תקין. רשימת המוצרים הנתמכים

• ‫methodSelectors: – חובה אם הערך של serviceName הוא לא "*". ההתחלה של רשימת שיטות שלקוח שעומד בתנאים של הבלוק from מורשה לגשת אליהן. במאמר הגבלות נתמכות על שיטות שירות תוכלו למצוא רשימה של שיטות והרשאות שאפשר להגביל בשירותים.

  ברשימה הזו מפורטות השיטות של השירותים שאי אפשר לשלוט בהן באמצעות VPC Service Controls.

• - method: – צריך להשתמש במאפיין הזה או במאפיין permission. השדה הזה יכול להיות שיטה תקינה של שירות, או שאפשר להגדיר אותו ל-"*" כדי לאפשר גישה לכל השיטות של השירות שצוין.

• - permission: – צריך להשתמש במאפיין הזה או במאפיין method. השדה הזה חייב להיות הרשאת שירות תקינה. הגישה למשאבים שבתוך ההיקף מותרת לפעולות שדורשות את ההרשאה.

  כשבקשה למשאב דורשת כמה הרשאות, צריך לציין את כל ההרשאות הנדרשות באותה פעולה כדי שכלל הכניסה יפעל. לדוגמה, אם בקשה למשאב של BigQuery דורשת את ההרשאות bigquery.jobs.create ו-bigquery.tables.create, צריך לציין את שתי ההרשאות האלה באותה פעולה. בנוסף, אם מציינים את ההרשאות כמה פעמים לאותו משאב באמצעותGoogle Cloud המסוף, ההרשאות לא נוצרות באותה פעולה. כדי למנוע את הבעיה הזו, צריך לציין את כל ההרשאות למשאב בבת אחת.

• roles: – צריך להשתמש במאפיין הזה או במאפיין operations. המאפיין הזה מתייחס לרשימה של תפקידי IAM שמגדירים את היקף הגישה לשירותים שצוינו בכלל.

• ‫ROLE_NAME – מציינים תפקיד אחד או שילוב של תפקידים שכוללים את כל ההרשאות שנדרשות כדי לגשת לשירותים. כדי לציין תפקיד, משתמשים בפורמטים של שמות התפקידים שמוזכרים בקטע רכיבי התפקיד, חוץ מהפורמט הבא: projects/PROJECT_ID/roles/IDENTIFIER.

  מידע על תפקידים נתמכים ב-IAM זמין במאמר תפקידים נתמכים.

• ‫resources: – שדה חובה. במאפיין הזה מציינים את רשימתGoogle Cloud המשאבים בגבולות גזרה לשירות שאליהם הלקוח מחוץ לגבולות גזרה יכול לגשת. אפשר להגדיר את השדה הזה לערך "*" כדי לאפשר גישה נכנסת לכל משאב Google Cloud בתוך ההיקף. אפשר לציין פרויקטים (projects/PROJECT_NUMBER), תיקיות (folders/FOLDER_NUMBER) או ארגונים (organizations/ORGANIZATION_NUMBER).

• ‫title: – אופציונלי. במאפיין הזה מציינים את השם של כלל התעבורה הנכנסת. השם חייב להיות ייחודי בתוך ההיקף, ולא יכול לחרוג מ-100 תווים. במדיניות הגישה, האורך הכולל של כל שמות הכללים לא יכול להיות יותר מ-240,000 תווים.

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

• מאפיין sources. צריך לציין מאפיין accessLevel, מאפיין resource (פרויקט, תיקייה, ארגון או רשת VPC) או מאפיין pscEndpoint, או להגדיר את המאפיין accessLevel כ-"*".

הערה: כדי לאפשר תעבורת נתונים נכנסת למשאבים, ב-VPC Service Controls המאפיינים sources ו-identityType נבדקים כתנאי AND, והמאפיינים accessLevel, ‏ resource ו-pscEndpoint של המאפיין sources נבדקים כתנאי OR. אם הערך של accessLevel, resource או pscEndpoint במקור מוגדר לערך ספציפי במקום ל-"*", מערכת VPC Service Controls מעריכה את המאפיינים sources ו-identityType.

• המאפיין identityType או identities
• מאפיין resources
• מאפיין serviceName

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

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

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

אפשר להגדיר כללי תעבורת נתונים יוצאת באמצעות מסוף Google Cloud , קובץ JSON או קובץ YAML. בדוגמה הבאה נעשה שימוש בפורמט .yaml:

- egressTo:
    operations:
    - serviceName: SERVICE_NAME
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    *OR*
    roles:
    - ROLE_NAME
    resources:
    - projects/PROJECT
    *OR*
    - folders/FOLDER
    *OR*
    - organizations/ORGANIZATION
    *OR*
    externalResources:
    - EXTERNAL_RESOURCE_PATH
  egressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER
    sources:
    - resource: RESOURCE
      *OR*
    - accessLevel: ACCESS_LEVEL
      *OR*
    - pscEndpoint:
        forwardingRule: PSC_ENDPOINT
    sourceRestriction: RESTRICTION_STATUS
  title: TITLE

• ‫- egressTo: – חובה. מתחיל את הבלוק to שבו מפורטות פעולות השירות המותרות במשאבי Google Cloud פרויקטים שצוינו מחוץ להיקף.

• operations: – חובה להשתמש במאפיין הזה או במאפיין roles. מציין את תחילת הרשימה של השירותים והפעולות/השיטות הנגישים, שלקוח שעומד בתנאי הבלוק from יכול לגשת אליהם.

• ‫- serviceName: – חובה. השדה הזה יכול להיות שם חוקי של שירות או להיות מוגדר לערך "*" כדי לאפשר גישה לכל השירותים. רשימת השירותים הזמינים מופיעה במאמר מוצרים נתמכים.

• ‫methodSelectors: – חובה אם הערך של serviceName הוא לא "*". תחילת הרשימה של השיטות שלקוח שעומד בתנאי הבלוק from יכול לגשת אליהן. במאמר הגבלות נתמכות על שיטות שירות מפורטת רשימה של שיטות והרשאות שניתן להגביל בשירותים.

  ברשימה הזו מפורטות השיטות של השירותים שאי אפשר לשלוט בהן באמצעות VPC Service Controls.

• - method: – צריך להשתמש במאפיין הזה או במאפיין permission. השדה הזה יכול להיות שיטה חוקית של שירות, או שאפשר להגדיר אותו לערך "*" כדי לאפשר גישה לכל השיטות של השירות שצוין.

• - permission: – צריך להשתמש במאפיין הזה או במאפיין method. השדה הזה חייב להיות הרשאת שירות תקינה. הגישה למשאבים שצוינו מחוץ להיקף מותרת לפעולות שדורשות את ההרשאה.

  כשבקשה למשאב דורשת כמה הרשאות, צריך לציין את כל ההרשאות הנדרשות באותה פעולה כדי שכלל היציאה יפעל. לדוגמה, אם בקשה למשאב של BigQuery דורשת את ההרשאות bigquery.jobs.create ו-bigquery.tables.create, צריך לציין את שתי ההרשאות האלה באותה פעולה. בנוסף, אם מציינים את ההרשאות כמה פעמים לאותו משאב באמצעותGoogle Cloud המסוף, ההרשאות לא נוצרות באותה פעולה. כדי למנוע את הבעיה הזו, צריך לציין את כל ההרשאות בבת אחת למשאב.

• roles: – צריך להשתמש במאפיין הזה או במאפיין operations. המאפיין הזה מתייחס לרשימה של תפקידי IAM שמגדירים את היקף הגישה לשירותים שצוינו בכלל.

• ‫ROLE_NAME – מציינים תפקיד יחיד או שילוב של תפקידים שכוללים את כל ההרשאות שנדרשות לגישה לשירותים. כדי לציין תפקיד, משתמשים בפורמטים של שמות התפקידים שמוזכרים בקטע רכיבי התפקיד, חוץ מהפורמט הבא: projects/PROJECT_ID/roles/IDENTIFIER.

  מידע על תפקידי IAM נתמכים זמין במאמר תפקידים נתמכים.

• ‫resources: – המאפיין הזה הוא רשימה של Google Cloudמשאבים (פרויקטים, תיקיות או ארגונים) מחוץ לגבולות השירות שלקוחות בתוך הגבולות יכולים לגשת אליהם. כדי לציין פרויקט, צריך להשתמש בפורמט projects/PROJECT_NUMBER. כדי לציין תיקייה, משתמשים בפורמט folders/FOLDER_NUMBER. כדי לציין ארגון, משתמשים ב-organizations/ORGANIZATION_NUMBER. אפשר להגדיר את השדה הזה לערך "*" כדי לאפשר גישה ליציאה לכל משאב Google Cloud .

• ‫externalResources: – המאפיין הזה משמש רק לציון משאבים של BigQuery Omni. המאפיין הזה הוא רשימה של משאבים חיצוניים שנתמכים על ידי BigQuery Omni, שלקוחות בתוך היקף ההרשאות יכולים לגשת אליהם. אפשר לציין רק משאבים של Amazon S3 או של Azure Blob Storage. ב-Amazon S3, הפורמט הנתמך הוא s3://BUCKET_NAME. ב-Azure Storage, הפורמט הנתמך הוא azure://myaccount.blob.core.windows.net/CONTAINER_NAME.

• ‫egressFrom: – חובה. מתחיל את הבלוק from שמפרט את המקורות והזהויות המותרים בתוך ההיקף.

• identityType: – חובה להשתמש במאפיין הזה או במאפיין identities. המאפיין הזה מגדיר את סוגי הזהויות שאפשר להשתמש בהן כדי לגשת למשאבים שצוינו מחוץ לגבולות הגזרה. ערכים קבילים: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. הערך ANY_IDENTITY מאפשר בקשות מכל הזהויות, כולל בקשות לא מאומתות. הערך ANY_USER_ACCOUNT מאפשר גישה לכל המשתמשים האנושיים, והערך ANY_SERVICE_ACCOUNT מאפשר גישה לכל חשבונות השירות, אבל ANY_USER_ACCOUNT ANY_SERVICE_ACCOUNTאף אחד מהם לא מאפשר בקשות לא מאומתות.

  המאפיין הזה לא מגביל את הזהויות על סמך הארגון. לדוגמה, הערך ANY_SERVICE_ACCOUNT מאפשר חשבון שירות מכל ארגון.

• identities: – צריך להשתמש במאפיין הזה או במאפיין identityType. המאפיין הזה מתחיל רשימה של חשבונות שירות, חשבונות משתמשים, קבוצות Google, זהויות של צד שלישי, חשבונות משתמשים של איחוד זהויות של עומסי עבודה ל-GKE (גרסת טרום-השקה (Preview)) וזהויות של סוכנים שיכולים לגשת למשאבים שצוינו מחוץ להיקף.

• ‫PRINCIPAL_IDENTIFIER – מציינים חשבון משתמש, חשבון שירות, קבוצה ב-Google, זהות של צד שלישי, ישות מורשית של איחוד זהויות של עומסי עבודה ל-GKE (בגרסת טרום-השקה) או זהות של סוכן שיכול לגשת למשאבים שצוינו מחוץ לגבולות הגזרה.

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

• sources: – המאפיין הזה מציין רשימה של מקורות ברשת. ערך המאפיין יכול להיות רשימה של פרויקטים, תיקיות, ארגונים, רמות גישה או נקודות קצה של Private Service Connect. כדי לאכוף הגבלות גישה על סמך הערך שצוין במאפיין sources, מגדירים את המאפיין sourceRestriction לערך SOURCE_RESTRICTION_ENABLED.

  ‫VPC Service Controls מעריך את המאפיינים accessLevel, resource ו-pscEndpoint של המאפיין sources כתנאי OR.

• - resource: – צריך להשתמש במאפיין הזה או במאפיין accessLevel. מציינים משאב אחד או יותר Google Cloud מתוך גבולות הגזרה לשירות ש רוצים לאפשר לו גישה לנתונים מחוץ לגבולות הגזרה. המאפיין הזה תומך בפרויקטים, בתיקיות ובארגונים. כדי לציין פרויקט, משתמשים בפורמט: projects/PROJECT_NUMBER. כדי לציין תיקייה, צריך להשתמש בפורמט: folders/FOLDER_NUMBER. כדי לציין ארגון, משתמשים בפורמט: organizations/ORGANIZATION_NUMBER.

  אי אפשר להשתמש ב-"*" במאפיין הזה כדי לאפשר את כל המשאבים של Google Cloud .

• - accessLevel: – צריך להשתמש במאפיין הזה או במאפיין resource. מציינים רמת גישה אחת או יותר שמאפשרת למשאבים בתוך הגבולות של הגזרה לגשת למשאבים מחוץ לגבולות של הגזרה. חשוב לוודא שרמות הגישה האלה מוגדרות באותה מדיניות גישה כמו ההיקף. אם מגדירים את המאפיין accessLevel כ-"*", מדיניות היציאה מאפשרת גישה מכל מקור ברשת.

• - pscEndpoint: – צריך להשתמש במאפיין הזה, במאפיין resource או במאפיין accessLevel. מציינת את נקודות הקצה של Private Service Connect שדרכן רוצים לאפשר למשאבים בתוך ה-perimeter לגשת למשאבים חיצוניים.

• ‫forwardingRule: – מציין את נקודת הקצה של Private Service Connect. כדי לציין נקודת קצה (endpoint) של Private Service Connect, משתמשים בפורמט הבא: //compute.googleapis.com/projects/PROJECT_ID/global/forwardingRules/FORWARDING_RULE_ID.

• sourceRestriction: – חובה אם משתמשים במאפיין sources. המאפיין הזה מאפשר לכם לאכוף הגבלות גישה על סמך sources שצוין. כדי לאכוף את הגבלות הגישה האלה, מגדירים את המאפיין sourceRestriction לערך SOURCE_RESTRICTION_ENABLED.

  כדי להשבית את הגבלות הגישה האלה, מגדירים את המאפיין sourceRestriction לערך SOURCE_RESTRICTION_DISABLED.

  אם לא מגדירים ערך למאפיין sourceRestriction, מערכת VPC Service Controls מתעלמת מהמאפיין sources ולא אוכפת הגבלות גישה.

• ‫title: – אופציונלי. המאפיין הזה מציין את השם של כלל התעבורה היוצאת. השם חייב להיות ייחודי בתוך ההיקף ולא יכול לחרוג מ-100 תווים. במדיניות הגישה, האורך הכולל של כל שמות הכללים לא יכול להיות יותר מ-240,000 תווים.

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

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

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

אם לא רוצים להעניק גישה לכל השיטות של שירות מסוים, לפעמים קשה לקבוע את רשימת השיטות המדויקת שרוצים לאפשר. הסיבה לכך היא ש-method מסוימת בשירות יכולה לגרום להפעלת method אחרת בשירות Google Cloud נפרד. לדוגמה, BigQuery טוען טבלה מקטגוריה של Cloud Storage כדי להריץ שאילתה.

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

תכונות שלא נתמכות

התכונות הבאות לא נתמכות כרגע בכללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress):

1. זיהוי משאבי Google Cloud לפי תוויות במקום לפי פרויקטים.
2. לא כל השירותים תומכים בכללי תעבורת נתונים נכנסת/יוצאת לכל שיטה. מידע נוסף על הגבלות על שיטות שירות נתמכות
3. אי אפשר להשתמש בסוגי הזהויות ANY_SERVICE_ACCOUNT ו-ANY_USER_ACCOUNT כדי לאשר את הפעולות הבאות:
   • כל הפעולות של Container Registry.
   • כל הפעולות בשירות notebooks.googleapis.com.
   • פעולות ב-Cloud Storage באמצעות כתובות URL חתומות.
   • עם פונקציות Cloud Run, אפשר לפרוס פונקציה של Cloud Functions מהמחשב המקומי.
   • ייצוא יומנים מ-sink ביומן Cloud Logging למשאב Cloud Storage.
   • כל הפעולות של ממשק האינטרנט של Apache Airflow ב-Managed Airflow.
4. חשוב להבין את המגבלות של השימוש בקבוצות זהויות בכללים לתעבורת נתונים נכנסת ויוצאת.

מגבלות

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

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

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