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

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

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

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

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

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

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

‫

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

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

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

דרישות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בדרך כלל, המערכת מחילה את הכלל בעל העדיפות הכי גבוהה שתואם לבקשה. עם זאת, יש יוצא מן הכלל לגבי בקשות עם גוף כשמעריכים כללים מוגדרים מראש של WAF ‏ (evaluatePreconfiguredWaf) או כללים בהתאמה אישית שמפנים אל request.body או אל request.params. החריגה היא:

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

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

רק כללי WAF שהוגדרו מראש (evaluatePreconfiguredWaf()) וכללים מותאמים אישית שמפנים אל request.body או אל request.params נבדקים מול גוף הבקשה. כל הביטויים האחרים נבדקים רק מול כותרת הבקשה. הבדיקה של גוף הבקשה מוגבלת למגבלת הבדיקה שהוגדרה לגוף הבקשה. כברירת מחדל, הגוף מפוענח כמו פרמטרים של שאילתות בכתובות URL. ‫Cloud Armor תומך גם בניתוח של גופי בקשות בפורמט JSON ‏ (Content-Type = "application/json"). עם זאת, Cloud Armor לא תומך במפענחים אחרים של HTTP Content-Type/Content-Encoding, כמו 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 שנחסמו במסגרת מדיניות אבטחה. דוגמאות:

  • הוספה של כתובת IP או טווח