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

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

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

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

יעדים נתמכים

מדיניות הגבלת קצב הבקשות בשירות זמינה ליעדים הבאים:

  • מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
  • Secure Web Proxy

בקשה לסינון לפי סדר

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

סדר ההערכה של סינון הבקשות.
סדר ההערכה של סינון הבקשות (לחצו כדי להגדיל).

כללים

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

תנאי ההתאמה

אלה התנאים להתאמה והמאפיינים שלהם. כל מאפיין יכול להתאים למחרוזת מדויקת, לתחילית, לסיומת או למחרוזת משנה:

  • ‫Source: המקור של הבקשה.
  • ‫Destination: היעד של הבקשה. אם מציינים כמה מאפיינים, הם משולבים עם אופרטור AND לוגי.
    • ‫header_set: רשימה של כותרות HTTP. התאמה מתרחשת כשכל הכותרות ב-header_set תואמות לכלל.
    • hosts: רשימה של מארחי HTTP. התאמה מתרחשת כשהבקשה מגיעה לאחד מהמארחים שצוינו ברשימה.
    • ‫paths: רשימה של נתיבי כתובות URL. התאמה מתרחשת כשהבקשה משתמשת באחד מהנתיבים שצוינו ברשימה.
    • ‫methods: רשימה של שיטות HTTP תקינות (כמו GET או POST). מתרחש התאמה כשבקשה משתמשת בכל אחת מהשיטות שצוינו ברשימה.

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

סדר הערכת הכללים

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

קטגוריות של הגבלת קצב של יצירת בקשות

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

בנוסף לסוגי המפתחות, אפשר להגדיר את המאפיינים הבאים של הקטגוריות:

  • הרצת בדיקה: במצב הרצת בדיקה, הכלל נבדק וההתאמות נשמרות, אבל הפעולה של הכלל לא מופעלת. כך תוכלו לבדוק את כללי הגבלת הקצב בלי להגביל את הלקוחות או להשפיע על תנועת הנתונים בפועל.
  • שינוי הגדרות המשתמש: אתם יכולים לשנות את מגבלות ברירת המחדל של הבקשות לערכי מפתחות ספציפיים. לדוגמה, אם יש לכם קטגוריה עם מגבלת ברירת מחדל של 100 בקשות לדקה לכל לקוח, ובקטגוריה הזו נעשה שימוש בסוג המפתח SOURCE_IP, תוכלו לבטל את המגבלה עבור כתובת IP ספציפית ולהגדיר במקומה מגבלה של 200 בקשות לדקה.

סוגי מפתחות

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

  • ‫ALL: מפתח אחד לכל הבקשות שעומדות בתנאי ההתאמה של הכלל.
  • ‫SOURCE_IP: מפתח ייחודי לכל כתובת ה-IP של הלקוח שהבקשות שלה עומדות בתנאי ההתאמה של הכלל.
  • ‫HTTP_HEADER: מפתח ייחודי לכל ערך ייחודי של כותרת HTTP שהשם שלה מוגדר. ערך המפתח נחתך ל-128 הבייטים הראשונים של ערך הכותרת. אם לא מצוינת כותרת כזו, סוג המפתח הוא ALL כברירת מחדל.
  • ‫HTTP_PATH: נתיב כתובת ה-URL של בקשת ה-HTTP. ערך המפתח נחתך ל-128 הבייטים הראשונים.
  • ‫PRINCIPAL: מחרוזת שמייצגת זהות, שנגזרת מהאישור של הלקוח. סוג חשבון המשתמש היחיד שנתמך הוא CLIENT_CERT_COMMON_NAME.

בכל כלל אפשר לציין סוג מפתח אחד או יותר. אם מציינים כמה סוגי מפתחות, השילוב הכולל של המפתחות לכל לקוח משמש כמפתח ייחודי. לדוגמה, אפשר להשתמש בשילוב של SOURCE_IP ו-HTTP_PATH כדי להגביל את קצב הגישה של כתובת IP ספציפית לנקודת קצה ספציפית.

שימוש בפרינציפלים להגבלת קצב יצירת הבקשות בשירותים

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

אם לא מציינים בורר ראשי לזיהוי, המערכת משתמשת ב-CLIENT_CERT_URI_SAN כבורר הראשי שמוגדר כברירת מחדל. המשמעות היא שהמערכת מעריכה את ה-SAN של ה-URI של אישור הלקוח כשמתקבלות החלטות לגבי הגבלת קצב.

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

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

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

ההשפעה של מגבלות הגודל של מאפיינים

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

דחייה יכולה להתרחש כשהמדיניות מאמתת מול CLIENT_CERT_COMMON_NAME והנושא של האישור (שמכיל את השם הנפוץ) חורג ממגבלת הגודל.

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