API უსაფრთხოება და მოთხოვნის ფილტრაცია

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

API არის პლატფორმის გარე და შიდა საზღვარი. ავთენტიფიკაციის, ავტორიზაციის, მოვალეობის შემსრულებლის ან მოთხოვნის ნორმალიზაციის ნებისმიერი შეცდომა გადაიქცევა დაუცველების ექსპლუატაციაში (BOLA/IDOR, injection, SSRF, მასობრივი დაბრკოლებები, რესურსების ამოწურვა). მიზანი: შექმნას მრავალ დონის დაცვა პერიმეტრიდან ბიზნეს წესებამდე, გაზომილი SLO და რისკების კონტროლი.

2) ინვენტარიზაცია და API კლასიფიკაცია

API კატალოგი: ყველა სერვისის/endpoint- ის რეესტრი, მეპატრონეები, ვერსიები, მომხმარებელთა ტიპები (ვებ, მობილური, პარტნიორები), რეჟიმი (საჯარო/პარტნიორი/შიდა), PII/ფინანსური.
კრიტიკა: მაღალი (ფინანსური ოპერაციები/ავტორიზაცია), საშუალო (პროფილის კითხვა), დაბალი (საზოგადოებრივი ცნობარი).
თავდასხმის ზედაპირი: REST, GraphQL, GRPC, WebSocket, webhooks.
სტატუსი: staging/staging/experimental, დეპრესიის პოლიტიკა, ტოკენის/კლავიშების სიცოცხლის ხანგრძლივობა.
Shadow/მიტოვებული API: ლოგების ინგრედიენტების აღმოჩენა, eBPF/Service Mesh ტელემეტრია, დირექტორიასთან შედარება.

3) საფრთხის მოდელი (მოკლედ)

იდენტიფიკაცია: ტოქსინების ქურდობა, სესიის დაფიქსირება, MitM, replay.
საავტორო უფლებები: BOLA/IDOR, ჰორიზონტალური/ვერტიკალური ესკალაცია.
შეყვანა: ინექციები (SQL/NoSQL/LDAP), შაბლონის/სერილიზაციის, path traversal, სათაურები.
ტრაფიკი: DDoS/L7 fluds, ნელი მოთხოვნები, ფანტომური ჭიდაობა.
ინტეგრაცია: უსაფრთხო ვებოქსი, SSRF URL პარამეტრების საშუალებით, ფაილების/სკანერების დატვირთვით.
ლოგიკა: ბონუსების ბოროტად გამოყენება, რბოლა, იდემპოტენტურობის შეუსაბამობა.

4) უსაფრთხოების ძირითადი სტანდარტი (მინიმალური)

1. TLS 1. 2 + ყველგან; HSTS; სუსტი შიფრები გამორთულია.
2. ავთენტიფიკაცია: OAuth2/OIDC მომხმარებლებისთვის, mTLS/ან HMAC - სერვისული მომსახურება.
3. ავტორიზაცია: ცენტრალიზებული PDP (RBAC/ABAC), ტესტირება ობიექტის დონეზე (BOLA).
4. შესაბამისობა: მკაცრი სქემა (OpenAPI/JSON Schema/Protobuf), უარყოფა ზედმეტი სფეროებში.
5. ლიმიტები: rate/= tas + burst, per-cliver/per-IP/pe-token.
6. Idempotention write ოპერაციებში, გამეორების/რბოლებისგან დაცვა.
7. WAF/გეითვეის ფილტრაცია: ბილიკების/სათაურების ნორმალიზაცია, დენის ფურცლები, payload ანტიბიოტიკების ბლოკი.
8. საიდუმლოებები: KMS/Vault, კლავიშების/სერთიფიკატების როტაცია, გაჟონვის კონტროლი.
9. დაკვირვება: ტრეკინგი, უსაფრთხოების აუდიტის ლოგოები (ვინ/რა/როდის/შედეგი), ალერტები.
10. პროცედურები: playbook ინციდენტები, ტესტის შემთხვევები და რეგულარული პენტესტები/DAST.

5) ტოქსინების ავთენტიფიკაცია და მართვა

