EC2 वर्कलोड के लिए इंस्टेंस प्रोफ़ाइल

EC2 पर चलने वाले अनुप्रयोगों को अक्सर AWS APIs को call करने की आवश्यकता होती है, लेकिन access keys को अनुप्रयोग में शामिल करना खतरनाक है। इसका समाधान instance profile के माध्यम से instance को अपना identity देना है, जो role के अस्थायी प्रमाण-पत्र अपने-आप उपलब्ध कराता है। Workloads से लंबे समय तक मान्य गोपनीय जानकारी हटाने के लिए यह सबसे अधिक परीक्षित तरीकों में से एक है।

instance profile किसी IAM role का container है, जिसे आप EC2 instance से जोड़ते हैं। यद्यपि वैचारिक रूप से आप role assign करते हैं, EC2 वास्तव में उस role को समेटने वाले instance profile को जोड़ता है। जब आप console में EC2 के लिए role बनाते हैं, तो उसी नाम का instance profile अपने-आप बन जाता है; CLI या API के साथ आपको इसे स्पष्ट रूप से बनाना पड़ सकता है।

Instance profile संलग्न होने के बाद, instance Instance Metadata Service (IMDS) से अस्थायी प्रमाण-पत्र प्राप्त कर सकता है। यह 169.254.169.254 पर उपलब्ध एक विशेष link-local endpoint है। AWS SDK और CLI इन प्रमाण-पत्रों को पारदर्शी रूप से प्राप्त और नवीनीकृत करते हैं, इसलिए अनुप्रयोग code को keys को बिल्कुल भी संभालना नहीं पड़ता।

क्रेडेंशियल भूमिका के नाम से जुड़े मेटाडेटा पथ के अंतर्गत रहते हैं। SDK उनका अनुरोध अपने-आप करते हैं, लेकिन इस पथ को समझने से यह पता लगाने में सहायता मिलती है कि किसी इंस्टेंस के पास अनपेक्षित अनुमतियाँ क्यों हैं। नीचे दिया गया कमांड दिखाता है कि इंस्टेंस पर क्रेडेंशियल कहाँ उपलब्ध कराए जाते हैं।

इसका एक बड़ा लाभ यह है कि IMDS क्रेडेंशियल की समय-सीमा समाप्त होने से काफी पहले ही स्वचालित रूप से बदली जाती है। आपको कुछ भी संग्रहीत करने, स्थायी रूप से लीक हो सकने वाली कुंजी रखने या रोटेशन प्रक्रिया बनाने की आवश्यकता नहीं होती। इसी कारण AWS सर्वर पर स्थिर कुंजियाँ रखने वाली किसी भी योजना के बजाय इंस्टेंस प्रोफ़ाइल की अनुशंसा करता है।

मूल मेटाडेटा सेवा (IMDSv1) का दुरुपयोग SSRF (सर्वर-साइड रिक्वेस्ट फोर्जरी) हमलों के माध्यम से भूमिका के क्रेडेंशियल चुराने के लिए किया जा सकता था। IMDSv2 में पहले PUT अनुरोध के माध्यम से प्राप्त किया गया सत्र टोकन आवश्यक होता है, जिससे अधिकांश SSRF शोषण रुक जाते हैं। परीक्षा में आपसे IMDSv2 लागू करने और आदर्श रूप से हॉप सीमा 1 रखने की अपेक्षा की जाती है, ताकि कंटेनर वहाँ तक न पहुँच सकें।

इंस्टेंस-प्रोफ़ाइल की भूमिका में न्यूनतम विशेषाधिकार का सिद्धांत लागू होना चाहिए: वर्कलोड के लिए आवश्यक विशिष्ट कार्रवाइयों और संसाधनों की ही अनुमति दें। EC2 की अत्यधिक व्यापक भूमिका खतरनाक होती है, क्योंकि इंस्टेंस के किसी भी तरह से समझौता किए जाने पर, SSRF के माध्यम से भी, वे अनुमतियाँ उजागर हो जाती हैं। नीतियों का दायरा कड़ाई से सीमित करें और नुकसान की सीमा घटाने के लिए शर्तों का उपयोग करें।

यदि आपको किसी एप्लिकेशन में हार्ड-कोड की गई स्थिर एक्सेस कुंजियाँ या इंस्टेंस पर क्रेडेंशियल फ़ाइल मिलती है, तो समाधान है कि इंस्टेंस प्रोफ़ाइल संलग्न करें और कुंजियाँ हटा दें। परीक्षा में इसे अक्सर किसी खोजे गए दोष को ठीक करने के रूप में प्रस्तुत किया जाता है: सही उत्तर दीर्घकालिक गुप्त जानकारी हटाकर IMDS से मिलने वाले भूमिका-आधारित क्रेडेंशियल पर निर्भर करता है।

एक EC2 इंस्टेंस पर एक समय में केवल एक इंस्टेंस प्रोफ़ाइल संलग्न हो सकती है और इसलिए केवल एक भूमिका। यदि किसी वर्कलोड को अलग-अलग अनुमति-समूह चाहिए, तो अलग भूमिकाएँ बनाएँ और या तो अलग इंस्टेंस का उपयोग करें, या आवश्यकता के अनुसार एप्लिकेशन से STS के माध्यम से अतिरिक्त भूमिकाएँ ग्रहण करवाएँ। इसके बजाय संलग्न एकमात्र भूमिका की अनुमतियों को अत्यधिक व्यापक न बनाएँ।

भूमिका के क्रेडेंशियल CloudTrail में ग्रहण की गई-भूमिका के सत्र द्वारा की गई कार्रवाइयों के रूप में दिखाई देते हैं, इसलिए आप ठीक-ठीक ऑडिट कर सकते हैं कि इंस्टेंस ने क्या किया। यदि किसी इंस्टेंस से समझौता हो जाए, तो उसका स्नैपशॉट लेने और उस भूमिका के सत्र के लिए CloudTrail जाँचने से पता चलता है कि हमलावर ने क्या एक्सेस किया। भूमिका का सीमित दायरा और CloudTrail की दृश्यता, दोनों मिलकर सुरक्षित और परीक्षा में पसंद किया जाने वाला संयोजन बनाते हैं।

EC2 की पहुँच सुरक्षित करने के लिए: न्यूनतम विशेषाधिकार वाली भूमिका को समाहित करने वाली इंस्टेंस प्रोफ़ाइल संलग्न करें, IMDSv2 लागू करें, मेटाडेटा हॉप सीमा 1 निर्धारित करें और सभी स्थिर कुंजियाँ हटा दें। इंस्टेंस IMDS से अस्थायी क्रेडेंशियल प्राप्त करके उन्हें अपने-आप बदलता रहता है, जिससे आपको प्रबंधित करने के लिए कोई गुप्त जानकारी रखे बिना कंप्यूट को सुरक्षित पहचान मिलती है।

इंस्टेंस प्रोफ़ाइल IAM भूमिका को समाहित करके उसे EC2 से संलग्न करती है और Instance Metadata Service के माध्यम से अपने-आप बदले जाने वाले अस्थायी क्रेडेंशियल उपलब्ध कराती है। इससे स्थिर कुंजियों की पूरी तरह आवश्यकता समाप्त हो जाती है। SSRF द्वारा क्रेडेंशियल चोरी रोकने के लिए IMDSv2 और हॉप सीमा 1 लागू करें, न्यूनतम विशेषाधिकार के अनुसार भूमिका का दायरा सीमित करें और उसके सत्रों का CloudTrail में ऑडिट करें।