SSH की और सर्टिफ़िकेट टीम के साथ सुरक्षित तरीक़े से कैसे शेयर करें

"बस SSH की Slack पर भेज दो।" हर डेवलपमेंट टीम ने यह बात सुनी है। सर्वर एक्सेस की जल्दी है, टीम के नए सदस्य को अपना एनवायरनमेंट सेट करना है, डिप्लॉयमेंट में कुछ ही मिनट बचे हैं और किसी के पास की नहीं है।

लेकिन यही एक अनुरोध किसी गंभीर सुरक्षा घटना की शुरुआत बन सकता है।

SSH की शेयर करना ख़ास तौर पर ख़तरनाक क्यों है

SSH की आम पासवर्ड जैसी नहीं होती। इससे सर्वर का पूरा एक्सेस मिल जाता है।

पहलू	पासवर्ड	SSH की
दायरा	एक ख़ास अकाउंट	पूरा सर्वर
लीक होने पर असर	सिर्फ़ वह अकाउंट	सर्वर का सारा डेटा
बदलना कितना आसान	तुरंत बदल सकते हैं	की दोबारा बनाएँ + सभी सर्वर अपडेट करें
2FA सपोर्ट	उपलब्ध	की ख़ुद ही ऑथेंटिकेशन है

लीक हुई SSH की सर्वर की हर फ़ाइल, हर डेटाबेस और कोड का हर हिस्सा उजागर कर देती है। यह किसी एक पासवर्ड के लीक होने से बुनियादी तौर पर अलग है।

टीमों को SSH की शेयर करने की ज़रूरत कब पड़ती है

सच कहें तो शेयर करने की कुछ जायज़ वजहें होती हैं।

• साझा सर्वर एक्सेस: स्टेजिंग या प्रोडक्शन सर्वर, जिनकी पूरी टीम को ज़रूरत है
• डिप्लॉय की: CI/CD पाइपलाइन में इस्तेमाल होने वाली की
• SSL सर्टिफ़िकेट: ज़िम्मेदारी बदलने पर सर्टिफ़िकेट का नवीनीकरण
• API सीक्रेट: थर्ड-पार्टी इंटीग्रेशन के लिए ऑथेंटिकेशन क्रेडेंशियल
• डेटाबेस क्रेडेंशियल: आपात स्थिति में इंसिडेंट रिस्पॉन्स

शेयर करने के ख़तरनाक तरीक़े

1. Slack या Discord DM

इनमें से कोई भी सर्विस एंड-टू-एंड एन्क्रिप्शन इस्तेमाल नहीं करती, और डिफ़ॉल्ट रूप से चैट हिस्ट्री उनके सर्वर पर लंबे समय तक सहेजी रहती है। बातचीत में शामिल कोई भी व्यक्ति "ssh" या "key" खोजकर पहले शेयर की गई की ढूँढ सकता है। कर्मचारी के जाने पर उसका अकाउंट डीएक्टिवेट किया जा सकता है, लेकिन उसने जो की भेजीं और पाईं, वे वर्कस्पेस हिस्ट्री में बनी रहती हैं।

2. ईमेल

मेल सर्वर पर हमेशा के लिए आर्काइव हो जाता है और एक बार फ़ॉरवर्ड होने के बाद उस पर कोई नियंत्रण नहीं रहता। मेल सर्वर में एक ही सेंध अब तक भेजी गई हर की को उजागर कर देती है।

3. साझा Google Drive या Notion

बारीक स्तर पर एक्सेस नियंत्रित करना मुश्किल है। फ़ाइलें सिंक होने पर डिवाइस पर लोकल कॉपी रह जाती हैं। किसी के टीम छोड़ने पर सारी कॉपियाँ वापस लेना व्यावहारिक रूप से नामुमकिन है।

4. Git रिपॉज़िटरी में कमिट करना

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

शेयर करने के सुरक्षित तरीक़े

तरीक़ा 1: LOCK.PUB गुप्त मेमो (एक बार भेजने के लिए सबसे अच्छा)

जब आपको कोई की सिर्फ़ एक बार भेजनी हो, तब यह सबसे व्यावहारिक समाधान है।

1. LOCK.PUB पर गुप्त मेमो बनाएँ
2. SSH की या सर्टिफ़िकेट का कंटेंट पेस्ट करें
3. मज़बूत पासवर्ड सेट करें
4. जितनी कम हो सके उतनी समय सीमा सेट करें (1-4 घंटे) (Pro)
5. लिंक Slack से भेजें, पासवर्ड फ़ोन पर बताएँ
6. प्राप्तकर्ता के की को लोकल रूप से सहेज लेने के बाद लिंक एक्सपायर हो जाता है

फ़ायदे:

