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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בתרשים הבא, מדיניות האבטחה של Cloud Armor‏ internal-users-policy משויכת לשירות ה-Backend‏ 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. אלה כללים מורכבים של חומת אש לאפליקציות אינטרנט (WAF) עם עשרות חתימות שנאספו מתקנים בתעשייה של קוד פתוח. כל חתימה מתאימה לכלל לזיהוי מתקפות בערכת הכללים. Google מציעה את הכללים האלה כמו שהם. הכללים מאפשרים ל-Cloud Armor להעריך עשרות חתימות שונות של תנועה על ידי הפניה לכללים עם שמות נוחים, במקום לדרוש מכם להגדיר כל חתימה באופן ידני. מידע נוסף על כללי WAF שהוגדרו מראש זמין במאמר סקירה כללית של כללי WAF שהוגדרו מראש.

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

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

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

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

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

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

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

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

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

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

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

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

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

דוגמאות

בדוגמה הבאה, הכללים 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-v422-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-v422-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 כולל את כל המדינות בארצות הברית, מחוז אחד ו-6 אזורים מרוחקים.

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

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

כללים של רשימת היתרים ורשימת חסימה של כתובות 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 מעבד רק בקשות עם גוף.

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

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

‫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 לא פועל כמצופה.

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