सालों बाद भी सक्रिय मिलीं 9,300 लीक AWS कुंजियां

किसी सार्वजनिक रिपॉजिटरी में क्रेडेंशियल दिख जाना अपने-आप में यह साबित नहीं करता कि खाता अभी खतरे में है। वास्तविक जोखिम तब बनता है जब कुंजी रद्द न की गई हो, उससे अब भी लॉगिन संभव हो और उसके पास उपयोगी अधिकार हों। इस जांच में ये तीनों स्थितियां बार-बार साथ मिलीं।

768 कुंजियों से कॉरपोरेट AWS खातों पर पूरा नियंत्रण

कॉरपोरेट खातों से जुड़ी सक्रिय कुंजियों में 817 कंपनियों से संबंधित थीं। इनमें शामिल थीं:

• 526 AWS root-account कुंजियां
• 242 IAM-user कुंजियां, जिन पर AWS की AdministratorAccess नीति लागू थी
• कुल 768 कुंजियां, जो किसी कंपनी के AWS खाते पर पूर्ण प्रशासनिक नियंत्रण दे सकती थीं

Root credentials AWS ग्राहक के लिए उपलब्ध सबसे ऊंचे स्तर का नियंत्रण देती हैं। वहीं AdministratorAccess वाली IAM पहचान AWS की लगभग सभी सेवाओं पर व्यापक अधिकार रख सकती है। ऐसी वैध कुंजी से खाता हथियाने, अनधिकृत संसाधन बनाने, डेटा तक पहुंचने या क्लाउड बिलिंग का दुरुपयोग करने का रास्ता खुल सकता है।

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

Hugging Face बना सबसे बड़ा एकल स्रोत

रिपोर्टिंग के अनुसार, Hugging Face से 8,482 AWS क्रेडेंशियल एक्सपोजर जुड़े थे, जो पहचाने गए स्रोतों में सबसे अधिक थे। Truffle Security ने बताया कि इनमें 17.9% AWS credentials root credentials थीं।

यह निष्कर्ष Hugging Face के सार्वजनिक डेटा पर की गई एक व्यापक स्कैनिंग के संदर्भ में आया है। Truffle Security के अनुसार, उसने 7.6 पेटाबाइट सार्वजनिक डेटासेट की जांच की और हजारों डेटासेट में सक्रिय क्रेडेंशियल पाए। इससे पता चलता है कि सीक्रेट केवल पारंपरिक सॉफ्टवेयर रिपॉजिटरी में नहीं, बल्कि सार्वजनिक रूप से वितरित डेटा में भी लंबे समय तक रह सकते हैं।

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

कई कुंजियां लगभग पांच साल पुरानी थीं

रिपोर्ट में क्रेडेंशियल की औसत मध्य आयु लगभग 1,831 दिन, यानी करीब पांच वर्ष बताई गई। सबसे पुरानी कुंजी 17.4 वर्ष पुरानी थी। केवल 13.7% प्रविष्टियों के साथ उसी उपयोगकर्ता की कोई नई कुंजी मिली, जिससे संकेत मिलता है कि अधिकांश कुंजियां सामान्य रोटेशन प्रक्रिया के तहत बदली ही नहीं गई थीं।

लंबे समय तक सक्रिय रहने वाली एक्सेस कुंजियां अनधिकृत इस्तेमाल के लिए ज्यादा समय देती हैं और यह पता लगाना कठिन बनाती हैं कि उनका मालिक कौन है। कर्मचारी बदलने, एप्लिकेशन माइग्रेशन, रिपॉजिटरी साफ करने या जिम्मेदारियां बदलने के बाद भी ऐसी कुंजियां सक्रिय रह सकती हैं।

व्यावहारिक सबक यह है कि कुंजी की उम्र को जोखिम का संकेत माना जाए। कई साल पुरानी लीक कुंजी को बेकार मान लेना सुरक्षित नहीं है। उसके सक्रिय होने की जांच कर उसे रद्द करना चाहिए और संबंधित गतिविधि की पड़ताल करनी चाहिए—जब तक मालिक यह साबित न कर दे कि वह अब वैध नहीं है।

बजट मॉनिटरिंग भी सीमित मिली

Truffle Security 2,754 खातों की जानकारी पढ़ सकी, लेकिन इनमें से केवल 262 खातों पर AWS budget alerts सक्रिय थे।

