अनुरोधों पर हस्ताक्षर और सत्यापन

अनुरोध का हस्ताक्षर प्रेषक की प्रामाणिकता और सामग्री की अखंडता को साबित करता है। टीएलएस (जो चैनल की रक्षा करता है) के विपरीत, एक लागू हस्ताक्षर प्रत्येक संदेश को सत्यापित करने योग्य और प्रॉक्सी, कैश और विलंबित डिलीवरी के लिए प्रतिरोधी बनाता है।

1. प्रामाणिकता (जिसने भेजा) और अखंडता (नहीं बदला)।

2. विशिष्टता (रिप्ले के खिलाफ सुरक्षा)।

3. परिवहन से decoupling (HTTP, कतारें, वेबहूक के शीर्ष पर काम करता है)।

4. श्रव्यता (महीनों के बाद प्रजनन योग्य जाँच)।

1) धमकी मॉडल (न्यूनतम)

मार्ग के साथ शरीर/हेडर का प्रतिस्थापन।

रीप्ले (वैध अनुरोध दोहराएं)।

डाउनग्रेड/स्ट्रिप कैप्शन।

एकीकरण रहस्य चोरी।

गैर-तुल्यकालिक घड़ी (घड़ीतिरछा) और लंबी कतारें।

2) आदिम का विकल्प

HMAC (समरूपता): सरल और तेज, कुंजी दोनों तरफ संग्रहीत है। B2B वेबहुक और आंतरिक API के लिए उपयुक्त।

आरएसए/ईसीडीएसए (विषमता): प्रेषक से निजी कुंजी, प्राप्तकर्ता से सार्वजनिक कुंजी। खुले एकीकरण के लिए उपयुक्त और जब किसी रहस्य को साझा न करना महत्वपूर्ण हो।

mTLS: परिवहन परत आपसी प्रमाणीकरण अक्सर NMAC/शरीर हस्ताक्षर के साथ संयुक्त होता है।

JWT/JWS: वाहक टोकन और आत्मनिर्भर टिकटों के लिए सुविधाजनक; शरीर पर हस्ताक्षर करने के लिए, canonicalization + JWS Detacted/HTTP संदेश हस्ताक्षर का उपयोग करना बेहतर है।

HTTP संदेश हस्ताक्षर (अनुरोध के चयनित भागों का हस्ताक्षर): REST के लिए आधुनिक दृष्टिकोण।

सिफारिश: वेबहुक के लिए - HMAC + timestamp + nonce + body canononicalization; सार्वजनिक एपीआई - एचटीटीपी संदेश हस्ताक्षर या जेडब्ल्यूएस के लिए; उच्च जोखिमों पर - mTLS जोड़ें।

3) Canonicalization (वास्तव में हम क्या हस्ताक्षर करते हैं

आपको एक नियतात्मक स्ट्रिंग पर हस्ताक्षर करने की आवश्यकता है जो दोनों पक्षों द्वारा समान रूप

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)

• क्वेरी पैरामीटर के पथ और क्रम को सामान्य करें।
• रिक्त स्थान/यूनिकोड/केस - फिक्स (उदाहरण के लिए, लोअर-केस हेडर, ट्रिम)।
• बड़े शरीर - हैश (डाइजेस्ट), "जैसा है" चालू नहीं।

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

जहाँ 'बच्चा '/' कीआईडी' आपको रजिस्ट्री से एक कुंजी चुनने की अनुमति देता है (रोटेशन देखें)।

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"

लगातार समय HMAC तुलना, तेजी से KV (TTL ≥ डिलीवरी विंडो) में 'nonce '/' (ts, event_id) का भंडारण।

6) एंटी-रीप्ले और विंडो

Timestamp + Nonce: ')' से पुराने अनुरोधों को अस्वीकार करें (उदा। 5 मिनट) और इस खिड़की में नॉन रेट्रीस।

वेबहुक के लिए: एक स्थिर 'ईवेंट _ आईडी' और एक इनबॉक्स टेबल का उपयोग करें - यह सिर्फ नॉन की तुलना में अधिक विश्वसनीय है।

री-डिलीवरी (रिट्रे) को एक ही ts/nonce/event_id का उपयोग करना चाहिए, न कि नए उत्पन्न करना।

7) बहु-किरायेदार और क्षेत्र

प्रति किरायेदार/क्षेत्र कुंजियाँ भंडारित करें: 'बच्चा = <किरायेदार>: <क्षेत्र>: '।

अलग गुप्त पूल और सीमा; डेटा रेजीडेंसी का निरीक्षण करें।

