סקירה כללית של מדיניות האבטחה

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

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

מדיניות האבטחה של Cloud Armor זמינה לסוגים הבאים של מאזני עומסים ונקודות קצה:

  • כל מאזני העומסים החיצוניים של אפליקציות (ALB), כולל מאזני עומסים קלאסיים של אפליקציות (ALB)
  • מאזן עומסים פנימי אזורי של אפליקציות (ALB)
  • מאזן עומסי רשת גלובלי חיצוני בשרת proxy‏ (TCP/SSL)
  • מאזן עומסי רשת קלאסי בשרת proxy‏ (TCP/SSL)
  • מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי (TCP/UDP)
  • העברת פרוטוקול חיצוני
  • מכונות וירטואליות עם כתובות IPv4 חיצוניות או טווחים של כתובות IPv6 חיצוניות שמוקצים לממשק רשת (NIC)

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

הקצה העורפי של שירות הקצה העורפי יכול להיות כל אחת מהאפשרויות הבאות:

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

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

הגנה על פריסות באמצעות כללי מדיניות האבטחה של Cloud Armor Google Cloud

איזון עומסים חיצוני מיושם בקצה הרשת של Google בנקודות הנוכחות (PoP) של Google ברחבי העולם. במסלול הפרימיום, תעבורת משתמשים שמנותבת אל מאזן עומסים חיצוני נכנסת לנקודת ה-PoP שהכי קרובה למשתמש. לאחר מכן, העומס מאוזן ברשת הגלובלית של Google, עד שהוא מגיע לקצה העורפי הקרוב ביותר שיש בו קיבולת מספקת. במסלול הרגיל, תעבורת נתונים של משתמשים נכנסת לרשת של Google דרך קישור בין רשתות שכנות (peering), ספק אינטרנט (ISP) או רשתות העברה באזור שבו פרסתם את משאבי Google Cloud.

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

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

מדיניות Cloud Armor בקצה הרשת.
מדיניות Cloud Armor בקצה הרשת (לחצו כדי להגדיל).

דרישות

אלה הדרישות לשימוש בכללי מדיניות האבטחה של Cloud Armor:

  • סכמת איזון העומסים של השירות לקצה העורפי חייבת להיות EXTERNAL,‏ EXTERNAL_MANAGED או INTERNAL_MANAGED.
  • הפרוטוקול של השירות העורפי חייב להיות אחד מהפרוטוקולים הבאים: HTTP,‏ HTTPS,‏ HTTP/2,‏ UDP,‏ TCP,‏ SSL או UNSPECIFIED.

מידע על מדיניות האבטחה של Cloud Armor

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

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

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

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

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

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

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

בתרשים הבא, מדיניות האבטחה של Cloud Armor‏ internal-users-policy משויכת לשירות הקצה העורפי test-network.

מדיניות אבטחה של Cloud Armor בקצה הרשת.
מדיניות האבטחה של Cloud Armor בקצה הרשת (לחצו כדי להגדיל).
כללי מדיניות האבטחה של Cloud Armor כוללים את התכונות הבאות:

  • אפשר להשתמש בפרוטוקול QUIC עם מאזני עומסים שמשתמשים ב-Cloud Armor.

  • אפשר להשתמש ב-Cloud Armor עם מאזני עומסים שנמצאים באחד ממסלולי שירות הרשת הבאים:

    • מסלול פרימיום
    • מסלול רגיל

  • אפשר להשתמש במדיניות אבטחה של בק-אנד עם GKE ובבקר ברירת המחדל של Ingress.

  • אתם יכולים להשתמש במדיניות אבטחה שמוגדרת כברירת מחדל ומגבילה את התנועה מעל סף שמוגדר על ידי המשתמש, כשאתם מגדירים אחד ממאזני העומסים הבאים:

    • מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
    • מאזן עומסים קלאסי של אפליקציות (ALB)
    • מאזן עומסים חיצוני אזורי של אפליקציות (ALB)
    • מאזן עומסים פנימי אזורי של אפליקציות (ALB)
    • מאזן עומסי רשת גלובלי חיצוני בשרת proxy‏ (TCP/SSL)
    • מאזן עומסי רשת קלאסי בשרת proxy‏ (TCP/SSL)

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

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

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

