הגדרת מדיניות הרשאות ל-Secure Web Proxy

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

בדף הזה מוסבר איך מגדירים מדיניות הרשאות ל-Secure Web Proxy.

לפני שמתחילים

• קוראים את הדפים סקירה כללית של Secure Web Proxy וסקירה כללית של מדיניות ההרשאה.

• מפעילים את ממשקי ה-API הבאים:

  • Network Security API
  • Network Services API
  • Certificate Manager API

• חשוב לוודא שיש לכם את התפקידים וההרשאות המתאימים.

• צריך לפרוס מופע פעיל של Secure Web Proxy ולקשר אותו ל-GatewaySecurityPolicy. מידע נוסף זמין במאמר בנושא פריסת מופע של Secure Web Proxy.

• כדי להגדיר מדיניות הרשאות ל-Secure Web Proxy, צריך להפעיל מדיניות של בדיקת TLS.

יצירת מדיניות הרשאות

בקטע הזה מוסבר איך ליצור סוגים שונים של מדיניות הרשאות שמצורפת למופע של Secure Web Proxy.

כדי ליצור מדיניות הרשאות ל-Secure Web Proxy:

• מגדירים קובץ YAML שמגדיר את היעד ואת הכללים.
• מייבאים את הקובץ באמצעות הפקודה gcloud network-security authz-policies import.

מדיניות הרשאות שמבוססת על זהות mTLS

Secure Web Proxy תומך באכיפת כללי אבטחה שמבוססים על זהויות שנגזרות מאישורי Mutual TLS (mTLS). אכיפת כללים שמבוססים על הזהויות האלה שימושית במיוחד בסביבות של אפס אמון, שבהן התנועה בין הלקוחות לבין ה-proxy מאובטחת באמצעות mTLS. מידע נוסף זמין במאמר בנושא מדיניות הרשאות שמבוססת על גורמים ראשיים.

בדוגמה הבאה מוצגת מדיניות הרשאות למופע של Secure Web Proxy בשם swp1. בדוגמה הזו ההנחה היא שהתנועה אל ה-proxy משתמשת בפרוטוקול HTTPS.

המדיניות עם פרופיל REQUEST_AUTHZ אוכפת את הדרישה שכל התנועה אל example.com/mcp תדרוש אימות mTLS ממנהל ראשי ספציפי לפני שהתנועה מורשית לעבור. המדיניות גם חוסמת את כל התנועה היוצאת שלא מיועדת ל-example.com/mcp.

1. יוצרים את קובץ ה-YAML של מדיניות ההרשאות.

   בדוגמה הבאה נוצר קובץ authz-policy.yaml. המדיניות מאפשרת תנועה למארח ולנתיב שצוינו רק אם הלקוח מציג אישור שתואם לעיקרון SPIFFE ID שהוגדר.

   $ cat >authz-policy.yaml <<EOF
   name: test-authz-policy-mtls
   target:
     resources:
     - "projects/ PROJECT_ID /locations/ LOCATION /gateways/swp1"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - to:
     operations:
     - hosts:
         - exact: "example.com"
       paths:
         - exact: "/mcp"
     from:
       sources:
       - principals:
         - principalSelector: CLIENT_CERT_URI_SAN
           principal:
             exact: "spiffe:// PROJECT_ID .global.123.workload.id.goog/ns/ns1/sa/hellomcp"
   action: ALLOW
   EOF
   

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

   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
   • ‫LOCATION: האזור של מופע Secure Web Proxy

2. יוצרים מדיניות הרשאות ומייבאים את קובץ ה-YAML באמצעות הפקודה gcloud network-security authz-policies import.

   gcloud beta network-security authz-policies import my-authz-policy-allow
       --source=authz-policy.yaml
       --location= LOCATION 
   

   מחליפים את LOCATION באזור של מופע Secure Web Proxy.

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

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

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

• יצרתם חשבון שירות וצרפתם אותו למשאב Google Cloud.

• יצרתם תג וצירפתם אותו למשאב Google Cloud כצמד מפתח/ערך. כשיוצרים תג, מגדירים את הדגל --purpose לערך GCE_FIREWALL. כדי להחיל את התג על מדיניות הרשאה, צריך לציין את המטרה GCE_FIREWALL.

חשבון שירות

1. יוצרים קובץ YAML של מדיניות הרשאות כדי לאפשר בקשות מסוימות.

   בדוגמה הבאה נוצר קובץ authz-policy.yaml עבור מופע Secure Web Proxy בשם swp1. המדיניות מוגדרת כך שתאפשר בקשות ממכונה וירטואלית (VM) של Compute Engine עם חשבון השירות [e-mail] להגיע לנתיב example1.com/url1.

   $ cat >authz-policy.yaml <<EOF
   name: my-authz-policy-allow
   target:
       resources:
       - "projects/PROJECT_ID/locations/ LOCATION /gateways/swp1"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - from:
       sources:
           - resources:
               - iamServiceAccount:
                   exact: "[e-mail]"
     to:
       operations:
       - hosts:
           - exact: "example1.com"
       paths:
       - prefix: "/url1"
   action: ALLOW
   EOF
   

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

   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
   • ‫LOCATION: האזור של מופע Secure Web Proxy

