हर टीम एक दिन उस मोड़ पर पहुंचती है जहां लॉगिन की जानकारी बहुत सारी जगहों पर बिखरी होती है: हर लैपटॉप पर एक .env, Slack में पिन किया हुआ एक मैसेज, “logins” नाम की एक स्प्रेडशीट, और CI का एक वेरिएबल जिसे किसी ने दो साल पहले सेट किया था। क्लाउड सीक्रेट मैनेजर इसीलिए है कि यह सब एक ऐसी जगह पर आ जाए जो एन्क्रिप्टेड हो, जिसके एक्सेस पर कंट्रोल हो और जिसका ऑडिट होता हो।
यह गाइड बताती है कि क्लाउड सीक्रेट मैनेजर क्या करता है, मुख्य विकल्पों में से कैसे चुनें, लंबे माइग्रेशन के बिना इसे कैसे लागू करें, और वह एक काम जो यह नहीं करता: किसी ऐसे व्यक्ति तक सीक्रेट पहुंचाना जो आपके क्लाउड अकाउंट के अंदर नहीं है।
क्लाउड सीक्रेट मैनेजर क्या करता है
सीक्रेट मैनेजर संवेदनशील वैल्यू स्टोर करता है और मांगने पर उन्हें अधिकृत पहचानों को सौंपता है। मुख्य सुविधाएं हर प्रोवाइडर में एक जैसी हैं:
- एन्क्रिप्टेड स्टोरेज, जिसकी एन्क्रिप्शन कुंजियां प्रोवाइडर की key management service में रहती हैं, और भेजते समय TLS।
- पहचान पर आधारित एक्सेस: हर सीक्रेट की एक पॉलिसी होती है जो बताती है कि कौन-से यूज़र, रोल या वर्कलोड उसे पढ़, लिख या रोटेट कर सकते हैं। ऐप्लिकेशन अपनी पहचान से लॉग इन करता है, किसी मास्टर पासवर्ड से नहीं।
- ऑडिट लॉगिंग: हर बार पढ़ने, लिखने और रोटेट करने का रिकॉर्ड, कि किसने, क्या और कब किया।
- वर्ज़निंग और रोटेशन: नई वैल्यू पहले से तैयार रखी जा सकती है, ऐप्लिकेशन उस पर ले जाए जा सकते हैं, और पुराना वर्ज़न बंद किया जा सकता है। कई मैनेजर डेटाबेस की लॉगिन जानकारी अपने आप रोटेट करते हैं।
- रनटाइम पर लेना: ऐप्लिकेशन शुरू होते समय या ज़रूरत पड़ने पर सीक्रेट मंगाता है, इसलिए वैल्यू कभी कोड, इमेज या कॉन्फ़िग फ़ाइलों में नहीं लिखी जाती।
सीक्रेट वह हर चीज़ है जो किसी चीज़ का एक्सेस देती है। जो कॉन्फ़िगरेशन सिर्फ़ व्यवहार बताता है, जैसे पोर्ट नंबर या फ़ीचर फ़्लैग, वह आम कॉन्फ़िग में रहना चाहिए। दोनों को मिलाने से सीक्रेट स्टोर में बेकार की भीड़ हो जाती है और कॉन्फ़िग स्टोर खतरनाक बन जाता है।
इसे कैसे चुनें
फ़ैसला आम तौर पर इस पर टिकता है कि आपके वर्कलोड कहां चलते हैं और आप कितने क्लाउड इस्तेमाल करते हैं।
| विकल्प | किसके लिए सबसे सही | किस बात पर ध्यान दें |
|---|---|---|
| AWS Secrets Manager / Parameter Store | जो वर्कलोड पहले से AWS पर हैं, हर जगह IAM पहचान | Secrets Manager पर हर सीक्रेट के हिसाब से कीमत; सादी वैल्यू के लिए Parameter Store सस्ता है |
| Google Secret Manager | GCP प्रोजेक्ट, Cloud Run और GKE वर्कलोड | रीजनल रेप्लिकेशन के विकल्प |
| Azure Key Vault | Azure वर्कलोड, सर्टिफ़िकेट के पूरे जीवनचक्र की ज़रूरत | पॉलिसी सरल रखने के लिए हर एनवायरनमेंट का अलग वॉल्ट |
| HashiCorp Vault | मल्टी-क्लाउड या ऑन-प्रेम, कम समय तक चलने वाली डायनैमिक लॉगिन जानकारी | होस्टेड वर्ज़न न लें तो इसे खुद चलाना पड़ता है |
| Doppler, Infisical, 1Password Secrets Automation | छोटी टीमें जिन्हें कई प्लेटफ़ॉर्म के साथ डेवलपर के लिए आसान सिंक चाहिए | भरोसे की कड़ी में एक और वेंडर |
ज़्यादातर फ़ैसले चार सवालों से तय हो जाते हैं। क्या यह आपके डिप्लॉयमेंट टूल और रनटाइम के साथ बिना कस्टम जुगाड़ के जुड़ता है? क्या वर्कलोड अपनी मौजूदा पहचान से इसमें लॉग इन कर सकते हैं? क्या यह उन तरह की लॉगिन जानकारी को रोटेट करता है जो असल में आपके पास है? और क्या इसके ऑडिट लॉग वहां पहुंचते हैं जहां आपकी सिक्योरिटी टीम पहले से देखती है? कीमत, रीजन और कंप्लायंस सर्टिफ़िकेशन इन चार सवालों के बाद आते हैं।
छह महीने के प्रोजेक्ट के बिना इसे लागू करना
- सूची बनाएं और मालिक तय करें। हर सीक्रेट की सूची बनाएं: वह कहां रखा है, कौन उसे इस्तेमाल करता है और कौन उसका ज़िम्मेदार है। मालिक ही रोटेशन की पॉलिसी और एक्सेस की सूची तय करता है।
- पहले पहचानें सेट करें। एक भी वैल्यू ले जाने से पहले हर वर्कलोड और एनवायरनमेंट के लिए रोल या सर्विस अकाउंट बनाएं। “यह सर्विस, यह एनवायरनमेंट, सिर्फ़ पढ़ने का एक्सेस” जैसी पॉलिसी ही इसका असली मकसद है।
- जोखिम के क्रम में माइग्रेट करें। पहले प्रोडक्शन डेटाबेस के पासवर्ड और पेमेंट की कुंजियां, फिर थर्ड-पार्टी API keys, फिर बाकी सब। हर वैल्यू को ले जाते समय कोड, CI वेरिएबल और कॉन्फ़िग फ़ाइलों से हटा दें, और मैनेजर में डालते समय उसे रोटेट कर दें, क्योंकि पुरानी वैल्यू पहले ही इधर-उधर कॉपी हो चुकी है।
- ऐप्लिकेशन के सीक्रेट पढ़ने का तरीका बदलें। हार्ड-कोड की गई वैल्यू और एनवायरनमेंट फ़ाइलों की जगह स्टार्टअप पर मैनेजर के SDK को कॉल करें, या प्लेटफ़ॉर्म के अपने इंटीग्रेशन से उन्हें इंजेक्ट करें।
- रोटेशन चालू करें उन सबके लिए जिन्हें मैनेजर खुद रोटेट कर सकता है, और बाकी के लिए रोटेशन फ़ंक्शन या रनबुक लिखें।
- असामान्य गतिविधि पर अलर्ट लगाएं। किसी नई पहचान से सीक्रेट पढ़ा जाना, पढ़ने में अचानक उछाल, या ऐसे रीजन से पढ़ा जाना जहां आप डिप्लॉय नहीं करते, इन पर किसी को तुरंत जगाना चाहिए।
आम गलतियां पहले से पता होती हैं: माइग्रेशन के बाद पुरानी कॉपियां वहीं छोड़ देना, किसी वर्कलोड को सिर्फ़ उसके अपने सीक्रेट के बजाय पूरे स्टोर को पढ़ने का एक्सेस दे देना, और मंगाई गई वैल्यू को ऐप्लिकेशन लॉग में लिख देना।
वह कमी जो सीक्रेट मैनेजर पूरी नहीं करता
सीक्रेट मैनेजर मशीनों के लिए और आपके आइडेंटिटी सिस्टम के अंदर के लोगों के लिए बना है। यह उस पल के लिए नहीं बना जब लॉगिन की जानकारी उस सिस्टम के बाहर किसी तक पहुंचानी हो: ऐसा कॉन्ट्रैक्टर जिसे कुछ समय के लिए डेटाबेस पासवर्ड चाहिए, कोई क्लाइंट जिसे अपना पहला एडमिन लॉगिन मिल रहा है, किसी वेंडर का इंजीनियर जिसे एक दोपहर के लिए टोकन चाहिए, या पहले दिन का नया कर्मचारी जिसका SSO अकाउंट अभी बना ही नहीं।
लॉगिन की जानकारी ऐसे सौंपी तो जाती ही है, और अगर इसके लिए कोई मंज़ूर रास्ता न हो तो वह ईमेल और चैट से जाती है, यानी ठीक वहीं से जहां से लॉगिन की जानकारी हटाने के लिए सीक्रेट मैनेजर लाए गए थे। मंज़ूर रास्ता है वन-टाइम सीक्रेट लिंक, यानी एक बार खुलने वाला लिंक। वैल्यू स्टोर होने से पहले आपके ब्राउज़र में ही एन्क्रिप्ट होती है, मैसेज में सिर्फ़ एक लिंक जाता है, लिंक पहली बार खुलते ही स्टोर की गई कॉपी मिट जाती है, और कोई न खोले तो लिंक तय समय पर एक्सपायर हो जाता है।
जो तरीका काम करता है: सीक्रेट मैनेजर रिकॉर्ड की मुख्य जगह है, और जब सिस्टम के बाहर किसी व्यक्ति को कोई वैल्यू एक बार चाहिए, तो वन-टाइम लिंक उसे पहुंचाने का ज़रिया है। लॉगिन की जानकारी बनाएं, उसे मैनेजर में स्टोर करें, वन-टाइम लिंक से व्यक्ति को भेजें, और जब उसका एक्सेस खत्म हो तो उसे रोटेट कर दें। सीक्रेट लिंक बनाम पासवर्ड मैनेजर यही तर्क टीम के पासवर्ड मैनेजर पर लागू करता है, और टीमों के बीच लॉगिन की जानकारी सौंपने वाली गाइड रोज़ के तरीके को समझाती है।
एक छोटी चेकलिस्ट
- हर सीक्रेट का एक मालिक, एक एक्सेस पॉलिसी और एक रोटेशन नियम है।
- वर्कलोड अपनी पहचान से लॉग इन करते हैं, किसी साझा कुंजी से कभी नहीं।
- माइग्रेशन के बाद कोई भी सीक्रेट कोड, इमेज, CI वेरिएबल या चैट में नहीं है।
- सीक्रेट पढ़े जाने का लॉग ऐसी जगह जाता है जहां कोई व्यक्ति सच में देखता है।
- आइडेंटिटी सिस्टम के बाहर के लोगों को सीक्रेट वन-टाइम लिंक से मिलते हैं, मैसेज में नहीं।
ये पांच काम कर लें, तो सीक्रेट मैनेजर एक खरीदा हुआ प्रोडक्ट भर नहीं रह जाता। वही वजह बन जाता है जिससे लॉगिन की जानकारी लीक होना बंद हुआ।