זיהוי הונאה בקצה הרשת: Cloudflare Workers + tracio.ai
הרצת אימות טביעת אצבע של מכשיר ב-Cloudflare Workers לפני שהבקשות מגיעות ל-origin. החלטות הונאה בקצה בפחות מ-5ms.
זיהוי הונאה מסורתי מתרחש בשכבת האפליקציה: הבקשה מגיעה לשרת שלכם, אתם שולחים שאילתה ל-API של זיהוי ההונאה, ממתינים לתשובה, ואז מחליטים אם לאשר או לחסום. הלוך ושוב זה מוסיף 50-200ms של latency לכל בקשה — מקובל עבור טעינת עמודים, אך כואב עבור נקודות קצה של API, קריאות AJAX ואינטראקציות בזמן אמת.
מה אם הייתם יכולים לקבל את החלטת ההונאה לפני שהבקשה מגיעה לשרת ה-origin שלכם? זה בדיוק מה שמאפשר עיבוד בקצה (edge computing), ו-Cloudflare Workers היא הפלטפורמה שבה אנו משתמשים כדי להדגים דפוס זה.
הארכיטקטורה
המערך כולל שלושה רכיבים: ה-JS SDK של tracio.ai (@tracio/sdk) שרץ בדפדפן, Cloudflare Worker היושב בין הלקוח לבין ה-origin שלכם, ו-webhooks חתומים של tracio.ai המספקים ניתוח אותות מלא ל-backend שלכם.
הזרימה עובדת כך: ה-JS SDK אוסף אותות מכשיר ושולח אותם ל-tracio.ai במהלך טעינת העמוד, ומחזיר visitorId לדפדפן. ה-backend שלכם מקבל את תוצאת הזיהוי המלאה — סיווג בוט, אותות חכמים, רמת ביטחון — באמצעות webhook חתום, וכותב את פסק הדין לתוך קאש הקצה. הדפדפן כולל את ה-visitorId בבקשות API הבאות (באמצעות header או cookie). ה-Cloudflare Worker מיירט כל בקשה, מאתר את פסק הדין השמור עבור אותו visitorId, ומקבל החלטת אישור/חסימה בפחות מ-5ms.
מימוש ה-Worker
ה-Worker מחזיק קאש קליל של תוצאות אימות מכשיר אחרונות באמצעות אחסון ה-KV של Cloudflare, המאוכלס על ידי ה-backend שלכם ככל שמגיעים webhooks חתומים של tracio.ai. כאשר בקשה מגיעה עם header של visitorId, ה-Worker בודק את הקאש. אם פסק הדין שמור בקאש והמבקר נקי (ציון בוט נמוך, ללא VPN, רמת ביטחון מעל הסף), הבקשה עוברת מיד. אם עדיין אין פסק דין שמור בקאש, ה-Worker מיישם את מדיניות ברירת המחדל שלכם — מעבר עם הגבלת קצב שמרנית, או challenge — עד שקאש מבוסס ה-webhook מדביק את הפער.
התובנה הקריטית היא שקאש האימות מאוכלס באופן יזום. טעינת העמוד הראשונה מפעילה איסוף אותות ושומרת את התוצאה בקאש. כל קריאות ה-API הבאות מאותו מבקר פוגעות בקאש — ללא צורך בהלוך ושוב ל-tracio.ai. ה-TTL של הקאש ניתן להגדרה; אנו ממליצים על 5 דקות עבור נקודות קצה בעלות אבטחה גבוהה ו-30 דקות עבור תוכן כללי.
נתוני ביצועים
מדדנו את הארכיטקטורה הזו עם לקוח המעבד 50,000 בקשות בדקה דרך Cloudflare Workers. התוצאות:
שיעור פגיעה בקאש: 94% (רוב הבקשות מגיעות ממבקרים שכבר טענו עמוד). Latency של החלטה בקצה (פגיעה בקאש): 1.2ms חציון, 3.8ms p99. Latency של החלטה בקצה (החטאת קאש): 45ms חציון (כולל קריאת API ל-tracio.ai). חיסכון ב-latency של ה-origin: 120ms חציון לכל בקשה (ביטול בדיקת ההונאה בצד השרת).
שיעור פגיעה בקאש של 94% משמעו ש-94% מהחלטות ההונאה מתרחשות בפחות מ-4ms בקצה, ללא מעורבות של ה-origin. 6% הנותרים הם בקשות ביקור ראשון הדורשות הלוך ושוב מלא של API.
אסטרטגיות חסימה
ה-Worker תומך בשלוש אסטרטגיות חסימה, הניתנות להגדרה לכל route:
חסימה קשה (hard block): החזרת 403 מיד עבור מבקרים בסיכון גבוה (ציון בוט > 0.9, מסגרת אוטומציה מוכרת). חסימה רכה (soft block): הוספת headers מסוג X-Tracio-Risk והשארת ההחלטה ל-origin. זה שימושי כאשר אתם רוצים הקשר ברמת האפליקציה עבור ההחלטה. Challenge: הפניית מבקרים חשודים (ציון בוט בינוני, זוהה VPN) לעמוד challenge הדורש אימות נוסף.
אנו ממליצים להתחיל עם חסימה רכה בסביבת production, לנטר את התפלגות הסיכון במשך שבוע, ואז להפעיל חסימה קשה עבור מקרים חד-משמעיים (בוטים מוכרים, דפדפני headless, אוטומציה ברמת ביטחון גבוהה).
ניתוח עלויות
התמחור של Cloudflare Workers מבוסס על בקשות וזמן חישוב. ב-50K בקשות בדקה (2.16 מיליארד בחודש), עלות ה-Worker היא כ-500$ בחודש. השוו זאת לחיסכון ב-latency: ביטול 120ms של בדיקת הונאה בצד ה-origin מפחית את השימוש ב-CPU של השרת ב-15-20%, מה שבדרך כלל חוסך יותר מעלות ה-Worker בחישוב.
הערך האמיתי טמון במניעת הונאה: תפיסת בוטים ובקשות הונאה לפני שהם צורכים משאבי origin, חיבורי מסד נתונים וקריאות API במורד הזרם. לקוח אחד צמצם את מספר שרתי ה-origin שלו מ-12 ל-8 לאחר מימוש זיהוי הונאה מבוסס-קצה — הבוטים שצרכו 30% מהחישוב שלו מעולם לא הגיעו ל-origin.