მოთხოვნის ხელმოწერა და გადამოწმება

მოთხოვნის ხელმოწერა ამტკიცებს გამგზავნის ნამდვილობას და შინაარსის მთლიანობას. TLS- სგან განსხვავებით (რომელიც იცავს არხს), გამოყენებითი ხელმოწერა თითოეულ შეტყობინებას ამოწმებს და გამძლეა მარიონეტული, ქეში და გადავადებული მიწოდებისთვის.

1. ავთენტურობა (ვინც გაგზავნა) და მთლიანობა (არ შეცვლილა).

2. უნიკალურობა (დაცვა რეფლექსებისგან).

3. ტრანსპორტიდან ნაგავი (მუშაობს HTTP, რიგები, ვებჰუკები).

4. აუდიტის შემოწმება (თვეების შემდეგ რეპროდუცირება).

1) მუქარის მოდელი (მინიმალური)

სხეულის/სათაურების შეცვლა გზის გასწვრივ.
Replay (ლეგიტიმური მოთხოვნის განმეორება).
Downgrade/ხელმოწერის სათაურები.
ინტეგრაციის საიდუმლოებების ქურდობა.
არათანაბარი საათი და გრძელი ხაზები.

2) პრიმიტიული არჩევანი

HMAC (სიმეტრია): მარტივი და სწრაფი, გასაღები ინახება ორივე მხარეს. შესაფერისია B2B ვებჰუკებისა და შიდა API- სთვის.
RSA/ECDSA (ასიმეტრია): პირადი გასაღები გამგზავნისგან, მიმღების საჯარო. შესაფერისია ღია ინტეგრაციისთვის და როდესაც მნიშვნელოვანია საიდუმლოების გაზიარება.
mTLS: ურთიერთგამომრიცხავი ტრანსპორტის დონეზე; ხშირად შერწყმულია NMAS/სხეულის ხელმოწერასთან.
JWT/JWS: მოსახერხებელია bearer ნიშნების და თვითკმარი სტიგმებისთვის; სხეულის ხელმოწერისთვის უმჯობესია გამოიყენოთ + JWS Detached/HTTP მესიჯი Signatures.
HTTP მესიჯი Signatures (მოთხოვნის არჩეული ნაწილების ხელმოწერა): თანამედროვე მიდგომა REST- სთვის.

რეკომენდაცია: ვებჰუკებისთვის - HMAC + timestamp + nonce + სხეულის კანონიზაცია; საზოგადოებრივი API- სთვის - HTTP მესიჯი Signatures ან JWS; მაღალი რისკებით - დაამატეთ mTLS.

3) კანონიკალიზაცია (რას ვაწარმოებთ)

თქვენ უნდა მოაწეროთ დეტერმინის სტრიქონი, რომელიც თანაბრად აღდგენილია ორივე მხარის მიერ.

method \n path_with_query_normalized \n content-type \n digest: SHA-256=BASE64(SHA256(body)) \n x-ts: <unix    iso> \n x-nonce: <uuid> \n host \n x-tenant: <tenant_id> \n

canonical = join("\n", fields)
signature = HMAC(secret, canonical)  # или ECDSA_sign(private_key, canonical)

• ნორმალიზებული ბილიკი და query პარამეტრების შეკვეთა.
• ხარვეზები/უნიკოდი/რეესტრი - დაფიქსირდეს (მაგალითად, lower-case სათაურები, trim).
• დიდი სხეულები - ჰალსტუხი (Digest) და არა „როგორც არის“.

4) სათაურების ფორმატი

X-Signature-Alg: hmac-sha256
X-Signature: v1=hex(hmac),ts=1730379005,nonce=550e8400-e29b-41d4-a716-446655440000,kid=prov_42
Digest: SHA-256=BASE64(SHA256(body))
X-Tenant: brand_eu

Signature: keyId="prov_42", alg="ecdsa-p256-sha256",
ts="2025-10-31T12:30:05Z", nonce="550e...", headers="(request-target) host digest x-tenant",
sig="BASE64(raw_signature)"

სადაც 'kid '/' keyId' საშუალებას გაძლევთ აირჩიოთ გასაღები რეესტრიდან (იხ. როტაცია).

5) გადამოწმება მიმღებ მხარეს

python def verify(request):
1) Basic assert abs (now () - request. ts) <= ALLOWED_SKEW  # напр., 300 с assert not replayed(request. nonce, window = TTL) # store nonce/ts in KV

2) Restore canonical canonical = build_canonical (
method=request. method,
path=normalize_path(request. path, request. query),
content_type=request. headers["content-type"],
digest=hash_body(request. body),
ts=request. ts,
nonce=request. nonce,
host=request. headers["host"],
tenant=request. headers. get("x-tenant")
)

3) Get the key key = key_registry. get(request. kid) # secret (HMAC) или public key (ECDSA)

