Հարցումների ստորագրում և հավատարմագրում

Հարցման ստորագրությունը ապացուցում է ուղարկողի իսկությունը և բովանդակության ամբողջականությունը։ Ի տարբերություն TFC-ից (որը պաշտպանում է ալիքը), կիրառական ստորագրությունը յուրաքանչյուր հաղորդագրություն է դարձնում ստուգված և դիմացկուն դեպի մատակարարումը, քեշը և հետաձգված առաքումը։

Նպատակները

1. Իսկությունը (ով ուղարկեց) և ամբողջականությունը (չի փոխվել)։

2. Անհնազանդություն (պաշտպանություն ռեպլեներից)։

3. Տրանսպորտի շեղումը (աշխատում է HTTP-ի, հերթերի, webhuks-ի վերևում)։

4. Վերարտադրողականությունը (վերարտադրված ստուգումը ամիսների ընթացքում)։

1) Սպառնալիքների մոդել (նվազագույն)

Մարմնի/վերնագրերի փոփոխությունը հետևելու ճանապարհին։

Repley (լեգիտիմ հարցման խոհարար)։

Downgrade/strip ստորագրության վերնագրեր։

Գաղտնիքները գողանում են։

Nesinhrone ժամացույցները (clock skew) և երկար գծերը։

2) Պրիմիտիվի ընտրությունը

HMAC (սիմետրիա) 'պարզ և արագ, բանալին պահպանվում է երկու կողմերում։ Հարմար է B2B-webhuks-ի և ներքին API-ի համար։

RSA/ECDSA (ասիմետրիա) 'մասնավոր ուղարկողի բանալին, ով հանրային է ստացողի մոտ։ Հարմար է բաց ինտեգրման համար, և երբ կարևոր է չկիսել գաղտնիքը։

MTSA 'փոխկապակցված վավերացում տրանսպորտի մակարդակում; հաճախ միացված է NMAS/մարմնի ստորագրությամբ։

JWT/JWS: հարմար է bearer-tocens և ինքնաբուխ կլեյմերի համար։ Մարմնի համար ավելի լավ է օգտագործել կանոկալիզացիան + JWS Detached/HTTP Live Signatures։

HTTP Windows Signatures (ռուսական հարցման մասերի ստորագրությունը) ժամանակակից մոտեցում է REST-ի համար։

Առաջարկություն 'Webhuks-ի համար - HMAC + timestamp + nonce + մարմնի կանոնականացում; ՀԱՆՐԱՅԻՆ API-ի համար HTTP Live Signatures կամ JWS-ի համար; բարձր ռիսկերի դեպքում ավելացրեք mTRC։

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-2019 կարգը։

Ալյումինե/unicod/գրանցամատյան - գրեք (օրինակ, lower-case վերնագրեր, trim)։

Մեծ մարմիններ 'հեշիրուրու (Digest), և մի միացրեք «ինչպես կա»։

4) Վերնագրերի ձևաչափը

HMAC-ի օրինակ

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

Ասիմետրիայի օրինակ (ECDPP-256)

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 »/« kim Id» թույլ է տալիս ընտրել կոդերի բանալին (տե՛ ս ռոտացիան)։

5) Որդեգրման կողմը

Prindocod

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"

Constrone Time-ը HMAC-ի համեմատությունը, "nonce '/" (ts, event _ id)" արագ KV (TTL-ն բացատրում է առաքման պատուհանը)։

6) Անտի Ռեպլեյը և պատուհանները

Timestamp + Nonce: շեղեք հարցումները ավելի մեծ «Windows» (օրինակ ՝ 5 րոպե) և nonce կրկնությունները այս պատուհանում։

Webhuks 'օգտագործեք կայուն «event _ id» և inbox-աղյուսակը ավելի հուսալի է, քան միայն nonce-ը։

Կրկնվող առաքումը (retray) պետք է օգտագործի նույն ts/nonce/event _ id-ը, ոչ թե նորերը։

7) Multi Tenant և տարածաշրջանները