OAuth2/OIDC: მოკლე წვდომის ნიშნები, რეფრესი მკაცრად OIDC- ს მიხედვით; audience/issuer/exp შემოწმებულია gateway- ზე.
JWT: RS256/ES256; კლაიმების მინიმალური ნაკრები; 'nbf/exp/aud' სავალდებულოა; PII შენახვის აკრძალვა. გასაღებების როტაცია JWKS- ით.
DPOP/PoP: ნიშნის დაკავშირება კლიენტის ღილაკზე, რათა შემცირდეს replay/ქურდობის რისკი.
mTLS შიდა სისტემებისა და სანდო პარტნიორებისთვის (სერტიფიკაცია CN/SAN, CRL/OCSP).
HMAC (ხელმოწერები): დეტერმინის კანონიზაცია (მეთოდი + გზა + timestamp + nonce + body-hash); დასაშვები დროის ფანჯარა (± 300s).
ბრაუზერის სესიები: SameSite = strict/lax, Only, Secure; დაცვა CSRF- სგან (ორმაგი წყალქვეშა/სახელმწიფო ნიშნები).
მომხმარებელთა საცავი: მობილური - უსაფრთხო საცავი (Keychain/Keystore), დაცვა დრაკონისგან, სერთიფიკატების დაფა.

6) ავტორიზაცია (BOLA-first)

Object-level: თითოეული ოპერაცია ამოწმებს კონკრეტული რესურსის უფლებას (resource owner/scope/ატრიბუტები).
RBAC/ABAC: როლები + ატრიბუტები (ქვეყანა, სეგმენტი, რისკის ლიმიტები, KYC დონე).
პოლიტიკოსები: deny-by-default; აშკარა ალოუ; პოლიტიკის ვერსია; ტესტები უარყოფითი შემთხვევებისთვის.
გადაწყვეტილებების ქეში: ადაპტირებული TTL + ინვალიდობა როლების/სეგმენტების შეცვლისას.

7) მოთხოვნების ფილტრაცია და ნორმალიზაცია (გეითვეიზე/WAF)

ნორმალიზაცია: განმეორებითი სლაზების შეკუმშვა, აკრძალვა '../', დეკოდირება ერთხელ, ჭრის ხარვეზები/ნულოვანი ბაიტი.
სათაურები: allow-list ('Host', 'Content-Type', 'Accept', 'Authorization', 'Date', 'Idempotence-Key', აუცილებელი ტრეკის სათაურები).
მეთოდები: 'GET/HEAD' სხეულის გარეშე; 'POST/PUT/PATCH' - 'განაცხადის/json' ტიპის ან მკაცრად ნებადართული.
ზომები: max-body, max-headers, max-path; early-reject 413/431.
ფაილები: MIME დამადასტურებელი, ანტივირუსული/sandbox, აქტიური შინაარსის აკრძალვა, სურათების გადამუშავება/შენარჩუნება.
URL გადამისამართება/ფეტჩი: SSRF ბლოკი (დენის პირადი რანგები/მეტადატა IP, სქემა მხოლოდ 'https', დომენების ალოუს სია).
SQL/NoSQL ნიმუშები: ინექციების ხელმოწერები WAF rule sets + სერვერის მოთხოვნის პარამეტრიზაციით.

სათაურების პოლიტიკის მაგალითი (ფსევდო ფორმატი)

deny_headers: ["X-Forwarded-Proto","X-Original-URL","Proxy-Connection","Destination"]
require_headers: ["Authorization" (для protected), "Content-Type" (для write)]
strip_duplicates: true max_header_count: 32 max_header_size: 16KB

8) ლიმიტები, კვოტები და ანტიბიოტიკების დაცვა

Rate limiting: token-bucket/ leaky-bucket; დონეები - per IP, per API key, per user, porg.
T tas: ყოველდღიური/ყოველთვიური, ცალკეული write/გაფართოების მეთოდებისთვის.
ადაპტაცია: დინამიური გამკაცრება ანომალიებში (sudden burst/credential stuffing).
Slow-loris/slow-POST: კითხვის დრო/keep-alive, პარალელური ნაერთების შეზღუდვა.
ანტიბოტი: მოწყობილობები-fingerprint, ქცევითი ნიშნები, proof-of-work/capch გაზრდილი რისკი, tors/მარიონეტული ქსელების სია.
IP კონტროლი: გეო/ASN ფილტრები, „ბინძური“ ქვესათაურების დენის ფურცლები, ალოუ ფურცლები პარტნიორებისთვის/admin პანელებისთვის.

9) შეყვანის მონაცემების და სქემების შესაბამისობა

Fail-closed: ყველაფერი, რაც სქემას არ გადის - 400. ზედმეტი ველები - გადახრა.
ტიპები/დიაპაზონი: ნომრები, თარიღები (UTC/ISO-8601), enum მნიშვნელობები, სტრიქონების სიგრძე, რეგექსტი.
JSON ხარისხი: max-nesting, დიდი მასივების/გასაღებების აკრძალვა, canonical order (სურვილისამებრ).
ბიზნეს ვალდებულება: Idempotenty 'Idempotency-Key'; ანტი-ფროიდის წესები (ოპერაციების სიხშირის ლიმიტები, amount caps).
GraphQL: depth/complexity-limites, allow-listed queries, ple-way საავტორო უფლებები.
GRPC: მკაცრი პროტობუფის სქემები, სავალდებულო ველები, შეტყობინებების ზომების შეზღუდვები.

