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

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

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

• למנוע מלקוח מסוים למצות את משאבי האפליקציה.
• הגנה על מופעים של האפליקציה מפני עליות חדות ובלתי צפויות בקצב הבקשות של הלקוחות.

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

ב-Cloud Armor יש שני סוגים של כללים שמבוססים על קצב:

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

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

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

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

זיהוי לקוחות להגבלת קצב

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

• ‫ALL: מפתח יחיד לכל הבקשות שעומדות בתנאי ההתאמה של הכלל.
• ‫IP: מפתח ייחודי לכל כתובת IP של לקוח שהבקשות שלה עומדות בתנאי ההתאמה של הכלל.
• ‫HTTP_HEADER: מפתח ייחודי לכל ערך ייחודי של כותרת HTTP שהשם שלה מוגדר. ערך המפתח נחתך ל-128 הבייטים הראשונים של ערך הכותרת. סוג המפתח מוגדר כברירת מחדל ל-ALL אם הכותרת הזו לא קיימת, או אם מנסים להשתמש בסוג המפתח הזה עם מאזן עומסי רשת בשרת proxy חיצוני.
• ‫XFF_IP: מפתח ייחודי לכל כתובת IP מקורית של לקוח, כלומר כתובת ה-IP הראשונה ברשימת כתובות ה-IP שצוינו בכותרת ה-HTTP‏ X-Forwarded-For. סוג המפתח מוגדר כברירת מחדל לכתובת IP אם הכותרת הזו לא קיימת, אם הערך הוא לא כתובת IP תקינה או אם מנסים להשתמש בסוג המפתח הזה עם מאזן עומסי רשת חיצוני לשרת proxy.
• ‫HTTP_COOKIE: מפתח ייחודי לכל ערך של קובץ Cookie‏ HTTP שהשם שלו מוגדר. ערך המפתח נחתך ל-128 הבייטים הראשונים של ערך קובץ ה-Cookie. סוג המפתח מוגדר כברירת מחדל ל-ALL אם קובץ ה-cookie הזה לא קיים, או אם מנסים להשתמש בסוג המפתח הזה עם מאזן עומסי רשת חיצוני של proxy.
• ‫HTTP_PATH: נתיב כתובת ה-URL של בקשת ה-HTTP. ערך המפתח נחתך ל-128 הבייטים הראשונים.
• ‫SNI: אינדיקציה של שם השרת בסשן TLS של בקשת ה-HTTPS. ערך המפתח נחתך ל-128 הבייטים הראשונים. סוג המפתח הוא ALL כברירת מחדל בסשן HTTP.
• ‫REGION_CODE: המדינה או האזור שממנו מגיעה הבקשה.
• ‫TLS_JA4_FINGERPRINT: טביעת אצבע של JA4 TLS/SSL אם הלקוח מתחבר באמצעות HTTPS, HTTP/2 או HTTP/3. אם לא מצוין סוג מפתח, ברירת המחדל היא ALL. מידע נוסף על JA4 זמין במאמר הפניה לשפת הכללים.
• ‫TLS_JA3_FINGERPRINT: טביעת אצבע של JA3 TLS/SSL אם הלקוח מתחבר באמצעות HTTPS, HTTP/2 או HTTP/3. אם לא מצוין סוג מפתח, ברירת המחדל היא ALL.
• ‫USER_IP: כתובת ה-IP של הלקוח המקורי, שכלולה בכותרות שהוגדרו בקטע userIpRequestHeaders והערך שלה מאוכלס על ידי שרת proxy במעלה הזרם. אם אין הגדרה של userIpRequestHeaders, או שלא ניתן לפתור כתובת IP ממנה, סוג המפתח מוגדר כברירת מחדל כ-IP. מידע נוסף זמין בהפניה לשפת הכללים.

אפשר להשתמש בכל אחד מהמפתחות שלמעלה בנפרד, או להגביל את קצב הבקשות על סמך שילוב של עד שלושה מפתחות. אפשר להשתמש בכמה מקשי HTTP-HEADER או HTTP-COOKIE, ורק במקש אחד מכל סוג אחר. מידע נוסף מופיע במאמר בנושא הגבלת קצב על סמך כמה מפתחות.

בחירה בין כללי חסימה מבוססי-קצב לבין כללי הגבלת קצב

ההבדל בין כללי הגבלת קצב ב-Cloud Armor rate-based ban לבין כללי הגבלת קצב ב-throttle הוא באופן הטיפול בתעבורה שחורגת מהסף שהוגדר.

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

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