बजट अलर्ट क्रेडेंशियल रद्द करने या खतरे का पता लगाने का विकल्प नहीं हैं। फिर भी, अगर लीक कुंजी से महंगे संसाधन बनाए जाएं—जैसे क्रिप्टोमाइनिंग के लिए—तो ये अचानक बढ़ते खर्च की शुरुआती चेतावनी दे सकते हैं। यदि अलर्ट ऐसे व्यक्ति तक न पहुंचे जो तुरंत कार्रवाई कर सके, तो खाता समझौता होने के बाद भी असामान्य खर्च जारी रह सकता है।

AWS की सूचनाएं समस्या का सिर्फ पहला हिस्सा हैं

रिपोर्ट में AWS की ऐसी सुरक्षा व्यवस्थाओं का उल्लेख है जो सार्वजनिक हुई एक्सेस कुंजियों की पहचान कर सकती हैं, प्रभावित ग्राहकों को सूचना दे सकती हैं और प्रतिबंध या क्वारंटीन उपाय लागू कर सकती हैं। हालांकि, जांच में बड़ी संख्या में कुंजियों का सक्रिय बने रहना दिखाता है कि सूचना या पहचान के बाद ग्राहक-पक्ष पर तत्काल रद्दीकरण और रोटेशन हमेशा नहीं हुआ।

क्रेडेंशियल रिस्पॉन्स में डिटेक्शन केवल पहला कदम है। पूरी प्रक्रिया में मालिक की पहचान, कुंजी की पहुंच और अनुमतियों का आकलन, संभावित दुरुपयोग की जांच और अंततः कुंजी को अमान्य करना शामिल होना चाहिए।

Truffle Security ने अपने परीक्षण को read-only बताया है। उसके अनुसार, शोधकर्ताओं ने केवल यह जांचा कि क्रेडेंशियल से प्रमाणीकरण हो रहा है या नहीं और अनुमति अथवा खाते से जुड़ा मेटाडेटा देखा; ग्राहक संसाधनों में बदलाव नहीं किया। उपलब्ध स्रोत इस पद्धति की हर संचालनात्मक जानकारी की स्वतंत्र पुष्टि नहीं करते, इसलिए इस बिंदु को Truffle Security के अपने विवरण के रूप में समझना चाहिए।

AWS कुंजी लीक होने पर संगठनों को क्या करना चाहिए

1. कुंजी तुरंत रद्द या रोटेट करें

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

2. Root access keys खत्म करें

AWS root-user access keys का इस्तेमाल नियमित प्रोग्रामेटिक पहुंच के लिए नहीं किया जाना चाहिए। Root कुंजियां डिलीट कर नियंत्रित, सीमित-अधिकार वाली पहचान या भूमिकाओं का इस्तेमाल करें।

3. अनुमतियों और मालिक की जांच करें

पता लगाएं कि कुंजी किस खाते, उपयोगकर्ता, सेवा और संसाधनों से जुड़ी थी। Root अधिकार, AdministratorAccess, व्यापक डेटा पहुंच या नया इंफ्रास्ट्रक्चर बनाने की क्षमता वाली कुंजियों को सबसे पहले संभालें।

4. रद्दीकरण से पहले और बाद की गतिविधि जांचें

प्रमाणीकरण गतिविधि, CloudTrail रिकॉर्ड, IAM में बदलाव, नए बनाए गए संसाधन और बिलिंग की समीक्षा करें। कुंजी रद्द करने से आगे का इस्तेमाल रुकता है, लेकिन यह साबित नहीं होता कि उसका पहले दुरुपयोग नहीं हुआ।

5. लंबे समय वाली कुंजियों की जगह short-lived identities अपनाएं

जहां संभव हो, स्थायी access keys के बजाय short-lived IAM roles और workload identities का उपयोग करें। Least-privilege permissions से लीक क्रेडेंशियल से होने वाला नुकसान सीमित किया जा सकता है।

6. बजट अलर्ट और कार्रवाई की स्पष्ट व्यवस्था बनाएं

AWS Budgets alerts और cost-anomaly monitoring सक्रिय करें। सूचनाएं ऐसे संपर्कों तक भेजें जो तुरंत कार्रवाई कर सकें। वित्तीय निगरानी एक अतिरिक्त सुरक्षा परत है—यह secret scanning, credential rotation और access review का विकल्प नहीं है।

बड़ी सीख: लीक, सक्रियता और अधिकार का मेल सबसे खतरनाक है

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

क्लाउड टीमों के लिए सुरक्षित मानक सरल है: हर उजागर AWS क्रेडेंशियल को समझौता हुआ मानें, उसकी पहुंच और अधिकारों की जांच करें, उसे तुरंत रोटेट या रद्द करें और लंबे समय तक चलने वाली कुंजियों की जगह short-lived, least-privilege identities अपनाएं।