מדיניות אבטחה של קצה עורפי

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

  • מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
  • מאזן עומסים קלאסי של אפליקציות (ALB)
  • מאזן עומסים חיצוני אזורי של אפליקציות (ALB)
  • מאזן עומסים פנימי אזורי של אפליקציות (ALB)
  • מאזן עומסי רשת גלובלי חיצוני בשרת proxy
  • מאזן עומסי רשת קלאסי בשרת proxy

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

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

למדיניות אבטחה של קצה עורפי יש ערך אופציונלי של דגל type CLOUD_ARMOR. אם לא מגדירים את הדגל type, ערך ברירת המחדל הוא CLOUD_ARMOR.

מדיניות אבטחה של Edge

מדיניות האבטחה של Edge מאפשרת למשתמשים להגדיר מדיניות סינון ובקרת גישה לתוכן שמאוחסן במטמון, כולל נקודות קצה כמו שירותי קצה עורפיים שמופעל בהם Cloud CDN וקטגוריות של Cloud Storage. מדיניות האבטחה ב-Edge תומכת בסינון שמבוסס על קבוצת משנה של פרמטרים בהשוואה למדיניות האבטחה בשרת העורפי. אי אפשר להגדיר מדיניות אבטחה של קצה הרשת כמדיניות של קצה העורף. יש תמיכה במדיניות אבטחה של Edge בנקודות הקצה הבאות:

  • מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
  • מאזן עומסים קלאסי של אפליקציות (ALB)

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

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

מדיניות אבטחה של Edge נבדקת ונאכפת לפני שרת proxy לאימות זהויות (IAP). בקשה שנחסמת על ידי מדיניות אבטחה של שרת קצה נדחית לפני ש-IAP מעריך את הזהות של שולח הבקשה. חסימת בקשה באמצעות כלל במדיניות האבטחה של Edge מונעת מ-IAP להציג דף כניסה או לנסות לאמת את המשתמש בדרך אחרת.

לכללי מדיניות האבטחה של Edge יש ערך דגל type של CLOUD_ARMOR_EDGE.

מדיניות אבטחה של קצה הרשת

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

  • מאזני עומסי רשת חיצוניים להעברת סיגנל ללא שינוי
  • העברת פרוטוקולים
  • מכונות וירטואליות עם כתובות IP ציבוריות

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

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

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

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

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

סדר ההערכה של הכללים נקבע לפי העדיפות של הכלל, מהמספר הנמוך ביותר למספר הגבוה ביותר. לכלל עם הערך המספרי הנמוך ביותר שמוקצה לו יש את העדיפות הלוגית הגבוהה ביותר, והוא נבדק לפני כללים עם עדיפות לוגית נמוכה יותר. העדיפות המספרית המינימלית היא 0. העדיפות של כלל יורדת ככל שהמספר שלו עולה (1, ‏ 2, ‏ 3, ‏ N+1). אי אפשר להגדיר שני כללים או יותר עם אותה עדיפות. העדיפות של כל כלל צריכה להיות מספר בין 0 ל-2147483646, כולל. ערך העדיפות 2147483647, שנקרא גם INT-MAX, שמור לכלל ברירת המחדל.

יכול להיות שיהיו פערים במספרי העדיפות. הפערים האלה מאפשרים לכם להוסיף או להסיר כללים בעתיד בלי להשפיע על שאר הכללים. לדוגמה, 1, 2, 3, 4, 5, 9, 12, 16 היא סדרה תקינה של מספרי עדיפות שאפשר להוסיף לה בעתיד כללים עם המספרים 6 עד 8, 10 עד 11 ו-13 עד 15. לא צריך לשנות את הכללים הקיימים, רק את סדר הביצוע שלהם.

בדרך כלל, הכלל בעדיפות הכי גבוהה שתואם לבקשה יחול. עם זאת, יש חריג כשבקשות עם גוף מוערכות לפי כללים שהוגדרו מראש ומשתמשים ב-evaluatePreconfiguredWaf. החריגה היא:

