AWS access key और secret key: इन्हें कैसे बनाएं, इस्तेमाल करें, रोटेट करें और सुरक्षित तरीके से शेयर करें

AWS access key दो स्ट्रिंग की जोड़ी है, जिनकी मदद से कोई प्रोग्राम किसी IAM यूज़र के तौर पर काम करता है: access key ID, जो key की पहचान बताती है, और secret access key, जो साबित करती है कि key आपके पास है। लोग इन्हें तीन नामों से सर्च करते हैं: access key and secret key, secret access key और सिर्फ़ AWS secret key। तीनों एक ही जोड़ी के नाम हैं। यह जोड़ी CLI कॉन्फ़िग में, CI पाइपलाइन में और ज़रूरत से कहीं ज़्यादा बार Slack मैसेज में भी मिल जाती है।

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

Access key ID बनाम secret access key

लंबे समय वाली keys AKIA से शुरू होती हैं। STS से मिलने वाले अस्थायी क्रेडेंशियल, जिनके साथ एक सेशन टोकन भी आता है, ASIA से शुरू होते हैं और अपने आप एक्सपायर हो जाते हैं। अगर किसी कॉन्फ़िग फ़ाइल में आपको ASIA वाली key दिखे, तो वह कुछ ही घंटों में काम करना बंद कर देगी। इसे इसी तरह डिज़ाइन किया गया है।

दोनों में से कोई भी हिस्सा अपने आप कोई अनुमति नहीं देता। key एक IAM यूज़र के तौर पर ऑथेंटिकेट करती है, और उस यूज़र से जुड़ी पॉलिसी तय करती हैं कि वह क्या कर सकता है। रीड-ओनली यूज़र की key लीक होना एक समस्या है। एडमिनिस्ट्रेटर की key लीक होना एक सिक्योरिटी इंसिडेंट है।

लंबे समय वाली key की ज़रूरत कब पड़ती है

सच कहें तो लोगों के अंदाज़े से कम।

• AWS पर चलने वाले वर्कलोड (EC2, Lambda, ECS, EKS) को IAM रोल इस्तेमाल करने चाहिए। SDK कम समय वाले क्रेडेंशियल अपने आप ले लेता है, और न कुछ रोटेट करना पड़ता है, न कुछ लीक होने को रहता है।
• लोगों को IAM Identity Center या फ़ेडरेटेड SSO से साइन इन करना चाहिए और aws sso login से अस्थायी क्रेडेंशियल लेने चाहिए।
• CI सिस्टम, जैसे GitHub Actions, OIDC के ज़रिए बिना कोई key स्टोर किए रोल ले सकते हैं।
• लंबे समय वाली keys सिर्फ़ उन मामलों के लिए बचती हैं जहां ऊपर का कोई तरीका काम नहीं करता: लैपटॉप पर कोई टूल जिसमें SSO सपोर्ट नहीं है, कोई थर्ड-पार्टी सर्विस जो सिर्फ़ स्टैटिक keys लेती है, या कोई पुराना जॉब जिसे आपने अभी माइग्रेट नहीं किया है।

अगर key चाहिए ही, तो उसे एक अलग IAM यूज़र पर बनाएं, ऐसी पॉलिसी के साथ जो उस काम के लिए जितनी ज़रूरी हो उतनी ही अनुमति दे। किसी व्यक्ति के एडमिनिस्ट्रेटर अकाउंट पर इसे कभी न बनाएं।

Key बनाएं और कॉन्फ़िगर करें

IAM कंसोल में यूज़र खोलें, “Security credentials” चुनें, फिर “Create access key”। AWS पूछता है कि key किस काम के लिए है: वह चुनें, AWS जो दूसरा विकल्प सुझाता है उसे पढ़ें और आगे बढ़ें। secret ठीक एक बार दिखता है। उसे सीधे अपने सीक्रेट स्टोर या पासवर्ड मैनेजर में सेव करें, या CSV डाउनलोड करें और इम्पोर्ट के बाद उसे डिलीट कर दें। हर IAM यूज़र के पास एक समय में ज़्यादा से ज़्यादा दो keys हो सकती हैं, और इसी वजह से रोटेशन मुमकिन होता है।

मशीन पर डिफ़ॉल्ट प्रोफ़ाइल की जगह एक नाम वाली प्रोफ़ाइल कॉन्फ़िगर करें:

aws configure --profile deploy-tool
# AWS Access Key ID [None]: AKIA...
# AWS Secret Access Key [None]: ...
# Default region name [None]: eu-west-1

इससे ~/.aws/credentials और ~/.aws/config फ़ाइलें बनती हैं। chmod 600 से फ़ाइल को सिर्फ़ अपने यूज़र तक सीमित करें। कंटेनर और CI के लिए AWS_ACCESS_KEY_ID और AWS_SECRET_ACCESS_KEY को प्लैटफ़ॉर्म के सीक्रेट स्टोर से सीक्रेट के रूप में डालें, YAML फ़ाइल में सादे वेरिएबल के रूप में नहीं। इन्हें कभी कमांड लाइन पर पास न करें, वहां से ये शेल हिस्ट्री में पहुंच जाती हैं।

बिना कुछ तोड़े रोटेट करें

रोटेशन चार स्टेप का काम है, और दो keys की सीमा की वजह से ही यह मुमकिन है।

