मुफ़्त सपोर्ट टियर को भी असली उत्तर क्यों मिलने चाहिए
जो सपोर्ट कतार केवल भुगतान करने वाले ग्राहकों को सोच-समझकर उत्तर देती है, वह मुफ़्त उपयोगकर्ताओं से कह रही है कि उनके सवाल ठीक से हल करने लायक नहीं हैं।
कभी एक्सपायर न होने वाली API कुंजियों की समस्या
कभी समाप्त न होने वाली कुंजी ठीक उसी तरह सुविधाजनक है जिससे उसका अस्तित्व भूल जाना आसान हो जाता है। उसे एक बार बनाया जाता है, किसी कॉन्फ़िगरेशन फ़ाइल या एनवायरनमेंट वेरिएबल में डाला जाता है, और फिर वह बस अनिश्चित काल तक काम करती रहती है, और कोई दोबारा नहीं देखता कि उसे ऐसा करना चाहिए या नहीं। सालों बाद, जिसने उसे बनाया था वह शायद कंपनी छोड़ चुका हो, जिस प्रोजेक्ट के लिए वह बनाई गई थी वह बंद हो चुका हो, और कुंजी खुद किसी भूले हुए सर्वर, लीक हुई रिपॉज़िटरी, या पुराने बैकअप में पड़ी हो, फिर भी पूरी तरह मान्य, क्योंकि सिस्टम ने कभी उससे यह साबित करने को नहीं कहा कि उसकी अब भी ज़रूरत है।
यह एक असली, कम आँकी गई सुरक्षा समस्या है, काल्पनिक नहीं। कुंजियाँ कमिट की गई कॉन्फ़िगरेशन फ़ाइलों से, गलती से किसी अनुरोध हेडर को दर्ज कर लेने वाले लॉग से, और उस प्रोजेक्ट से ज़्यादा समय तक बचे पुराने बैकअप से लीक होती हैं जिसके वे थे। कभी समाप्त न होने वाली कुंजी का मतलब है कि लीक के ये सभी रास्ते अनिश्चित काल तक खतरनाक बने रहते हैं, और ऐसा कोई स्वाभाविक बिंदु नहीं होता जब जोखिम अपने आप बंद हो जाए। जो कुंजी समय-समय पर रोटेट या समीक्षा की जाती है, वह कम से कम यह सीमित करती है कि कोई लीक कितने समय तक दुरुपयोग लायक रहे, भले ही लीक का कभी पता न चला हो।
हमें नहीं लगता कि जवाब ऐसी समाप्ति तिथियाँ थोपना है जो बिना चेतावनी इंटीग्रेशन तोड़ दें, क्योंकि इससे एक समस्या की जगह दूसरी, उतनी ही झुँझलाने वाली समस्या आ जाती है: ऐसी कुंजी जो प्रोडक्शन के बीच में काम करना बंद कर दे, किसी ऐसी रोटेशन नीति के कारण जिसके बारे में किसी ने साफ़ नहीं बताया। जवाब है ऐसी दृश्यता और नियंत्रण जो रोटेशन को एक सोचा-समझा, जानकारी भरा फ़ैसला बनाएँ, न कि ऐसा कुछ जो या तो कभी होता ही नहीं या अचानक बिना योजना के होता है। हर रिस्पॉन्स पर कोटा हेडर, जिसमें यह गिनती भी शामिल है कि किसी कुंजी के कितने IP स्लॉट इस्तेमाल में हैं, लगातार संकेत देते हैं कि कुंजी का उपयोग पैटर्न अब भी उस उद्देश्य से मेल खाता है या नहीं जिसके लिए वह जारी की गई थी, और यही वह जानकारी है जिससे समय-समय पर “क्या इस कुंजी की अब भी ज़रूरत है” समीक्षा शुरू होनी चाहिए।
कुंजी को एक स्थायी, एक बार इंस्टॉल करके भूल जाने वाला क्रेडेंशियल मानने की उद्योग की व्यापक आदत इस बात से आती है कि उस क्रेडेंशियल के पूरे जीवनकाल के बजाय शुरुआती इंटीग्रेशन की सुविधा को प्राथमिकता दी जाती है। पहले दिन ऐसी कुंजी बनाना सच में आसान है जिसे फिर कभी छूना न पड़े। वह सुविधा शुरुआत में मिलती है, और उसकी लागत, यानी कहीं पड़ी एक पुरानी, बिना निगरानी वाली, बिना रोटेट की गई कुंजी जो स्थायी जोखिम है, भविष्य की किसी ऐसी घटना पर टल जाती है जिसके बारे में पहले दिन कोई नहीं सोच रहा।
हमें लगता है कि बेहतर डिफ़ॉल्ट यह है कि कुंजी को एक स्थिर इंस्टॉलेशन से कम और ऐसे क्रेडेंशियल से ज़्यादा माना जाए जिसका खाते के साथ लगातार रिश्ता हो: अपने किए अनुरोधों के ज़रिए रियल टाइम में दिखाई देने वाली, समय-समय पर समीक्षा योग्य, और जिस प्रोजेक्ट की वह थी उसके सच में ख़त्म होने पर बिना झंझट के रद्द की जा सकने वाली। इसमें से किसी के लिए भी किसी पर समाप्ति थोपने की ज़रूरत नहीं है। ज़रूरत इस बात की है कि यह देखना इतना आसान हो कि कोई कुंजी असल में क्या कर रही है कि किसी पुरानी कुंजी को हमेशा के लिए पड़े रहने देना सबसे आसान रास्ता न रहे।