4) Verify if request signature. alg. startswith("hmac"):
ok = hmac_compare(key. secret, canonical, request. signature)
else:
ok = asym_verify(key. public, canonical, request. signature)

5) Solution if not ok: return 401, "SIGNATURE_INVALID"
return 200, "OK"

Constant time შედარება HMAC, შენახვა 'nonce '/' (ts, event _ id)' სწრაფი KV (TTL - მიწოდების ფანჯარა).

6) ანტი-რეფლი და ფანჯრები

Timestamp + Nonce: გადახრა მოთხოვნა უფრო ძველია, ვიდრე 'p' (მაგ., 5 წუთი) და ამ ფანჯარაში nonce გამეორება.
ვებჰუკებისთვის: გამოიყენეთ სტაბილური 'event _ id' და inbox ცხრილი - ეს უფრო საიმედოა, ვიდრე მხოლოდ nonce.
განმეორებითი მიწოდება (retrai) უნდა გამოიყენოს იგივე ts/nonce/event _ id, ვიდრე ახლის წარმოქმნა.

7) მულტფილმები და რეგიონები

შეინახეთ გასაღებები per tenant/region: 'kid = <tenant>: <region>: <key _ id>'.
გაიზიარეთ საიდუმლოებებისა და ლიმიტების აუზები; დაიცავით მონაცემთა დათმობა.
სათაურებში/კანონიკალიზაციაში მიუთითეთ „X-Tenant“ და რეგიონი დადასტურებული კონტექსტის ნაწილია.

8) კლავიშების მართვა და როტაცია

გასაღებების რეესტრი (KMS/Vault): 'kid', ტიპი, ალგორითმი, სტატუსი ('აქტიური', 'deprecating', 'retired'), 'valid _ from/valid _ to'.
ორმაგი საიდუმლო: ერთდროულად შეინარჩუნეთ მიმდინარე და შემდეგი გასაღები (მიმღები იღებს ორივე).
როტაცია გრაფიკით და მოვლენით (კომპრომისი).
კეი პინინგი (თუ ეს შესაძლებელია) და კლავიშების მასალებზე წვდომის შეზღუდვა.
გასაღებების დაშვების ლოგოები და მათთან მოქმედებები.

9) კომბინაცია mTLS და OAuth

mTLS ამოწმებს არხს და ვინ ხართ სერტიფიკატის დონეზე.
ხელმოწერა იცავს შეტყობინებას (სასარგებლოა მარიონეტული/კეში/რიგის საშუალებით).
OAuth/JWT ავსებს ავთენტიფიკაციას/ავტორიზაციას, მაგრამ თავისთავად არ იძლევა გარანტიას სხეულის მთლიანობას (თუ ის არ არის ხელმოწერილი კანონიკალიზაციაში).
საუკეთესო პრაქტიკა: mTLS + სხეულის ხელმოწერა (Digest) + HMAC/ECDSA + მოკლე 'ts' - ინტერიერი.

10) შეცდომები და პასუხების კოდები

'401 SIGNATURE _ INVALID' - არასწორი ხელმოწერა/ალგორითმი.
'401 KEY _ REVOKED' - 'kid' არასწორი/ვადაგადაცილებული.
'400 TIMESTAMP _ OUT _ OF _ RANGE' - საათი/ფანჯარა.
'409 NONCE _ REPLAYED' - აღმოაჩინეს რეპლიკა.
'400 DIGEST _ MISMATCH' - სხეული შეიცვალა.
'415 UNSUPORTED _ ALGORITHM' - გადაუჭრელი 'alg'.
'429 TOO _ MANY _ ATTEMPTS' - გასაღები/ტენანტი.

დალიეთ ზუსტი მიზეზი მანქანაში წაკითხული 'error _ code "; ნუ დააბრუნებთ საიდუმლოებებს/კანონიკალიზაციას „როგორც არის“.

11) დაკვირვება და აუდიტი

• `verify_p95_ms`, `verify_error_rate`, `digest_mismatch_rate`, `replay_blocked_rate`, `alg_usage{hmac,ecdsa}`, `clock_skew_ms`.
• Logs (სტრუქტურული): 'kid', 'alg', 'tenant', 'region', 'ts', 'nonce', 'digest _ hash', 'decision', 'reason'.
• ტრეისი: ატრიბუტები 'signature. kid`, `signature. alg`, `signature. ts_skew`.
• აუდიტი: როტაციების უცვლელი ჟურნალი, გასაღებების და დაშვების დროშების გამოყენება.

12) პროდუქტიულობა

გაუფრთხილდით სხეულს ნაკადით (არ შეინარჩუნოთ მეხსიერება).
მოკლე TTL- ით 'kid' - ის საზოგადოებრივი გასაღებები და ღონისძიების ინვალიდობა.
edge/gateway- ზე გაიტანეთ წინასწარი შემოწმებები (ts/nonce/ფორმატი).
HMAC უფრო სწრაფია, ვიდრე ECDSA; ECDSA უფრო მოსახერხებელია გარე ინტეგრაციისთვის და „განუყოფელი“ გასაღებებისთვის.

