Google Cloud Armor ו-reCAPTCHA מספקים כלים שיעזרו לכם להעריך בקשות נכנסות שאולי מגיעות מלקוחות אוטומטיים ולפעול בהתאם.
reCAPTCHA משתמש בטכניקות מתקדמות לניתוח סיכונים כדי להבחין בין משתמשים אנושיים לבין לקוחות אוטומטיים.reCAPTCHA מעריך את המשתמש על סמך ההגדרה של מפתחות האתר של reCAPTCHA WAF. לאחר מכן, המערכת מנפיקה אסימון מוצפן עם מאפיינים שמייצגים את הסיכון המשויך. Cloud Armor מפענח את האסימון הזה בשורה, בלי בקשה או תגובה נוספות לשירות reCAPTCHA. על סמך מאפייני הטוקן, Cloud Armor מאפשר לאשר, לדחות, להגביל את קצב הבקשות או להפנות מחדש את הבקשות הנכנסות. מידע נוסף זמין במאמר סקירה כללית על שילוב של Cloud Armor ו-reCAPTCHA.
ניהול הבוטים ב-Cloud Armor כולל את היכולות המשולבות הבאות.
אתגר ידני (דף מבחן reCAPTCHA)
- צריך להגדיר כלל במדיניות האבטחה כדי להפנות בקשה לבדיקת reCAPTCHA.
- אתם יכולים ליצור מפתח אתר משלכם ל-reCAPTCHA WAF ולשייך אותו למדיניות האבטחה שלכם. מומלץ מאוד לעשות זאת. מידע נוסף זמין במאמר בנושא הטמעה של מבחן reCAPTCHA.
- אתם יכולים לאפשר רק למשתמשי קצה שעוברים את האתגר הידני של reCAPTCHA להשתמש בשירות, על ידי הפניה אוטומטית של משתמשי קצה להערכה של reCAPTCHA.
אכיפת בדיקה חלקה של reCAPTCHA
- אתם יכולים לבצע פעולות שונות לגבי בקשות נכנסות בהתאם להערכת הסיכון של reCAPTCHA לכך שהבקשה מגיעה מבוט. אתם יכולים לכתוב כללים של מדיניות אבטחה כדי להעריך ולסנן את התנועה על סמך הניקוד של האסימון ומאפיינים אחרים של האסימון.
- צריך להטמיע טוקנים של פעולות reCAPTCHA, טוקנים של סשנים reCAPTCHA או את שניהם. טוקנים של פעולות reCAPTCHA נתמכים באפליקציות שפועלות באתרים, ב-iOS וב-Android. טוקנים של סשנים reCAPTCHA נתמכים רק באתרים. מידע נוסף על טוקנים של reCAPTCHA זמין במאמרים בנושא טוקנים של פעולות ב-reCAPTCHA וטוקנים של סשנים ב-reCAPTCHA.
- צריך להגדיר כלל במדיניות האבטחה שמעריך טוקנים של reCAPTCHA.
- כדי למנוע גניבת טוקנים, מומלץ לשייך את מפתחות reCAPTCHA שלכם ל-WAF לכלל מדיניות האבטחה.
ניהול הבוטים ב-Cloud Armor כולל גם את היכולות הבאות.
- הפניה אוטומטית (302)
- אתם יכולים להפנות בקשות לכתובת ה-URL החלופית שהגדרתם על ידי הגדרת Cloud Armor כך שיציג תגובה מסוג HTTP 302 ללקוח.
- הוספת קישוט לבקשה
- אתם יכולים להוסיף כותרות מותאמות אישית לבקשות, וערכים סטטיים לכותרות האלה, לפני העברת הבקשות לשרתי הקצה העורפיים.
תרחישים לדוגמה
בקטע הזה מוסבר איך אפשר להשתמש ביכולות של Cloud Armor לניהול בוטים כדי לצמצם את הסיכון מבוטים ולשלוט בגישה מלקוחות אוטומטיים.
שימוש באתגר ידני כדי להבחין בין משתמשים לגיטימיים לבין לקוחות אוטומטיים
אתם יכולים להפנות בקשה ל-reCAPTCHA כדי להעריך את לקוח הקצה ולהציג אתגרים ידניים אם צריך, בלי להטמיע reCAPTCHA נוסף. כשמשתמשים שהם בני אדם חולקים את אותו חתימה (כמו נתיבי URL או חתימות אחרות ברמה 7) עם בוט או מערכת פוגעת, הפעולה הזו מאפשרת להם להוכיח שהם בני אדם. רק משתמשים שעוברים את ההערכה יכולים לקבל גישה לשירות שלכם.
בתרשים הבא מוצג איך אתגר ידני מבחין בין בקשה שמגיעה מאדם לבין בקשה שמגיעה מלקוח אוטומטי:
נניח שמשתמשת בשם מאיה ובוט גולשים בדף הכניסה (/login.html) באתר שלכם. כדי לאפשר גישה ל-Maya בלי לתת גישה לבוט, אפשר להגדיר כלל מדיניות אבטחה עם ביטוי ההתאמה המתקדם request.path.matches("/login.html"), עם פעולה redirect מסוג GOOGLE_RECAPTCHA. חוויית המשתמש מקצה לקצה היא כזו:
- משתמש קצה נכנס לאתר שלכם בפעם הראשונה.
- Cloud Armor מעריך את הבקשה ומחליט להפנות אותה ל-reCAPTCHA.
- מערכת reCAPTCHA מגיבה בדף HTML עם JavaScript מוטמע של reCAPTCHA.
- כשמעבדים את התגובה, קוד ה-JavaScript המוטמע מופעל כדי להעריך את המשתמש, ואם צריך, מוצגים אתגרים ידניים.
- אם המשתמש עובר את ההערכה, reCAPTCHA מנפיק קובץ cookie של פטור, שהדפדפן מצרף באופן אוטומטי לכל אחת מהבקשות הבאות לאותו אתר עד שתוקף קובץ ה-cookie יפוג.
- אחרת, מערכת reCAPTCHA לא מנפיקה קובץ Cookie של פטור.
בדוגמה הזו, רק מאיה עוברת את בדיקת reCAPTCHA ומקבלת עוגיית פטור, וכך מקבלת גישה לאתר שלכם.
כשמשתמשים באתגרים ידניים, מומלץ ליצור מפתח אתר משלכם ל-reCAPTCHA WAF ולשייך אותו למדיניות האבטחה. כך תוכלו לראות את מדדי reCAPTCHA שמשויכים למפתח האתר, ולאמן מודל אבטחה שספציפי למפתח האתר. מידע נוסף זמין במאמר בנושא יצירת מפתח אתר לאתגר reCAPTCHA WAF.
אם לא תיצרו מפתח אתר ולא תשייכו אותו, מערכת reCAPTCHA תשתמש במפתח אתר שמנוהל על ידי Google במהלך ההערכה. אי אפשר לראות מדדים של reCAPTCHA שמשויכים למפתחות אתר שלא נמצאים בבעלותכם, כולל מפתחות אתר שמנוהלים על ידי Google.
אכיפת בדיקת reCAPTCHA
כשבקשה נכנסת עם טוקן reCAPTCHA מצורף, Cloud Armor מעריך את הבקשה ומחיל את הפעולה שהוגדרה על סמך המאפיינים האישיים בטוקן. ההערכה של מדיניות האבטחה ב-Cloud Armor מתבצעת בקצה הרשת של Google, כך שהבקשות לעורף לא מעורבות בפענוח הטוקן.
טוקנים של reCAPTCHA
מערכת reCAPTCHA מנפיקה שני סוגים של טוקנים: טוקנים של פעולות וטוקנים של סשנים. שני סוגי הטוקנים מחזירים ניקוד לכל בקשה על סמך האינטראקציות עם האתר או האפליקציה. שני סוגי הטוקנים מכילים מאפיינים, כולל ניקוד שמייצג את הסיכון שמשויך למשתמש. הם גם מכילים מידע על מפתח reCAPTCHA שבו השתמשתם כשנוצר הטוקן.
לפני שמגדירים כללים של מדיניות אבטחה, צריך להחליט אם להשתמש בטוקנים של פעולות, בטוקנים של סשנים או בשניהם. מומלץ לקרוא את המסמכים בנושא reCAPTCHA כדי לקבל החלטה מושכלת. מידע נוסף מופיע בהשוואה בין תרחישי שימוש ב-reCAPTCHA.
אחרי שקובעים באיזה סוג טוקן רוצים להשתמש, מטמיעים את reCAPTCHA כדי שהטוקן יצורף לבקשה. למידע על הטמעת טוקנים ב-reCAPTCHA, אפשר לעיין בדפים הבאים:
- אפליקציות אינטרנט
- אפליקציות לנייד
לבסוף, משתמשים בשפת הכללים של Cloud Armor כדי להגדיר כללים של מדיניות אבטחה להערכת אסימוני reCAPTCHA שמצורפים לבקשה. כדי למנוע גניבת אסימונים, מומלץ מאוד לשייך את מפתחות reCAPTCHA לכללים של מדיניות האבטחה. כשמשייכים מפתחות reCAPTCHA לכלל במדיניות אבטחה, Cloud Armor מבצע אימות נוסף של הטוקן על ידי השוואה בין מפתח reCAPTCHA בטוקן לבין מפתחות reCAPTCHA שמשויכים לכלל. Cloud Armor מחשיב טוקן עם מפתח reCAPTCHA לא ידוע כטוקן לא תקין. מידע נוסף זמין במאמר בנושא הפעלת הערכה חלקה של reCAPTCHA.
באיור הבא מוצג תהליך האכיפה של אסימון reCAPTCHA.
הפניה (תגובה 302)
אתם יכולים להשתמש בפעולת הפניה מבוססת-URL כדי להפנות בקשות באופן חיצוני לנקודת קצה אחרת. אתם מספקים יעד להפניה בפורמט של כתובת URL, ו-Cloud Armor מפנה את הבקשה על ידי הצגת תגובת HTTP 302 ללקוח.
הוספת עיצוב לבקשה
Cloud Armor יכול להוסיף כותרות בקשה בהתאמה אישית עם ערכים סטטיים שהמשתמש מגדיר לפני העברת הבקשות לאפליקציה דרך ה-proxy. האפשרות הזו מאפשרת לתייג בקשות חשודות לצורך עיבוד חלופי בהמשך, למשל הצגת מלכודת דבש, או לצורך ניתוח ומעקב נוספים. הערה: צריך להוסיף את פרמטר הפעולה הזה לפעולה קיימת מסוג allow.
כותרות מותאמות אישית
אם הגדרתם את Cloud Armor להוספת כותרת או ערך מותאמים אישית עם אותו שם כותרת כמו אחת מהכותרות המותאמות אישית של מאזן העומסים של אפליקציות (ALB) החיצוני הגלובלי או מאזן העומסים של אפליקציות (ALB) הקלאסי, מאזן העומסים יחליף את ערך הכותרת. מידע נוסף זמין במאמר בנושא יצירת כותרות מותאמות אישית בשירותי קצה עורפיים.
בנוסף, אם בוחרים שם של כותרת שכבר קיימת בבקשה, כולל כותרות HTTP רגילות, הערך המקורי בכותרת הזו מוחלף בערך שהוגדר על ידי המשתמש שסופק לכלל Cloud Armor.
אינטגרציה עם הגבלת קצב של יצירת בקשות
כללי הגבלת קצב של יצירת בקשות ב-Cloud Armor תואמים ליכולות של ניהול בוטים. לדוגמה, אפשר להפנות בקשה להערכה של reCAPTCHA או להפנות לכתובת URL אחרת כשהמספר של הבקשות חורג מהסף שהוגדר. בנוסף, אתם יכולים לזהות לקוחות לצורך הגבלת קצב הבקשות על סמך קובצי Cookie או טוקנים של פטור מ-reCAPTCHA, כדי להגביל את מספר הבקשות או לחסום לקוחות שעושים שימוש חוזר באותו קובץ Cookie או טוקן, או מנצלים אותו לרעה, בקצב שחורג מהסף שהוגדר על ידי המשתמש.
הגבלת קצב של קובצי Cookie או טוקנים של פטור מ-reCAPTCHA
מטעמי אבטחה, מומלץ להגדיר כללים להגבלת קצב של יצירת בקשות כדי למנוע שימוש לרעה בטוקנים באמצעות שימוש חוזר בטוקן פעולה ייחודי של reCAPTCHA, בטוקן לסשן או בקובץ Cookie של חריגה. בטבלה הבאה אפשר לראות איך אפשר לזהות קובץ Cookie או טוקן של reCAPTCHA כפטורים מהגבלת קצב של יצירת בקשות, ולציין אותם כמפתח בכלל להגבלת קצב של יצירת בקשות.
| משאב | enforce_on_key |
enforce_on_key_name |
|---|---|---|
| קובץ Cookie של פטור | HTTP-COOKIE |
recaptcha-ca-e |
| טוקן פעולה | HTTP-HEADER |
X-Recaptcha-Token |
| טוקן לסשן | HTTP-COOKIE |
recaptcha-ca-t |
אתם יכולים לווסת נתונים (throttle) של בקשות או לחסום לקוחות שמסתמכים על אותו קובץ Cookie או טוקן של פטור, ושחורגים מהסף שהוגדר. מידע נוסף על פרמטרים של הגבלת קצב של יצירת בקשות זמין במאמר בנושא החלת הגבלת קצב של יצירת בקשות.
דוגמאות להגבלת קצב של יצירת בקשות
נניח שאתם משתמשים רק באתגרים ידניים בכתובות URL נבחרות (למשל, /login.html) באתר שלכם. כדי לעשות זאת, מגדירים את כללי מדיניות האבטחה באופן הבא:
- כלל 1: אם לבקשה מצורף קובץ Cookie תקף לפטור, ומספר השימושים בקובץ ה-Cookie לפטור נמוך מהסף שהגדרתם, הבקשה מאושרת.
- כלל 2: הפניה של הבקשה לבדיקת reCAPTCHA.
שנית, נניח שאתם משתמשים באתר רק בטוקנים של פעולות או בטוקנים של סשנים.
לדוגמה, אפשר להשתמש בטוקנים של פעולות כדי להגן על פעולות משתמשים חשובות, כמו /login.html. כדי לעשות זאת, צריך לבצע פעולות על סמך הניקוד של action-token באופן הבא:
- כלל 1: אם הניקוד של האסימון לפעולה גבוה מסף מוגדר מראש (לדוגמה,
0.8), המערכת מאשרת את הבקשה אם מספר השימושים באסימון לפעולה נמוך מהסף שהגדרתם. - כלל 2: דחיית הבקשה.
אפשר להגדיר כללים דומים למדיניות אבטחה כדי לאכוף הערכה של טוקן סשן של reCAPTCHA.
שלישית, נניח שאתם משלבים אסימוני פעולה או אסימוני סשן עם אתגרים ידניים בכתובות URL נבחרות (כמו /login.html) באתר שלכם, ואתם רוצים לבצע פעולות על סמך הניקוד מאסימון הפעולה. ואתם רוצים לתת למשתמש הזדמנות שנייה לפתור אתגרים אם הציון לא מספיק טוב. כדי לעשות את זה,
מגדירים את הכללים של מדיניות האבטחה באופן הבא:
- כלל 1: אם הניקוד של האסימון לפעולה גבוה מסף מוגדר מראש (לדוגמה,
0.8), המערכת מאשרת את הבקשה אם מספר השימושים באסימון לפעולה נמוך מהסף שהגדרתם. - כללים 2 ו-3: אם הציון של טוקן הפעולה גבוה מסף מוגדר מראש אחר (לדוגמה,
0.5), המערכת תפנה מחדש את הבקשה לבדיקת reCAPTCHA, אלא אם מצורף לבקשה קובץ Cookie תקף של חריגה ומספר השימושים בקובץ ה-Cookie של החריגה נמוך מהסף שהגדרתם. - כלל 4: דחיית הבקשה.
אתם יכולים להגדיר כללים דומים למדיניות האבטחה כדי לאכוף הערכה של טוקן סשן של reCAPTCHA באמצעות אתגרים ידניים.
אם לא משנים את כללי הגבלת קצב של יצירת בקשות, Cloud Armor לא מגביל את מספר הפעמים שאפשר להשתמש בכל קובץ Cookie של פטור מ-reCAPTCHA, בכל טוקן פעולה ובכל טוקן סשן. במקרה של טוקנים של פעולות, מומלץ להשתמש בסף נמוך (לדוגמה, 1) ובמרווח זמן גבוה (לדוגמה, 30 דקות, כי הטוקנים של הפעולות תקפים למשך 30 דקות). מומלץ לגזור את ערך הסף מנתוני התנועה.