1. दूसरी key बनाएं, उसी यूज़र पर।
2. हर जगह नई key डालें जहां पुरानी इस्तेमाल होती है: कॉन्फ़िग, CI सीक्रेट, सीक्रेट मैनेजर की एंट्री। IAM कंसोल हर key के आखिरी इस्तेमाल का समय दिखाता है, जिससे पता चलता है कि कोई जगह छूट तो नहीं गई।
3. पुरानी key डीएक्टिवेट करें। एक दिन या एक डिप्लॉय साइकल इंतज़ार करें। कुछ टूटे तो उसे फिर से चालू करें, उस जगह को ठीक करें और दोबारा कोशिश करें।
4. पुरानी key डिलीट करें, जब उसका कहीं इस्तेमाल न हो रहा हो।

जिन keys का होना ज़रूरी है, उनके साथ यह तय समय पर करें। और सभी keys के साथ यह खास मौकों पर करें: किसी के जाने पर, वेंडर बदलने पर, लैपटॉप खोने पर या लीक का शक होने पर। AWS Config और IAM Access Analyzer उन keys को फ़्लैग कर सकते हैं जो आपकी पॉलिसी की तय उम्र से पुरानी हैं।

जब key लीक हो जाए

अगर कोई key किसी रिपॉज़िटरी, लॉग, टिकट या चैट में आ गई, तो उसे लीक हुई मानें, भले ही उसे एक मिनट बाद हटा दिया गया हो। स्कैनर पुश किए गए सीक्रेट कुछ सेकंड में ढूंढ लेते हैं।

1. Key को अभी IAM में डीएक्टिवेट करें। पहले नई key बनाने का इंतज़ार न करें, जब तक कि सर्विस बंद होने का नुकसान लीक से ज़्यादा न हो।
2. नई key बनाएं और जहां-जहां इस्तेमाल होती है वहां अपडेट करें।
3. CloudTrail पढ़ें और लीक के बाद से उस access key ID से हुई हर कार्रवाई देखें। नए IAM यूज़र या keys, नए इंस्टेंस, बदली हुई बकेट पॉलिसी और अनजान रीजन पर नज़र रखें।
4. बिल देखें और Cost Explorer में ऐसे अचानक उछाल ढूंढें जो क्रिप्टो-माइनिंग जैसे लगें।
5. Secret को हटाएं, कोड, लॉग और git हिस्ट्री से। पब्लिक लीक पकड़ने पर AWS खुद यूज़र पर AWSCompromisedKeyQuarantine पॉलिसी लगा सकता है। सफ़ाई पूरी होने तक उसे लगा रहने दें।
6. पुरानी key डिलीट करें, फिर पता लगाएं कि वह वहां तक कैसे पहुंची और वह रास्ता बंद करें।

AWS secret key किसी व्यक्ति के साथ कैसे शेयर करें

कभी-कभी key किसी इंसान तक पहुंचानी ही पड़ती है: किसी कॉन्ट्रैक्टर को डिप्लॉयमेंट टूल के लिए, किसी डेवलपर को जो SSO सेट होने से पहले प्रोजेक्ट में आ गया है, या किसी वेंडर इंटीग्रेशन को जो चाहता है कि key उसके डैशबोर्ड में पेस्ट की जाए। ईमेल, Slack और टिकट, तीनों कॉपी रखते हैं, और इनमें से किसी में भी पड़ा 40 कैरेक्टर का secret सालों तक पढ़ा जा सकता है।

सुरक्षित तरीके में एक मिनट लगता है:

1. उस व्यक्ति के लिए key बनाएं, एक अलग IAM यूज़र पर, सिर्फ़ उतनी पॉलिसी के साथ जितनी उसके काम के लिए ज़रूरी है। ऐसी key शेयर न करें जिसे कोई और चीज़ भी इस्तेमाल करती हो।
2. सिर्फ़ secret access key को एक वन-टाइम सीक्रेट लिंक में पेस्ट करें, यानी एक बार खुलने वाला लिंक। key स्टोर होने से पहले आपके ब्राउज़र में ही एन्क्रिप्ट होती है, लिंक पहली बार खुलते ही स्टोर की गई कॉपी मिट जाती है, और अगर कोई लिंक न खोले तो वह एक घंटे, एक दिन या एक हफ़्ते में एक्सपायर हो जाता है।
3. लिंक भेजें, एक लाइन के संदर्भ के साथ। access key ID, रीजन और प्रोफ़ाइल का नाम अलग मैसेज में भेजें। इनमें से कोई भी अकेले गोपनीय नहीं है।
4. Pro अकाउंट पर पासफ़्रेज़ जोड़ें, अगर key रीड-ओनली से ज़्यादा अनुमति देती है, और पासफ़्रेज़ SMS या कॉल पर बताएं।
5. पक्का कर लें कि उन्होंने लिंक खोला। अगर लिंक बताए कि वह पहले ही खुल चुका है और उन्होंने उसे नहीं खोला, तो key डीएक्टिवेट करें और फिर से शुरू करें।
6. काम खत्म होने पर key डीएक्टिवेट करें, और उसके बाद डिलीट कर दें।

API key गाइड में दूसरे प्रोवाइडर के लिए यही तरीका है, और डेवलपर के लिए सुरक्षित लिंक शेयरिंग में बताया गया है कि ऑनबोर्डिंग के लिए यह हैंडओवर स्क्रिप्ट से कैसे करें।

संबंधित लेख

• API keys सुरक्षित तरीके से कैसे शेयर करें
• क्लाउड सीक्रेट मैनेजर: यह क्या है और सही कैसे चुनें
• कॉन्ट्रैक्टर को अस्थायी डेटाबेस लॉगिन सुरक्षित तरीके से कैसे भेजें
• वन-टाइम सीक्रेट लिंक कैसे काम करते हैं