प्रॉम्प्ट और दायरा
एक पेमेंट पार्टनर को प्रत्येक HTTP अनुरोध के प्रेषक के प्रमाण और अखंडता (integrity) की आवश्यकता है। RFC 9421 का उपयोग करके, साइनिंग और वेरिफिकेशन डिज़ाइन करें और कवर्ड कंपोनेंट्स, रीप्ले डिफेंस, की रोटेशन और प्रॉक्सी रीराइट्स के बारे में बताएं।
RFC 9421 सिग्नेचर इनपुट, कवर्ड HTTP कंपोनेंट्स और पैरामीटर्स जैसे created, expires और nonce को अलग करता है। यह प्रश्न परीक्षण करता है कि क्या उम्मीदवार केवल बॉडी को हैश करने के बजाय "किसने हस्ताक्षर किए" और "किन बाइट्स पर हस्ताक्षर किए गए" को इंटरऑपरेबल बना सकता है या नहीं।
इंटरव्यूअर क्या मूल्यांकन करता है
मूल्यांकन करें कि क्या कवर्ड कंपोनेंट्स अनुरोध के सिमेंटिक्स (semantics) को बाइंड करते हैं; क्या दोनों पक्ष सिग्नेचर बेस को समान रूप से कैनोनिकलाइज़ करते हैं; क्या समय, नॉनस और की (key) आईडी रीप्ले को रोकते हैं; प्रॉक्सी, रिट्री, कम्प्रेशन और टेनेंट वेरिफिकेशन को कैसे प्रभावित करते हैं; और क्या की (key) पब्लिकेशन, रिवोकेशन और मॉनिटरिंग संचालन योग्य (operable) हैं।
30-सेकंड उत्तर फ्रेमवर्क
"मैं मेथड, टारगेट पाथ, अथॉरिटी, महत्वपूर्ण व्यावसायिक फ़ील्ड और Content-Digest को कवर करना अनिवार्य करूँगा, जिसमें एल्गोरिदम, पैरामीटर क्रम और क्लॉक टॉलरेंस निश्चित होंगे। सर्वर Signature-Input को पार्स करता है, उसी बेस का पुनर्निर्माण करता है, की (key) ढूंढता है, सिग्नेचर को सत्यापित करता है, created, expires और सिंगल-यूज़ नॉनस की जाँच करता है, और उसके बाद ही बिजनेस लॉजिक में प्रवेश करता है। वर्ज़न वाले की (key) आईडी डुअल वेरिफिकेशन और रिवोकेशन का समर्थन करते हैं। एक प्रॉक्सी केवल अनकवर्ड फ़ील्ड को रीराइट कर सकता है; अन्यथा वेरिफिकेशन विफल हो जाता है।"
चरण-दर-चरण विस्तृत उत्तर
चरण 1: सिद्ध की जाने वाली प्रॉपर्टी को परिभाषित करें
एक सिग्नेचर यह सिद्ध करता है कि एक की (key) होल्डर ने चयनित HTTP कंपोनेंट्स पर हस्ताक्षर किए हैं और यह छेड़छाड़ का पता लगाने में मदद करता है। यह TLS, ऑथराइजेशन, इनपुट वैलिडेशन या बिजनेस आइडमपोटेंसी का स्थान नहीं लेता है। स्पष्ट करें कि क्या प्रोटोकॉल को ऑथेंटिकेशन, इंटीग्रिटी या नॉन-रेप्यूडिएशन की आवश्यकता है।
चरण 2: कवर्ड कंपोनेंट्स का चयन करें
कम से कम मेथड, टारगेट पाथ और अथॉरिटी को कवर करें। आवश्यकतानुसार content-digest, एक आइडमपोटेंसी की, टेनेंट आईडी, या महत्वपूर्ण व्यावसायिक फ़ील्ड जोड़ें। किसी एक रिप्लेसेबल फ़ील्ड पर हस्ताक्षर न करें या उन हेडर्स को आँख मूँद कर कवर न करें जिन्हें एक वैध प्रॉक्सी रीराइट करता है। प्रोटोकॉल के हिस्से के रूप में कंपोनेंट सूची का वर्ज़निंग करें।
चरण 3: सिग्नेचर बेस को कैनोनिकलाइज़ करें
दोनों पक्षों को RFC 9421 कंपोनेंट आइडेंटिफायर्स, ऑर्डरिंग, पैरामीटर एन्कोडिंग और डिराइव्ड-कंपोनेंट नियमों का पालन करना चाहिए। सर्वर को रॉ हेडर स्ट्रिंग्स को जोड़कर अनुमान लगाने के बजाय पार्स किए गए अनुरोध और Signature-Input से बेस का पुनर्निर्माण करना चाहिए। अज्ञात या डुप्लिकेट महत्वपूर्ण कंपोनेंट्स को अस्वीकार करें।
चरण 4: अनुरोध सामग्री (request content) को सुरक्षित करें
बॉडी वाले अनुरोधों के लिए, Content-Digest की गणना करें और इसे सिग्नेचर में शामिल करें। वेरिफिकेशन से पहले, प्राप्त बाइट्स को हैश करें ताकि कम्प्रेशन, ट्रांसकोडिंग या JSON रीफ़ॉर्मेटिंग सामग्री को चुपचाप न बदल सके। यदि कोई प्रॉक्सी डीकंप्रेस या री-एन्कोड करता है, तो परिभाषित करें कि साइनिंग उस ट्रांसफ़ॉर्मेशन से पहले होती है या बाद में।
चरण 5: समय और रीप्ले सुरक्षा जोड़ें
created अनिवार्य करें, और उपयोगी होने पर expires और एक अद्वितीय nonce अनिवार्य करें। टाइम विंडो और क्लॉक स्क्यू (clock skew) की जाँच करें, और प्रति टेनेंट उपयोग किए गए नॉनसेस को कुछ समय के लिए स्टोर करें। उसी व्यावसायिक अनुरोध के रिट्री असीमित सिग्नेचर लाइफटाइम के बजाय एक आइडमपोटेंसी की पर निर्भर करते हैं। समय की जाँच पास करने से राइट (write) ऑपरेशन को दो बार निष्पादित करना सुरक्षित नहीं हो जाता है।
चरण 6: कीज़ (Keys) को खोजना और रोटेट करना
Signature-Input में की (key) आईडी एक नियंत्रित डायरेक्टरी या JWKS-जैसे एंडपॉइंट से एक पब्लिक की का चयन करती है। वर्ज़न वाले परिणामों को कैश करें। रोटेशन के दौरान, नई की (key) प्रकाशित करें, एक सीमित ओवरलैप अवधि के लिए पुरानी और नई दोनों कीज़ की अनुमति दें, फिर ट्रैफ़िक पूरी तरह समाप्त होने के बाद पुरानी की (key) को निरस्त (revoke) करें। प्राइवेट कीज़ को साइनिंग एंडपॉइंट्स पर रखें और कभी भी की (key) मटीरियल या संपूर्ण सिग्नेचर बेस को लॉग न करें।
चरण 7: प्रॉक्सी और रिट्री सीमाओं को परिभाषित करें
दस्तावेज़ित करें कि कौन सी लेयर्स ट्रेसिंग फ़ील्ड जोड़ सकती हैं, अनुरोधों को पुनः प्रयास (retry) कर सकती हैं, या अथॉरिटी बदल सकती हैं। किसी कवर्ड कंपोनेंट का अनधिकृत रीराइट वेरिफिकेशन को विफल कर देना चाहिए। एक प्रॉक्सी वन-टाइम नॉनस को कॉपी नहीं कर सकता है या किसी सिग्नेचर को दूसरे टारगेट पर फ़ॉरवर्ड नहीं कर सकता है। वेरिफिकेशन से पहले राइट ऑपरेशन्स या महंगे बिजनेस लॉजिक न चलाएं।
चरण 8: विफलताओं को सुरक्षित रूप से संचालित करें
एक अनुरोध आईडी के साथ की (key) आईडी, सिग्नेचर वर्ज़न, विफलता वर्ग, क्लॉक स्क्यू, नॉनस टकराव, अनुपलब्ध कंपोनेंट्स और प्रॉक्सी स्रोत को रिकॉर्ड करें। हमलावरों को जांच में मदद करने वाले की (key) मटीरियल या विस्तृत बेस को लौटाए बिना पार्टनर्स को कार्रवाई योग्य वर्ग प्रदान करें जैसे कि एक्सपायर्ड, अज्ञात की, या डाइजेस्ट बेमेल।
ट्रेड-ऑफ और सीमाएं
असममित (Asymmetric) सिग्नेचर बनाम साझा कीज़ (Shared Keys)
असममित कीज़ मल्टी-पार्टी वेरिफिकेशन और स्वतंत्र रिवोकेशन को सरल बनाती हैं लेकिन इसके लिए अधिक इंफ्रास्ट्रक्चर की आवश्यकता होती है। साझा HMAC कम खर्चीला है, फिर भी प्रत्येक सत्यापनकर्ता (verifier) अनुरोधों को जाली (forge) बना सकता है; इसका उपयोग केवल तभी करें जब ट्रस्ट बाउंड्री स्पष्ट हो।
कवरेज बनाम प्रॉक्सी अनुकूलता
अधिक कवरेज मजबूत इंटीग्रिटी देता है लेकिन जब कोई गेटवे वैध रूप से किसी फ़ील्ड को बदलता है तो यह विफल हो सकता है। वेरिफिकेशन को चुपचाप कमजोर करने के बजाय प्रोटोकॉल में प्रॉक्सी अनुबंध शामिल करें और आवश्यकता पड़ने पर सीमा पर पुनः हस्ताक्षर (re-sign) करें।
संकीर्ण विंडो बनाम ऑफ़लाइन रिट्री
छोटी विंडो रीप्ले जोखिम को कम करती हैं लेकिन क्लॉक सिंक्रोनाइज़ेशन और तेज़ रिट्री की आवश्यकता होती है। ऑफ़लाइन क्लाइंट्स को लंबे समय तक चलने वाले सिग्नेचर का पुन: उपयोग करने के बजाय एक नए सिग्नेचर का अनुरोध करना चाहिए; सर्वर पार्टनर-विशिष्ट सीमित टॉलरेंस लागू कर सकता है।
विफलता अभ्यास (Failure drills) और विकास
एक प्रॉक्सी पाथ बदलता है
एक टेस्ट प्रॉक्सी में पाथ या अथॉरिटी को रीराइट करें और पुष्टि करें कि बिजनेस लॉजिक से पहले वेरिफिकेशन विफल हो जाता है। अनुमत ट्रेसिंग-हेडर परिवर्तनों से सिग्नेचर प्रभावित नहीं होना चाहिए।
एक पुराना अनुरोध रीप्ले किया जाता है
एक ही सिग्नेचर और नॉनस को दो बार भेजें और सत्यापित करें कि दूसरा प्रयास अस्वीकार कर दिया गया है। समान आइडमपोटेंसी की के साथ एक नए नॉनस का उपयोग करें और बिजनेस-लेयर आइडमपोटेंसी को सत्यापित करें।
एक की (key) रोटेट होती है
पुरानी और नई कीज़ को एक साथ प्रकाशित करें और पॉलिसी-अनुपालन वाले हस्ताक्षरों को सत्यापित करें। रिवोकेशन के बाद, पुराने सिग्नेचर्स विफल होने चाहिए और पुराना कैश उन्हें अनिश्चित काल तक वैध नहीं रखना चाहिए।
सामान्य गलतियाँ और फॉलो-अप
गलती 1: केवल बॉडी हैश पर हस्ताक्षर करना
पूछें कि क्या सिग्नेचर को किसी अन्य पाथ या मेथड पर कॉपी किया जा सकता है; कवर्ड टारगेट कंपोनेंट्स को अनुरोध के अर्थ को बांधना (bind) चाहिए।
गलती 2: यह मान लेना कि HTTPS पर्याप्त है
पूछें कि एक आंतरिक TLS-टर्मिनेटिंग प्रॉक्सी के बाद मूल प्रेषक और सामग्री को कैसे प्रमाणित किया जाता है।
गलती 3: नॉनस और समय की अनदेखी करना
पूछें कि क्या कैप्चर किए गए भुगतान अनुरोध को उसकी वैधता विंडो के दौरान रीप्ले किया जा सकता है; समय, नॉनस और आइडमपोटेंसी को संयोजित करें।
गलती 4: पुरानी की (key) को तुरंत हटाना
पूछें कि इन-फ़्लाइट अनुरोध और मल्टी-रीजन कैश कैसे ओवरलैप होते हैं; रिवोकेशन से पहले डुअल-वेरिफाई करें।
गलती 5: विफलता पर सिग्नेचर-बेस विवरण लौटाना
पूछें कि पार्टनर्स की (key) मटीरियल, साइन्ड इनपुट या आंतरिक प्रॉक्सी विवरण को उजागर किए बिना डिबग कैसे करते हैं।
विस्तारित फॉलो-अप और संदर्भ उत्तर
सिग्नेचर में Content-Digest को क्यों शामिल करें?
डाइजेस्ट बॉडी बाइट्स का प्रतिनिधित्व करता है; सिग्नेचर उस डाइजेस्ट को मेथड, टारगेट और अन्य कंपोनेंट्स से बांधता है ताकि एक वैध डाइजेस्ट को किसी अन्य अनुरोध पर स्थानांतरित न किया जा सके।
क्या रीराइट करने के बाद प्रॉक्सी को फिर से हस्ताक्षर (re-sign) करना चाहिए?
यदि रीराइट डाउनस्ट्रीम प्रोटोकॉल का हिस्सा है, तो बाउंड्री प्रॉक्सी को अपनी पहचान के रूप में हस्ताक्षर करना चाहिए। अन्यथा इसे कवर्ड कंपोनेंट्स को संरक्षित रखना चाहिए ताकि मूल सिग्नेचर सत्यापन योग्य बना रहे।
ऑथेंटिकेशन और ऑथराइजेशन किस प्रकार भिन्न हैं?
वेरिफिकेशन यह साबित करता है कि एक की (key) होल्डर ने अनुरोध पर हस्ताक्षर किए हैं। ऑथराइजेशन अभी भी टेनेंट, खाते, राशि, आइडमपोटेंसी और व्यावसायिक स्थिति की जांच करता है; केवल एक सिग्नेचर निष्पादन को अधिकृत नहीं कर सकता है।