API key सुरक्षित तरीके से कैसे शेयर करें

API key को चैट या ईमेल में पेस्ट न करें। उसे वन-टाइम सीक्रेट लिंक से भेजें: key आपके ब्राउज़र में ही एन्क्रिप्ट होती है, उसे खोलने वाली कुंजी लिंक में # के बाद के हिस्से में रहती है, और स्टोर की गई कॉपी एक बार खुलते ही मिट जाती है। जो key पहले ही सादे टेक्स्ट में पेस्ट हो चुकी है, उसे रोटेट कर दें।

यह गाइड बाकी ब्योरा देती है: आम चैनल क्यों फ़ेल होते हैं, हैंडओवर का ठीक-ठीक तरीका, key लीक हो जाए तो क्या करें, और किन मामलों में वन-टाइम लिंक सही टूल नहीं है।

Slack या ईमेल में API key भेजना असुरक्षित क्यों है?

क्योंकि दोनों मैसेज को तब तक रखते हैं जब तक कोई भी चीज़ उसे संभाले रखती है, और रास्ते में उसे हर डिवाइस और हर एक्सपोर्ट में कॉपी कर देते हैं।

• दोनों में हमेशा सर्च किया जा सकता है। 2023 में शेयर की गई key से ही आपकी अगली सुरक्षा घटना शुरू हो सकती है। जो हमलावर किसी कंपनी की चैट या मेलबॉक्स में घुस जाते हैं, वे अक्सर ठीक उन्हीं स्ट्रिंग को सर्च करते हैं जो API key जैसी दिखती हैं: sk_live, AKIA, ghp_, Bearer।
• दोनों हर जगह सिंक होते हैं। फ़ोन, निजी लैपटॉप, टैबलेट: ऐसे डिवाइस जो आपके सुरक्षा कंट्रोल के दायरे से बाहर हैं और जिन तक आपकी रिमोट-वाइप पॉलिसी नहीं पहुंचती।
• दोनों एक्सपोर्ट होते हैं। कंप्लायंस रिव्यू, कानूनी जांच और वर्कस्पेस एक्सपोर्ट, सबमें हिस्ट्री की कॉपी बनती है। हर एक्सपोर्ट एक और जगह है जहां key मौजूद रहती है।
• ऑफ़बोर्डिंग के बाद भी दोनों बने रहते हैं। कॉन्ट्रैक्टर का काम खत्म हो जाता है, लेकिन वह DM थ्रेड बना रहता है जिसमें आपकी Stripe key पड़ी है।

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

शेयर करने से पहले: key को छोटा करें

सबसे अच्छा हैंडओवर वह है जिसमें सौंपी जा रही key से लगभग कोई फ़र्क न पड़े। कुछ भी बनाने से पहले, key जहां से बनती है वहीं कम से कम अधिकार का नियम लागू करें:

• दायरा सीमित करें। Stripe restricted keys, GitHub fine-grained personal access tokens, खास actions और resources तक सीमित AWS IAM पॉलिसी: ज़्यादातर गंभीर प्रोवाइडर ऐसी key बनाने देते हैं जो सिर्फ़ वही एक काम कर सके जिसकी प्राप्तकर्ता को ज़रूरत है।
• सिर्फ़ पढ़ने का ऐक्सेस दें, जब तक लिखने की सच में ज़रूरत न हो।
• प्रोवाइडर की तरफ़ एक्सपायरी सेट करें, जहां प्लेटफ़ॉर्म इसकी सुविधा देता है (GitHub fine-grained PATs, STS से AWS के अस्थायी क्रेडेंशियल)। तब लीक हुई key की भी एक तय उम्र होती है, चाहे आप बाद में कुछ भी करें या न करें।
• key का नाम प्राप्तकर्ता के नाम पर रखें (vendor-x-readonly), ताकि छह महीने बाद उसे वापस लेने का फ़ैसला एक नज़र में हो जाए, उसके लिए पुराने रिकॉर्ड न खंगालने पड़ें।

सीमित दायरे वाली, एक्सपायर होने वाली, सिर्फ़ पढ़ने वाली key से सबसे बुरा लीक भी सुरक्षा घटना नहीं, बस एक झंझट बनकर रह जाता है।

हैंडओवर का तरीका

