Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

כללי אבטחה

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

בעזרת Secure Web Proxy אפשר להגדיר סוגים שונים של כללי אבטחה במדיניות האבטחה של השער כדי לאבטח תנועת אינטרנט יוצאת. אתם יכולים להשתמש בכללים האלה כדי לשלוט באופן מדויק באבטחת התנועה. לשם כך, אתם יכולים להשתמש בפרטים ספציפיים של בקשות – כמו כותרות ותבניות של כתובות URL – כדי לוודא שרק תנועת HTTP/S מאושרת יוצאת מהרשת שלכם.

כללי אבטחה של שער כוללים את התכונות הבאות:

כל כלל הוא הצהרת if-then שבודקת בקשה לאחזור מהרשת לפי הפרמטרים הבאים:
- זהות המקור: מי שולח את הבקשה, כמו מכונה וירטואלית (VM) ספציפית או חשבון שירות.
- יעד: לאן הבקשה מופנית, למשל כתובת יעד או דומיין כמו trusted-partner.com.
- פעולה: ההחלטה לאשר את התנועה או לדחות אותה.
כללי אבטחה של שער מספקים שליטה פרטנית. הכללים האלה מאפשרים לכם לאכוף תקני אבטחה שונים בארגון באמצעות הגדרות ברורות ומובנות.

כללים להתאמה למארח

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

