במסמך הזה מתוארים תרחישים נפוצים לשימוש בכללי מדיניות האבטחה של Google Cloud Armor. מדיניות האבטחה של Cloud Armor עוזרת להגן על האפליקציה באמצעות רשימות של כתובות IP שמוגדרות כרשימות מותרות או כרשימות חסומות, וכללים שמוגדרים מראש ומונעים מתקפות נפוצות באינטרנט.
דוגמאות למדיניות אבטחה
בקטע הזה מוסבר איך משתמשים בכללי מדיניות האבטחה של Cloud Armor כדי לשלוט בגישה לאפליקציות או לשירותים.
איך מאשרים גישה למשתמשים בכתובות IP ספציפיות באמצעות רשימות היתרים
אפשר להשתמש ברשימת היתרים של כתובות IP כדי להגביל את הבקשות לכתובות IP ספציפיות או לטווחים של CIDR, כמו כתובות ה-IP הציבוריות של הסניפים שלכם. אתם יכולים לאפשר רק תנועה שמגיעה מהטווחים שצוינו.
כדי לשלוט בגישה למאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או למאזן עומסים קלאסי של אפליקציות (ALB), צריך להגדיר רשימת היתרים עם כתובות IP של לקוחות או טווחי CIDR של לקוחות. בקטע הבא מוסבר על ההגדרה הזו.
בהגדרה הזו, אתם מאפשרים רק לבקשות מכתובות IP של לקוחות בטווח מסוים לגשת למאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או למאזן עומסים קלאסי של אפליקציות. רוצים לדחות את כל התנועה האחרת.
כדי ליצור את ההגדרה הזו, מבצעים את השלבים הבאים:
- יוצרים כללי מדיניות אבטחה של Cloud Armor.
- במדיניות האבטחה, מוסיפים כלל שמוסיף את הטווח לרשימת ההיתרים.
התיאור של הכלל הזה הוא
allow [RANGE], כאשר[RANGE]הוא טווח כתובות ה-IP הרצוי. - משנים את כלל ברירת המחדל במדיניות מכלל הרשאה לכלל דחייה. כלל ברירת המחדל הוא הכלל האחרון במדיניות, והוא חל על תנועה שלא תואמת לאף אחד מהכללים הקודמים. שינוי הכלל הזה ל-
denyחוסם את כל התנועה שלא נמצאת בטווח של רשימת ההיתרים. - משייכים את המדיניות הזו למאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או לשירות לקצה העורפי של מאזן העומסים הקלאסי של אפליקציות (ALB).
אם הארגון שלכם משתמש בספק אבטחה של צד שלישי כדי לסנן תנועה, אתם יכולים להוסיף את כתובת ה-IP של ספק האבטחה לרשימת ההיתרים כדי לוודא שרק תנועה מסוננת תוכל לגשת אל Global External Application Load Balancer או אל classic Application Load Balancer ואל ה-backends.
באיור הבא, ספק הצד השלישי מזוהה לפי טווח ה-CIDR 192.0.2.0/24, והטווח הזה נמצא ברשימת ההיתרים.
חסימת הגישה של משתמשים בכתובות IP ספציפיות באמצעות רשימות ישויות שנחסמו
אפשר להשתמש ברשימות חסימה כדי לדחות תנועה מכתובות IP ספציפיות או מטווחים של CIDR.
באיור הבא, למדיניות האבטחה של Cloud Armor יש deny כלל שחוסם תעבורה מכתובת ה-IP 198.51.100.1, שבה זוהה משתמש זדוני.
כללים מותאמים אישית לסינון על סמך פרמטרים בשכבות 3 עד 7
מגדירים ביטויים בתנאי ההתאמה של כלל באמצעות שפת הכללים המותאמים אישית של Cloud Armor. Cloud Armor מעריך בקשות נכנסות בהשוואה לביטויים האלה. אם הבקשה תואמת, הפעולה של הכלל חלה, והתנועה נדחית או מאושרת.
הדוגמאות הבאות הן ביטויים שנכתבו בתוסף Cloud Armor של Common Expression Language (CEL). מידע נוסף זמין במאמר בנושא הפניה לשפה של כללים מותאמים אישית.
אפשר להגדיר ביטויים באמצעות הדגל --expression של Google Cloud CLI או באמצעותCloud de Confiance המסוף. מידע נוסף מופיע במאמר בנושא יצירה של מדיניות, כללים וביטויים לאבטחה.
בדוגמה הבאה, בקשות מ-2001:db8::/32 (כמו בודקי האלפא שלכם) באזור AU תואמות לביטוי הבא:
origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')
הדוגמה הבאה מתאימה לבקשות מ-192.0.2.0/24 ולסוכן משתמש שמכיל את המחרוזת WordPress:
inIpRange(origin.ip, '192.0.2.0/24') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')
דוגמאות נוספות מופיעות בדוגמאות לביטויים במאמר בנושא שפת ההפניה של כללים מותאמים אישית.
הגנה על הפריסה מפני מתקפות בשכבת האפליקציה וצמצום הסיכונים של עשרת סיכוני האבטחה המובילים של OWASP
Cloud Armor עוזר להגן על שרתי המקור של Cloud CDN מפני מתקפות בשכבת האפליקציה (L7), כמו הזרקת SQL (SQLi) ופרצות אבטחה XSS (cross-site scripting). תוכן במטמון הוא סטטי ובדרך כלל לא מהווה סיכון להתקפה ממוקדת. עם זאת, שרת המקור עשוי להיות אפליקציה דינמית עם נקודות חולשה. יכול להיות שדרישות האבטחה שלכם יחייבו אתכם לצמצם את הסיכונים האלה כדי למנוע ניצול לרעה של שרת המקור.
כדי לצמצם את הסיכונים, צריך לבצע את הפעולות הבאות:
- יוצרים או מאתרים שירות קצה עורפי עם CDN מופעל.
- יוצרים כללי מדיניות אבטחה של Cloud Armor.
- יוצרים כלל אחד או יותר במדיניות האבטחה כדי לדחות מתקפות ברמה 7.
- מגדירים את אחד היעדים של מדיניות האבטחה להיות שירות ה-Backend שיצרתם או שזיהיתם בשלב 1.
אפשר להשתמש בכללים שהוגדרו מראש כדי לזהות ולחסום מתקפות נפוצות בשכבת האפליקציה.
כללים שהוגדרו מראש הם קבוצות של ביטויים שהוגדרו מראש שאפשר להוסיף למדיניות אבטחה. כדי להוסיף את קבוצות הביטויים האלה לכלל, משתמשים בדגל --expression של ה-CLI של gcloud או במסוף Cloud de Confiance .
מידע נוסף מופיע במאמר בנושא יצירה של מדיניות, כללים וביטויים לאבטחה.
כלל שהוגדר מראש בודק כברירת מחדל עד 8 kB הראשונים של גוף הבקשה. עם זאת, אפשר להגדיר את המגבלה הזו לכל מדיניות. מידע נוסף על הגדרת מגבלת הבדיקה הזו לגבי גוף הבקשה כשמשתמשים בכללי WAF שהוגדרו מראש זמין במאמר מגבלת בדיקה של גוף הבקשה.
מידע נוסף על כללים שהוגדרו מראש זמין במאמר כללים שהוגדרו מראש במאמר בנושא שפה של כללים בהתאמה אישית.
בדוגמה הבאה נעשה שימוש בכלל שהוגדר מראש כדי לצמצם את הסיכון לתקיפות של פרצת אבטחה XSS (cross-site scripting):
evaluatePreconfiguredWaf('xss-v422-stable')
בדוגמה הבאה נעשה שימוש בכלל שהוגדר מראש כדי לצמצם את הסיכון להתקפות הזרקת SQL (SQLi):
evaluatePreconfiguredWaf('sqli-v422-stable')
אפשר גם לשלב כללים שהוגדרו מראש עם ביטויים אחרים. בדוגמה הבאה נעשה שימוש בכלל שהוגדר מראש כדי לצמצם את הסיכון לתקיפות SQLi מטווח כתובות ה-IP 192.0.2.1/24:
inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredWaf('sqli-v422-stable')
הפחתת הסיכון של 10 נקודות החולשה המובילות של OWASP בעומסי עבודה היברידיים
Cloud Armor מציע אמצעים לצמצום ההשפעה של ההתקפות הבאות, בין אם הן מתרחשות ב- Cloud de Confiance, בפריסה מקומית או אצל ספק צד שלישי:
- הזרקת SQL (SQLi)
- פרצת אבטחה XSS (cross-site scripting)
- הכללת קבצים מקומיים (LFI)
- הכללת קבצים מרחוק (RFI)
- הרצת קוד מרחוק (RCE)
אתם יכולים להשתמש ביכולות האלה כדי לטפל בכמה מהסיכונים הנפוצים ביותר לאבטחת אפליקציות אינטרנט, כולל הסיכונים שמפורטים ברשימת OWASP Top 10.
אפשר להוסיף את כללי ה-WAF שהוגדרו מראש ב-Cloud Armor למדיניות אבטחה כדי לזהות ולדחות בקשות בשכבה 7 שמכילות ניסיונות של SQLi או XSS. Cloud Armor מזהה בקשות זדוניות ומוחק אותן בקצה התשתית של Google. הבקשות לא מועברות דרך פרוקסי לשירות הקצה העורפי, לא משנה איפה שירות הקצה העורפי פרוס.
כדי להגן על עומס עבודה שלא מתארח ב-Cloud de Confianceמפני התקפות כאלה בקצה של הרשת של Google, פועלים לפי השלבים הבאים:
- מגדירים מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסים של אפליקציות (ALB) בגרסה הקלאסית עם שירות קצה עורפי שיש לו קצה עורפי של NEG באינטרנט.
- יוצרים כללי מדיניות אבטחה של Cloud Armor.
- מוסיפים למדיניות כללי SQLi ו-XSS שהוגדרו מראש.
- מצרפים את מדיניות האבטחה לשירות הקצה העורפי שיצרתם בשלב 1.
- מעקב אחרי הפעילות ב-Cloud Armor באמצעות Cloud Logging, Cloud Monitoring והממצאים שנשלחים אל Security Command Center.
בקרות גישה בשכבה 7 והתקפות של ביטול מטמון
בהתאם לארכיטקטורת האפליקציה, אפשר להגדיר שירות עורפי אחד שיטפל בבקשות לכתובות URL שונות, כולל תוכן שאפשר לשמור במטמון ותוכן שלא ניתן לשמור במטמון. בתרחישי פריסה כאלה, צריך ליצור מדיניות אבטחה של Cloud Armor שדוחה תעבורה לא רצויה בנתיבי בקשות מסוימים, אבל מאפשרת לכל הלקוחות לגשת לתוכן סטטי בנתיב בקשה אחר.
במצבים אחרים, גם אם התוכן מוגש מהמטמון, לקוח זדוני עשוי ליצור הרבה בקשות שגורמות לאי מציאה במטמון. אי מציאה במטמון מחייבת את שרת המקור לאחזר או ליצור את התוכן, מה שעלול להעמיס על המשאבים ולהשפיע על הזמינות. יוצרים מדיניות אבטחה שתתאים לחתימות של לקוחות שגורמות לבעיה, ודוחים את הבקשות לפני שהן מגיעות לשרת המקור.
כדי לעשות זאת:
- יוצרים כללי מדיניות אבטחה של Cloud Armor.
מגדירים כלל. לדוגמה, הכלל הבא דוחה גישה אל
"/admin":request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')מצרפים את מדיניות האבטחה משלב 1 לשירות הקצה העורפי שבו מופעל Cloud CDN.
הגנה על מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי
אם יש לכם מינוי ל-Cloud Armor Enterprise, אתם יכולים להשתמש בהגנה מתקדמת מפני DDoS ברשת כדי להגן על מאזני עומסים חיצוניים של רשתות passthrough, על העברת פרוטוקולים ועל מכונות וירטואליות עם כתובות IP ציבוריות. התכונה הזו מספקת הפחתה מוטמעת וקבועה של מתקפות DDoS ברמה 3 וברמה 4.
מידע נוסף זמין במאמר סקירה כללית על הגנה מתקדמת מפני מתקפות DDoS ברשת.