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

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

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

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

• קבוצות של מכונות
• כל הסוגים של קבוצות של נקודות קצה ברשת (NEG) שמאוזן העומסים תומך בהם

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

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

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

דרישות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשמשתמשים בהגבלת קצב של יצירת בקשות עם מאזני עומסים גלובליים חיצוניים בשרת 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. אפשר גם להשתמש במסוףCloud de Confiance .

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

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

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

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

רישום ביומן

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

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

מגבלות

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

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

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

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

• הגדרת מדיניות אבטחה ב-Cloud Armor
• פתרון בעיות ב-Cloud Armor