Bot Protection და API ანტიფროზი

1) რატომ არის ეს აუცილებელი?

ბოტები და თავდამსხმელები თავს დაესხნენ შეყვანის ზრდასა და ფულს: რეგისტრაცია, ლოგინი (ATO), ანაბრები/დასკვნები, პრომო მექანიკა, თამაშების/კოეფიციენტების კატალოგები. სახელმძღვანელო წესები და სუფთა საბადოები უკვე არასაკმარისია: ჩვენ გვჭირდება მრავალ დონის სიგნალები, რეალურ დროში სკანირება და გადაწყვეტილების კონტროლი (allow/deny/challenge/throttle) ბიზნეს მოვლენებისგან უკუკავშირით (chargeback-ratio, KYC fails).

2) მუქარის ტაქსონომია

რეგისტრაცია/ონბორდი: მასობრივი ანგარიშები, ერთჯერადი ელექტრონული ფოსტის/SIM ბანკები, მოწყობილობების მეურნეობები.
ATO (Account Takeover): credential stuffing, password spraying, session hijack.
ბონუს აბიუსი: მულტიკაუტი, გეო/იურისდიქციის არბიტრაჟი, სელფ-ექსკლუზიური შემოვლითი.
კარტგი/გადახდის ფროიდი: ბარათის ტესტი, მოპარული საფულეები, თანხების გადახდა.
Scraping/ინვენტარი: შინაარსის, ფასების, კოეფიციენტების აგრესიული გაჭიმვა.
API-DoS დაბალი ინტენსივობა: კუს შეტევები, slow-POST, მობილური SDK ემულაციები.
ვებჰუკი/ინტეგრაცია: შეტყობინებების გაყალბება HMAC/mTLS, replay.

3) თავდაცვის არქიტექტურა

3. 1 ფენები

1. Edge (CDN/WAF/კარიბჭე): ადრეული წარუმატებლობები (ASN/Geo/IP რეპუტაცია), მსუბუქი ჩელენჯები, ლიმიტები, PoW.
2. Risk API (რისკის PDP): წესების ცენტრალიზებული ძრავა/ML; ответ — `decision`, `score`, `reason`, `ttl`.
3. App დონე: აფეთქების ღუმელის ინვარიანტები, ბიზნეს ლოგიკა (ლიმიტები, KYC, AML), ასინქრონული შურისძიება.
4. მოვლენების ნაკადი: Kafka/Kinesis - feature store/მოდელი - უკუკავშირი გადახდების/დავებისგან.

3. 2 გამოსავალი

[Request] → Edge Plugins → (enrich) → Risk API (rules+ML) → Decision:
allow      deny      throttle      challenge(type=captcha    sms    PoW    biometry)

გამოსავალი იშლება გასაღებით (მაგალითად, მოწყობილობის × account × route) 'ttl' წამში.

4) სიგნალები და გამდიდრება

ქსელი/არხი: IP/ASN, მარიონეტული/VPN/Tor, rdns, rtt/jitter, SYN-rate, TLS-fingerprint (JA3/JA4), HTTP/2/3 ქცევა.
Devais/ბრაუზერი: canvas/audio/WebGL FP (ფრთხილად), პლატფორმა/SDK, Timezone/locale, გარჩევადობა, შრიფტები, WebDriver/headless ინდიკატორები, მობილური).
ქცევა: შეყვანის სიჩქარე, თაგვის/ტრაექტორია, ეკრანების თანმიმდევრობა, დველის დრო, მცდელობების სიხშირე, ბრაუზერის იდენტიფიკატორებს შორის გადასვლა.
შინაარსი/მოთხოვნა: ელექტრონული ფოსტის/დომენის ფორმა, დისპოზიციური პროვაიდერები, phone HLR/ან ტიპის ნომერი, BIN ბარათი, ანგარიში/IBAN რეესტრებში, FIO/მისამართების მსგავსი.
ანგარიში/ისტორია: ანგარიშის ასაკი, KYC სტატუსი, რეცენზენტი, ARPPU, დეპოზიტების/დასკვნების/ბონუსების გამოწვევა.
გარე წყაროები: კომპრომისული სიები (HIBP მსგავსი), გადახდის სარისკო სიგნალები (PSP), ASN რეპუტაცია.

