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

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

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

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

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

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

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

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

‫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 דקות.

אכיפת סף

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

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

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

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

רישום ביומן

שירות 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.

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