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

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

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

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

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

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

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

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

1. כללי כניסה ויציאה מאפשרים לכם להחליף נתונים באופן פרטי ויעיל בתוך ארגונים ובארגונים שונים באמצעות ממשקי API של שירותים. Google Cloud
2. כללים לתעבורת נתונים נכנסת ויוצאת מאפשרים לכם להעניק גישה ל Google Cloud משאבים בגבול גזרה על סמך ההקשר של בקשת ה-API:
   1. הגבלת סוגי הזהויות או הזהויות שאפשר להשתמש בהן בהינתן רשת מקור, כתובת IP או מכשיר.
   2. הגבלת Google Cloud הגישה לממשקי API ולשיטות מסוימות בהתאם לרשת המקור, לכתובת ה-IP, למכשיר ולסוג הזהות.
3. כדי לצמצם את הסיכון לזליגת מידע, צריך להגביל את השירות, השיטות,Google Cloud הפרויקטים, רשתות ה-VPC והזהויות שמשמשים להפעלת אוסף הנתונים לשיתוף.
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 בשני הכיוונים. כללים לתעבורת נתונים נכנסת (ingress) ויוצאת (egress) לא תלויים בסמנטיקה של בקשת ה-API ובכיוון של תנועת הנתונים.

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

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

• לקוח 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, זהויות של צד שלישי וזהויות של סוכנים שיכולים לגשת למשאבים בפרימטר.

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

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

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

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

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

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

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

אפשר להגדיר כללי תעבורת נתונים יוצאת (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. השדה הזה יכול להיות method תקף של שירות, או שאפשר להגדיר בו את הערך "*" כדי לאפשר גישה לכל ה-methods של השירות שצוין.

• - 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, זהויות של צד שלישי וזהויות של סוכנים שיכולים לגשת למשאבים שצוינו מחוץ להיקף.

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

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

• ‫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 שדרכן רוצים לאפשר למשאבים בתוך גבולות הגזרה לגשת למשאבים חיצוניים.

• ‫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 מאשרת בקשה אם היא עומדת בתנאים של אחד מכללי היציאה.

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

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

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

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

התכונות הבאות לא נתמכות כרגע בכללי תעבורת נתונים נכנסת (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 מהמחשב המקומי.
   • ייצוא יומנים ממאגר Cloud Logging למשאב Cloud Storage.
   • כל הפעולות בממשק האינטרנט של Apache Airflow ב-Managed Airflow.
4. חשוב להבין את המגבלות של השימוש בקבוצות זהויות בכללים לתעבורת נתונים נכנסת ויוצאת.

מגבלות

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

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

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