Soʻrovlarning imzosi va verifikatsiyasi

So’rovning imzosi jo’natuvchining haqiqiyligini va tarkibning yaxlitligini isbotlaydi. TLS (kanalni himoya qiluvchi) dan farqli oʻlaroq, amaliy imzo har bir xabarni tekshiriladigan va proksi, kesh va kechiktirilgan yetkazib berishga chidamli qiladi.

1. Autentlik (kim yuborgan) va yaxlitlik (o’zgarmagan).

2. Takrorlanmaslik (repleylardan himoya qilish).

3. Transportdan ajratish (HTTP, navbatlar, vebxuklar ustida ishlaydi).

4. Auditorlik tekshiruvi (bir necha oydan keyin takrorlanadigan tekshiruv).

1) Tahdidlar modeli (minimal)

Yo’lda tana/sarlavhalarni almashtirish.
Replay (qonuniy so’rovni takrorlash).
Imzo sarlavhalari uchun Downgrade/strip.
Integratsiya sirlarini o’g "irlash.
Sinxron boʻlmagan soatlar (clock skew) va uzun navbatlar.

2) Ibtidoiy tanlash

HMAC (simmetriya): oddiy va tez, kalit har ikki tomonda saqlanadi. B2B vebxuklari va ichki API uchun mos keladi.
RSA/ECDSA (asimmetriya): joʻnatuvchida shaxsiy kalit, oluvchida ochiq. Ochiq integratsiyalashuv uchun va sirni baham ko’rmaslik muhim bo’lganda mos keladi.
mTLS: transport darajasida o’zaro autentifikatsiya qilish; ko’pincha tananing NMAS/imzosi bilan birlashtiriladi.
JWT/JWS: bearer-tokenlar va o’zini o’zi ta’minlaydigan tamg’alar uchun qulay; tanani imzolash uchun + JWS Detached/HTTP Message Signatures dan foydalanish yaxshiroqdir.
HTTP Message Signatures (tanlangan soʻrov qismlarining imzosi): REST uchun zamonaviy yondashuv.

Tavsiya: vebxuklar uchun - HMAC + timestamp + nonce + tanani kanonikatsiya qilish; ommaviy API uchun - HTTP Message Signatures yoki JWS; xavf yuqori bo’lganda - mTLS qo’shing.

3) Kanonikalizatsiya (aynan nimani imzolaymiz)

Ikki tomon tomonidan bir xil tarzda tiklanadigan determinatsiya qilingan satrni imzolash kerak.

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 parametrlarining tartibi va yoʻlini normallashtiring.
• Boʻshliqlar/unikod/registr - tuzating (masalan, lower-case sarlavhalar, trim).
• Katta tanalar - «bo’lgani kabi» yoqish o’rniga (Digest) xesh qiling.

4) Sarlavhalar formati

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)"

Bu yerda’kid ’/’ keyId’sizga reyestrdan kalitni tanlash imkonini beradi (rotatsiyaga qarang).

5) Qabul tomonida verifikatsiya qilish

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 qiyoslash HMAC, saqlash’nonce ’/’ (ts, event_id)’tezkor KV (TTL ≥ yetkazib berish oynasi).

6) Anti-replay va derazalar

Timestamp + Nonce:’± Δ’dan katta boʻlgan soʻrovlarni (masalan, 5 daqiqa) va ushbu oynadagi nonce takrorlarini rad eting.
Vebxuklar uchun: barqaror’event _ id’va inbox jadvalidan foydalaning - bu faqat nonce’dan ishonchliroq.
Qayta yetkazib berish (retraj) yangilarini emas, balki xuddi shu ts/nonce/event_id foydalanishi kerak.

7) Multi-tenant va hududlar

per tenant/region kalitlarini saqlang:’kid = <tenant>: <region>: <key _ id>’.
Maxfiy pullar va limitlarni ajrating; data residency.
Sarlavhalarda/kanonikalizatsiyada’X-Tenant’va mintaqani ko’rsating - bu tekshirilayotgan kontekstning bir qismidir.

8) Kalitlarni boshqarish va rotatsiya

Kalitlar reyestri (KMS/Vault):’kid’, turi, algoritmi, maqomi (’active’,’deprecating’,’retired’),’valid _ from/valid _ to’.
Dual-secret: joriy va keyingi kalitlarni bir vaqtda saqlang (qabul qilgich ikkalasini ham qabul qiladi).
Jadval va voqea bo’yicha rotatsiya (murosaga keltirish).
Key pinning (iloji boricha) va kalitlar materiallariga kirishni cheklash.
Kalitlar va ular bilan ishlash uchun foydalanish daftarlari.

9) mTLS va OAuth bilan kombinatsiya

mTLS sertifikat darajasida kanalni va «siz kimsiz» ni tekshiradi.
Imzo xabarni himoya qiladi (proksi/kessi/navbatlar orqali foydalidir).
OAuth/JWT autentifikatsiya/avtorizatsiyani to’ldiradi, lekin o’z-o’zidan tananing yaxlitligini kafolatlamaydi (agar uni kanonikalizatsiyada imzolamasangiz).
Eng yaxshi amaliyotlar: mTLS + tana imzosi (Digest) + HMAC/ECDSA + qisqa’ts’- interval.

10) Xatolar va javoblar kodlari

