‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

בדף הזה מוסבר איך להגדיר כללי מדיניות הרשאה ל-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.

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

אפשר להגדיר כללי מדיניות של הרשאות לשני תרחישים שונים:

ניהול תנועה של סוכנים: כדי לאבטח את התנועה היוצאת מסוכני AI לשרתים, לכלים ולמודלים של Model Context Protocol‏ (MCP), קראו את המאמר הגדרת כללי מדיניות הרשאה ליעדים של סוכנים. אתם יכולים להגדיר כללי מדיניות וקישורי תוספים במשאב agentGateway כדי לאכוף הגבלות על כלי MCP, זהויות של סוכני mTLS והסרת תוכן זדוני או רגיש מהמטען הייעודי (payload).
אבטחת תנועה באתר ללא סוכנים: כדי לאבטח תנועה יוצאת באתר מעומסי עבודה ארגוניים ללא סוכנים, עיינו בדוגמאות שבקטעים הבאים. אתם יכולים להגדיר כללי מדיניות ישירות במשאב של Secure Web Proxy Gateway כדי לאכוף זהויות של אישורי לקוח mTLS, חשבונות שירות, תגים מאובטחים או תוספים מותאמים אישית שמפנים לבדיקת הרשאות.

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

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

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

כשפורסים את Secure Web Proxy בתור Agent Gateway, אפשר להגדיר כללי מדיניות של הרשאות כדי לבדוק ולהגביל את התנועה שמופנית לשרתי הכלים של MCP וליעדים של סוכני ה-AI.

אפשר להגדיר כללים שאוכפים את בקרת הגישה בשכבות הבקשה הבאות:

כללי רשת: דילוג על בדיקת TLS או על ניתוח מעמיק של המטען הייעודי (payload) בנקודות קצה ספציפיות של מודלים או סוכנים חיצוניים מהימנים.
קישורי תוספים: משתמשים במשאבי ExtensionBinding בתוספי שירות כדי לצרף מעבדי אבטחה ופיקוח חיצוניים, כמו שרת proxy לאימות זהויות (IAP) לאימות זהות הסוכן ו-Model Armor לניקוי הנחיות ותשובות.
סינון כלים ושיטות HTTP MCP: אכיפת אמצעי בקרה מפורטים על פעולות MCP ספציפיות, כמו tools/list או tools/call, ואימות ארגומנטים כדי להגביל את הכלים שנציג יכול להפעיל.

סדר ההערכה של כללי ההרשאה

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

כללי הרשאה ברשת (L4): נבדקים קודם. אם חל כלל התאמה של SNI, כמו מתן הרשאה לתקשורת ישירה עם נקודת קצה של מודל חיצוני, תעבורת הנתונים עוקפת את יירוט ה-TLS.
יירוט TLS: תנועה שלא עוקפת את השער מיורטת ומפוענחת באמצעות מדיניות בדיקת ה-TLS של השער.
כללי קישור של תוספים: הבקשות נבדקות על ידי שירותי תוספים שהוגדרו, כמו IAP, כדי לאמת את זהות מבצע הקריאה בכותרות של הבקשות, ו-Model Armor כדי לבדוק מטענים ייעודיים (payloads) מפוענחים, לשמור על הבטיחות של ההנחיות ולמנוע דליפות של נתונים רגישים בתשובות.
כללי הרשאה של HTTP (L7): כללי מדיניות הרשאה ברמת HTTP, כמו הגבלות על כלי MCP וסינון שיטות, נבדקים.

דוגמה 1: הגבלת ההפעלה של כלי MCP

בדוגמה הבאה מוצגת מדיניות הרשאה שמצורפת למשאב agentGateway, שמאפשרת לנציגים לגלות כלים (tools/list) ולהריץ רק כלים שאושרו (tools/call עבור get_weather ו-get_location):

יוצרים קובץ בשם authz-policy-mcp.yaml.

name: authz-policy-restrict-tools
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
httpRules:
- to:
    operations:
    - mcp:
        baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS
        methods:
        - name: "tools/list"
        - name: "tools/call"
          params:
          - exact: "get_weather"
          - exact: "get_location"
action: ALLOW

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

‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
‫LOCATION: האזור שבו פרוסים המכונות של Agent Gateway ו-Secure Web Proxy
‫AGENT_GATEWAY_NAME: השם של המשאב agentGateway שמשויך לשער של Secure Web Proxy

כדי לייבא את מדיניות ההרשאות, מריצים את הפקודה gcloud network-security authz-policies import.

gcloud network-security authz-policies import authz-policy-restrict-tools \
    --source=authz-policy-mcp.yaml \
    --location=LOCATION

דוגמה 2: עקיפת יירוט TLS באמצעות התאמת SNI

אם ספקים מסוימים של מודלים חיצוניים או ממשקי API של סוכנים משתמשים בהצמדת אישורים או לא דורשים בדיקת מטען ייעודי (payload), אתם יכולים להשתמש בכללי רשת כדי להתאים את ציון שם השרת (SNI) ולאפשר את החיבור בלי לפענח את הסשן.

