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

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

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

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

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

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

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

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

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

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

הגבלת קצב של יצירת בקשות ב-Cloud Armor והגבלת קצב של יצירת בקשות בשירות

הגבלת קצב של יצירת בקשות ב-Cloud Armor והגבלת קצב של יצירת בקשות בשירות הן שתי אסטרטגיות שונות להגבלת קצב:

  • הגבלת קצב של יצירת בקשות ב-Cloud Armor: היא נאכפת במאזני עומסים בקצה הרשת. השתמשו בהגבלת קצב של יצירת בקשות ב-Cloud Armor כדי למנוע התקפות מניעת שירות מבוזרות (DDoS) מלקוחות לא מהימנים.
  • הגבלת קצב של יצירת בקשות לשירות: נאכפת במאזן עומסים פנימי של אפליקציות (ALB) וב-Secure Web Proxy. השתמשו בהגבלת קצב של יצירת בקשות בשירות כדי לנהל לקוחות מהימנים שעלולים להתנהג בצורה לא תקינה, וכדי למקסם את זמינות השירות לתנועה החשובה ביותר.

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

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

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

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

אפשר להשתמש בכל אחד מהמפתחות שצוינו בנפרד, או להגביל את קצב הבקשות על סמך שילוב של עד שלושה מפתחות. אפשר להשתמש בכמה מקשי 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,‏ 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 שאליה המשתמשים יופנו. רלוונטי רק כש-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, 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 שאליה המשתמשים יופנו. כתובת ה-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 שבהם נפרסו שירותי הקצה העורפי של HTTP(S). לדוגמה, אם השירות שלכם פרוס בשני אזורים, כל אחד משני האזורים מחיל את סף הגבלת הקצב של יצירת בקשות שהוגדר על כל מפתח, כך ששירות הקצה העורפי שלכם עשוי לחוות נפחי תעבורת נתונים מצטברים חוצי-אזורים שהם פי שניים מהסף שהוגדר. אם הסף שהוגדר הוא 5,000 בקשות, יכול להיות שהשירות לקצה העורפי יקבל 5,000 בקשות מאזור אחד ו-5,000 בקשות מהאזור השני.

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

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

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

רישום ביומן

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

‫Cloud Armor עם Cloud Service Mesh

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

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