בבקשות שמכילות גופים, Cloud Armor מקבל את הכותרת של הבקשה לפני הגוף (המטען הייעודי). מכיוון ש-Cloud Armor מקבל את פרטי הכותרת קודם, הוא מעריך כללים שתואמים לכותרת, אבל הוא לא מתאים לכללים שהוגדרו מראש בגוף. אם יש כמה כללים שמבוססים על כותרות, Cloud Armor מעריך אותם על סמך העדיפות שלהם, כצפוי. שימו לב שפעולות redirect והוספה של פעולות כותרת בהתאמה אישית פועלות רק במהלך שלב עיבוד הכותרת. פעולת redirect, אם היא תואמת במהלך שלב העיבוד הבא של הגוף, מתורגמת לפעולת deny. הפעולה של כותרת הבקשה המותאמת אישית, אם היא תואמת במהלך שלב העיבוד של גוף הבקשה, לא תיכנס לתוקף.

אחרי ש-Cloud Armor מקבל את גוף הבקשה, הוא מעריך את הכללים שחלים על כותרות הבקשה ועל גוף הבקשה. כתוצאה מכך, יכול להיות שכללים בעדיפות נמוכה יותר שמאפשרים את הכותרת של הבקשה יותאמו לפני כללים בעדיפות גבוהה יותר שחוסמים את גוף הבקשה. במקרים כאלה, יכול להיות שחלק הכותרת של בקשת ה-HTTP יישלח לשירות הבק-אנד של היעד, אבל גוף הבקשה שמכיל תוכן שעלול להיות זדוני ייחסם. ‫Cloud Armor בודק עד 64 KB הראשונים (בהתאם למגבלת הבדיקה שהוגדרה של 8 KB,‏ 16 KB,‏ 32 KB,‏ 48 KB או 64 KB) של גוף הבקשה. מידע נוסף על ההגבלה הזו זמין במאמר בנושא הגבלות על בדיקת גוף הבקשה.

הביטוי evaluatePreconfiguredWaf() עבור כללים שהוגדרו מראש הוא הביטוי היחיד שנבדק מול גוף הבקשה. כל הביטויים האחרים מוערכים רק ביחס לכותרת הבקשה. בדיקת הגוף מוגבלת למגבלת הבדיקה שהוגדרה, עד 64 KB הראשונים (8 KB, ‏ 16 KB,‏ 32 KB, ‏ 48 KB או 64 KB) של גוף הבקשה, והיא מפוענחת כמו פרמטרים של שאילתת כתובת URL. ‫Cloud Armor יכול לנתח ולהחיל כללים של WAF שהוגדרו מראש עבור גופים בפורמט JSON ‏(Content-Type = "application/json"). עם זאת, Cloud Armor לא תומך במפענחים אחרים שמבוססים על Content-Type או Content-Encoding של HTTP, כמו XML, ‏ Gzip או UTF-16.

דוגמאות