יוצרים קובץ בשם authz-policy-sni.yaml.
```
name: authz-policy-skip-interception
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
networkRules:
- to:
    operations:
    - snis:
      - exact: "api.example-model-provider.com"
action: ALLOW
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
- ‫LOCATION: האזור שבו פרוסים המכונות של Agent Gateway ו-Secure Web Proxy
- ‫AGENT_GATEWAY_NAME: השם של המשאב agentGateway שמשויך לשער של Secure Web Proxy

כדי לייבא את מדיניות ההרשאות, מריצים את הפקודה gcloud network-security authz-policies import.

gcloud network-security authz-policies import authz-policy-skip-interception \
    --source=authz-policy-sni.yaml \
    --location=LOCATION

דוגמה 3: הפעלת בדיקה מעמיקה של המטען הייעודי (payload) באמצעות Model Armor באמצעות קישורי תוספים

כדי להתגונן מפני החדרת פרומפטים, פלט רעיל או דליפת מידע רגיש, אתם יכולים להעביר את עיבוד התנועה ל-Model Armor או למעבד ext_proc מותאם אישית באמצעות קישורי תוספים ב-Service Extensions.

המודל הזה מפריד בין ספק התוסף לבין הצרכן באופן הבא:

שירותי Google (אינטראקציה ישירה): Google מנהלת את התשתית הבסיסית של שירותי Google המובנים, כמו Model Armor ו-IAP. אפשר לקשר ישירות את השירות באמצעות מזהי URI של נקודות קצה שהוגדרו מראש (modelarmor.googleapis.com או iap.googleapis.com).
תוספים בהתאמה אישית ותוספים של שותפים (2P/3P): למעבדים פנימיים בהתאמה אישית או לספקי אבטחה של צד שלישי, היצרן מפרסם משאב ProducerExtension שמפנה לקובץ המצורף לשירות Private Service Connect, והצרכן מקשר את ה-URI של המשאב הזה.

למידע נוסף על האופן שבו מתבצעת הערכה של מדיניות הרשאות ותוספים במשאב agentGateway, קראו את המאמרים הקצאת הרשאות באמצעות Service Extensions ומדיניות ניתנת להרחבה ב-Agent Gateway.

כדי להגדיר קישור של תוסף ל-Model Armor:

מפעילים את Service Extensions API.

gcloud services enable serviceextensions.googleapis.com

יוצרים קובץ תצורה בשם extension-binding-model-armor.yaml שמטרגט את המשאב agentGateway, מגדיר את תבניות הבדיקה ומיירט את התנועה שמיועדת לשרתי MCP.
```
name: ext-binding-model-armor
target:
  resources:
  - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
failOpen: false
producerExtension: modelarmor.googleapis.com
producerMetadata:
  model_armor_settings: '[
    {
      "request_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID",
      "response_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID"
    }
  ]'
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
- ‫LOCATION: האזור שבו פרוסים המכונות של Agent Gateway ו-Secure Web Proxy
- ‫AGENT_GATEWAY_NAME: השם של המשאב ב-agentGateway
- ‫TEMPLATE_PROJECT_ID: מזהה הפרויקט שבו נוצרו התבניות של Model Armor
- ‫REQUEST_TEMPLATE_ID: מזהה התבנית שמשמשת לבדיקת הבקשות הנכנסות
- ‫RESPONSE_TEMPLATE_ID: מזהה התבנית שמשמשת לבדיקת התשובות היוצאות
הערה:
- ‫failOpen: false חוסם את התנועה אם שירות התוסף לא נגיש. כדי לאפשר לתנועה לעבור בלי בדיקה במהלך שיבושים בשירות, מגדירים את failOpen: true.
- כדי לקשר תוסף פנימי או תוסף של צד שלישי בהתאמה אישית במקום Model Armor, מגדירים את producerExtension לנתיב המשאב של היצרן בפורמט הבא: projects/PRODUCER_PROJECT_ID/locations/LOCATION/producerExtensions/PRODUCER_EXTENSION_NAME.

כדי לייבא את הקישור של התוסף, מריצים את הפקודה gcloud beta service-extensions extension-bindings import.

gcloud beta service-extensions extension-bindings import ext-binding-model-armor \
    --source=extension-binding-model-armor.yaml \
    --location=LOCATION

מידע נוסף על קישור IAP לאימות זהות זמין במאמר צירוף קישורי תוספים ל-Agent Gateway.

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

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

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

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

יוצרים את קובץ ה-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

יוצרים מדיניות הרשאה ומייבאים את קובץ ה-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.

חשבון שירות

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

בדוגמה הבאה נוצר קובץ authz-policy.yaml למכונה של Secure Web Proxy בשם swp1. המדיניות מוגדרת כך שהיא מאפשרת לבקשות ממכונה וירטואלית (VM) של Compute Engine עם חשבון השירות my-sa-123@56788.iam.gserviceaccount.com להגיע לנתיב 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: "my-sa-123@56788.iam.gserviceaccount.com"
  to:
    operations:
    - hosts:
        - exact: "example1.com"
    paths:
    - prefix: "/url1"
action: ALLOW
EOF
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
- ‫LOCATION: האזור של מכונת Secure Web Proxy
יוצרים מדיניות הרשאה ומייבאים את קובץ ה-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.

תג

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

בדוגמה הבאה נוצר קובץ authz-policy-tag.yaml למכונה של Secure Web Proxy בשם swp1. המדיניות מאפשרת רק לבקשות שמגיעות ממשאב Google Cloudעם ערך התג TAG_VALUE_PERMANENT_ID לגשת לנתיב כתובת ה-URL‏ example1.com/url1.
```
$ 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
יוצרים מדיניות הרשאה ומייבאים את קובץ ה-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. לאחר מכן תוכלו להעביר את ההחלטות לגבי ההרשאות לתוספים שמפנים לבדיקת הרשאות (תוספי שירות).

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

‫Secure Web Proxy תומך בסוגי ההקצאות הבאים:

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

מגבלות

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

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

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

שימוש ב-mTLS של ממשק קצה עם Secure Web Proxy