1. key उसी सिस्टम में बनाएं जहां वह इस्तेमाल होगी (AWS, Stripe, आपका अपना API), ऊपर बताए अनुसार कम से कम अधिकारों के साथ।
2. उसे वन-टाइम सीक्रेट लिंक में पेस्ट करें, “पढ़ने के बाद मिटाएं” चालू रखें और काम के हिसाब से सबसे छोटी एक्सपायरी चुनें: सबसे छोटा प्रीसेट 1 घंटा है, उसके बाद 24 घंटे और 7 दिन, और Pro पर अपनी पसंद की तारीख और समय। बस असली हैंडओवर के लिए जितना समय चाहिए, उससे ज़्यादा नहीं।
3. पासफ़्रेज़ जोड़ें और उसे किसी दूसरे चैनल से भेजें: लिंक ईमेल से, पासफ़्रेज़ SMS या Slack DM से। LinkPilot में पासफ़्रेज़, अपनी पसंद की एक्सपायरी और ऑडिट टाइमलाइन Pro की सुविधाएं हैं, $29/माह पर। अगर किसी एक चैनल से लीक हो भी जाए, तो हमलावर के पास पहेली का आधा हिस्सा ही होता है। (LinkPilot पासफ़्रेज़ को भेजने से पहले ब्राउज़र में ही SHA-256 से हैश करता है; असली पासफ़्रेज़ सर्वर के डेटाबेस या लॉग तक कभी नहीं पहुंचता, और कोशिशें हर IP से हर मिनट 5 तक सीमित हैं।)
4. लिंक भेज दें।
5. किसी दूसरे चैनल से पुष्टि करें कि प्राप्तकर्ता ने उसे खोल लिया है, और ऑडिट टाइमलाइन देखें: एक बार खुला, उम्मीद के समय पर, उम्मीद की जगह से। यही आपकी रसीद है।

अगर एक्सपायरी तक लिंक नहीं खुलता, तो उसे वापस लें और नया लिंक भेजें। एक्सपायरी न बढ़ाएं और वही लिंक दोबारा इस्तेमाल न करें।

उदाहरण: Stripe restricted key भेजना

# generate a restricted key with the minimum needed scopes
stripe api_keys create \
  --restricted \
  --display-name "vendor-x-readonly"

# pipe the resulting key into a LinkPilot secret
curl -X POST https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -d 'payload=sk_restricted_…' \
  -d 'expires_in=3600' \
  -d 'burn_after_read=true'

प्राप्तकर्ता को क्या दिखता है: लिंक खोलने पर “दिखाएं” वाला पेज खुलता है, key नहीं। लिंक प्रीव्यू बॉट और ईमेल स्कैनर, जो URL को पहले से लोड कर लेते हैं, सिर्फ़ मेटाडेटा पाते हैं, क्योंकि लिंक का खुलना सिर्फ़ “दिखाएं” पर साफ़ क्लिक से दर्ज होता है, GET से कभी नहीं। प्राप्तकर्ता “दिखाएं” पर क्लिक करता है (और पासफ़्रेज़ सेट हो तो उसे डालता है), तब key ठीक एक बार दिखती है। उसके बाद स्टोर किए गए डेटा पर दूसरा डेटा लिख दिया जाता है और लिंक HTTP 410 लौटाता है। अगर ईमेल पूरी कंपनी में फ़ॉरवर्ड होता रहे, तब भी सिर्फ़ पहला व्यक्ति ही उसे पढ़ सकता था, और ऑडिट रिकॉर्ड आपको बताता है कि वह कौन था।

किस हैंडओवर के लिए कौन-सा चैनल

API key लीक हो जाए तो क्या करें?

उसे एक्सपोज़ हुआ मानें और प्रोवाइडर के यहां उसे रोटेट करें; मैसेज डिलीट करने से कुछ नहीं होता। जो भी key किसी चैट मैसेज, ईमेल, स्क्रीनशॉट, git commit या सार्वजनिक पेस्ट में आई है, वह इसी गिनती में है। इस क्रम में:

1. पहले नई key जारी करें, अगर प्रोवाइडर एक साथ दो चालू keys रखने देता है। इससे सही इस्तेमाल करने वालों का काम नहीं रुकता।
2. लीक हुई key को प्रोवाइडर के यहां वापस लें। सिर्फ़ यही कदम असल में खतरा खत्म करता है; Slack मैसेज डिलीट करने से यह नहीं होता।
3. नई key ठीक तरीके से सौंपें: वन-टाइम लिंक, पासफ़्रेज़, छोटी एक्सपायरी, ऊपर बताए तरीके से।
4. प्रोवाइडर के इस्तेमाल वाले लॉग देखें, लीक होने से लेकर वापस लिए जाने तक उस key से क्या हुआ। अनजान कॉल दिखें तो मतलब यह अब सफ़ाई का काम नहीं, सुरक्षा घटना है।
5. जहां से पेस्ट हुआ, वह वजह ठीक करें: सीक्रेट को अपने .gitignore में शामिल env टूलिंग में डालें, रिपॉज़िटरी होस्ट पर secret scanning चालू करें, या वह रनबुक अपडेट करें जिसमें किसी को key DM करने को कहा गया था।

