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

בדף הזה מפורטים תרחישים לדוגמה נפוצים לשימוש בכללי מדיניות האבטחה של Google Cloud Armor. מדיניות האבטחה של Cloud Armor יכולה להגן על האפליקציה באמצעות תכונות כמו רשימות של כתובות IP מותרות ורשימות של כתובות IP שנחסמו, וכללים שהוגדרו מראש כדי להרתיע מפני התקפות נפוצות באינטרנט.

שליטה בגישה לשירותים ולאפליקציות אינטרנט

בקטע הזה מוצגות כמה דרכים להשתמש במדיניות האבטחה של Cloud Armor כדי לשלוט בגישה לאפליקציות או לשירותים שלכם.

איך מאשרים גישה למשתמשים בכתובות IP ספציפיות באמצעות רשימות היתרים

תרחיש שימוש נפוץ להוספת כתובות IP של משתמשים לרשימת היתרים הוא כשגישה למאזן עומסים חיצוני גלובלי של אפליקציות (ALB) או למאזן עומסים קלאסי של אפליקציות מתאפשרת רק לקבוצה מסוימת של משתמשים. בדוגמה הבאה, רק למשתמשים מהארגון שלכם מותרת גישה לשירותים שמאחורי מאזן העומסים. למשתמשים האלה מוקצות כתובות IP או בלוקים של כתובות שמוקצים על ידי הארגון שלכם. אפשר להוסיף את כתובות ה-IP או טווחי ה-CIDR האלה לרשימת ההיתרים, כך שרק למשתמשים האלה תהיה גישה למאזן העומסים.

הגבלת הגישה למאזן העומסים באמצעות רשימת היתרים.
הגבלת הגישה למאזן העומסים באמצעות רשימת היתרים (לחצו כדי להגדיל).

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

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

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

  1. יוצרים כללי מדיניות אבטחה של Cloud Armor.
  2. במדיניות האבטחה, מוסיפים כלל שמוסיף את הטווח לרשימת ההיתרים ככלל הראשון. התיאור של הכלל הזה הוא allow [RANGE], כאשר [RANGE] הוא טווח כתובות ה-IP הרצוי.
  3. משנים את כלל ברירת המחדל במדיניות מכלל הרשאה לכלל דחייה. כלל ברירת המחדל חל על תנועה שלא תואמת לאף אחד מהכללים הקודמים. זהו הכלל האחרון במדיניות. שינוי הכלל מ-allow ל-deny חוסם את כל התנועה שלא מגיעה מהטווח שברשימת ההיתרים.
  4. משייכים את המדיניות הזו למאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או לשירות לקצה העורפי של מאזן עומסים קלאסי של אפליקציות.

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

באיור הבא, ספק הצד השלישי מזוהה לפי טווח ה-CIDR‏ 192.0.2.0/24, והטווח הזה נמצא ברשימת ההיתרים.

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

חסימת הגישה למשתמשים בכתובות IP ספציפיות באמצעות רשימות חסימה

אפשר להשתמש ברשימות חסימה כדי ליצור מדיניות אבטחה של Cloud Armor שדוחה תנועה מכתובת IP או מטווח CIDR. באיור הבא, למדיניות האבטחה של Cloud Armor יש כלל deny שחוסם תנועה מכתובת ה-IP‏ 198.51.100.1, שבה זוהה משתמש זדוני.

הגבלת הגישה למאזן העומסים באמצעות רשימת חסימה.
הגבלת הגישה למאזן העומסים באמצעות רשימת כתובות חסומות (לחצו כדי להגדיל).

כללים מותאמים אישית לסינון על סמך פרמטרים בשכבות 3 עד 7

משתמשים בשפה של כללים מותאמים אישית ב-Cloud Armor כדי להגדיר ביטוי אחד או יותר בתנאי ההתאמה של כלל. כש-Cloud Armor מקבל בקשה, הוא בודק את הבקשה מול הביטויים האלה. אם יש התאמה, הפעולה של הכלל נכנסת לתוקף, והתנועה הנכנסת נדחית או מאושרת.