5) გადაწყვეტილება: წესები + ML

5. 1 წესები (დეტერმინიზმი)

Velocity: „N რეგისტრაციები s/24 10 წუთში“, „M ლოგინი ერთი მოწყობილობით X ანგარიშებზე“, „K 3DS-fails ზედიზედ“.
გეო/იურისდიქცია: კონფლიქტები IP-geo vs მისამართი/დოკუმენტი, ადგილმდებარეობის მოულოდნელი ნახტომი.
ბიზნეს ინვარიანტები: საპასუხისმგებლო გადახდების შეზღუდვები, თვითკლუზია, სანქციების სიები.

5. 2 ML Scoring (Real Time)

მსუბუქი მოდელი (GBM/logreg) ონლაინ ნიშნით: 'ip _ risk', 'device _ age', 'account _ age', 'pwd _ fail _ rate', 'bin _ risk', 'velocity _', 'behavihavioraloral _'.
ცალკე მოდელი ATO- სთვის და ცალკე - გადახდების/დასკვნებისთვის.
იურისდიქციის/ტენანტის სეგმენტი (რეიდების კალიბრაციის პრო-ბაზარი).

5. 3 გადაწყვეტილების მიღება

if ip_blacklisted or bad_asn then deny else if rule_severe then challenge(hard)
else if score >= 0. 9 then deny else if 0. 7 <= score < 0. 9 then challenge(soft)
else allow

'challenge' -ში შეინახეთ გავლის/მარცხის ფაქტები; ხახუნის ესკალაცია/შემცირება დინამიურად.

6) Velocity და კვოტები (გასაღებები და ფანჯრები)

Ключи: `ip`, `ip/24`, `device_id`, `account_id`, `payment_instrument`, `email_domain`, `bin`.
ფანჯრები: მოცურების (1m/5m/1h/24h) + ცალკეული „burst „/„ sustained “.
პოლიტიკოსები: ცხელ მარშრუტებზე „მკაცრი“ დენი (ლოგინი/ანაბარი), შინაარსზე რბილი throttle.

pseudo allow, retry_after = gcra_allow(key="login:ip:"+ip, rate=60/min, burst=30)
if not allow:
return 429, {"Retry-After": retry_after}

7) ჩელენჯი და „კაცობრიობის“ შემოწმება

CAPTCHA/turnstile: как soft-challenge; ამოიღეთ „სუფთა“ სესიის მაღალი ნდობის შემდეგ.
Proof-of-Work (PoW): API/სკრიპტებისთვის - გამოთვალეთ ჰეში მოცემული სირთულეებით; დინამიური სირთულე დატვირთვის გაზრდით.
OTP/SMS/Email/Push: ATO/კრიტიკული ოპერაციებისთვის; არ ბოროტად გამოყენება (ღირებულება/UX).
WebAuthn/ბიომეტრია: ნდობის მაღალი დონე cash-out/payout ნაწილების შეცვლა.
Device trust: დადასტურებული მოწყობილობის ანგარიში; ახალი მოწყობილობები - გამოწვევა.

8) ინტეგრაცია კარიბჭეში/მარიონეტებში

8. 1 Envoy: ext _ authz - Risk API (ფსევდო)