यह पूरा काम कुछ मिनट में हो जाना चाहिए। अगर key रोटेट करना इतना डरावना है कि लोग उससे बचते हैं, तो असली कमज़ोरी वही नाज़ुकपन है। पहले उसे ठीक करें।

किन चीज़ों से बचें

• वही सीक्रेट दोबारा भेजना। इसके बजाय रोटेट करें। दोबारा भेजने से ऑडिट का “ठीक एक बार दिखा” वाला रिकॉर्ड खत्म हो जाता है, जिसकी वजह से वन-टाइम लिंक इस्तेमाल करना फ़ायदेमंद था।
• लंबी एक्सपायरी। छोटी एक्सपायरी को डिफ़ॉल्ट रखें। ज़्यादातर हैंडओवर कुछ मिनट में हो जाते हैं; 8 घंटे की अवधि बस ज़्यादा लंबा लीक है।
• पासफ़्रेज़ छोड़ देना। इसमें लगभग कुछ नहीं लगता और यह गलती से URL लीक होने से बचाता है: फ़ॉरवर्ड किए गए ईमेल, स्क्रीन शेयर, साझा स्क्रीन पर किसी का कंधे के ऊपर से झांकना।
• keys के स्क्रीनशॉट। ये कैमरा रोल, क्लाउड फ़ोटो सिंक और इमेज सर्च में पहुंच जाते हैं। स्क्रीनशॉट भी चैट में पेस्ट करने जितना ही स्थायी है, बस आपके लिए उसमें सर्च करना मुश्किल है और OCR के लिए आसान।
• लिंक टूल को स्टोरेज की तरह इस्तेमाल करना। लिंक कूरियर है, वॉल्ट नहीं। key मिलते ही प्राप्तकर्ता को उसे पासवर्ड मैनेजर या env टूलिंग में स्टोर कर लेना चाहिए।

कब वन-टाइम लिंक सही टूल नहीं है

ईमानदारी से कहें तो इस तरीके की भी सीमाएं हैं:

• मशीन से मशीन वाले क्रेडेंशियल सीक्रेट मैनेजर या प्लेटफ़ॉर्म के अपने स्टोर में रहने चाहिए, जहां से वे डिप्लॉय या रनटाइम पर डाले जाएं। किसी इंसान का लिंक पर क्लिक करना डिप्लॉयमेंट का कदम नहीं है।
• लंबे समय तक साझा रहने वाले क्रेडेंशियल पासवर्ड मैनेजर में रहने चाहिए, जहां असली ऐक्सेस कंट्रोल हो और हर व्यक्ति का ऐक्सेस अलग से वापस लिया जा सके।
• बार-बार रोटेशन (हर घंटे बदलने वाली keys) शुरू से अंत तक ऑटोमेट होनी चाहिए; उस प्रक्रिया में इंसानों और लिंक की कोई जगह नहीं होनी चाहिए।
• ऐसे सीक्रेट जिन्हें किसी भी तीसरे पक्ष के हाथ लगने का जोखिम आप नहीं उठा सकते: हैंडओवर ऑफ़लाइन करें। अपडेट, 29 सितंबर 2026: इस बिंदु में पहले लिखा था कि LinkPilot E2EE का दावा नहीं करता और इसकी जगह कोई एंड-टू-एंड एन्क्रिप्टेड टूल इस्तेमाल करें। अब LinkPilot टेक्स्ट को ब्राउज़र में ही एन्क्रिप्ट करता है, इसलिए वह सिर्फ़ एन्क्रिप्ट किया हुआ डेटा स्टोर करता है, और साथ में जोड़ी गई फ़ाइलें भी इसी तरह। सिक्योरिटी आर्किटेक्चर पेज ठीक-ठीक बताता है कि क्या सुरक्षित है और क्या नहीं।

आम मामले में, जब एक व्यक्ति किसी दूसरे व्यक्ति को एक क्रेडेंशियल एक बार सौंपता है, पासफ़्रेज़ और छोटी एक्सपायरी वाला वन-टाइम लिंक आसान तरीकों में सबसे मज़बूत है।

और पढ़ें

• URL से संवेदनशील जानकारी क्यों लीक होती है
• पासवर्ड सुरक्षित तरीके से शेयर करना: 5 तरीकों की तुलना
• LinkPilot सिक्योरिटी आर्किटेक्चर
• URL शॉर्टनर API की तुलना
• मुफ़्त सीक्रेट लिंक जनरेटर

संदर्भ

• Stripe Docs, API keys: limit access with restricted keys.
• GitHub Docs, Managing your personal access tokens.
• AWS IAM User Guide, Temporary security credentials in IAM.