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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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