הדוגמאות הבאות הן ביטויים שנכתבו בתוסף Cloud Armor של Common Expression Language ‏(CEL). מידע נוסף זמין במאמר בנושא הפניה לשפה של כללים בהתאמה אישית.

כדי להגדיר ביטויים בכלל, משתמשים בדגל --expression של gcloud או במסוףGoogle Cloud . מידע נוסף זמין במאמר בנושא יצירה של כללי מדיניות, כללים וביטויים לאבטחה ב-Cloud Armor.

בדוגמה הבאה, בקשות מ-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). תוכן במטמון הוא סטטי, וכנראה שלא מהווה סיכון להתקפה ממוקדת מהאינטרנט. עם זאת, שרת המקור של התוכן הבסיסי עשוי להיות אפליקציה דינמית עם נקודות חולשה ידועות או פוטנציאליות באפליקציית האינטרנט. יכול להיות שדרישות האבטחה או התאימות שלכם מחייבות אתכם לצמצם את הסיכונים האלה כדי למנוע ניצול של נקודות חולשה באינטרנט לצורך תקיפה מוצלחת של שרת המקור.

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

  1. יוצרים או מאתרים שירות קצה עורפי עם CDN מופעל.
  2. יוצרים כללי מדיניות אבטחה של Cloud Armor.
  3. יוצרים כלל אחד או יותר במדיניות האבטחה כדי לדחות מתקפות ברמה 7.
  4. מגדירים את אחד היעדים של מדיניות האבטחה להיות שירות ה-Backend שיצרתם או שזיהיתם בשלב 1.

אפשר גם להשתמש בכללים שהוגדרו מראש כדי לזהות ולחסום מתקפות נפוצות בשכבת האפליקציה. כללים שהוגדרו מראש הם קבוצות של ביטויים שהוגדרו מראש שאפשר להוסיף לכללי מדיניות האבטחה של Cloud Armor. כדי להוסיף את קבוצות הביטויים האלה לכלל, משתמשים בדגל --expression של gcloud או במסוף Google Cloud . מידע נוסף זמין במאמר בנושא יצירה של מדיניות, כללים וביטויים לאבטחה.

כלל שהוגדר מראש בודק כברירת מחדל עד 8 kB הראשונים של גוף הבקשה. עם זאת, אפשר להגדיר את המגבלה הזו לכל מדיניות. מידע נוסף על הגדרת מגבלת הבדיקה הזו לגבי גוף הבקשה כשמשתמשים בכללי WAF שהוגדרו מראש זמין במאמר מגבלת הבדיקה של גוף הבקשה.

מידע נוסף על כללים שהוגדרו מראש זמין במאמר כללים שהוגדרו מראש במאמר בנושא שפה של כללים בהתאמה אישית.

בדוגמה הבאה נעשה שימוש בכלל שהוגדר מראש כדי לצמצם את הסיכון לתקיפות של פרצת אבטחה XSS‏ (cross-site scripting):

evaluatePreconfiguredWaf('xss-stable')

בדוגמה הבאה נעשה שימוש בכלל שהוגדר מראש כדי לצמצם את הסיכון להתקפות הזרקת SQL ‏(SQLi):

evaluatePreconfiguredWaf('sqli-stable')

אפשר גם לשלב כללים שהוגדרו מראש עם ביטויים אחרים. בדוגמה הבאה נעשה שימוש בכלל שהוגדר מראש כדי לצמצם את הסיכון לתקיפות SQLi מטווח כתובות ה-IP‏ 192.0.2.1/24:

inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredWaf('sqli-stable')

הפחתת הסיכון של 10 נקודות החולשה המובילות של OWASP בעומסי עבודה היברידיים

‫Cloud Armor מציע אמצעים לצמצום ההשפעה של המתקפות הבאות, בין אם הן מתרחשות ב- Google Cloud, בפריסה מקומית או אצל ספק צד שלישי:

  • הזרקת SQL‏ (SQLi)
  • פרצת אבטחה XSS‏ (cross-site scripting)
  • הכללת קבצים מקומיים (LFI)
  • הכללת קבצים מרחוק (RFI)
  • הרצת קוד מרחוק (RCE)

