Виявлення шахрайства на межі мережі: Cloudflare Workers + tracio.ai

Традиційне виявлення шахрайства відбувається на рівні застосунку: запит надходить на ваш сервер, ви звертаєтеся до API виявлення шахрайства, чекаєте на відповідь, а потім вирішуєте, дозволити чи заблокувати. Цей повний цикл додає 50-200 мс затримки до кожного запиту — прийнятно для завантаження сторінок, але болісно для API-ендпоінтів, AJAX-викликів та взаємодій у реальному часі.

А що, якби ви могли ухвалити рішення про шахрайство ще до того, як запит дійде до вашого origin-сервера? Саме це уможливлюють обчислення на межі мережі, і Cloudflare Workers — це платформа, яку ми використовуємо, щоб продемонструвати цей підхід.

Архітектура

Схема має три компоненти: JS SDK tracio.ai (@tracio/sdk), що працює в браузері, Cloudflare Worker, розташований між клієнтом і вашим origin, та підписані вебхуки tracio.ai, що доставляють повний аналіз сигналів на ваш бекенд.

Потік працює так: JS SDK збирає сигнали пристрою та надсилає їх до tracio.ai під час завантаження сторінки, повертаючи visitorId у браузер. Ваш бекенд отримує повний результат ідентифікації — класифікацію ботів, smart signals, впевненість — через підписаний вебхук і записує вердикт у кеш на межі мережі. Браузер додає visitorId до наступних API-запитів (через заголовок або cookie). Cloudflare Worker перехоплює кожен запит, шукає кешований вердикт для цього visitorId та ухвалює рішення дозволити/заблокувати менш ніж за 5 мс.

Реалізація Worker

Worker підтримує легкий кеш нещодавніх результатів перевірки пристроїв за допомогою сховища KV від Cloudflare, який наповнюється вашим бекендом у міру надходження підписаних вебхуків tracio.ai. Коли запит надходить із заголовком visitorId, Worker перевіряє кеш. Якщо вердикт кешовано і відвідувач «чистий» (низький бал бота, немає VPN, впевненість вища за поріг), запит одразу проходить далі. Якщо вердикт ще не кешовано, Worker застосовує вашу резервну політику — пропустити з консервативним обмеженням частоти або надіслати виклик (challenge) — доки кеш, керований вебхуками, не наздожене.

Ключове спостереження полягає в тому, що кеш перевірки наповнюється проактивно. Перше завантаження сторінки запускає збір сигналів і кешує результат. Усі наступні API-виклики від цього відвідувача влучають у кеш — жодного циклу звернення до tracio.ai не потрібно. TTL кешу налаштовується; ми рекомендуємо 5 хвилин для ендпоінтів із високими вимогами до безпеки та 30 хвилин для загального контенту.

Показники продуктивності

Ми провели тестування цієї архітектури з клієнтом, який обробляє 50 000 запитів на хвилину через Cloudflare Workers. Результати:

Рівень влучань у кеш: 94% (більшість запитів надходить від відвідувачів, які вже завантажили сторінку). Затримка рішення на межі мережі (влучання в кеш): 1,2 мс медіана, 3,8 мс p99. Затримка рішення на межі мережі (промах кешу): 45 мс медіана (включно з викликом API до tracio.ai). Заощадження затримки origin: 120 мс медіана на запит (усунено перевірку шахрайства на боці сервера).

Рівень влучань у кеш 94% означає, що 94% рішень про шахрайство ухвалюються менш ніж за 4 мс на межі мережі, без залучення origin. Решта 6% — це запити першого відвідування, які потребують повного циклу звернення до API.

Стратегії блокування

Worker підтримує три стратегії блокування, які налаштовуються для кожного маршруту:

Жорстке блокування: одразу повертати 403 для відвідувачів високого ризику (бал бота > 0,9, відомий фреймворк автоматизації). М'яке блокування: додавати заголовки X-Tracio-Risk і дозволяти origin вирішувати. Це корисно, коли ви хочете мати контекст рівня застосунку для рішення. Виклик (challenge): перенаправляти підозрілих відвідувачів (помірний бал бота, виявлено VPN) на сторінку виклику, яка вимагає додаткової перевірки.

Ми рекомендуємо починати з м'якого блокування у production, спостерігати за розподілом ризику протягом тижня, а потім вмикати жорстке блокування для однозначних випадків (відомі боти, headless-браузери, автоматизація з високою впевненістю).

Аналіз витрат

Ціноутворення Cloudflare Workers ґрунтується на кількості запитів та часі обчислень. За 50 тис. запитів/хвилину (2,16 мільярда/місяць) вартість Worker становить приблизно $500/місяць. Порівняйте це із заощадженням затримки: усунення 120 мс перевірки шахрайства на боці origin зменшує використання CPU сервера на 15-20%, що зазвичай заощаджує більше, ніж вартість Worker на обчисленнях.

Справжня цінність — у запобіганні шахрайству: перехоплення ботів і шахрайських запитів до того, як вони спожили ресурси origin, з'єднання з базою даних і подальші виклики API. Один клієнт скоротив кількість своїх origin-серверів із 12 до 8 після впровадження виявлення шахрайства на межі мережі — боти, що споживали 30% його обчислювальних ресурсів, так і не дійшли до origin.