ויסות תנועת הנתונים

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

לדוגמה, אפשר להגדיר את סף הבקשות ל-2,000 בקשות תוך 1,200 שניות (20 דקות). אם לקוח שולח 2,500 בקשות בפרק זמן של 1,200 שניות, כ-20% מהתעבורה של הלקוח מווסתת עד שנפח הבקשות המותר מגיע לסף שהוגדר או מתחתיו.

אם קצב התנועה של לקוח נמוך מ-rate_limit_threshold_count או שווה לו, הבקשות פועלות לפי conform_action, שתמיד מוגדר כפעולת allow. הבקשה מותרת על ידי מדיניות האבטחה ויכולה להגיע ליעד שלה. אם קצב התנועה של לקוח חורג מהערך שצוין בrate_limit_threshold_count, Cloud Armor מחיל את exceed_action, שיכול להיות deny או redirect, על בקשות שחורגות מהמגבלה למשך יתרת הזמן של מרווח הסף.

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

• ‫rate_limit_threshold_count: מספר הבקשות לכל לקוח שמותר לשלוח בפרק זמן מסוים. הערך המינימלי הוא 1 והערך המקסימלי הוא 1,000,000.
  • ‫interval_sec: מספר השניות במרווח הזמן. הערך צריך להיות 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 או 3600 שניות.
• ‫exceed_action: כשבקשה חורגת מהערך rate_limit_threshold_count,‏ Cloud Armor מחיל את הערך המוגדר exceed_action. ערכים אפשריים של exceed_action:
  • deny(status): הבקשה נדחית ומוחזר קוד הסטטוס שצוין. הערכים התקפים הם 403 Forbidden,‏ 404 Page Not Found,‏ 429 Too Many Requests ו-502 Bad Gateway. מומלץ להשתמש בקוד הסטטוס 429 Too Many Requests.
  • ‫redirect: הבקשה מופנית מחדש להערכה של reCAPTCHA או לכתובת URL אחרת, בהתאם לפרמטר exceed_redirect_options.
• ‫exceed_redirect_options: כשהערך של exceed_action הוא redirect, משתמשים בפרמטר הזה כדי לציין את פעולת ההפניה:
  • ‫type: סוג פעולת ההפניה לכתובת אחרת, GOOGLE_RECAPTCHA או EXTERNAL_302.
  • ‫target: כתובת ה-URL של היעד להפניה האוטומטית. רלוונטי רק אם type הוא EXTERNAL_302.
• ‫conform_action: הפעולה שמתבצעת כשמספר הבקשות נמוך מrate_limit_threshold_count. הפעולה הזו היא תמיד פעולת allow.

חסימת לקוחות על סמך שיעורי בקשות

הפעולה rate_based_ban בכלל מאפשרת לאכוף סף לכל לקוח כדי להשעות באופן זמני לקוחות שעברו את המגבלה. כדי לעשות זאת, המערכת מחילה את ההגדרה exceed_action על כל הבקשות מהלקוח למשך תקופה שניתנת להגדרה. הסף מוגדר כמספר מסוים של בקשות במרווח זמן מסוים. אתם יכולים לחסום זמנית תנועה למשך תקופת זמן שהוגדרה על ידי המשתמש ('ban_duration_sec'), בתנאי שהתנועה תואמת לתנאי ההתאמה שצוין ועוברת את הסף שהוגדר.

לדוגמה, אפשר להגדיר את סף הבקשות ל-2,000 בקשות תוך 1,200 שניות (20 דקות). אם לקוח שולח 2,500 בקשות תוך 1,200 שניות, Cloud Armor מחיל את exceed_action על התנועה מהלקוח הזה שעוברת את סף 2,000 הבקשות, עד שיחלפו 1,200 השניות המלאות, וגם למשך מספר שניות נוסף שמוגדר כמשך תקופת החסימה. אם משך האיסור מוגדר ל-3600, לדוגמה, התנועה מהלקוח תיחסם למשך 3,600 שניות (שעה אחת) מעבר לסוף מרווח הזמן של סף ההגבלה.

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

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

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

• ‫rate_limit_threshold_count: מספר הבקשות לכל לקוח שמותרות במרווח זמן מוגדר. הערך המינימלי הוא בקשה אחת והערך המקסימלי הוא 10,000 בקשות.
  • ‫interval_sec: מספר השניות במרווח הזמן. הערך חייב להיות 10, 30, 60, 120, 180, 240, 300, 600, 900, 1,200, 1,800, 2,700 או 3,600 שניות.
