סקירה כללית של כתובות ה-IP של המשתמשים

כללים במדיניות האבטחה של Google Cloud Armor שמסננים על סמך כתובת IP בדרך כלל משתמשים בכתובת ה-IP של הלקוח של המתקשר. אם השירותים שלכם נמצאים מאחורי מתווך, כמו רשת להעברת תוכן (CDN) של צד שלישי, כתובת ה-IP של הלקוח בשדה origin.ip היא כתובת ה-IP של המתווך האחרון, ולא של הלקוח המקורי.

התכונה 'כתובת ה-IP של המשתמש' מאפשרת להגדיר שדה חלופי, origin.user_ip, כדי לבצע המרה מכותרת שהספק במעלה הזרם מאכלס. אחר כך תוכלו להשתמש בשדה origin.user_ip בכללי מדיניות האבטחה כדי לציין את כתובת ה-IP שבה נעשה שימוש בתכונות האלה. כשמשתמשים ב-origin.user_ip, אפשר להגדיר את האפשרות userIpRequestHeaders[] בשדה advancedOptionsConfig של מדיניות האבטחה.

איך כתובות ה-IP של המשתמשים פועלות

מגדירים את Cloud Armor לחילוץ כתובת ה-IP של משתמש הקצה מכותרת בקשה ספציפית. הערך הזה מאכלס את השדה origin.user_ip, שאחר כך אפשר להשתמש בו בכללים של מדיניות האבטחה.

אם הכותרות שצוינו ב-userIpRequestHeaders[] לא קיימות, או אם הערכים שלהן לא מייצגים כתובות IP תקינות, Cloud Armor יחזור לכתובת ה-IP של הלקוח (origin.ip) במקום זאת. בדוגמה הבאה מוצגת השוואה ישירה למקרה ברירת המחדל.

origin.ip != origin.user_ip

בדוגמאות הבאות מוצגות דרכים לשימוש ב-origin.user_ip בשפת הכללים, ב-Google Threat Intelligence ובקבוצות כתובות.

inIpRange

inIpRange(origin.user_ip, '9.9.9.0/24')

מידע נוסף על שימוש ב-inIpRange עם origin.user_ip זמין במאמר מאפיינים.

Google Threat Intelligence

evaluateThreatIntelligence('iplist-known-malicious-ips', origin.user_ip)

מידע נוסף זמין במאמר בנושא החלת Google Threat Intelligence.

קבוצות של כתובות

evaluateAddressGroup('example-address-group', origin.user_ip)

מידע נוסף מופיע במאמר הגדרת קבוצות כתובות.

קבוצות כתובות בהיקף הארגון

evaluateOrganizationAddressGroup('example-org-address-group', origin.user_ip)

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

שיטות מומלצות

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

כדי לאמת את המקור במעלה הזרם, יוצרים מדיניות אבטחה עם לפחות שני כללים. הכלל הראשון, עם עדיפות גבוהה יותר, בודק שכתובת ה-IP של הלקוח המיידי (origin.ip) שייכת לספק מהימן במעלה הזרם. הכלל השני, עם עדיפות נמוכה יותר, מחיל את הלוגיקה הרצויה באמצעות השדה origin.user_ip.

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

  • כלל 1: evaluateThreatIntelligence('iplist-public-clouds', origin.ip)
  • כלל 2: inIpRange(origin.user_ip, '9.9.9.0/24')

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