בדוגמה הבאה, הכללים 1, 2 ו-3 מוערכים בסדר הזה בשדות הכותרת IP ו-HTTP. עם זאת, אם כתובת ה-IP‏ 9.9.9.1 מפעילה מתקפת XSS בגוף הבקשה, רק הגוף נחסם (לפי כלל 2), והכותרת HTTPעוברת אל ה-Backend (לפי כלל 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredWaf('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

בדוגמה הבאה, המדיניות מאפשרת ל-IP 9.9.9.1 בלי לסרוק מפני מתקפות XSS:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredWaf('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

כלל ברירת המחדל

כל כללי מדיניות האבטחה של Cloud Armor מכילים כלל ברירת מחדל שמופעל אם אף אחד מהכללים בעדיפות גבוהה יותר לא מופעל, או אם אין כללים אחרים במדיניות. לכלל ברירת המחדל מוקצית אוטומטית עדיפות של 2147483647 (INT-MAX), והוא תמיד קיים במדיניות האבטחה.

אי אפשר למחוק את כלל ברירת המחדל, אבל אפשר לשנות אותו. פעולת ברירת המחדל של כלל ברירת המחדל היא deny, אבל אפשר לשנות את הפעולה לallow.

טביעת אצבע

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

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

שפת הכללים ומנוע האכיפה

מנוע האכיפה ושפת הכללים מספקים את האפשרויות הבאות:

  • היכולת לכתוב ביטויי כללים מותאמים אישית שיכולים להתאים למאפיינים שונים של בקשות נכנסות, משכבה 3 עד שכבה 7. ‫Cloud Armor מספק מאפיינים של שפה ליצירת כללים בהתאמה אישית לכתיבת תנאי התאמה בהתאמה אישית.

  • היכולת לשלב עד 5 ביטויי משנה בכלל אחד.

  • היכולת לדחות או לאשר בקשות על סמך קוד האזור של הבקשה הנכנסת. קודי האזורים מבוססים על קודי ISO 3166-1 alpha-2. לפעמים קודי האזור תואמים למדינות ספציפיות, אבל חלק מהם כוללים מדינה ואזורים שקשורים אליה. לדוגמה, הקוד US כולל את כל המדינות בארצות הברית, מחוז אחד ושישה אזורים מרוחקים.

סוגים של כללים

ב-Cloud Armor יש את סוגי הכללים הבאים.

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

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

  • הוספה של כתובת IP או טווח CIDR לרשימת כתובות חסומות מאפשרת לחסום גישה של כתובת IP של לקוח או טווח CIDR למאזני עומסים נתמכים.

  • הוספה של כתובת IP או טווח CIDR לרשימת ההיתרים מאפשרת לכתובת IP של לקוח או לטווח CIDR לגשת למאזני עומסים נתמכים.

  • יש תמיכה בכתובות IPv4 ו-IPv6 בכללים של רשימת ההיתרים ורשימת החסימה.

  • כללי דחייה יכולים להחזיר קוד סטטוס HTTP‏ 403 Unauthorized, 404 Access Denied או 502 Bad Gateway.

  • כללים של חריגה ממכסה יכולים להחזיר קוד סטטוס HTTP 429 Too Many Requests.

כללים גיאוגרפיים של לקוחות

אתם יכולים לאשר או לדחות בקשות שמקורן באזורים גיאוגרפיים נבחרים שמוגדרים לפי קוד המדינה של Unicode.

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

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

כללי WAF שהוגדרו מראש

‫Cloud Armor מספק רשימה מקיפה של כללי WAF מוגדרים מראש שמבוססים על OWASP Core Rule Set (CRS) כדי לעזור לכם לזהות את הדברים הבאים:

  • מתקפות של הזרקת SQL
  • תקיפות מסוג XSS‏ (cross-site scripting)
  • מתקפות של הכללת קבצים מקומיים
  • תקיפות של הכללת קבצים מרחוק
  • מתקפות של הרצת קוד מרחוק
  • תקיפות של אכיפת שיטות
  • התקפות של זיהוי סורקים
  • תקיפות פרוטוקולים
  • מתקפות החדרת קוד PHP
  • התקפות של קיבוע סשן
  • מתקפות Java
  • התקפות NodeJS

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

כללים לניהול בוטים

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

  1. הפניה אוטומטית של בקשות לבדיקת reCAPTCHA עם אתגרים ידניים אופציונליים.
  2. הערכת טוקנים של reCAPTCHA שמצורפים לבקשה והחלת הפעולה שהוגדרה על סמך מאפייני הטוקן.
  3. הפניית בקשות לכתובת ה-URL החלופית שהגדרתם עם קוד סטטוס 302.
  4. הוספת כותרות מותאמות אישית לבקשות לפני העברתן לשרתי הקצה העורפיים.

מידע נוסף על ניהול בוטים זמין במאמר סקירה כללית על ניהול בוטים.

כללים שהוגדרו מראש לרשימות של כתובות IP עם שמות

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

  • שילוב של רשימות של כתובות IP עם שמות מספקים של צד שלישי עם Cloud Armor.

  • לפשט את התחזוקה של טווחי כתובות IP מותרים או אסורים.

  • סנכרון יומי של רשימות מספקי צד שלישי.

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

כללים להגבלת קצב של יצירת בקשות

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

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

כשמשתמשים בהגבלת קצב של יצירת בקשות עם מאזני עומסים גלובליים חיצוניים בשרת proxy או עם מאזני עומסי רשת בשרת proxy בגרסה הקלאסית, חלות ההגבלות הבאות:

  • ‫Cloud Armor אוכף רק פעולות של הגבלת קצב של יצירת בקשות, כמו ויסות או חסימה, על בקשות חיבור חדשות מלקוחות.
  • יש תמיכה רק בסוגי המפתחות ALL ו-IP.
  • אם תנסו להשתמש בסוג המפתח HTTP-HEADER או HTTP-COOKIE עם מאזני עומסים של TCP/SSL, סוג המפתח יפורש כ-ALL, וכך גם XFF-IP יפורש כ-IP.

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

מצב תצוגה מקדימה

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

אפשר להפעיל מצב תצוגה מקדימה לכלל באמצעות Google Cloud CLI והדגל --preview של הפקודה gcloud compute security-policies rules update.

כדי להשבית את מצב התצוגה המקדימה, משתמשים בדגל --no-preview. אפשר גם להשתמש במסוףGoogle Cloud .

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

תשובות שגיאה מותאמות אישית

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

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

רישום ביומן

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

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

רישום ביומן של בקשות במאזן עומסים חיצוני של אפליקציות (ALB)

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

מידע נוסף זמין במאמר בנושא רישום ביומן ומעקב אחרי מאזן עומסים של אפליקציות (ALB) חיצוני.

רישום ביומן של בקשות במאזן עומסי רשת חיצוני בשרת proxy

אפשר להגדיר רישום ביומן למאזני עומסי רשת חיצוניים לשרת proxy באמצעות פקודות Google Cloud CLI שמופיעות במאמר רישום ביומן ומעקב אחר מאזני עומסים של שרת proxy ל-TCP/SSL. אי אפשר להפעיל רישום ביומן למאזני עומסים חיצוניים של רשתות proxy באמצעות מסוף Google Cloud .

מגבלות

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

מגבלה על בדיקת גוף הבקשה

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

הבדיקה מוגבלת למגבלת הבדיקה שהוגדרה, עד ל-64 KB הראשונים (8 KB,‏ 16 KB,‏ 32 KB,‏ 48 KB או 64 KB) של גוף הבקשה. מידע נוסף על הגדרת מגבלת הבדיקה של גוף הבקשה כשמשתמשים בכללי WAF שהוגדרו מראש זמין במאמר עדכון מגבלת הבדיקה של כללי WAF שהוגדרו מראש.

יכול להיות ששאר גוף הבקשה יכיל נתוני payload שתואמים לחתימה של כלל WAF, והאפליקציה שלכם תקבל אותם. כדי לצמצם את הסיכון שגודל גוף הבקשה יחרוג ממגבלת הבדיקה שהוגדרה, עד 64 KB הראשונים (8 KB,‏ 16 KB,‏ 32 KB,‏ 48 KB או 64 KB), אפשר לעיין במאמר צמצום הסיכון שגוף הבקשה יחרוג ממגבלת הבדיקה שהוגדרה.

‫Cloud Armor יכול לנתח ולהחיל כללי WAF שהוגדרו מראש על גופי בקשות בפורמט JSON ועל גופי בקשות שמוצפנים בפורמט URL (Content-Type = "application/json"). במקרה כזה, הכללים מוחלים באופן עצמאי על השמות והערכים שפוענחו בנתונים. במקרה של סוגי תוכן וסוגי קידוד אחרים, Cloud Armor לא מפענח את הנתונים, אלא מחיל את הכללים שהוגדרו מראש על נתונים גולמיים.

איך מתבצע טיפול בחיבורי WebSocket

מאזני עומסים גלובליים חיצוניים של אפליקציות כוללים תמיכה מובנית בפרוטוקול WebSocket. ערוצי WebSocket מופעלים מבקשות HTTP(S). ‫Cloud Armor יכול לחסום הקמה של ערוץ WebSocket, למשל אם רשימת כתובות IP שנדחו חוסמת את כתובת ה-IP של הלקוח. עם זאת, טרנזקציות עוקבות בערוץ לא תואמות לפרוטוקול HTTP, ו-Cloud Armor לא מבצע הערכה של הודעות אחרי הבקשה הראשונה.

איך מתבצע טיפול בחיבורי gRPC

מאזני עומסים גלובליים חיצוניים של אפליקציות תומכים בפרוטוקול gRPC. ‏gRPC הוא פריימוורק בקוד פתוח שמשתמש ב-HTTP/2 כפרוטוקול הבסיסי שלו. קריאות gRPC מופעלות מבקשות HTTP(S) POST. אתם יכולים להגדיר את Cloud Armor לחסימת קריאות gRPC, למשל באמצעות רשימת כתובות IP חסומות שחוסמת את כתובת ה-IP של הלקוח. עם זאת, יכול להיות שתראו שמאזן העומסים עדיין מדווח על תגובות עם קוד סטטוס של HTTP‏ 200 OK ביומנים ובמדדים שלו. זה לא אומר ש-Cloud Armor לא פועל כמצופה.

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