पेमेंट API key रोटेशन: एक्सेस रजिस्टर से वेरिफ़िकेशन तक

सीक्रेट रोटेशन पूरा हुआ: प्रोडक्शन key सभी मुख्य सर्विसेज़ में सफलतापूर्वक बदल दी गई। एक हफ़्ते बाद रिकंसिलिएशन बनना बंद हो गया: एक भूली हुई स्क्रिप्ट अब भी पुराना सीक्रेट इस्तेमाल कर रही थी। औपचारिक रूप से रोटेशन हो गया, लेकिन ऑपरेशनल रूप से वह पूरा नहीं हुआ। पेमेंट एक्सेस का प्रबंधन इस्तेमाल करने वालों के रजिस्टर से शुरू होता है, उनमें वे भी शामिल हैं जो ज़्यादातर समय चुप रहते हैं।

सीक्रेट के बिना एक्सेस का नक्शा बनाइए

हर key के लिए मालिक, एनवायरनमेंट, प्रोवाइडर अकाउंट, मकसद, अनुमत कार्रवाइयाँ, इस्तेमाल करने वालों की सूची और रद्द करने का तरीका लिखिए। रजिस्टर में सुरक्षित वॉल्ट के लिंक होने चाहिए, key की वैल्यू नहीं। कभी-कभार चलने वाले जॉब्स को अलग से चिह्नित कीजिए: साप्ताहिक एक्सपोर्ट, बैकअप हैंडलर और सपोर्ट की मैनुअल यूटिलिटी। सामान्य ऐप्लिकेशन अपडेट में इन्हें ही भूलना सबसे आसान है।

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

एक्सेस को काम के हिसाब से बाँटिए

तीन अंदरूनी सर्विसेज़ वाले एक प्लेटफ़ॉर्म की कल्पना कीजिए। «कलेक्शन» अनुमत पेमेंट ट्रांज़ैक्शन बनाती है। «रिपोर्ट» रिकंसिलिएशन के लिए ज़रूरी जानकारी पढ़ती है। «रिफ़ंड» मंज़ूर किए गए रिफ़ंड पूरे करती है। प्रस्तावित ढाँचे में रिपोर्टिंग प्रोसेस को पैसे भेजने का अधिकार सिर्फ़ इसलिए नहीं मिलता कि एक साझा key सेट करना आसान है। रिफ़ंड सर्विस को अपना एक्सेस और कार्रवाइयों का अलग इतिहास मिलता है।

वेबहुक के सिग्नेचर की जाँच उसी के लिए बने मैकेनिज़्म से होती है। अगर हैंडलर को अतिरिक्त रूप से मौजूदा स्टेटस पूछना है, तो उसे ज़रूरी रीड अनुमतियाँ दीजिए। नोटिफ़िकेशन के साइनिंग सीक्रेट और API कॉल की सर्वर key को «पेमेंट का पासवर्ड» जैसी एक ही चीज़ मत बनाइए। इनका मकसद और बदलने की प्रक्रिया अलग हो सकती है।

टेस्ट और प्रोडक्शन एनवायरनमेंट की सेटिंग्स और एक्सेस भी अलग होने चाहिए। टेस्टिंग रिपोर्ट में, अगर अंदरूनी नियम अनुमति देते हैं, सीक्रेट या कॉन्फ़िगरेशन के वर्ज़न का आईडी लिखिए, पूरा सीक्रेट नहीं। ऑपरेटर को key की वैल्यू खोले बिना पता होना चाहिए कि वह किस एनवायरनमेंट पर काम कर रहा है।

वॉल्ट से ऐप्लिकेशन तक का रास्ता सुरक्षित कीजिए

सीक्रेट वॉल्ट एक ऐसी सर्विस है जो एक्सेस को नियंत्रित करती है और ऐप्लिकेशन को वैल्यू देती है। लेकिन उसका होना इस सवाल का जवाब नहीं देता कि सीक्रेट कौन पढ़ सकता है। AWS इन्फ़्रास्ट्रक्चर के लिए IAM डॉक्यूमेंटेशन वर्कलोड के लिए न्यूनतम अनुमतियों और अस्थायी क्रेडेंशियल्स की सलाह देता है। यह AWS एक्सेस से जुड़ा है; ऐसी भूमिका अपने आप में किसी बाहरी पेमेंट प्रोवाइडर की key की जगह नहीं लेती।

जाँचिए कि ऐप्लिकेशन वैल्यू कहाँ से लेता है, कौन-से प्रोसेस उसे पढ़ सकते हैं और गलती होने पर वह कहाँ पहुँच सकती है। सुरक्षित जाँच के लिए असली सीक्रेट की जगह एक कृत्रिम मार्कर इस्तेमाल कीजिए और टेस्ट लॉग, बिल्ड रिपोर्ट और डायग्नॉस्टिक पेजों से उसका रास्ता ट्रैक कीजिए। ऐसा टेस्ट यह साबित नहीं करता कि कोई लीक नहीं है, लेकिन खास अनचाही कॉपियाँ पकड़ने में मदद करता है।

OWASP सीक्रेट्स के इस्तेमाल के ऑडिट और उनके लाइफ़साइकल का वर्णन करता है। व्यावहारिक रजिस्टर में यह दिखना उपयोगी है कि किस सर्विस को एक्सेस मिला, वर्ज़न कब बदला और बदलाव को किसने मंज़ूरी दी। इसके लिए लॉग में सीक्रेट की वैल्यू की ज़रूरत नहीं है।