• ‫exceed_action: כשבקשה חורגת מהערך rate_limit_threshold_count,‏ Cloud Armor מחיל את הערך המוגדר exceed_action. הערכים האפשריים של exceed_action הם:
  • deny(status): הבקשה נדחית ומוחזר קוד הסטטוס שצוין. הערכים התקפים הם 403 Forbidden,‏ 404 Page Not Found,‏ 429 Too Many Requests ו-502 Bad Gateway. מומלץ להשתמש בקוד הסטטוס 429 Too Many Requests.
  • ‫redirect: הבקשה מופנית מחדש להערכה של reCAPTCHA או לכתובת URL אחרת, בהתאם לפרמטר exceed_redirect_options.
• ‫exceed_redirect_options: אם הערך של exceed_action הוא redirect, משתמשים בפרמטר הזה כדי לציין את פעולת ההפניה האוטומטית:
  • ‫type: הסוג של פעולת ההפניה לכתובת אחרת, GOOGLE_RECAPTCHA או EXTERNAL_302.
  • ‫target: כתובת ה-URL של היעד להפניה האוטומטית. הטירגוט לפי כתובת ה-URL הזה רלוונטי רק אם הערך של type הוא EXTERNAL_302.
• ‫conform_action: הפעולה שמתבצעת כשמספר הבקשות נמוך מrate_limit_threshold_count. הפעולה הזו היא תמיד פעולה של allow.
• ‫ban_threshold_count: מספר הבקשות לכל לקוח שמותרות במרווח זמן מוגדר, שבמהלכו Cloud Armor חוסם בקשות. אם מציינים את המאפיין הזה, המפתח נחסם למשך הזמן שמוגדר ב-ban_duration_sec כשמספר הבקשות שחורגות מהמגבלה שמוגדרת ב-rate_limit_threshold_count חורג גם מהמגבלה שמוגדרת ב-ban_threshold_count.
  • ‫ban_threshold_interval_sec: מספר השניות במרווח הזמן של ban_threshold_count. הערך של ban_threshold_interval_sec חייב להיות 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 או 3600 שניות.
• ‫ban_duration_sec: מספר השניות הנוסף שבהן הלקוח מושעה אחרי שחלף פרק הזמן interval_sec. הערך של ban_duration_sec חייב להיות 60,‏ 120,‏ 180,‏ 240,‏ 300,‏ 600,‏ 900,‏ 1,200,‏ 1,800,‏ 2,700 או 3,600 שניות.

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

כשמגדירים מדיניות אבטחה שמוגדרת כברירת מחדל במהלך יצירת איזון עומסים, סף ברירת המחדל הוא 500 בקשות במהלך כל מרווח של דקה אחת (rate_limit_threshold_count ו-interval_sec של 500 ו-60, בהתאמה). אם רוצים לבחור סף אחר, מומלץ לבצע את השלבים הבאים כדי לשנות את הפרמטרים:

1. מפעילים את Cloud Logging ומריצים שאילתה כדי לברר מהו המספר המקסימלי של בקשות שהגיעו לכל כתובת IP ולכל דקה במהלך יום או יותר בשירות לקצה העורפי שמוגן על ידי Cloud Armor.

   לדוגמה, נניח שאתם מאמינים ש-99% מתעבורת הרשת שאתם מקבלים לא מושפעת מכלל הגבלת הקצב. בתרחיש הזה, מומלץ להגדיר את סף הגבלת הקצב לאחוזון ה-99 של המספר המקסימלי של בקשות לכל כתובת IP ולכל דקה של ההפצה שנוצרת מנתוני Cloud Logging.

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

   1. הפעלת שמירה במטמון (Cloud CDN או Media CDN).
   2. הגדלת מרווח הזמן של ההגבלה (בקשות שמתקבלות כל כמה דקות, במקום כל 60 שניות).
   3. אפשר לחסום לקוחות כדי להפחית עוד יותר את ההשפעה של ההתקפה אחרי הגל הראשוני. הפעולה rate_based_ban של Cloud Armor מאפשרת לחסום את כל הלקוחות שחורגים מהמגבלות יותר מדי פעמים בחלון שצוין על ידי המשתמש. לדוגמה, לקוחות שחורגים מהמגבלות 10 פעמים בתוך דקה יכולים להיחסם למשך 15 דקות.

אכיפת סף

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

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

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

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

רישום ביומן

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

‫Cloud Armor עם Cloud Service Mesh

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

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

• הגדרת הגבלת קצב של יצירת בקשות