מצב פריסה	תהליך אימות המארח
מצב שרת proxy מפורש	בתנועה לא מוצפנת, שרת ה-proxy בודק את שם המארח מול כותרת החיבור של HTTP. אם משתמשים ב[מאפיינים של Application Matcher](/secure-web-proxy/docs/cel-matcher-language-reference#attributes-available-only-to-applicationmatcher) לבדיקת TLS, ה-proxy בודק את שם המארח קודם ברמת החיבור ואז ברמת האפליקציה.
מצב הצעד הבא	בתנועה מוצפנת, ה-proxy בודק את שם המארח של היעד מול השדה Server Name Indication (SNI) בבקשה היוצאת. השדה הזה גלוי גם בחיבורים מאובטחים.

מצב פריסה

תהליך אימות המארח

מצב שרת proxy מפורש

בתנועה לא מוצפנת, שרת ה-proxy בודק את שם המארח מול כותרת החיבור של HTTP. אם משתמשים ב[מאפיינים של Application Matcher](/secure-web-proxy/docs/cel-matcher-language-reference#attributes-available-only-to-applicationmatcher) לבדיקת TLS, ה-proxy בודק את שם המארח קודם ברמת החיבור ואז ברמת האפליקציה.

מצב הצעד הבא

בתנועה מוצפנת, ה-proxy בודק את שם המארח של היעד מול השדה Server Name Indication (SNI) בבקשה היוצאת. השדה הזה גלוי גם בחיבורים מאובטחים.

הגדרת כללי התאמה למארחים במצב proxy מפורש

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

התאמת מארחים במצב פרוקסי מפורש פועלת עבור סוגים שונים של תנועת אינטרנט באופן הבא:

סוג תעבורה	מנגנון ההתאמה	הגדרת הכלל
HTTP לא מוצפן	Secure Web Proxy בודק את שם המארח של היעד מול השדה `host` בכותרת `CONNECT` הרגילה של בקשת ה-HTTP.	בשדה `sessionMatcher`, משתמשים ב-`host() == "example.com"`.
‫HTTPS מוצפן (ללא בדיקה של Transport Layer Security‏ (TLS))	אי אפשר לבצע התאמה למארח ברמת האפליקציה או ברמת הסשן. הסיבה לכך היא שפרטי הבקשה מוצפנים והמאפיין `destination.ip` לא נתמך. צריך להשתמש באמצעי בקרה רחבים יותר של מדיניות, כמו התאמה של זהות המקור, או להפעיל בדיקת TLS לסינון מבוסס-מארח.	כדי להשתמש בכלי להשוואת אפליקציות, משתמשים בהשוואת זהויות של מקורות כמו חשבונות שירות, או מפעילים בדיקת TLS.
‫HTTPS מוצפן (עם בדיקת TLS)	כדי לבדוק את הבקשה המלאה, צריך להשתמש גם ב-Session Matcher וגם ב-Application Matcher.	1. מגדירים כלל כללי של התאמת סשנים שמחזיר `true` או מתאים למארח היעד, כמו `host() == "example.com"`. 2. בשדה `applicationMatcher` מוסיפים כלל ספציפי למארח, כמו `request.host() == "example.com"`.

הגדרת כללי התאמה למארח למצב 'הקפיצה הבאה'

כשפורסים את Secure Web Proxy כנקודת מעבר הבאה, צריך להגדיר כללים להתאמת מארחים. התנועה מנותבת מחדש ל-proxy דרך מסלול של ענן וירטואלי פרטי (VPC) על סמך טווחי כתובות IP שאתם מגדירים. כללי התאמה למארח מוודאים ששרת ה-proxy מזהה נכון את מארח היעד על ידי בדיקה של שדות שונים בתעבורה, כמו כותרת Server Name Indication‏ (SNI).

התאמת מארחים במצב 'הקפיצה הבאה' פועלת עבור סוגים שונים של תנועת אינטרנט באופן הבא:

סוג תעבורה	מנגנון ההתאמה	הגדרת הכלל
HTTP לא מוצפן	שרת ה-Proxy המאובטח לאינטרנט בודק את שם המארח של היעד מול השדה `host` בכותרת בקשת ה-HTTP הרגילה.	בשדה `sessionMatcher`, משתמשים ב-`host() == "example.com"`.
‫HTTPS מוצפן (ללא בדיקת TLS)	השירות Secure Web Proxy בודק את שם המארח מול כותרת ה-SNI בבקשה היוצאת, שגלוי גם אם שאר התנועה מוצפנת.	בשדה `sessionMatcher`, משתמשים ב-`host() == "example.com"`.
‫HTTPS מוצפן (עם בדיקת TLS)	כדי לבדוק את הבקשה המלאה, צריך להשתמש גם ב-Session Matcher וגם ב-Application Matcher.	1. מגדירים כלל כללי של התאמת סשנים שמחזיר `true` או מתאים למארח היעד, כמו `host() == "example.com"`. 2. בשדה `applicationMatcher` מוסיפים כלל ספציפי למארח, כמו `request.host() == "example.com"`.

כללים לשרת proxy ל-TCP

כללי שרת proxy של פרוטוקול בקרת העברה (TCP) מאפשרים לכם לשלוט בתנועה שאינה תנועת אינטרנט רגילה, כמו HTTP (יציאה 80) או HTTPS (יציאה 443). על ידי הגדרת כללי שרת proxy של TCP, אתם יכולים לאפשר או לחסום תנועה בכל יציאת TCP אחרת. הכללים האלה עוזרים לחסום תעבורה זדונית ולנהל אפליקציות שאינן אפליקציות אינטרנט שמשתמשות ב-TCP.

אם עומס העבודה (למשל האפליקציות והשירותים) משתמש ב-Secure Web Proxy כצעד הבא, כדאי להחיל כללי TCP Proxy. הפניה מבוססת-נתיב מפנה תנועה שאינה HTTP(S) ותנועה שאינה באינטרנט למופע של Secure Web Proxy. כך תוכלו לחסום תנועה יוצאת כדי שלא תגיע לאתרים חיצוניים זדוניים, ולנהל את השירותים החיצוניים שעומסי העבודה ברשת יכולים להתחבר אליהם.

הגדרת כללים ל-TCP proxy

אתם יכולים להגדיר כללי TCP proxy לאפליקציה כדי לאבטח תעבורה שאינה תעבורת אינטרנט ולאכוף מדיניות אבטחה באפליקציות שלא משתמשות ב-HTTP/S רגיל, למשל עבור יציאות 80 ו-443.

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

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

בטבלה הבאה מפורט מידע נוסף על המאפיינים השונים שאפשר להשתמש בהם בכלל של שרת proxy ל-TCP:

מאפיין	סוג מאפיין	תיאור
`source.ip`	מחרוזת	כתובת ה-IP של הלקוח ששלח את הבקשה.
`source.port`	מחרוזת	יציאת הלקוח ששלחה את הבקשה.
`destination.port`	מחרוזת	יציאת ה-Upstream שאליה מופנית התנועה ממופע Secure Web Proxy.
`source.matchTag(SECURE_TAG)`	בוליאני	‫`True`, אם המקור משויך ל-`SECURE_TAG`. הארגומנט הוא המזהה הקבוע של התג המאובטח, למשל `source.matchTag('tagValues/123456')`.
`source.matchServiceAccount(SERVICE_ACCOUNT)`	בוליאני	‫`True`, אם המקור משויך ל- `SERVICE_ACCOUNT` כמו `source.matchServiceAccount('x@my-project.iam.gserviceaccount.com')`.
`inIpRange(IP_ADDRESS, IP_RANGE)`	בוליאני	‫`True`, אם `IP_ADDRESS` נמצא בתוך `IP_RANGE`, כמו `inIpRange(source.ip, '1.2.3.0/24')`. מסכות של רשתות משנה לכתובות IPv6 לא יכולות להיות גדולות מ-‎/64.

דוגמה לכלל של שרת proxy ל-TCP

בדוגמה הזו מוסבר איך להגדיר Secure Web Proxy ‏(SWP) ‏gatewaySecurityPolicyRule באמצעות ביטוי CEL כדי לאפשר את כל תעבורת ה-TCP ליציאה 22. אפשר להשתמש בהגדרה הזו כשמפעילים את היכולות של שרת ה-TCP proxy של Secure Web Proxy.

בדוגמת הקוד הבאה אפשר לראות איך מגדירים כלל של שרת proxy ל-TCP:

name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/POLICY_NAME/rules/RULE_NAME
enabled: true
priority: 100 # Lower numbers have higher priority
description: "Allow TCP proxy traffic to port 22 - such as, for SSH"
basicProfile: ALLOW
sessionMatcher: "destination.port == 22"

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

‫PROJECT_ID: מזהה הפרויקט
‫REGION: האזור של המדיניות
‫POLICY_NAME: שם המדיניות
‫RULE_NAME: השם של כלל ה-TCP proxy. בדוגמה הזו, אפשר להתייחס לערך שלו כאל allow-ssh-tcp-proxy.

שיקולים חשובים

לכל כללי ה-proxy של TCP שאתם מגדירים צריכה להיות עדיפות גבוהה יותר (מספר נמוך יותר) מכללי HTTP/S, כדי לוודא שהמערכת תעריך אותם ותפעל לפיהם קודם. מידע נוסף מופיע במאמר בנושא סדר ההערכה של הכללים.
כשמגדירים כללי TCP proxy, לא ניתן להשתמש במאפיין host Session Matcher כי פרטי המארח לא זמינים בשכבת ה-TCP.
כללי שרת proxy של TCP מסננים את תנועת הגולשים באתר רק על סמך יציאת היעד. כדי לשפר את אבטחת הרשת, מומלץ להוסיף תנאים אחרים באמצעות אופרטורים לוגיים: האופרטור הלוגי AND ‏ (&&) והאופרטור הלוגי OR ‏ (||), ותכונות נתמכות כמו source.ip. דוגמה להגדרת כלל ספציפי יותר של TCP Proxy:
```
  // Allow port 22 from only a specific source IP range
  sessionMatcher: "destination.port == 22 && inIpRange(source.ip, '10.0.0.0/24')"
```
ב-Secure Web Proxy אין תמיכה בהגדרת כללי proxy לאפליקציות של User Datagram Protocol‏ (UDP). כתוצאה מכך, Secure Web Proxy חוסם את התנועה של אפליקציות מבוססות UDP.

יצירת כלל אבטחה

לפני שיוצרים כלל אבטחה לשער, חשוב לבצע את הפעולות הבאות:

משלימים את כל השלבים של ההגדרה הראשונית.
יצירת מדיניות

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

המסוף

נכנסים לדף SWP Policies במסוף Google Cloud .

מעבר אל מדיניות SWP
לוחצים על שם המדיניות, למשל policy1.
לוחצים על הוספת כלל.
לכל כלל, מבצעים את הפעולות הבאות:
1. בשדה עדיפות, מזינים מספר של סדר ההערכה של הכלל. הכללים מוערכים מהעדיפות הגבוהה ביותר לנמוכה ביותר, כאשר 0 היא העדיפות הגבוהה ביותר.
2. בשדה Name, מזינים שם לכלל.
3. בשדה Description (תיאור), מזינים תיאור לכלל.
4. בקטע פעולה, בוחרים באחת מהאפשרויות הבאות:
  - אישור: כדי לאשר בקשות לחיבור שתואמות לכלל.
  - ‫Deny: כדי לדחות בקשות לחיבור שתואמות לכלל.
5. בשדה סטטוס, בוחרים אחת מהאפשרויות הבאות לאכיפת הכלל:
  - מופעלת: כדי לאכוף את הכלל במופע Secure Web Proxy.
  - מושבת: כדי לא לאכוף את הכלל במופע של Secure Web Proxy.
6. בקטע Session Match (התאמה לסשן), מציינים את הקריטריונים להתאמה לסשן, כמו host() == "www.wikipedia.org".
  
  מידע נוסף על התחביר של SessionMatcher זמין במאמר הפניה לשפת ההתאמה של CEL.
7. בקטע Application Match, מציינים את הקריטריונים להתאמת הבקשה.
  
  מידע נוסף על התאמת תנועת TCP זמין במאמר הגדרת כללי שרת proxy של TCP.
8. לוחצים על הוספת כלל.

Cloud Shell

משתמשים בעורך הטקסט המועדף כדי ליצור קובץ rule.yaml. מידע נוסף על התחביר של sessionMatcher זמין במאמר בנושא הפניה לשפת ההתאמה של CEL.
```
name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
description: Allow wikipedia.org
enabled: true
priority: 1
basicProfile: ALLOW
sessionMatcher: host() == 'www.wikipedia.org'
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט
- ‫REGION: האזור של המדיניות
- ‫RULE_NAME: שם הכלל. בדוגמה הזו, אפשר להתייחס לערך שלו כאל allow-wikipedia-org.
אופציונלי: אם רוצים ליצור כלל עם בדיקת TLS מופעלת, יוצרים את הקובץ rule.yaml כמו שמוצג כאן. מידע נוסף זמין במאמרים סקירה כללית על בדיקת TLS והפעלת בדיקת TLS.
```
  name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
  description: Allow wikipedia.org
  enabled: true
  priority: 1
  basicProfile: ALLOW
  sessionMatcher: host() == 'www.wikipedia.org'
  applicationMatcher: request.path.contains('index.html')
  tlsInspectionEnabled: true
```
מידע נוסף על התאמת תנועת TCP זמין במאמר הגדרת כללי שרת proxy של TCP.

חשוב: כדי להפעיל בדיקת TLS לכל כלל שיוצרים, צריך להגדיר את מאפיין tlsInspectionEnabled לערך true לכל כלל שמשתמש ב-applicationMatcher כדי להתאים לתנועת HTTPS. הבדיקה של TLS לכלל מוגבלת לתנועה שתואמת למאפיין sessionMatcher של הכלל. מידע נוסף זמין במאמר בנושא הערכת כלל לבדיקת TLS.

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

gcloud network-security gateway-security-policies rules import allow-wikipedia-org \
    --source=rule.yaml \
    --location=REGION \
    --gateway-security-policy=policy1

מגבלות

אם יוצרים מדיניות הרשאה במופע של Secure Web Proxy, ה-proxy מתעלם מכל כללי האבטחה של השער ומכל מדיניות האבטחה של השער שקיימים.
ב-Secure Web Proxy אין תמיכה בהגדרת כללים לאפליקציות של User Datagram Protocol‏ (UDP). ‫Secure Web Proxy חוסם את התעבורה של אפליקציות שמבוססות על UDP.