2. יוצרים מדיניות הרשאות ומייבאים את קובץ ה-YAML באמצעות הפקודה gcloud network-security authz-policies import.

   בדוגמה הבאה מוצגת פקודה לייבוא של קובץ המדיניות שנוצר קודם וליצירת מדיניות הרשאות:

   gcloud network-security authz-policies import my-authz-policy-allow
   
       --source=authz-policy.yaml
       --location= LOCATION 
   

   מחליפים את LOCATION באזור של מופע Secure Web Proxy.

תג

1. יוצרים קובץ YAML של מדיניות הרשאות כדי לאפשר בקשות מסוימות.

   בדוגמה הבאה נוצר קובץ authz-policy-tag.yaml עבור מופע Secure Web Proxy בשם swp1. המדיניות מאפשרת גישה לנתיב כתובת ה-URL example1.com/url1 רק לבקשות שמקורן במשאב Google Cloudעם ערך תג TAG_VALUE_PERMANENT_ID.

   $ cat >authz-policy-tag.yaml <<EOF
   name: my-authz-policy-tag-allow
   target:
       resources:
       - "projects/PROJECT_ID/locations/ LOCATION /gateways/ GATEWAY_NAME "
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - from:
       sources:
       - resources:
           - tagValueIdSet:
               ids: ["TAG_VALUE_PERMANENT_ID"]
     to:
       operations:
       - hosts:
           - exact: "example1.com"
           paths:
           - exact: "/url1"
   action: ALLOW
   EOF
   

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

   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
   • ‫LOCATION: האזור של מופע Secure Web Proxy
   • ‫GATEWAY_NAME: השם של שער Secure Web Proxy
   • ‫TAG_VALUE_PERMANENT_ID: המזהה הקבוע של ערך תג, כמו tagValues/123456789012

2. יוצרים מדיניות הרשאות ומייבאים את קובץ ה-YAML באמצעות הפקודה gcloud network-security authz-policies import.

   הפקודה הבאה מייבאת את קובץ המדיניות שנוצר קודם ויוצרת מדיניות הרשאות באזור Google Cloud שצוין:

   gcloud network-security authz-policies import my-authz-policy-tag-allow
       --source=authz-policy-tag.yaml
       --location= LOCATION 
   

   מחליפים את LOCATION באזור של מופע Secure Web Proxy.

מדיניות הרשאות להקצאת הרשאות

כדי לקבל החלטות הרשאה מורכבות שלא ניתן לבטא באמצעות כללי ALLOW או DENY רגילים, אפשר ליצור מדיניות הרשאה עם פעולת CUSTOM. לאחר מכן תוכלו להעביר את ההחלטות שלכם לגבי הרשאות לתוספי הרשאות (Service Extensions).

חשוב: Secure Web Proxy תומך רק בתוספי הרשאה שמשתמשים בשם דומיין שמוגדר במלואו (FQDN).

כשמגדירים מדיניות עם פעולה CUSTOM, Secure Web Proxy מעביר את מטא-נתוני הבקשה או את מטען הייעודי (payload) ל-Service Extensions. בהתאם לתגובה מ-Service Extensions, שרת ה-proxy מאשר או דוחה את תעבורת הנתונים.

Secure Web Proxy תומך בסוגים הבאים של העברות הרשאה:

• האצלת החלטות הרשאה לבקשות ל-Service Extensions: אפשר להשתמש במדיניות הרשאות שמוגדרת עם פעולת CUSTOM ופרופיל REQUEST_AUTHZ כדי להאציל החלטות על סמך מטא-נתונים וכותרות של בקשות. במצב הזה, ההחלטה לגבי הגישה מועברת לתוסף הרשאה. במצב הזה אפשר לאמת זהויות והרשאות.

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

מגבלות

כשמטמיעים מדיניות הרשאות ל-Secure Web Proxy, חלות ההגבלות הבאות:

• מגבלות על היעד והקישוריות: תוספי הרשאות ל-Secure Web Proxy לא תומכים בשרת proxy לאימות זהויות (IAP) כיעד ישיר.

• סתירות בתנאי המדיניות ותאימות: אם יש לכם מדיניות אבטחה של שער עם כללי אבטחה קיימים, אתם לא צריכים להסיר אותם. ‫Secure Web Proxy מתעלם מהכללים האלה כשמחילים מדיניות הרשאה על המופע.

• דרישות הפרוטוקול והבדיקה: כדי להגדיר מדיניות הרשאות ל-Secure Web Proxy, צריך להפעיל בדיקת TLS.

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

• שימוש ב-mTLS בחלק הקדמי עם Secure Web Proxy