webhook साइनिंग सीक्रेट सेटअप की कोई मामूली जानकारी नहीं, एक क्रेडेंशियल है। इसे वैसे ही भेजें जैसे पासवर्ड भेजते हैं: पहले पक्का करें कि इसे कौन ले रहा है, फिर ऐसे रास्ते से सौंपें जो कोई कॉपी न रखे, और ध्यान रखें कि यह टिकट में नहीं, सीक्रेट स्टोर में पहुंचे। छोटा जवाब: पुष्टि किए गए संपर्क को वन-टाइम सीक्रेट लिंक भेजें, यानी एक बार खुलने वाला लिंक, और सेटअप के निर्देश अलग से भेजें।
इस गाइड के बाकी हिस्से में बताया गया है कि कौन-सा रास्ता चुनें, भेजने से पहले क्या जांचें, क्लाइंट इस वैल्यू का क्या करे, और रोटेशन व समस्याओं को कैसे संभालें ताकि सीक्रेट दोबारा कहीं पेस्ट न करना पड़े।
सीक्रेट किस रास्ते से भेजा जाए?
रास्ता दो कसौटियों पर चुनें: क्या आप पक्का कर सकते हैं कि इसे कौन खोल सकता है, और यह पीछे कितनी कॉपी छोड़ता है? ईमेल और चैट दूसरी कसौटी पर फ़ेल हो जाते हैं, क्योंकि हर मैसेज हैंडओवर खत्म होने के बहुत बाद तक रखा जाता है, सिंक होता है और एक्सपोर्ट होता है।
| तरीका | इससे क्या मिलता है | भेजने से पहले क्या जांचें |
|---|---|---|
| लॉगिन वाला क्लाइंट पोर्टल | नाम वाले यूज़र का एक्सेस, जिसे आप वापस ले सकते हैं | अकाउंट सही संपर्क व्यक्ति का है |
| वन-टाइम सीक्रेट लिंक | एक बार खुलने के बाद मिट जाता है, मैसेज में कुछ नहीं बचता | जिस पते पर भेज रहे हैं, उसे अलग से जांच लें |
| एन्क्रिप्टेड मैसेजिंग | भेजते समय सुरक्षित | उस बातचीत को और कौन खोल सकता है |
हर व्यक्ति के अलग लॉगिन वाला क्लाइंट पोर्टल हो, तो वही सबसे अच्छा पहला विकल्प है। एक्सेस किसी नामित व्यक्ति को दें, किसी साझा प्रोजेक्ट थ्रेड को नहीं, और हैंडओवर पूरा होते ही उसे हटा दें।
वन-टाइम लिंक क्रेडेंशियल को उस ईमेल या चैट मैसेज से बाहर रखता है जिससे आप बाकी तालमेल करते हैं। LinkPilot में सीक्रेट स्टोर होने से पहले आपके ब्राउज़र में ही एन्क्रिप्ट होता है, स्टोर की गई कॉपी एक बार खुलने के बाद मिट जाती है, और आप लिंक को एक घंटे, एक दिन या एक हफ़्ते बाद एक्सपायर होने के लिए सेट कर सकते हैं। Pro प्लान में पासफ़्रेज़ भी जोड़ा जा सकता है, जिसे आप किसी अलग रास्ते से बताते हैं। ये कंट्रोल हैंडओवर को सीमित करते हैं। लेकिन दूसरी तरफ़ सही व्यक्ति है या नहीं, यह जांचने की ज़रूरत इनसे खत्म नहीं होती।
एन्क्रिप्टेड मैसेजिंग तब काम आती है जब ऊपर के दोनों तरीके व्यावहारिक न हों। भेजते समय का एन्क्रिप्शन गलत पते पर गए मैसेज या ज़रूरत से बड़े ग्रुप की समस्या हल नहीं करता, इसलिए यहां प्राप्तकर्ता की जांच और भी ज़रूरी है।
आप जो भी चुनें, सादे टेक्स्ट वाले ईमेल और चैट को सिर्फ़ तालमेल के लिए रखें। जो सेवाएं भेजते समय एन्क्रिप्ट करती हैं, उनमें भी डेटा कितने समय रखा जाए, बैकअप और अकाउंट का एक्सेस आपके हाथ में नहीं होता।
क्लाइंट और प्राप्तकर्ता की पुष्टि करें
अगर सीक्रेट गलत इनबॉक्स में चला गया, तो सुरक्षित रास्ता किसी काम का नहीं। भेजने से पहले पक्का करें कि मांगने वाला व्यक्ति सच में इस इंटीग्रेशन का ज़िम्मेदार है, और जिस रास्ते से आप भेजने वाले हैं वह सच में उसी का है।
- किसी जाने-पहचाने रिकॉर्ड से पहचान की पुष्टि करें। भरोसेमंद संपर्क एंट्री, पहले से चल रहे कारोबारी रिश्ते या क्लाइंट की तय प्रक्रिया का इस्तेमाल करें। नया मांगने वाला, अचानक बदला हुआ संपर्क या असामान्य जल्दबाज़ी दिखे, तो स्वतंत्र रूप से जांच करें।
- पते को एक-एक अक्षर करके पढ़ें, खासकर जब आप उसे किसी टिकट या हाल के मैसेज से कॉपी कर रहे हों। मिलते-जुलते नाम और साझा इनबॉक्स ही वे जगहें हैं जहां गलती होती है।
- देखें कि और किसके पास एक्सेस है। पोर्टल या वर्कस्पेस से शेयर करने से पहले उसके सदस्यों की सूची देखें और उन सबको हटा दें जिन्हें इस क्रेडेंशियल की ज़रूरत नहीं।
- दूसरे रास्ते से पुष्टि करें कि सीक्रेट पहुंच गया। अगर लिंक ईमेल से गया है, तो किसी जाने-पहचाने फ़ोन नंबर या प्रोजेक्ट के सामान्य चैनल पर पूछ लें कि एक्सेस मिल गया या नहीं। उस मैसेज में सीक्रेट न डालें।
सीक्रेट उसी एक व्यक्ति को दें जो एंडपॉइंट कॉन्फ़िगर करेगा, और उसे ही इसे क्लाइंट के अपने सीक्रेट स्टोर में रखने दें। अगर कई इंजीनियरों को इसकी ज़रूरत है, तो कौन इसे देख सकता है, यह उस स्टोर के एक्सेस कंट्रोल से तय होना चाहिए, हर इंजीनियर को अलग कॉपी भेजकर नहीं।
हैंडओवर से पहले सीक्रेट तैयार करें
तय करें कि यह क्रेडेंशियल किस चीज़ का है, क्लाइंट इसे कहां रखेगा और हैंडओवर कितनी देर खुला रहेगा। यह तैयारी बाद में रोटेशन और समस्याएं सुलझाने को काफ़ी आसान बना देती है।
- हर क्लाइंट या एंडपॉइंट के लिए एक अलग सीक्रेट। एक ही वैल्यू दोबारा इस्तेमाल करने का मतलब है कि एक लीक उन सभी इंटीग्रेशन तक पहुंच जाता है जो उसे साझा करते हैं, और एक क्लाइंट के लिए रोटेट करने पर सभी पर असर पड़ता है। अंदरूनी रिकॉर्ड रखें कि कौन-सा सीक्रेट किस एंडपॉइंट का है, लेकिन प्रोजेक्ट नोट्स में वैल्यू की कॉपी न रखें।
- अपनी कॉपी सीक्रेट मैनेजर में रखें। किसी लोकल टेक्स्ट फ़ाइल, टिकट या साझा डॉक्यूमेंट में नहीं। यही अनुशासन API keys शेयर करने पर भी लागू होता है: क्रेडेंशियल तक पहुंचने वालों को सीमित रखें और हैंडओवर को कम समय का रखें।
- लेने की समय-सीमा तय करें। क्लाइंट को वैल्यू लेने और सेटअप पूरा करने के लिए जितना समय चाहिए, उतना दें, उससे ज़्यादा नहीं। एक बार खुलते ही मिट जाने वाला और एक दिन में एक्सपायर होने वाला लिंक ज़्यादातर हैंडओवर के लिए काफ़ी है। अगर समय-सीमा निकल जाए, तो पुराने को फिर से खोलने के बजाय नया लिंक बनाएं।
- सेटअप के निर्देश अलग से भेजें। एंडपॉइंट URL, सिग्नेचर हेडर और वेरिफ़िकेशन के स्टेप क्लाइंट के डॉक्यूमेंटेशन या प्रोजेक्ट चैनल में होने चाहिए। इन्हें सीक्रेट से अलग रखने का मतलब है कि अगर निर्देशों वाला पेज कॉपी हो जाए, तो क्रेडेंशियल साथ में कॉपी नहीं होता।
क्लाइंट को इसे सुरक्षित रखने और इस्तेमाल करने में मदद करें
क्लाइंट के वैल्यू पढ़ लेने से डिलीवरी पूरी नहीं होती। यह तब पूरी होती है जब सर्वर इसे सुरक्षित तरीके से पढ़ सके और आने वाले सिग्नेचर जांचने में इसका इस्तेमाल करे।
- इसे सीक्रेट मैनेजर या सुरक्षित एनवायरनमेंट वेरिएबल में रखें जिसे सर्वर प्रोसेस पढ़ सके, और एक्सेस सिर्फ़ ऐप्लिकेशन और उसे चलाने वाले लोगों तक सीमित रखें।
- इसे सोर्स कोड, लॉग और webhook पेलोड से बाहर रखें। सीक्रेट से सिग्नेचर बनाया या जांचा जाता है। यह कभी रिक्वेस्ट बॉडी में नहीं जाता, और इसे डीबग आउटपुट, रिपॉज़िटरी या सपोर्ट टिकट में नहीं दिखना चाहिए। विस्तृत डायग्नोस्टिक्स चालू करने से पहले देख लें कि आपके डिप्लॉयमेंट टूल क्या-क्या रिकॉर्ड करते हैं।
- सिग्नेचर सर्वर पर जांचें। रिसीवर साझा सीक्रेट से कच्ची रिक्वेस्ट बॉडी पर सिग्नेचर दोबारा बनाता है और उसकी तुलना भेजने वाले के सेट किए हेडर से करता है। साइनिंग से साबित होता है कि रिक्वेस्ट असली है और उसमें बदलाव नहीं हुआ; यह पेलोड को एन्क्रिप्ट नहीं करती। HackerOne की webhook साइन करने पर गाइड बताती है कि कच्ची बॉडी और सही सीक्रेट, दोनों क्यों मायने रखते हैं।
- एक टेस्ट इवेंट चलाएं। क्लाइंट से पुष्टि करवाएं कि सही सिग्नेचर स्वीकार होता है और जान-बूझकर बिगाड़ा गया सिग्नेचर रिजेक्ट होता है। इससे आम गलतियां पकड़ में आ जाती हैं: किसी दूसरे एंडपॉइंट का सीक्रेट, या वेरिफ़िकेशन से पहले पार्स की गई बॉडी। जहां इंटीग्रेशन इसकी सुविधा देता हो, वहां टेस्ट और प्रोडक्शन के क्रेडेंशियल अलग रखें।
डिलीवरी के बाद जोखिम कम करें
हैंडओवर के बाद काम का रिकॉर्ड बचना चाहिए, फ़ालतू कॉपी का सिलसिला नहीं।
- दर्ज करें कि किसे और कब अधिकार दिया गया। प्राप्तकर्ता, एंडपॉइंट या क्लाइंट और हैंडओवर का समय लॉग करें। वैल्यू कभी नहीं। अगर आप नहीं बता सकते कि लिंक खोला गया या नहीं, या साझा फ़ोल्डर तक कौन पहुंच सकता था, तो इसे अगली बार प्रक्रिया कसने का कारण मानें।
- लीक का ज़रा भी शक हो, तो रोटेट करें। टिकट में पेस्ट हुआ, गलत पते पर गया या किसी लॉग में मिला सीक्रेट अब निजी नहीं रहा। नया सीक्रेट बनाएं, एंडपॉइंट अपडेट करें और पुरानी वैल्यू को अमान्य कर दें। शेयर करने वाला लिंक हटा देने से लीक का असर खत्म नहीं होता; यह सिर्फ़ रोटेशन से होता है।
- रोटेशन की प्रक्रिया अभी तय कर लें। तय करें कि नया सीक्रेट कौन मांगेगा, कौन बनाएगा और कौन इंस्टॉल करेगा, क्या इम्प्लीमेंटेशन थोड़ी देर तक दोनों वैल्यू साथ चलाने देता है, और पुरानी वैल्यू हटाने से पहले नई को कैसे टेस्ट करेंगे। आउटेज के दौरान हड़बड़ी में होने वाली बातचीत से पहले से तय प्रक्रिया कहीं बेहतर है।
- सफ़ाई करें। क्लाइंट के पुष्टि करते ही कि सीक्रेट मिल गया, अस्थायी एक्सेस वापस लें और ड्राफ़्ट, टिकट और नोट्स में पड़ी बची-खुची कॉपी मिटा दें। इसमें शामिल हर सिस्टम के डेटा रखने के नियम जांचें; किसी एक जगह से मैसेज मिटाने पर वह बैकअप से शायद ही कभी हटता है।
सीक्रेट उजागर किए बिना समस्याएं सुलझाएं
डिलीवरी में दिक्कत आने का मतलब यह नहीं कि क्रेडेंशियल किसी कमज़ोर रास्ते से दोबारा भेज दिया जाए। पहले पता करें कि तीन में से क्या गड़बड़ है: क्लाइंट सीक्रेट ले नहीं पा रहा, एंडपॉइंट कॉन्फ़िगर नहीं कर पा रहा, या रिक्वेस्ट तो आ रही हैं पर सिग्नेचर सही साबित नहीं हो रहे।
- सीक्रेट नहीं मिल पाया या समय-सीमा निकल गई। प्राप्तकर्ता की फिर से पुष्टि करें और नया, नियंत्रित हैंडओवर करें। वैल्यू को टिकट में पेस्ट न करें, और क्लाइंट से तुलना के लिए उसकी वैल्यू वापस भेजने को न कहें।
- सिग्नेचर मेल नहीं खा रहा। लगभग हमेशा यह वेरिफ़िकेशन के इनपुट की समस्या होती है: उस एंडपॉइंट का गलत सीक्रेट, हैशिंग से पहले दोबारा फ़ॉर्मैट की गई बॉडी, या गलत तरीके से पढ़ा गया हेडर। क्लाइंट से भेजने वाले के टेस्टिंग टूल के ज़रिए किसी जाने-पहचाने इवेंट से टेस्ट करवाएं।
- रिक्वेस्ट पहुंचती ही नहीं। यह डिलीवरी या रूटिंग की समस्या है, क्रेडेंशियल की नहीं। रोटेशन के बारे में सोचने से पहले टाइमस्टैंप, रिस्पॉन्स कोड और एंडपॉइंट का चुनाव जांचें। Stripe का webhook डॉक्यूमेंटेशन एक अच्छा उदाहरण है कि एंडपॉइंट रजिस्ट्रेशन और इवेंट डिलीवरी को सिग्नेचर वेरिफ़िकेशन से अलग कैसे रखा जाए।
- काट-छांट किए गए डायग्नोस्टिक्स शेयर करें। इवेंट id, टाइमस्टैंप, एंडपॉइंट और एरर की श्रेणी काफ़ी हैं। सीक्रेट, संवेदनशील होने पर पूरा सिग्नेचर और पेलोड के निजी फ़ील्ड हटा दें, और सैंपल रिक्वेस्ट भेजने से पहले जांच लें कि सब ठीक से हटा है।
प्राप्तकर्ता की पुष्टि करें, सीक्रेट एक बार ऐसे रास्ते से सौंपें जो उसे याद न रखे, पक्का करें कि वह सीक्रेट स्टोर में पहुंचे, और लीक की आशंका हो तो बिना झिझक रोटेट करें। इंजीनियरिंग के काम में वन-टाइम लिंक के बड़े पैटर्न के लिए डेवलपर के लिए सुरक्षित लिंक शेयरिंग देखें।