शीर्षक/विहित में, 'एक्स-किरायेदार' का संकेत देते हैं और क्षेत्र जाँच किए जा रहे संदर्भ का हिस्सा है।

8) प्रमुख प्रबंधन और रोटेशन

कुंजी रजिस्ट्री (केएमएस/वॉल्ट): 'बच्चा', प्रकार, एल्गोरिथ्म, स्थिति ('सक्रिय', 'पदावनत', 'सेवानिवृत्त'), 'वैध _ for/valid _ to'।

दोहरे रहस्य: वर्तमान और अगली कुंजी को एक साथ रखें (रिसीवर दोनों को स्वीकार करता है)।

एक कार्यक्रम पर और एक घटना (समझौता) पर रोटेशन।

कुंजी पिनिंग (यदि संभव हो) और प्रमुख सामग्रियों तक पहुंच को प्रतिबंधित करना

उनके साथ कुंजियों और क्रियाओं तक पहुंच के लॉग।

9) mTLS और OAuth के साथ संयोजन

mTLS प्रमाणपत्र स्तर पर चैनल और "आप कौन हैं" की जाँच करता है।

हस्ताक्षर संदेश की रक्षा करता है (प्रॉक्सी/कैश/कतार के माध्यम से उपयोगी)।

OAuth/JWT प्रमाणीकरण/प्राधिकरण का पूरक है, लेकिन अपने आप में शरीर की अखंडता की गारंटी नहीं देता है (जब तक कि विहित में हस्ताक्षर नहीं किए जाते)।

सर्वोत्तम प्रथाएँ: mTLS + बॉडी सिग्नेचर (डाइजेस्ट) + HMAC/ECDSA + शॉर्ट 'ts' -interval।

10) त्रुटियां और प्रतिक्रिया कोड

'401 SIGNATURE_INVALID' एक अवैध हस्ताक्षर/एल्गोरिथ्म है।

'401 KEY_REVOKED' -' बच्चा 'अवैध/समाप्त हो गया है।

'400 TIMESTAMP_OUT_OF_RANGE' - घड़ी/खिड़की।

'409 NONCE_REPLAYED' - रेडो का पता चला।

'400 DIGEST_MISMATCH' - शरीर बदल गया।

'415 UNSUPPORTED_ALGORITHM' एक अनसुलझा' अल्ग 'है।

'429 TOO_MANY_ATTEMPTS' - कुंजी/किरायेदार थ्रॉटलिंग।

मशीन पढ़ ने योग्य 'त्रुटि _ कोड' में सटीक कारण को लात मारें; रहस्य/विहिताकरण वापस न करें "जैसा कि है।"

11) अवलोकन और लेखा परीक्षा

• 'सत्यापित _ p95 _ ms', 'सत्यापित _ त्रुटि _ दर', 'डाइजेस्ट _ मिसमैच _ रेट', 'रीप्ले _ ब्लॉक _ रेट', 'alg _ usage {hmac, ecdsa}', 'घड़ी _ skew _ ms'।
• लॉग्स (संरचनात्मक): 'बच्चा', 'अल्ग', 'किरायेदार', 'क्षेत्र', 'टीएस', 'नॉनस', 'डाइजेस्ट _ हैश', 'निर्णय', 'कारण'।
• ट्रेसिंग: विशेषताओं के हस्ताक्षर। बच्चा ',' हस्ताक्षर। alg ',' हस्ताक्षर। ts_skew'।
• ऑडिट: रोटेशन, कुंजी उपयोग और सहिष्णुता के झंडे का अपरिवर्तनीय लॉग।

12) प्रदर्शन

स्ट्रीमिंग द्वारा शरीर को हैश करें (इसे अपनी स्मृति में न रखें)।

छोटे टीटीएल के साथ 'बच्चे' द्वारा कैश सार्वजनिक कुंजी और घटना द्वारा विकलांगता।

किनारे/गेटवे पर, प्रारंभिक जांच करें (ts/nonce/format)।

ECDSA की तुलना में HMAC तेज; ECDSA बाहरी एकीकरण और "गैर-साझा" कुंजियों के लिए अधिक सुविधाजनक है।

13) परीक्षण

स्थिरता सेट: समान अनुरोध → समान विहितीकरण/हस्ताक्षर; गंदे स्थान/क्वेरी क्रम/ → हेडर स्थिर हैं।

नकारात्मक: अमान्य 'किड/एल्ग', संशोधित बॉडी/होस्ट, नॉन रिपीट, अप्रचलित टी, घड़ी तिरछा।

