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

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

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

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

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

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

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

כשמגדירים כלל עם פעולת חסימה שמבוססת על קצב, אי אפשר לשנות אותו לפעולת ויסות נתונים (throttle) בהמשך. עם זאת, כשמגדירים כלל עם פעולת ויסות נתונים (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 שצוינו בכותרת X-Forwarded-For HTTP. סוג המפתח מוגדר כברירת מחדל ככתובת IP אם הכותרת הזו לא קיימת, אם הערך הוא לא כתובת IP תקינה או אם מנסים להשתמש בסוג המפתח הזה עם מאזן עומסי רשת חיצוני של פרוקסי.
  • ‫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: במקום לחסום את כלל התנועה, ויסות נתונים (throttle) מגביל את קצב הבקשות למקסימום מוגדר. ויסות נתונים (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: כתובת היעד של פעולת ההפניה האוטומטית. כתובת היעד הזו רלוונטית רק אם הערך של 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 מאפשרת לחסום את כל הלקוחות שחורגים מהמגבלות יותר מדי פעמים בפרק זמן שמוגדר על ידי המשתמש. לדוגמה, אפשר לחסום למשך 15 דקות לקוחות שחורגים מהמגבלות 10 פעמים בתוך דקה.

אכיפת סף

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

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

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

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

רישום ביומן

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

שילוב עם reCAPTCHA

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

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

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

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

‫Cloud Armor עם Cloud Service Mesh

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

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