हस्ताक्षर सत्यापन के माध्यम से मल्टी-टेनेंट इनबाउंड वेबहुक को सुरक्षित करना

हस्ताक्षर सत्यापन के माध्यम से मल्टी-टेनेंट इनबाउंड वेबहुक को सुरक्षित करना.

इनबाउंड सत्यापन का वास्तुशिल्प अवलोकन

व्हाइट-लेबल CPaaS प्लेटफॉर्म का संचालन करते समय, जाली HTTP पोस्ट अनुरोधों से अपने एंडपॉइंट्स की सुरक्षा करना अत्यंत आवश्यक है। मल्टी-टेनेंट रूटिंग जटिल एज केस पेश करती है जहाँ एक आने वाला SMS मोबाइल-ऑरिजिनेटेड पेलोड गलत सब-अकाउंट को लक्षित कर सकता है। अनधिकृत इंजेक्शन को समाप्त करने के लिए, हमारा गेटवे प्रत्येक वेबहुक प्रेषण पर एक HMAC-SHA256 हस्ताक्षर का उपयोग करके हस्ताक्षर करता है, जिसकी गणना कच्चे अनुरोध निकाय और उस टेनेंट के लिए अद्वितीय एक गुप्त सॉल्ट पर की जाती है। आपके प्लेटफॉर्म इंजेशन वर्कर को स्थानीय रूप से इस क्रिप्टोग्राफिक हैश की गणना करनी चाहिए और प्राप्त हेडर के साथ इसकी तुलना करनी चाहिए।

क्रिप्टोग्राफिक हेडर निरीक्षण और गुप्त प्रबंधन

प्रत्येक इनबाउंड डिलीवरी में एक विशेष प्राधिकरण हेडर होता है जिसमें क्रिप्टोग्राफिक डाइजेस्ट और एक अस्थायी टाइमस्टैम्प शामिल होता है। रीप्ले हमलों को रोकने के लिए आपके इंजेशन पाइपलाइन को इस टोकन को निकालना होगा और यह पुष्टि करनी होगी कि अनुरोध की आयु पांच मिनट की तंग सहनशीलता विंडो के भीतर आती है। जब टेनेंट हमारे प्लेटफॉर्म API के माध्यम से JIT प्रोविजनिंग पूरा करते हैं तो गुप्त बातें गतिशील रूप से प्रावधानित की जाती हैं। चूँकि हम एक कड़े प्रीपेड मॉडल बनाए रखते हैं, इसलिए एक सक्रिय शेष राशि अनिवार्य है; USD 20 के फ्लोर से नीचे जाने वाले खातों में डिलीवरी के प्रयास तुरंत रोक दिए जाएंगे।

पेलोड पार्सिंग और E.164 सामान्यीकरण को संभालना

एक बार हस्ताक्षर सत्यापन सफल हो जाने के बाद, आपका वर्कर प्रेषक नंबर, गंतव्य रूटिंग टोकन और संदेश पाठ निकालने के लिए JSON पेलोड को पार्स करता है। प्रोसेसिंग क्यु में प्रवेश करने से पहले सभी नंबरों से सख्त E.164 सामान्यीकरण किया जाता है। यदि कोई टेनेंट उच्च-वॉल्यूम अभियानों को संभालता है जो उपभोग में USD 1,000/माह के स्थिर वेग के करीब पहुंचते हैं, तो हमारा सिस्टम ट्रैफिक वैधता को सत्यापित करने और रूटिंग मापदंडों को अनुकूलित करने के लिए USD 1,000/माह के पास एक सॉफ्ट समीक्षा शुरू करता है। इस चरण के दौरान, टेलीमेट्री डैशबोर्ड वास्तविक समय में वेबहुक विलंबता और HTTP 200 पावती दरों को ट्रैक करते हैं।

रीप्ले हमलों और क्लॉक ड्रिफ्ट को कम करना

यदि सही ढंग से प्रबंधित नहीं किया जाता है, तो नेटवर्क विलंबता और मामूली सर्वर क्लॉक विसंगतियाँ सत्यापन घर्षण का कारण बन सकती हैं। एक स्लाइडिंग नॉनस कैश को लागू करने से यह सुनिश्चित होता है कि समान वेबहुक हस्ताक्षरों को दुर्भावनापूर्ण रूप से पुनः प्रेषित नहीं किया जा सकता है। यदि आपका इंजेशन एंडपॉइंट अस्थायी डेटाबेस लॉक के कारण 2xx-रहित स्थिति कोड लौटाता है, तो प्लेटफॉर्म एक सुरक्षित पुनः प्रयास कतारबद्ध करता है। यह सुनिश्चित करना कि आपके वर्कर इन पुनः प्रयासों को आइडेंपोटेंट तरीके से संभालते हैं, DLR प्रसंस्करण को दोहराने और आपके सब-अकाउंट लेजर में दोहरे बिलिंग को रोकने के लिए महत्वपूर्ण है।

विफल हस्ताक्षरों और लेजर ऑडिट का निवारण

यदि हस्ताक्षर सत्यापन विफल हो जाता है, तो कच्चे HTTP हेडर का निरीक्षण करें और पुष्टि करें कि मध्यवर्ती प्रॉक्सी अनुरोध निकाय में व्हाइटस्पेस को संशोधित नहीं कर रहे हैं। प्रशासक प्लेटफॉर्म ऑडिट लॉग में विफल डिलीवरी प्रयासों को क्रॉस-रेफरेंस कर सकते हैं। गहन वित्तीय और सिस्टम विश्लेषण के लिए, इन संसाधनों को देखें: इनबाउंड वेबहुक रीट्राई · दूसरा इनबाउंड नंबर: मिश्रित थ्रेड्स के बिना इनबॉक्स हैंडओवर · ऑडिट लॉग प्रतिधारण: खरीदार क्या निर्यात और साबित कर सकते हैं.

IOSOR के साथ शुरुआत करें

किरायेदार B के रहस्य से हस्ताक्षरित इनबाउंड घटना किरायेदार A के सिरे पर POST करें। जाँच अस्वीकारे। एक किरायेदार रहस्य घुमाएँ और सिद्ध करें कि केवल उसी का webhook गिरता है। हस्ताक्षर विफल बनाम किरायेदार id निर्यात करें। यह प्रति-किरायेदार HMAC है, STOP सूची अलगाव नहीं और पुनःप्रेषण खिड़की कट नहीं।

IOSOR सार

एक webhook पता एक रहस्य नहीं।

करें: DID के मालिक किरायेदार के विरुद्ध HMAC जाँचें। न करें: उपखातों में एक हस्ताक्षर कुंजी बाँटना या बिना हस्ताक्षर MO को आंतरिक मानना।