yaml http_filters:
- name: envoy. filters. http. ext_authz typed_config:
http_service:
server_uri: { uri: http://risk-api:8080, cluster: risk, timeout: 80ms }
authorization_request:
allowed_headers:
patterns:
- exact: "x-tenant"
- exact: "x-device-id"
- exact: "user-agent"
authorization_response:
allowed_upstream_headers:
patterns: [{ exact: "x-risk-score" }, { exact: "x-risk-decision" }]
- name: envoy. filters. http. router

8. 2 NGINX/Lua: მსუბუქი POW და velocity

nginx lua_shared_dict vel 20m;

access_by_lua_block {
local ip = ngx. var. remote_addr if not gcra_allow("reg:ip:"..ip, 20, 40) then ngx. header["Retry-After"] = 30; return ngx. exit(429)
end

local pow = ngx. req. get_headers()["X-POW"]
if not verify_pow(pow, ngx. var. request_id, 18) then ngx. status = 401; ngx. say('need-pow'); return ngx. exit(401)
end
}

9) Risk API კონტრაქტი

json
{
"tenant":"eu-1",
"route":"POST /v1/login",
"subject":{"account_id":"a123","email":"u@d. com"},
"device":{"id":"d-xyz","fp":"...","ja3":"...","headless":false},
"network":{"ip":"203. 0. 113. 10","asn":12345,"country":"DE","rtt_ms":42},
"context":{"fail_5m":3,"pwd_reset_24h":1}
}

json
{ "decision":"challenge", "score":0. 83, "reason":"high_velocity+new_device", "ttl_sec":900, "challenge":"captcha" }

10) მონაცემები, ფიჩები და მოდელები

Feature Store (ონლაინ): Redis/Scylla/KeyDB - მრიცხველები/velocity/დროებითი ეტიკეტები.
Batch/offline: DWH (BigQuery/S3 + Athena) სწავლისთვის/რეფიტებისთვის; შეინახეთ გადინება, chargeback, ხელით revie.
მოდელები: მარტივი რეალურ დროში (ლოგრაგი/GBM); მძიმე (XGBoost/NN) - ოფლაინი PGMs/კარადით და შემდგომში დისტილაციით.
დრიფტის კონტროლი: PSI, AUC/PR, რეიდების კალიბრი რეგიონების/არხების საშუალებით.

11) დაკვირვება და ოპერაციული წრე

• `risk_requests_total{route,decision}`
• `risk_score_bucket` (distribution)
• `waf_block_total`, `velocity_block_total`, `challenge_pass_rate`
• `ato_incidents`, `carding_detected`, `cashout_denied`
• ბიზნეს მეტრები: 'chargeback _ rate', 'bonus _ abuse _ rate', 'false _ positive _ rate'
• Logs (რედაქტირებული): 'decision', 'score', საკვანძო სიგნალები, 'trace _ id', PII/საიდუმლოებების გარეშე.
• A/B და Shadow: ახალი პოლიტიკა shadow რეჟიმში (გადაწყვეტილების მოლოდინი), შემდეგ კანარი (1-5%), SLO/FP ავტობუსი.
• Playbooks: ესკალაცია, დროებითი გამკაცრება, გამოტოვება, „ვირტუალური პატჩი“.

12) კონფიდენციალურობა და შესაბამისობა

მინიმუმამდე დაიყვანეთ PII; დააკვირდით სტაბილურ იდენტიფიკატორებს (მაგალითად, email SHA-256 მარილით).
პატივს სცემთ რეგიონალურ იურისდიქციას (მონაცემების ლოკალიზაცია, თანხმობა).
გამჭვირვალე ახსნა გადაწყვეტილებები ხელით შურისძიებისთვის; შეინახეთ მხოლოდ საჭირო TTL- ით.

13) iGaming/ფინანსების სპეციფიკა

რეგისტრაცია: დისპოზიციური ელექტრონული ფოსტის ფილტრები/VoIP, velocity თითო/24, devais მეურნეობები - challenge/deny.
Login/ATO: ახალი მოწყობილობები/გეო-რბოლა OTP/WebAuthn; password spraying → throttle/deny.
პრემიები: ლიმიტები „გათეთრების გზაზე“ (ანაბარი - ბონუსი - მინიმალური ბრუნვა - დასკვნა), ასოცირების გრაფიკული ანალიზი (მისამართები/მოწყობილობები/ბარათები).
გადახდები/დასკვნები: BIN რისკი, country-mismatch, PSP სიგნალები; ახალი ინსტრუმენტისთვის cashout არის მაღალი ბარიერი და KYC შემოწმება.
ვებჰუკები PSP/KYC: HMAC + mTLS, ვიწრო IP-allow სია, anti-replay ('X-Timestamp', ფანჯარა ± 5 წთ).