10) Webhooks და გარე ზარები

ხელმოწერები: HMAC დროული სტამპით/nonce; გადამოწმება დამუშავებამდე; ფანჯარა +/- 5 წთ

ადგილზე მიტანა: ექსპონენციალური პაუზა და ჯიტერი; მაქსის მცდელობები; ღონისძიების ID დედუპლიკაცია.
IP ალოუ-ლისტის მიმწოდებელი; ცალკე დომენი/გზა; მინიმალური ჰოსტინგის დასტის.
პასუხები: 2xx მხოლოდ წარმატებული შიდა ჩაწერის შემდეგ; წინააღმდეგ შემთხვევაში 4xx/5xx გასაგები კოდით.
გამავალი SSRF კონტროლი: callback URL - allow-list, პირადი მისამართების აკრძალვა.

11) საიდუმლოების დაშიფვრა და მართვა

არხში: TLS 1. 2+/1. 3, pinning, მკაცრი შიფრების პოლიტიკა.
დასვენების დროს: BD/ობიექტის საცავის დაშიფვრა, PII/findan- ის ცალკეული გასაღებები.
KMS/Vault: საიდუმლოებების ცენტრალიზებული შენახვა, მოკლე TTL, ავტომატური როტაცია.
გასაღებები და სერთიფიკატები: ცალკეული გარემოსთვის; ემისიის აუდიტი; ლოგებში გაყვანის აკრძალვა.
Token-introspection: offline მიმოხილვის სიები, მოკლე 'exp'.

12) დაკვირვება, აუდიტი და რეაგირება

უსაფრთხოების Logs: ავტორიზაციის მცდელობები/წარმატებები, ავტორიზაციის უარის თქმის, ღონისძიებების განხორციელება, როლების/ლიმიტების შეცვლა.
კვალი: correlation-ID; გარე გამოწვევების ტრეკი.
მეტრიკა: RPS, P95/P99 latency, error-rate კოდებით, წილი 401/403/429, ლიმიტების ჰიტ-ვერსია, ანომალიები.
ალერტები: აურზაური 401/403/429, ზრდა 5xx, ხშირი idempotence კონფლიქტები, გრაფიკის მკვეთრი გადახრები.
Playbooks: გასაღებების/ნიშნების დაბლოკვა, წესების სწრაფი დაბრუნება, დენის სიის დათბობა, მომსახურების მფლობელების შეტყობინება.
Forenzica: საკამათო payload- ის შენარჩუნება (PII- ის უსაფრთხო რედაქტირება), იზოლირებულ სკამზე ფრაგმენტები.

13) შეცდომები და პასუხები კლიენტისთვის

შეცდომების ერთიანი ფორმატი (კოდი, შეტყობინება, ტრეკი, კატეგორია).
გაჟონვის გარეშე: არ გაამჟღავნოთ SQL, ცხრილების სახელები, შიდა იდეები; 403 ნაცვლად „რატომ არა“.
კოდები: 400 (შესაბამისობა), 401 (არ არსებობს ავთენტიფიკაცია), 403 (მართალი), 404 (შენიღბვა), 405/406, 413/429, 500/503.
Retry-Hints: для 429 — `Retry-After`; იდემპოტენტურობისთვის - რჩევა იგივე გასაღებით გამეორებისთვის.

14) არქიტექტურული ნიმუშები

Zero-Trust: mTLS, აშკარა ავტორიზაცია ყველა სერვისს შორის, მინიმალური პრივილეგიები.
API კარიბჭე + WAF + მომსახურება: მოვალეობების გამიჯვნა - პერიმეტრი, L7 პოლიტიკა, შიდა ავთენტიფიკაცია.
Canary/Blue-Green: ფილტრაციის ახალი წესების ეტაპობრივად გადაყრა დაკვირვებით.
Fail-closed: კრიტიკული write- ისთვის - უმჯობესია უსაფრთხოდ უარი თქვან, ვიდრე არასწორი ოპერაციის დაშვება.
Backpressure: რიგები/ბუფერები, circuit breaker, timeouts/budgets.

15) პრაქტიკული წესების მაგალითები (ფსევდო კონფისკაცია)

15. 1 ბილიკებისა და მეთოდების შეზღუდვა

/api/v1/payments:
allow_methods: [POST, GET]
auth: oauth2_required body:
content_type: application/json max_size: 256KB

15. 2 იდემპოტენტობა

require_header: Idempotency-Key (UUIDv4)
store: redis:ttl=24h on_duplicate: return_previous_result

