Google Cloud Armor ו-reCAPTCHA מספקים כלים שיעזרו לכם להעריך בקשות נכנסות שאולי מגיעות מלקוחות אוטומטיים, ולפעול בהתאם.
reCAPTCHA משתמש בטכניקות מתקדמות לניתוח סיכונים כדי להבחין בין משתמשים אנושיים לבין לקוחות אוטומטיים.reCAPTCHA מעריך את המשתמש על סמך ההגדרה של מפתחות האתר של reCAPTCHA WAF. לאחר מכן, המערכת מנפיקה אסימון מוצפן עם מאפיינים שמייצגים את הסיכון המשויך. Cloud Armor מפענח את האסימון הזה בשורה, בלי בקשה או תגובה נוספות לשירות reCAPTCHA. על סמך מאפייני הטוקן, Cloud Armor מאפשר לאשר, לדחות, להגביל את הקצב או להפנות מחדש את הבקשות הנכנסות. מידע נוסף זמין במאמר סקירה כללית על שילוב של Cloud Armor ו-reCAPTCHA.
ניהול הבוטים ב-Cloud Armor כולל את היכולות המשולבות הבאות.
אתגר ידני (דף אתגר reCAPTCHA)
- צריך להגדיר כלל במדיניות האבטחה כדי להפנות בקשה לבדיקת reCAPTCHA.
- אתם יכולים ליצור מפתח אתר משלכם ל-WAF של reCAPTCHA ולשייך אותו למדיניות האבטחה שלכם. מומלץ מאוד לעשות את זה. מידע נוסף זמין במאמר בנושא הטמעה של אתגר 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 כדי להפנות בקשות באופן חיצוני לנקודת קצה (endpoint) אחרת. אתם מספקים יעד להפניה מחדש בצורה של כתובת URL, ו-Cloud Armor מפנה מחדש את הבקשה על ידי הצגת תגובה מסוג HTTP 302 ללקוח.
הוספת עיצוב לבקשה
Cloud Armor יכול להוסיף כותרות בקשה מותאמות אישית עם ערכים סטטיים שהוגדרו על ידי המשתמש לפני העברת הבקשות לאפליקציה דרך שרת proxy. האפשרות הזו מאפשרת לתייג בקשות חשודות לצורך עיבוד חלופי בהמשך, למשל הצגת מלכודת דבש, או לצורך ניתוח ומעקב נוספים. הערה: צריך להוסיף את פרמטר הפעולה הזה לפעולה קיימת מסוג allow.
כותרות מותאמות אישית
אם הגדרתם את Cloud Armor להוספת כותרת או ערך בהתאמה אישית עם אותו שם כותרת כמו אחת מהכותרות בהתאמה אישית של מאזן העומסים הגלובלי החיצוני של אפליקציות או של מאזן העומסים הקלאסי של אפליקציות, ערך הכותרת ייכתב מחדש על ידי מאזן העומסים. מידע נוסף זמין במאמר יצירת כותרות בהתאמה אישית בשירותי קצה עורפי.
בנוסף, אם בוחרים שם של כותרת שכבר קיימת בבקשה, כולל כותרות 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 |
אתם יכולים להגביל את מספר הבקשות או לחסום לקוחות שמסתמכים על אותו קובץ 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 דקות). מומלץ לגזור את ערך הסף מסטטיסטיקות התנועה.