אתם יכולים להשתמש ביכולות האלה כדי לטפל בכמה מסיכוני האבטחה הנפוצים ביותר באפליקציות אינטרנט, כולל הסיכונים שמפורטים ברשימת OWASP Top 10.

אפשר להוסיף כללי WAF שהוגדרו מראש ב-Cloud Armor למדיניות אבטחה כדי לזהות ולדחות בקשות לא רצויות בשכבה 7 שמכילות ניסיונות של SQLi או XSS. ‫Cloud Armor מזהה בקשות זדוניות ומסיר אותן בקצה התשתית של Google. הבקשות לא מועברות דרך פרוקסי לשירות לקצה העורפי, לא משנה איפה השירות לקצה העורפי פרוס.

כדי להגן על עומס עבודה שלא מתארח ב-Google Cloudמפני ההתקפות האלה בקצה של הרשת של Google, פועלים לפי השלבים הבאים:

  1. מגדירים מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסים של אפליקציות (ALB) בגרסה הקלאסית עם שירות קצה עורפי שיש לו קצה עורפי של NEG באינטרנט.
  2. יוצרים כללי מדיניות אבטחה של Cloud Armor.
  3. מוסיפים למדיניות כללים שהוגדרו מראש ל-SQLi ול-XSS.
  4. מצרפים את מדיניות האבטחה לשירות הקצה העורפי שיצרתם בשלב 1.
  5. מעקב אחרי הפעילות ב-Cloud Armor באמצעות Cloud Logging,‏ Cloud Monitoring והממצאים שנשלחים אל Security Command Center.

הגנה מפני DDoS בשרת מקור חיצוני של Cloud CDN ומעקב בשכבה 7

פריסות של Cloud CDN עם שרת מקור חיצוני יכולות להשתמש בתשתית הקצה של Google כחלק הקדמי של הפרוקסי, של השמירה במטמון ושל הסינון בשכבה 7 של Cloud Armor. כשמשתמשים ב-NEGs של האינטרנט, שרת המקור יכול להיות מקומי או אצל ספק תשתית צד שלישי.

‫Cloud Armor ושאר התשתית של Google בקצה הרשת מצמצמים את ההשפעה של מתקפות L3/L4 ומבטלים אותן, שולחים התראות על פעילות חשודה בשכבה 7 ומוכנים לדחות בקשות לא רצויות בשכבה 7 באמצעות כללים מותאמים אישית. רישום ביומן וטלמטריה של Cloud Armor ב-Cloud Logging, ב-Cloud Monitoring וב-Security Command Center מספקים תובנה פרקטית לגבי אפליקציות מוגנות, לא משנה איפה הן נפרסות.

כדי להפעיל את ההגנה של Cloud Armor על שרתי מקור חיצוניים של CDN, פועלים לפי השלבים הבאים:

  1. מגדירים מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסים של אפליקציות (ALB) בגרסה הקלאסית עם שירות קצה עורפי שיש לו קצה עורפי של NEG באינטרנט.
  2. מפעילים את Cloud CDN לשירות לקצה העורפי הזה.
  3. יוצרים כללי מדיניות אבטחה של Cloud Armor.
  4. מצרפים את מדיניות האבטחה לשירות הקצה העורפי שיצרתם בשלב 1.
  5. גישה להתראות, לרישום ביומן ולטלמטריה של Cloud Armor ב-Security Command Center, ב-Cloud Logging וב-Cloud Monitoring.

בנוסף, אפשר להשתמש במדיניות אבטחה של קצה הרשת כדי להגן על תוכן שמאוחסן במטמון. מידע נוסף על מדיניות אבטחה של Edge זמין במאמר סקירה כללית על מדיניות אבטחה.

בקרות גישה בשכבה 7 והתקפות שמטרתן לעקוף את הזיכרון מטמון

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

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

כדי לעשות זאת:

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

  2. מגדירים כלל. לדוגמה, הכלל הבא דוחה גישה אל "/admin":

    request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')

  3. מצרפים את מדיניות האבטחה משלב 1 לשירות הקצה העורפי שבו מופעל Cloud CDN.

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