15. 3 მოთხოვნის ხელმოწერა (HMAC)

signature:
scheme: "HMAC-SHA256"
required_headers: ["X-Signature","X-Timestamp","X-Nonce"]
allowed_drift: 300s string_to_sign: METHOD + "\n" + PATH + "\n" + SHA256(body) + "\n" + X-Timestamp + "\n" + X-Nonce

15. 4 SSRF დაცვა

outbound_http:
allowlist_domains: ["kyc. partner. com","psp. example. net"]
block_private_ip: true require_https: true

15. 5 GraphQL ლიმიტი

graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true

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

სეგმენტის ლიმიტები: დამოკიდებულია KUS/ქვეყნიდან/სარისკო პროფილზე.
დროებითი ფანჯრები: ანაბრების/დასკვნების სიხშირის წესები, გარიგებებს შორის „გაცივება“.
პრემიების ანტი-აბიუსი: თანმიმდევრული ბლოკირება ანგარიშზე/მოწყობილობაზე/IP/გადახდის ინსტრუმენტზე.
რეგულატორების მოთხოვნების აუდიტი: მოქმედებებისა და გადაწყვეტილებების ლოგოების შენახვა (KYC/AML), რეტენირების პერიოდები, უცვლელი ჟურნალები.

17) მზადყოფნის საკონტროლო სია

• API- ის სრული კატალოგი და მონაცემთა ნაკადის რუკა (PII/ფინანსები აღინიშნება).
• OpenAPI/Protobuf სქემები, ვალიდაციის ტესტები და კონტრაქტები CI- ში.
• mTLS/HMAC/OAuth2 მორგებულია; მოკლე TTL ნიშნები; კლავიშების როტაცია.
• BOLA ტესტები და ავტორიზაციის უარყოფითი შემთხვევები; ცენტრალიზებული PDP.
• ლიმიტები/კვოტები/ანტი-ბოტი, დაცვა slow-loris- ისგან; IP ფილტრები.
• WAF/გეითვეის წესები ნორმალიზაციის, ინექციური ხელმოწერების შესახებ.
• write ოპერაციების idempotence; დაცვა replay- სგან.
• Webhook ხელმოწერები და ალოუ სია; იზოლირებული endpoints.
• საიდუმლოებები KMS/Vault- ში; დაშიფრული სკამები; ალერტები ანომალიებში.
• Deschbords, alerty, audit-logs; შემუშავებული playbooks ინციდენტები.
• რეგულარული პენტესტი/DAST/SAST, დაუცველთა სიმღერები და პატჩების დაცემით.

18) ანტიპატერები (რაც შეუძლებელია)

ენდობა 'X-Forwarded-' მკაცრი TLS ტერმინალის გარეშე მის პერიმეტრზე.
მიიღეთ თვითნებური „შინაარსის ტიპი“ და „რბილი“ JSON სქემები.
გრძელი JWT გაწვევის/როტაციის გარეშე.
აურიეთ როლები და ბიზნეს წესები კოდში ცენტრალიზებული პოლიტიკოსის გარეშე.
ლოგები საიდუმლოებით/PII; დეტალური 500 შეტყობინება გარეთ.
„დროებითი“ ღია ენდოინები ლიმიტების და ავტორიზაციის გარეშე.

19) ვერსიები და დეპრესია

ვერსიები გზაზე/სათაური; დამხმარე პოლიტიკა (მაგალითად, N-2).
განცხადებები: დეპრესიის დრო, ძველი ვერსიების გამოყენების მონიტორინგი, კონტროლირებადი გამორთვა.
თავსებადობა: კონტრაქტები და მომხმარებელთა/პარტნიორების საცდელი მატრიცები.

20) უსაფრთხოების ტესტირება

სქემების/პოლიტიკის საკონტრაქტო ტესტები, fuzzing შეყვანა, negative auh.
სპექტაკლის პროფილები ლიმიტებით/კვოტებით, დაცვის ტესტი (ქაოსის ტრაფიკი).
Red-team/bug-bounty: BOLA, SSRF სკრიპტები, ხელმოწერები/აბზაცები, GraphQL-complexity.

TL; DR

1. API + მკაცრი სქემების კატალოგი.
2. OAuth2/OIDC მომხმარებლებისთვის, mTLS/HMAC შიგნით.
3. BOLA პერიმეტრი თითოეული რესურსისთვის (ABAC/RBAC).
4. ფილტრაცია: ბილიკების/სათაურების ნორმალიზაცია, ლიმიტები, WAF წესები.
5. Idempotence, ხელმოწერები, დაცვა replay/SSRF.
6. KMS/Vault და საიდუმლოებების როტაცია.
7. დაკვირვება, ალერტები, playbooks.