API कुंजी सुरक्षा चार आदतों पर टिकी है: हर कुंजी को उतनी ही अनुमतियां दें जितनी उसे चाहिए, उसे उचित सीक्रेट स्टोर में रखें, बिना डाउनटाइम के रोटेट करें, और उस दिन के लिए योजना तैयार रखें जब कोई कुंजी लीक हो। लीक हुई सेंडिंग कुंजी किसी को भी आपके नाम से ईमेल भेजने देती है, इसलिए इससे आपके डेटा के साथ-साथ आपकी प्रेषक प्रतिष्ठा भी जोखिम में पड़ जाती है।
अपने अकाउंट में अनुमतियों के नाम जांचें। इस गाइड में दिए गए अनुमतियों के नाम पैटर्न के उदाहरण हैं। अपने MigoSMTP अकाउंट में जो विकल्प वास्तव में उपलब्ध हों उन्हें इस्तेमाल करें, और काम करने वाला सबसे संकरा विकल्प चुनें।
कुंजियां क्यों लीक होती हैं
| कैसे लीक होती है | उदाहरण | रोकथाम |
|---|---|---|
| रिपॉज़िटरी में कमिट हो जाना | कुंजी वाली कॉन्फ़िग फ़ाइल पब्लिक या साझा रिपॉज़िटरी में पुश हो जाती है | एनवायरनमेंट वेरिएबल, ignore फ़ाइलें और सीक्रेट स्कैनिंग इस्तेमाल करें |
| क्लाइंट तक पहुंच जाना | JavaScript या मोबाइल ऐप के अंदर कुंजी | इसके बजाय अपने सर्वर को कॉल करें |
| चैट या टिकटों में साझा करना | सपोर्ट थ्रेड में चिपकाई गई कुंजी | सीक्रेट मैनेजर के ज़रिए साझा करें और उजागर होने पर रोटेट करें |
| जा चुके खाते पर छूट जाना | पूर्व कॉन्ट्रैक्टर के पास अब भी कुंजी है | लोगों के जाने पर रोटेट करें |
| गलती से लॉग हो जाना | डीबग लॉग रिक्वेस्ट हेडर प्रिंट कर देता है | लॉग में सीक्रेट मास्क करें |
| समझौता किया गया सर्वर | मैलवेयर एनवायरनमेंट वेरिएबल पढ़ लेता है | सर्वर पैच करें और सीमित करें कि हर सर्वर किस तक पहुंच सकता है |
चरण 1: हर एप्लिकेशन और एनवायरनमेंट के लिए एक कुंजी
प्रोडक्शन, स्टेजिंग और मेल भेजने वाले हर एप्लिकेशन के लिए अलग कुंजियां बनाएं। उन्हें ऐसे नाम दें कि ऑडिट लॉग में पहचानी जा सकें।
| कुंजी का नाम | किसके द्वारा इस्तेमाल | अनुमति |
|---|---|---|
| shop-production | ऑनलाइन स्टोर, ऑर्डर ईमेल | केवल भेजना |
| shop-staging | टेस्ट एनवायरनमेंट | केवल भेजना, टेस्ट पतों पर |
| crm-production | CRM, कैंपेन सेंडिंग | भेजना और अपने कॉन्टैक्ट प्रबंधित करना |
| webhooks-reader | रिपोर्टिंग जॉब | केवल इवेंट पढ़ना |
| ops-admin | नामित व्यक्ति, कभी-कभार के काम | टू-फ़ैक्टर ऑथेंटिकेशन के साथ पूर्ण पहुंच |
चरण 2: न्यूनतम अधिकार लागू करें
हर कुंजी से पूछें: उसे कम से कम क्या करना है? मेल भेजने के लिए आपकी कॉन्टैक्ट सूची पढ़ना, DNS बदलना या बिलिंग संभालना ज़रूरी नहीं है, और रिपोर्टिंग जॉब को बिल्कुल भी भेजने में सक्षम नहीं होना चाहिए।
- जो भी सिस्टम केवल संदेश डिलीवर करता है, उसके लिए सेंड-ओनली कुंजी को प्राथमिकता दें।
- अकाउंट, बिलिंग और यूज़र प्रबंधन टू-फ़ैक्टर ऑथेंटिकेशन वाले लोगों के लिए रखें, कुंजियों के लिए नहीं।
- हर तिमाही अनुमतियों की समीक्षा करें और जो अब ज़रूरी नहीं है उसे हटाएं।
- अगर आपका अकाउंट IP पते, डोमेन या रेट लिमिट के आधार पर पाबंदियां देता है, तो उन्हें इस्तेमाल करें। क्या उपलब्ध है, इसके लिए अकाउंट सुरक्षा सेटिंग देखें।
चरण 3: कुंजियां सुरक्षित रखें
कुंजी को रनटाइम पर एनवायरनमेंट या सीक्रेट मैनेजर से लोड करें। एक न्यूनतम पैटर्न नीचे है।
# .env (never commit this file)
MIGOSMTP_API_KEY=replace-with-your-key
# .gitignore
.env
*.pem<?php
$key = getenv('MIGOSMTP_API_KEY');
if (!$key) {
throw new RuntimeException('API key is not configured');
}सीक्रेट स्कैनिंग जोड़ें। अपने कोड होस्ट में सीक्रेट स्कैनिंग चालू करें और अपनी बिल्ड पाइपलाइन में स्कैनर चलाएं। यह कुंजियों को साझा ब्रांच तक पहुंचने से पहले पकड़ लेता है और अगर कोई निकल जाए तो आपको अलर्ट देता है।
चरण 4: बिना डाउनटाइम के रोटेट करें
- नई कुंजी बनाएं। उसे वही अनुमतियां दें और ऐसा नाम दें जिसमें तारीख या वर्शन हो।
- उसे स्टोर करें। उसे अपने सीक्रेट मैनेजर या एनवायरनमेंट कॉन्फ़िगरेशन में जोड़ें।
- डिप्लॉय करें। बदलाव रिलीज़ करें और कुंजी पढ़ने वाली सेवाओं को रीस्टार्ट करें।
- पुष्टि करें। डिलीवरी लॉग से जांचें कि ट्रैफ़िक नई कुंजी इस्तेमाल कर रहा है।
- पुरानी कुंजी रद्द करें। यह तभी करें जब ट्रैफ़िक चला गया हो। थोड़ी देर रुकें और विफलताएं जांचें।
- दर्ज करें। तारीख, कारण और करने वाले का नाम नोट करें।
चरण 5: दुरुपयोग की निगरानी करें
| संकेत | इसका क्या मतलब हो सकता है | कार्रवाई |
|---|---|---|
| सामान्य से कहीं ज़्यादा वॉल्यूम | लीक हुई कुंजी या आपके कोड में लूप | कुंजी को रोकें और जांच करें |
| नए या अपरिचित प्राप्तकर्ता | आपकी कुंजी से भेजा गया स्पैम या फ़िशिंग | कुंजी रद्द करें और संदेशों की समीक्षा करें |
| असामान्य समय पर भेजना | स्वचालित दुरुपयोग | स्रोत IP जांचें और पहुंच सीमित करें |
| बढ़ते बाउंस या शिकायतें | खराब प्राप्तकर्ता या दुरुपयोग | सप्रेशन और स्रोत जांचें, स्पैम चेकलिस्ट देखें |
| नए IP पतों से अनुरोध | आपके सर्वरों के बाहर इस्तेमाल हो रही कुंजी | allow list जोड़ें और रोटेट करें |
अगर कुंजी लीक हो जाए: पहला घंटा
| मिनट | यह करें |
|---|---|
| 0 से 10 | कुंजी रद्द करें। अगर आप अभी बदली हुई कुंजी डिप्लॉय नहीं कर सकते, तो लगातार दुरुपयोग की तुलना में छोटा आउटेज स्वीकार करें |
| 10 से 30 | नई कुंजी बनाएं और डिप्लॉय करें। सामान्य सेंडिंग की पुष्टि करें |
| 30 से 60 | डिलीवरी लॉग में ऐसे संदेश खोजें जो आपने नहीं भेजे। शिकायत और बाउंस दरें तथा ब्लॉकलिस्ट जांचें |
| उसके बाद | पता लगाएं कि वह कैसे लीक हुई, स्रोत हटाएं, संबंधित सीक्रेट रोटेट करें और जो सीखा उसे लिख लें |
अगर आपके नाम से मेल भेजा गया है, तो ब्लॉकलिस्ट हटाने की गाइड का पालन करें और सपोर्ट से संपर्क करें ताकि अकाउंट की समीक्षा को संदर्भ मिल सके।
लगता है कि कोई कुंजी उजागर हो गई? पहले उसे रद्द करें, फिर कुंजी का नाम और समय बताते हुए हमसे संपर्क करें ताकि हम हाल की सेंडिंग की समीक्षा में आपकी मदद कर सकें।
आगे पढ़ें और स्रोत
अक्सर पूछे जाने वाले प्रश्न
ईमेल API कुंजी इतनी संवेदनशील क्यों है?
जिसके पास भी सेंडिंग कुंजी है, वह आपके नाम से ईमेल भेज सकता है। हमलावर लीक हुई कुंजियों से मिनटों में फ़िशिंग और स्पैम भेज देते हैं, जिससे आपका डोमेन और IP ब्लॉकलिस्ट हो सकते हैं और आपका अकाउंट सस्पेंड हो सकता है। नुकसान प्रतिष्ठा का होता है, और उसे सुधारने में हफ़्ते लग जाते हैं।
API कुंजियों के लिए न्यूनतम अधिकार (least privilege) का क्या मतलब है?
इसका मतलब है कि हर कुंजी केवल वही कर सके जो उसके काम के लिए ज़रूरी है, उससे ज़्यादा कुछ नहीं। वेब फ़ॉर्म से मेल भेजने वाली कुंजी कॉन्टैक्ट पढ़ने, डोमेन बदलने या बिलिंग संभालने में सक्षम नहीं होनी चाहिए। अगर वह लीक हो जाए, तो नुकसान उसी तक सीमित रहता है जिसकी उसे अनुमति थी।
क्या मुझे सब कुछ के लिए एक ही कुंजी इस्तेमाल करनी चाहिए?
नहीं। हर एप्लिकेशन और एनवायरनमेंट के लिए अलग कुंजी इस्तेमाल करें। अगर एक लीक हो जाए तो आप सिर्फ़ उसी को रद्द करते हैं, और आपके लॉग दिखाते हैं कि कोई संदेश किस सिस्टम से आया। साझा कुंजियां इन्सिडेंट रिस्पॉन्स को धीमा और जोखिम भरा बना देती हैं।
मुझे API कुंजियां कहां स्टोर करनी चाहिए?
एनवायरनमेंट वेरिएबल या सीक्रेट मैनेजर इस्तेमाल करें और उन्हें रनटाइम पर लोड करें। कुंजियों को सोर्स कोड में, वेबसाइट या मोबाइल ऐप के फ्रंट एंड में, पब्लिक रिपॉज़िटरी में, टिकटों में या चैट में न रखें। सीक्रेट वाली कॉन्फ़िगरेशन फ़ाइलों को अपनी ignore फ़ाइल में जोड़ें।
कुंजियां कितनी बार रोटेट करनी चाहिए?
आम नियम प्रोडक्शन कुंजियों के लिए हर 90 दिन है, और तुरंत तब जब पहुंच रखने वाला कोई व्यक्ति चला जाए, लैपटॉप खो जाए या लीक का संदेह हो। अंतराल से ज़्यादा महत्वपूर्ण यह है कि आपके पास रोटेशन की ऐसी प्रक्रिया हो जिसका आप पहले अभ्यास कर चुके हों।
बिना डाउनटाइम के कुंजी कैसे रोटेट करूं?
नई कुंजी बनाएं, उसे अपने सीक्रेट स्टोर में जोड़ें, बदलाव डिप्लॉय करें, पुष्टि करें कि ट्रैफ़िक नई कुंजी इस्तेमाल कर रहा है और उसके बाद ही पुरानी कुंजी रद्द करें। पहले रद्द कभी न करें, क्योंकि डिप्लॉय करते समय इससे आउटेज हो जाता है।
अगर कोई कुंजी लीक हो जाए तो मुझे क्या करना चाहिए?
कुंजी को तुरंत रद्द करें, नई कुंजी बनाएं, उसे डिप्लॉय करें, हाल की सेंडिंग में ऐसे संदेश खोजें जो आपने नहीं भेजे, और ब्लॉकलिस्ट लिस्टिंग तथा शिकायतों में उछाल जांचें। फिर पता लगाएं कि वह कैसे लीक हुई और वह रास्ता बंद करें।
मैं कैसे पता करूं कि किसी कुंजी का दुरुपयोग हो रहा है?
अचानक बढ़ा वॉल्यूम, नए या असामान्य प्राप्तकर्ता, अजीब समय पर भेजना, बाउंस या शिकायतों में बढ़ोतरी और अनजान IP पतों से आने वाले अनुरोध देखें। वॉल्यूम और बाउंस रेट पर अलर्ट आपको जल्दी चेतावनी देते हैं।
क्या SMTP क्रेडेंशियल API कुंजियों से अलग हैं?
उनका उद्देश्य एक ही है, यानी यह साबित करना कि आपको भेजने की अनुमति है, और उन्हें उतनी ही देखभाल चाहिए। SMTP यूज़रनेम और पासवर्ड को API कुंजी की तरह मानें: हर एप्लिकेशन के लिए एक सेट, सीक्रेट के रूप में स्टोर और तय शेड्यूल पर रोटेट। कनेक्शन के विवरण के लिए SMTP सेटिंग गाइड देखें।
क्या मैं API कुंजी को मोबाइल ऐप में या वेब पेज के JavaScript में रख सकता हूं?
नहीं। जो कुछ भी डिवाइस या ब्राउज़र को भेजा जाता है, उसे निकाला जा सकता है। मेल अपने सर्वर से भेजें, और ऐप या पेज को अपना सर्वर कॉल करने दें, जो फिर कुंजी के साथ ईमेल API को कॉल करे।