13) ტესტირება

ფიქსატორების ნაკრები: იგივე მოთხოვნები - იგივე კანონიზაცია/ხელმოწერა; „ბინძური“ ხარვეზები/query/სათაურების შეკვეთა სტაბილურია.
Negative: არასწორი 'kid/alg', შეცვლილი სხეული/host, განმეორება nonce, მოძველებული ts, clock skew.
Property-based: ნებისმიერი ეკვივალენტური მოთხოვნა იძლევა ერთ canonical ხაზს.
Interop: ჯვარედინი ენის შემოწმება (Go/Java/Node/Python).
ქაოსი: შეფერხებები, ჭიდაობა, გასაღების შეცვლა „ფრენაზე“.

14) Playbooks (runbooks)

1. SIGNATURE _ INVALID '

შეამოწმეთ გასაღებების როტაცია, clock rassinchron, გამგზავნის კანონიზაციის ცვლილებები.
დროებით ჩართეთ 'dul-accept' ძველი 'kid- ისთვის, აცნობეთ პარტნიორს.

2. ზრდა 'REPLAYED'

გაზარდეთ TTL nonce- ის შენახვა, შეამოწმეთ გამგზავნისგან ხელახალი მატარებლები, შეამოწმეთ clock skew.
დაბლოკეთ ბოროტად გამოყენების IP/ASN edge- ზე.

3. 'DIGEST _ MISMATCH' მასიურად

შეამოწმეთ მარაგი/შეკუმშვა/სათაურების გადაწერა; ჩაწერეთ კანონიკალიზაციის ვერსია.
გამორთეთ შუამავლები, რომლებიც არღვევენ სხეულს/სათაურებს.

4. გასაღების კომპრომისი

დაუყოვნებლივ revoke 'kid', თარგმნეთ 'შემდეგი _ kid ", გადააკეთეთ ყველა საიდუმლოება/ნიშანი, წვდომის აუდიტი.

15) ტიპიური შეცდომები

ხელი მოაწერეთ „სხეულის ნაწილს“ ან JSON- ს შეკვეთის დაფიქსირების გარეშე - დაუცველობა ველების გადაკეთებაზე.
'Digest' - ის არარსებობამ შეიძლება შეცვალოს სხეული შეუმჩნეველი.
გრძელი ფანჯარა 'ts' nonce- ს გარეშე ღიაა.
შეინახეთ საიდუმლოებები ცვლადი გარემოში KMS/Vault- ის გარეშე.
ხელმოწერის შედარება არ არის თანმიმდევრული დრო.
'host '/' path' უგულებელყოფა გადამყვანზე თავდასხმის კანონიკალიზაციაში.
აურიეთ „kid“ სხვადასხვა ტენანტებსა და რეგიონებს.

16) ჩეკის სია გაყიდვამდე

• განისაზღვრება კანონიკალიზაციის ფორმატი (method, path + query, შინაარსის ტიპი, Digest, ts, nonce, host, tenant).
• ხორციელდება HMAC/ECDSA 'kid' - ით, გასაღებების რეესტრი და ორმაგი საიდუმლო.
• ჩართულია ანტი-მიმღები (nonce + ts) და inbox/event _ id შენახვა ვებჰუკებისთვის.
• შეცდომების კოდი/რეაგირების პოლიტიკა და trottling per tenant/key.
• დაკვირვება: მეტრიკა verify, ლოგოები, ტრეკერი, ალერტები.
• კლავიშების როტაცია ავტომატიზირებულია; აუდიტი და დაშვების უფლებები შეზღუდულია.
• ტესტის ნაკრები კანონიკალიზაციისა და ინტერ-ენობრივი თავსებადობისთვის.
• დოკუმენტაცია ინტეგრატორებისთვის, მაგალითით 3-4 ენაზე და ფიქსატორებით.
• mTLS შედის მგრძნობიარე ინტეგრაციისთვის; JWT გამოიყენება მხოლოდ როგორც დამატება, არა სხეულის ხელმოწერის შეცვლა.

დასკვნა

მოთხოვნის ხელმოწერა და გადამოწმება არ არის „ერთი სათაური“, არამედ დისციპლინა: მკაფიო კანონიკალიზაცია, მოკლე დროში ფანჯრები, ანტისეპტიკური, გასაღების როტაცია და დაკვირვება. ააშენეთ ერთი სტანდარტი ყველა ინტეგრაციისთვის (API და ვებჰუკი), გამოიყენეთ 'kid '/KMS, მიიღეთ ორი გასაღები როტაციის დროს, და თქვენი კონტურები გახდება მდგრადი ჩანაცვლებისთვის, პროგნოზირებადი და მოსახერხებელი აუდიტისთვის.