संपत्ति-आधारित: कोई भी समकक्ष प्रश्न एक एकल विहित स्ट्रिंग का उत्पादन करता है

इंटरऑप: क्रॉस-लैंग्वेज चेक (गो/जावा/नोड/पायथन)।

अराजकता: देरी, पीछे हटना, ऑन-द-फ्लाई कुंजी परिवर्तन।

14) प्लेबुक (रनबुक)

1. 'हस्ताक्षर _ अवैध' स्पाइक

कुंजी घूर्णन, घड़ी मिसलिग्नमेंट, प्रेषक में कैनोनिकलाइजेशन में परिवर्तन की जाँच करें।

अस्थायी रूप से पुराने 'बच्चे' के लिए 'दोहरी स्वीकृति' सक्षम करें, साथी को सूचित करें।

2. 'REPREAY' वृद्धि

नॉन स्टोरेज का टीटीएल बढ़ाएं, प्रेषक पर रिट्रेनर की जांच करें, घड़ी तिरछा जांचें।

किनारे पर अपमानजनक आईपी/एएसएन ओवरराइड करें।

3. 'DIGEST _ MISMATCH' बड़े पैमाने पर

प्रॉक्सी/संपीड़न/पुनर्लेखन शीर्षिका जाँचें; canonicalization संस्करण ठीक करें।

बॉडी/हेडर घुसपैठियों को अक्षम करें।

4. कुंजी समझौता

तुरंत 'किड' को रद्द करें, 'नेक्स्ट _ किड' में अनुवाद करें, सभी रहस्यों/टोकन को पुनर्जीवित करें, ऑडिट एक्सेस करें।

15) विशिष्ट त्रुटियां

आदेश को ठीक किए बिना "बॉडी पार्ट" या JSON पर हस्ताक्षर करना - क्षेत्र क्रमपरिवर्तन के लिए भेद

'डाइजेस्ट' की अनुपस्थिति - प्रॉक्सी शरीर को किसी का ध्यान नहीं रख सकती है।

बिना नॉनस के एक लंबा 'ts' विंडो फिर से खेलने के लिए खुला है।

केएमएस/वॉल्ट के बिना वातावरण चर में रहस्य रखें।

हस्ताक्षर की तुलना निरंतर समय नहीं करें।

कैनोनिकलाइजेशन में 'होस्ट '/' पथ' को अनदेखा करें → फॉरवर्ड अटैक।

विभिन्न किरायेदारों और क्षेत्रों को मिलाएं 'बच्

16) प्री-सेल चेकलिस्ट

• कैनोनिकलाइजेशन प्रारूप परिभाषित (विधि, पथ + क्वेरी, सामग्री-प्रकार, डाइजेस्ट, टी एस, नॉन, होस्ट, किरायेदार)।
• HMAC/ECDSA को 'बच्चे', प्रमुख रजिस्ट्री और दोहरे रहस्य के साथ लागू किया गया।
• वेबहुक के लिए एंटी-रिप्ले (नॉनस + टी) और inbox/event_id भंडारण शामिल हैं।
• कॉन्फ़िगर त्रुटि कोड/रिट्रे नीति और प्रति किरायेदार/कुंजी थ्रॉटलिंग।
• अवलोकन: फटने के लिए मेट्रिक्स, लॉग, ट्रेस, अलर्ट सत्यापित करें।
• कुंजी घूर्णन स्वचालित है; ऑडिट और एक्सेस अधिकार सीमित हैं।
• Canonicalization और interlanguage संगतता परीक्षण किट।
• 3-4 भाषाओं और सुधारों में एक उदाहरण के साथ इंटीग्रेटर के लिए प्रलेखन।
• एमटीएलएस संवेदनशील एकीकरण के लिए सक्षम; JWT का उपयोग केवल एक अतिरिक्त के रूप में किया जाता है, शरीर के हस्ताक्षर के लिए प्रतिस्थापन नहीं।

निष्कर्ष

अनुरोधों पर हस्ताक्षर और सत्यापन करना "एक हेडर" नहीं है, बल्कि एक अनुशासन है: स्पष्ट विहित, समय की छोटी खिड़कियां, एंटी-रीप्ले, कुंजी रोटेशन और अवलोकन। सभी एकीकरणों (एपीआई और वेबहूक) के लिए एक मानक का निर्माण करें, 'बच्चे '/केएमएस का उपयोग करें, रोटेशन के दौरान दो कुंजियों को स्वीकार करें, और आपके आकृति स्पूफिंग, अनुमानित और ऑडिट के लिए आसान हो जाएगी।