14) ანტიპატერები

ერთი უნივერსალური captcha „ყველგან და ყოველთვის“ არის მაღალი FP/კონვერტაციის ვარდნა.
მხოლოდ ქცევითი/მოწყობილობის სიგნალების გარეშე მხოლოდ ქცევითი ლიმიტი.
„ნედლეული“ ანაბეჭდების შენახვა და PII შეუზღუდავია.
ახალი პოლიტიკოსისთვის shadow-progon- ის არარსებობა.
სრული ნდობა გარეგანი „რეპუტაციის“ ეტიკეტებზე საკუთარი ნამდვილობის გარეშე.
კლიენტზე გადაწყვეტილების მიღება (JS/მობილური SDK) სერვერის შემოწმების გარეშე.

15) წესებისა და ფსევდო კოდების მაგალითები

15. 1 კომპოზიციური წესი (ნამდვილი დრო)

pseudo score = 0 if ip_asn in bad_asn_list then score += 0. 5 if device_age < 1d and route in {login, withdraw} then score += 0. 3 if velocity("login:account", 5m) > 10 then score += 0. 3 if geovelocity(last_login_loc, current_loc) > 800km/h then score += 0. 2 decision = score>=0. 9? "deny": score>=0. 7? "challenge": "allow"

15. 2 ობლიგაციების გრაფიკი (მრავალ ანგარიში)

edge(accountA, deviceX)
edge(accountB, deviceX)
edge(accountB, cardY)
edge(accountC, cardY)
Threshold by common nodes → investigation/deny bonus

16) მზადყოფნის სიის სია

• მრავალ დონის არქიტექტურა: Edge - Risk API - App, მოვლენების ნაკადი.
• სიგნალები: ქსელი, მოწყობილობა, ქცევა, შინაარსი, გადახდა; PII- ის მინიმიზაცია.
• Velocity/GCRA კლავიშებზე ip/device/account/payment, მოცურების ფანჯრები.
• გადაწყვეტილებები: allow/deny/challenge/throttle; გადაწყვეტილებების ქეში TTL- სთან; ჩელენჯის ფაქტების შენახვა.
• ჩელენჯი: captcha/PoW/OTP/WebAuthn; დინამიური სირთულე.
• Risk API: SLA <100 ms, ქეში, დეგრადაცია „მინიმალური უსაფრთხო“ რეჟიმში.
• დაკვირვება: მეტრიკა, FP/FN, დაშბორდები, ალერტები; ბიზნეს მეტრიკა (chargeback/bonus-abuse).
• Shadow → canary → enforce; ესკალაციისა და უკან დახევის ფლეიბუსები.
• ვებჰუკი PSP/KYC: HMAC + mTLS + anti-replay + allow-list.
• რეგიონალური მოთხოვნები და TTL მგრძნობიარე მონაცემებისთვის.

17) TL; DR

ააშენეთ ფენიანი დაცვა: ადრეული edge ფილტრები და ჩელენჯები, ცენტრალიზებული Risk API + ML წესებით და მოვლენების ნაკადი უკუკავშირისთვის. გამოიყენეთ velocity ლიმიტები, ქსელის/მოწყობილობის/ქცევის სიგნალები, დინამიური გამოწვევა (captcha/PoW/OTP/WebAuthn). მიიღეთ გადაწყვეტილებები allow/deny/challenge/throttle, გაზომეთ FP/FN და ბიზნეს ეფექტი, გადაიტანეთ shadow/canary საშუალებით. გადახდის/ბონუსის ბილიკებისთვის - ცალკეული გამკაცრებული პროფილები და კავშირი KYC/AML- სთან.