नियोजित बदलाव को जाँचने योग्य प्रक्रिया की तरह चलाइए

1. 1.प्रोवाइडर के नियम स्पष्ट कीजिए: क्या एक साथ कई सक्रिय keys हो सकती हैं, कौन-सी अनुमतियाँ ट्रांसफ़र करनी हैं और पुरानी key कैसे रद्द करनी है।
2. 2.मंज़ूर सुरक्षित प्रक्रिया से नई key तैयार कीजिए और उसे वॉल्ट में रखिए।
3. 3.ज्ञात सूची के अनुसार इस्तेमाल करने वालों को अपडेट कीजिए। अगर keys का समानांतर काम करना अनुमत है, तो सीमित ट्रांज़िशन विंडो रखिए; वरना स्विच करने का उपयुक्त क्रम तय कीजिए।
4. 4.अनुमत कार्रवाइयाँ और अपेक्षित पाबंदियाँ जाँचिए। एक सफल रीड रिक्वेस्ट यह साबित नहीं करती कि सभी ज़रूरी फ़ंक्शन काम कर रहे हैं।
5. 5.पक्का कीजिए कि कभी-कभार चलने वाले जॉब्स भी अपडेट हो गए हैं, फिर पुरानी key रद्द कीजिए और जाँचिए कि उसका इस्तेमाल जारी नहीं है।

एक काल्पनिक उदाहरण में बदलाव के बाद ऐप्लिकेशन चल रहा है, लेकिन साप्ताहिक रिकंसिलिएशन में अब भी पुराना कॉन्फ़िगरेशन है। इस्तेमाल करने वालों का रजिस्टर अगली बार चलने से पहले इसे पकड़ने देता है। कुछ दिनों बाद किसी अचानक एरर का इंतज़ार करने के बजाय दुर्लभ प्रोसेस को पहले से जाँच में शामिल कीजिए।

वह जाँचिए जो key के लिए वर्जित है

रिपोर्ट का सफल रीड दिखाता है कि key रिपोर्ट पढ़ सकती है। इससे यह पुष्टि नहीं होती कि उसके पास रिफ़ंड करने का अधिकार नहीं है। हर अनुमति सेट के लिए उपयुक्त सुरक्षित एनवायरनमेंट में नेगेटिव टेस्ट बनाइए: भूमिका से बाहर की कार्रवाई अस्वीकार होनी चाहिए। पाबंदी को असली पैसे वाले किसी रैंडम ट्रांज़ैक्शन से मत परखिए; प्रोवाइडर का दिया तरीका और मंज़ूर टेस्ट सीनेरियो इस्तेमाल कीजिए।

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

असली सीक्रेट के बिना रिहर्सल

एक टेबलटॉप एक्सरसाइज़ कीजिए: «डायग्नॉस्टिक आर्काइव में key मिली»। एक्सेस कौन रद्द कर सकता है, बैकअप लॉगिन किसके पास है, कौन-से ऑपरेशन रुकेंगे, इस्तेमाल के निशान कहाँ खोजें? इंसिडेंट से पहले जवाब तैयार रखिए। प्रोडक्ट टीम अलग से तय करती है कि नई key डिप्लॉय न होने तक सर्विस सुरक्षित रूप से कैसे बर्ताव करे: किसी दूसरे के अकाउंट या टेस्ट डिटेल्स पर चुपचाप चले जाने से साफ़ ठहराव बेहतर है।

बदलाव के बाद सिर्फ़ ऑथराइज़ेशन एरर ही नहीं, अपेक्षित काम के गायब होने पर भी नज़र रखिए। रात की रिपोर्ट मुख्य ऐप्लिकेशन में कोई अलार्म बजाए बिना बस बनना बंद हो सकती है। रोटेशन के पूरा होने को जाँचे गए उपभोक्ताओं की सूची से जोड़िए, जिसमें दुर्लभ जॉब्स भी हों। ऐसा रिकॉर्ड «सीक्रेट अपडेट हो गया» वाले निशान से ज़्यादा उपयोगी है, क्योंकि यह बिज़नेस के लिए नतीजा बताता है।

लीक प्राथमिकताएँ बदल देता है

लीक का शक होने पर इंसिडेंट प्रक्रिया के मुताबिक काम कीजिए: प्रभावित एक्सेस को तुरंत रद्द कीजिए या बदलिए, इस्तेमाल का आकलन कीजिए और ज़रूरी सबूत सुरक्षित तरीके से सहेजिए। जल्दी बहाली के लिए लीक हुई key पर वापस मत जाइए। फ़ाइल के आखिरी वर्ज़न से लाइन हटाने से पहले बन चुकी कॉपियाँ खत्म नहीं होतीं और यह रद्द करने की जगह नहीं लेता।

नियंत्रित इंटीग्रेशन चार सवालों का जवाब दे सकता है: key का इस्तेमाल कौन करता है, उसे क्या करने की अनुमति है, उसे कैसे बदलें और कैसे पक्का करें कि पुराना एक्सेस अब काम नहीं करता। एक सर्विस से शुरुआत कीजिए और इस श्रृंखला को जाँचे गए नतीजे तक पहुँचाइए।