Պահեք per ten.ru/region: 'kid = : : ։

Բաժանեք գաղտնիքների և լիմիտների պուլերը։ հետևեք residency-ին։

Վերնագրերում/կանոնական նշեք «X-Tenault» և տարածաշրջանը ստուգված կոնտեքստի մի մասն է։

8) Բանալիների կառավարումը և նավարկումը

System (KMS/Vox): «kid», տիպը, ալգորիթմը, կարգավիճակը («action», «deprecating», «retired»), «valid _ from/valid _ to»։

Dance-secret: Միևնույն ժամանակ պահեք ներկա և հաջորդ բանալին (ընդունիչը վերցնում է երկուսն էլ)։

Ժամանակացույցով և իրադարձությամբ (փոխզիջում)։

Key pinning (հնարավորության դեպքում) և նյութերի հասանելիության սահմանափակումը։

Բաների և նրանց հետ գործողությունների համար։

9) Համադրություն mTSA և OAuth-ի հետ

MTRC-ն ստուգում է ջրանցքը և «ով եք դուք» մրցույթի մակարդակում։

Ստորագրությունը պաշտպանում է հաղորդագրությունը (օգտակար է 108/կեշի/հերթերի միջոցով)։

OAuth/JWT-ը լրացնում է վավերացումը/հեղինակային իրավունքը, բայց ինքնին չի երաշխավորում մարմնի ամբողջականությունը (եթե այն չի ստորագրվում կանոնակարգում)։

Լավագույն փորձարկումները ՝ mTSA + մարմնի ստորագրությունը (Digest) + HMAC/ECDPS + կարճ 'ts' - ինտերվալ։

10) Սխալներ և պատասխաններ

«401 SIGNATURE _ MS ALID» - սխալ ստորագրություն/ալգորիթմ։

«401 KEY _ REVOKED» - «kid» բաղադրիչ/ժամկետանց։

«400 TIMESTAMP _ OUT _ OF _ RANGE» - ժամացույց/պատուհան։

409 NONCE _ REPLAYED "- հայտնաբերվում է խոհարար։

«400 DIGEST _ MISMATCH» - մարմինը փոխված է։

«415 UNSUPSA TED _ ALGORITHM» - անլուծելի «ալգ»։

«429 TOO _ MANY _ ATTEMPSA» - Trottling բանալին/tenantu։

Օգտագործեք ճշգրիտ պատճառը մեքենայական ընթերցվող «error _ code» -ում։ մի վերադարձրեք գաղտնիքները/կանոնականացումը «ինչպես կա»։

11) Դիտողությունն ու աուդիտը

Մետրիկները

`verify_p95_ms`, `verify_error_rate`, `digest_mismatch_rate`, `replay_blocked_rate`, `alg_usage{hmac,ecdsa}`, `clock_skew_ms`.

Լոգները (կառուցվածքային) '«kid», «alg», «tenault», «region», «ts», «nonce», «digest _ hash», «decision», «reason»։

