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

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

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

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

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

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

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

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

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

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

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

  • ‫from מפנה למאפיינים של לקוח ה-API.
  • ‫to מפנה למאפיינים של השירותים והמשאבים של Google Cloud .

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

  • בקשה מלקוח מחוץ להיקף למשאב Google Cloud בתוך ההיקף מותרת אם מתקיימים התנאים של כלל הכניסה הנדרש.
  • בקשה מלקוח בתוך גבולות הגזרה למשאב Google Cloud מחוץ לגבולות הגזרה מותרת אם מתקיימים התנאים של כלל תעבורת הנתונים היוצאת (egress) הנדרש.
  • קריאה ל-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).
  • לקוח BigQuery בתוך ההיקף שמשתמש במשימת BigQuery בפרויקט מחוץ להיקף כדי לשלוח שאילתה למערך נתונים של BigQuery בתוך ההיקף (לדוגמה, באמצעות הפקודה bq query).

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

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

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

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

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

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

מסמך עזר בנושא כללים לתעבורת נתונים נכנסת (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 (גרסת טרום-השקה (Preview)) או זהות של סוכן שרוצים לתת להם גישה למשאבים שבתוך ההיקף.

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

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

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

  • - 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 לערך "*".
  • המאפיין identityType או identities
  • מאפיין resources
  • מאפיין serviceName

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

אם מגדירים כמה כללי תעבורת נתונים נכנסת (ingress) בגבולות גזרה לשירות, 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 או בנקודות קצה של קטלוג מאוחד של Lakehouse. אפשר לציין רק משאבים של Amazon S3,‏ Azure Blob Storage או Azure Data Lake Storage Gen2:

    • Amazon S3:‏ s3://BUCKET_NAME
    • Azure Blob Storage (BigQuery Omni): azure://STORAGE_ACCOUNT.blob.core.windows.net/CONTAINER_NAME
    • ‫Azure Data Lake Storage Gen2 (נקודות קצה של קטלוג מאוחד של Lakehouse): abfss://CONTAINER_NAME@STORAGE_ACCOUNT.dfs.core.windows.net

    אי אפשר להחליף בין כתובות ה-URI של Azure Blob Storage (azure://) ושל Azure Data Lake Storage Gen2 (abfss://). צריך לציין את פורמט ה-URI שתואם לפרוטוקול האחסון שבו השירות משתמש.

  • ‫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 (גרסת טרום-השקה (Preview)) או זהות של סוכן שיכולים לגשת למשאבים שצוינו מחוץ להיקף.

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

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

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

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

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

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

בשלב הזה, התכונות הבאות לא נתמכות בכללי תעבורת נתונים נכנסת ויוצאת:

  1. זיהוי משאבי Google Cloud לפי תוויות במקום לפי פרויקטים.
  2. לא כל השירותים תומכים בכללי תעבורת נתונים נכנסת/יוצאת לכל שיטה. למידע על הגבלות על שיטות שירות נתמכות
  3. אי אפשר להשתמש בסוגי הזהויות ANY_SERVICE_ACCOUNT ו-ANY_USER_ACCOUNT כדי לאפשר את הפעולות הבאות:
  4. להבין את המגבלות של השימוש בקבוצות זהויות בכללים לתעבורת נתונים נכנסת ויוצאת.

מגבלות

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

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