’401 SIGNATURE_INVALID' - noto’ g "ri imzo/algoritm.
’401 KEY_REVOKED' -’ kid’haqiqiy emas/muddati o’tgan.
’400 TIMESTAMP_OUT_OF_RANGE' - soat/oyna.
’409 NONCE_REPLAYED' - takrorlash aniqlandi.
’400 DIGEST_MISMATCH' - tanasi o’ zgartirilgan.
’415 UNSUPPORTED_ALGORITHM' - hal etilmagan’ alg.
’429 TOO_MANY_ATTEMPTS' - kalit/tenant bo’ yicha trottling.

Mashinada oʻqiladigan’error _ code’ga aniq sababni teping; sirlarni/kanonikalizatsiyani «avvalgidek» qaytarmang.

11) Kuzatuv va audit

• `verify_p95_ms`, `verify_error_rate`, `digest_mismatch_rate`, `replay_blocked_rate`, `alg_usage{hmac,ecdsa}`, `clock_skew_ms`.
• Loglar (tarkibiy):’kid’,’alg’,’tenant’,’region’,’ts’,’nonce’,’digest _ hash’,’decision’,’reason’.
• Treysing:’signature’atributlari. kid`, `signature. alg`, `signature. ts_skew`.
• Audit: rotatsiyalar, ruxsatnoma kalitlari va bayroqlaridan foydalanishning o’zgarmas jurnali.

12) Unumdorlik

Tanani striming bilan xeshlang (xotirada saqlamang).
Qisqa TTL va nogironlik bilan’kid’orqali ochiq kalitlarni kesh qiling.
edge/gateway’da oldindan tekshirish (ts/nonce/format).
HMAC ECDSA dan tezroq; ECDSA tashqi integratsiyalar va «ajralmas» kalitlar uchun qulaydir.

13) Test sinovi

Fikstura to’plamlari: bir xil so’rovlar → bir xil kanonikalizatsiya/imzo; «iflos» bo’shliqlar/query/sarlavhalar tartibi → barqaror.
Negative: notoʻgʻri’kid/alg’, modifikatsiyalangan jism/host, takrorlash nonce, eskirgan ts, clock skew.
Property-based: har qanday ekvivalent soʻrovlar bitta canonical satrni beradi.
Interop: kross-til tekshiruvi (Go/Java/Node/Python).
Chaos: kechikishlar, retralar, «uchish» kalitini almashtirish.

14) Pleybuklar (runbooks)

1. ’SIGNATURE _ INVALID’

Kalitlar rotatsiyasini, rassinxron clock, joʻnatuvchida kanonikatsiya oʻzgarishlarini tekshirish.
Eski’kid’uchun vaqtincha’dual-accept’ni yoqish, sherikni xabardor qilish.

2. ’REPLAYED’ ning o’sishi

Nonce saqlash TTL ni kattalashtirish, retraynerlarni joʻnatuvchida tekshirish, clock skew ni tekshirish.
Foydalanuvchi IP/ASNni edge bilan yopish.

3.’DIGEST _ MISMATCH’ommaviy

Proksi/siqish/sarlavhalarni qayta yozishni tekshirish; kanonikalizatsiya versiyasini qayd etish.
Tana/sarlavhalarni buzayotgan vositachilarni oʻchirish.

4. Kalitni buzish

Darhol revoke’kid’,’next _ kid’ga tarjima qilish, barcha sirlarni/tokenlarni qayta tiklash, kirish auditi.

15) Tipik xatolar

«Tana qismi» yoki JSONni tartib belgilamasdan imzolash → Maydonlarni almashtirish zaifligi.
’Digest’ → proksi yoʻqligi tanani sezmasdan oʻzgartirishi mumkin.
’ts’ ning uzun oynasi nonce → ochilgan.
Maxfiylikni KMS/Vault’siz muhit oʻzgaruvchisida saqlash.
Imzoni taqqoslash constant-time emas.

’host ’/’ path’ ni kanonikallashtirishda eʼtiborsiz qoldirish

Kid’ni turli tenantlar va mintaqalarga aralashtirish.

16) Sotishdan oldingi chek-varaq

• Kanonikalizatsiya formati aniqlandi (method, path + query, content-type, Digest, ts, nonce, host, tenant).
• HMAC/ECDSA s’kid’, kalitlar reyestri va dual-secret amalga oshirildi.
• Anti-replay (nonce + ts) va vebxuk inbox/event_id saqlash kiritilgan.
• Xato kodlari/retraj siyosati va trottling per tenant/key moslashtirilgan.
• Kuzatilganlik: verify metrikasi, loglar, trastirovka, portlash uchun alertlar.
• Kalitlar rotatsiyasi avtomatlashtirilgan; audit va kirish huquqlari cheklangan.
• Kanonikalizatsiya va tillararo moslik uchun test to’plamlari.
• 3-4 tilda va fiksturalarda namunali integratorlar uchun hujjatlar.
• mTLS sezgir integratsiyalar uchun yoqilgan; JWT faqat tana imzosini almashtirish uchun ishlatilmaydi.

Xulosa

So’rovlarning imzosi va verifikatsiyasi «bitta sarlavha» emas, balki aniq kanonikalizatsiya, qisqa vaqt oynalari, anti-reple, kalitlarning rotatsiyasi va kuzatish fanidir. Barcha integratsiyalar (API va vebxuklar) uchun yagona standartni yarating,’kid ’/KMS’dan foydalaning, rotatsiya paytida ikkita kalitni qabul qiling va konturlaringiz o’zgarishlarga chidamli, oldindan aytib bo’ladigan va audit uchun qulay bo’ladi.