• की किसी स्थायी सर्वर पर प्लेनटेक्स्ट में सहेजी नहीं रहती
• समय सीमा ख़त्म होने के बाद लिंक खुलता नहीं
• चैट हिस्ट्री में की का प्लेनटेक्स्ट नहीं रहता

तरीक़ा 2: सीक्रेट मैनेजर (बड़ी टीमों के लिए)

HashiCorp Vault, AWS Secrets Manager या Google Secret Manager जैसे समर्पित टूल इस्तेमाल करें।

• एक्सेस कंट्रोल और ऑडिट लॉग शामिल
• की का ऑटोमैटिक रोटेशन संभव (Vault और AWS में बिल्ट-इन; Google Secret Manager सिर्फ़ रोटेशन की सूचना भेजता है, इसलिए रोटेशन आपको ख़ुद बनाना होता है)
• लागत और सेटअप की जटिलता इसकी कमियाँ हैं

तरीक़ा 3: SSH सर्टिफ़िकेट अथॉरिटी (लंबी अवधि का समाधान)

साझा की के बजाय SSH CA चलाएँ, जो हर यूज़र को अलग सर्टिफ़िकेट जारी करे।

• की शेयर करने की ज़रूरत पूरी तरह ख़त्म
• हर यूज़र के हिसाब से एक्सेस मैनेजमेंट
• शुरुआती सेटअप की लागत ज़्यादा

तरीक़ा 4: हर यूज़र की अलग की (सबसे ज़्यादा अनुशंसित)

जहाँ संभव हो, पूरी टीम में एक की शेयर करने के बजाय हर व्यक्ति को अलग की दें।

सिद्धांत: साझा की < अलग-अलग की
साझा की लीक → पूरी टीम प्रभावित
अलग की लीक → सिर्फ़ वही यूज़र प्रभावित

जब शेयर करना ही पड़े, तब की चेकलिस्ट

अगर हर यूज़र को अलग की देना संभव नहीं है और शेयर करना ज़रूरी है, तो यह चेकलिस्ट अपनाएँ।

भेजने से पहले

• क्या आपने की के लिए न्यूनतम अनुमति का दायरा तय किया है?
• क्या सिर्फ़ रीड-ओनली की से काम चल जाएगा?
• क्या आप IP प्रतिबंध लगा सकते हैं?

भेजते समय

• क्या आप की और पासवर्ड अलग-अलग माध्यमों से भेज रहे हैं?
• क्या आपने व्यावहारिक रूप से सबसे कम समय सीमा सेट की है?
• क्या प्राप्तकर्ता की पुष्टि के बाद भेजने वाला मूल कॉपी डिलीट कर सकता है?

भेजने के बाद

• पुष्टि करें कि प्राप्तकर्ता ने की सुरक्षित रूप से सहेज ली है
• जाँचें कि शेयर किया गया लिंक/मेमो एक्सपायर हो गया है
• की के इस्तेमाल के लॉग पर नज़र रखें

की रोटेशन शेड्यूल

नियमित रूप से की बदलने से किसी भी लीक हुई की के मान्य रहने की अवधि सीमित हो जाती है।

की का प्रकार	अनुशंसित रोटेशन
प्रोडक्शन सर्वर की	90 दिन
डिप्लॉय की	90 दिन
SSL सर्टिफ़िकेट	हर नवीनीकरण पर
API सीक्रेट	90 दिन
डेवलपमेंट/स्टेजिंग की	180 दिन

DevOps टीमों के लिए सुरक्षा चेकलिस्ट

• क्या सभी सर्वरों के लिए अलग-अलग SSH की इस्तेमाल होती हैं?
• अगर साझा की मौजूद हैं, तो क्या IP प्रतिबंध लगाए गए हैं?
• क्या नौकरी छोड़ने वाले कर्मचारियों की की तुरंत निष्क्रिय की जाती हैं?
• क्या की रोटेशन का शेड्यूल तय है?
• क्या कभी कोई SSH की Git रिपॉज़िटरी में कमिट हुई है?
• क्या कोई की चैट हिस्ट्री में प्लेनटेक्स्ट में पड़ी है?
• क्या गुप्त जानकारी भेजने के लिए एक्सपायर होने वाला माध्यम इस्तेमाल होता है?

सारांश

SSH की और सर्टिफ़िकेट सर्वर सुरक्षा की रीढ़ हैं। इन्हें Slack DM या ईमेल से भेजना अपने घर की चाबी सार्वजनिक नोटिस बोर्ड पर टाँगने जैसा है। जहाँ संभव हो, हर यूज़र को अलग की दें। जब शेयर करना टाला न जा सके, तो सबसे कम समय सीमा वाला गुप्त मेमो इस्तेमाल करें।

SSH की सुरक्षित रूप से भेजने के लिए अभी एक गुप्त मेमो बनाएँ।

गुप्त मेमो बनाएँ