Թրեյսինգը 'ատրիբուտներ' signature։ kid`, `signature. alg`, `signature. ts_skew`.

Աուդիտ ՝ անփոփոխ պարտատոմսեր, դեղորայքներ և դրոշներ։

12) Արտադրողականություն

Քաշիրուզու՞ մ եք մարմինը ստրիմինգով (մի հիշեք)։

Քեշիրուզեք հանրային բանալիներ '«kid» կարճ TTL-ով և հաշմանդամությամբ։

Edge/gateway-ում նախնական ստուգումներ կատարեք (ts/nonce/ձևաչափ)։

HMAC-ը ավելի արագ է, քան ECDLS-ը; ECD.RU-ն ավելի հարմար է արտաքին ինտեգրման և «բաժանման» համար։

13) Թեստավորում

Ֆիքսված հավաքածուներ 'նույն հարցումները համապատասխանում են նույն կանոնականացմանը/ստորագրությանը։ «կեղտոտ» ֆոսֆորները/query/վերնագրերի կարգը կայուն են։

Negative: սխալ «kid/alg», փոփոխված մարմինը/host, nonce, հնացած ts, clock skew։

Property-based: Ցանկացած համարժեք հարցումներ տալիս են մեկ canonical տող։

Interop: քրոս-լեզվական ստուգումներ (Go/Java/Node/Python)։

Chaos 'ձգձգումներ, retray, բանալին փոխելը «ամռանը»։

14) Պլեյբուկի (runbooks)

1. «SIGNATURE _ ALID»

Ստուգել միգրացիայի, ռասինխրոն clock-ի, ուղարկողի կանոնների փոփոխությունը։

Ժամանակավորապես ներառել «dox-accept» հին «kid» -ի համար, տեղեկացնել գործընկերոջը։

2. Աճը 'REPLAYED'

Բարձրացրեք TTL-ը nonce պահեստավորման համար, կրճատեք ուղարկողի վերափոխումները, ստուգեք clock skew-ը։

Արգելափակել չարաշահող IP/ASN edge-ը։

3. «DIGEST _ MISMATCH» զանգվածաբար

Ստուգել/հակադարձ/վերնագրերի վերաշարադրումը; ամրագրել կանոնների տարբերակը։

Անջատել միջնորդները, որոնք խախտում են մարմինը/վերնագրերը։

4. Փոխզիջում բանալին

Անմիջապես revoke 'kid ", թարգմանել" next _ kid ", վերագրանցել բոլոր գաղտնիքները/հոսանքները, հասանելիության աուդիտը։

15) Տիպիկ սխալներ

Ստորագրեք «մարմնի մի մասը» կամ JSON-ը առանց ամրագրելու կարգուկանոնի խոցելիությունը դաշտերի փոխպատվաստման համար։

«Digest» -ի բացակայությունը կարող է աննկատ փոխել մարմինը։

Երկար պատուհանը 'ts' առանց nonce-ի բաց է։

Պահել գաղտնիքները փոփոխական միջավայրերում առանց KFC/Vox։

Համեմատել ստորագրությունը չի constrone-time։

Անտեսել «host »/« path» -ը նավարկության վրա ռուսական հարձակումները։

Խառնել «kid» տարբեր տենանտներ և տարածաշրջաններ։

16) Չեկ թուղթ մինչև վաճառելը

• Canonicae (method, path + query, content-type, Digest, ts, nonce, host, tenae)։
• Իրականացվել է HMAC/ECDPS-ը 'kid', www.ru և dj-secret։
• Ներառված են հակա-ռեպլեյը (nonce + ts) և inbox/event _ id webhuks-ի համար։
• Վճռական են սխալները/ռեթլինգի քաղաքականությունը և տրոտլինգը per tenault/key։
• Դիտարկումը 'մետրեր verify, լոգներ, հետքեր, ալտերտեր։
• Միգրացիան ավտոմատացված է; աուդիտը և հասանելիության իրավունքները սահմանափակ են։
• Թեստային հավաքածուներ կանոկալիզացիայի և միջանկյալ համատեղելիության համար։
• Ինտեգրատորների համար, օրինակ 3-4 լեզուներով և ֆիքսուրներով։
• mTSA-ն ներառված է զգայուն ինտեգրման համար։ JWT-ն օգտագործվում է միայն որպես ավելացում, ոչ թե մարմնի ստորագրության փոխարինում։

Եզրակացություն

Հարցումների ստորագրումն ու հավատարմագրումը ոչ թե «մեկ վերնագիր» է, այլ կարգապահություն 'հստակ կանոնականացում, կարճ ժամանակի պատուհաններ, հակատիպեր, կոդավորման և դիտարկման։ Դուք կկառուցեք մեկ ծրագիր բոլոր ինտեգրումների համար (API և webhuki), օգտագործեք «kid »/KTS, ընդունեք երկու բանալին, և ձեր ուրվագծերը կդառնան կայուն փոխարինումների, կանխատեսելի և հարմար հաճախորդների համար։