साइबर सुरक्षा
Turnkey ने AI एजेंटों को क्रेडेंशियल उपलब्ध कराने के लिए Managed Secrets लॉन्च किया
Securities.io को Google पर अपने पसंदीदा स्रोतों में जोड़ें
Turnkey ने Managed Secrets लॉन्च किया है। इसके ज़रिए कंपनी ने एन्क्लेव-आधारित वॉलेट अवसंरचना का विस्तार उन API कुंजियों, पासवर्ड, भुगतान विवरणों और पुनर्प्राप्ति संबंधी जानकारी तक किया है, जिनकी ऐप्लिकेशन और AI एजेंटों को काम करने के लिए ज़रूरत होती है। 29 अक्टूबर की घोषणा के साथ कंपनी निजी-कुंजी प्रबंधन से आगे बढ़कर एक व्यापक समस्या का समाधान कर रही है: सॉफ़्टवेयर को काम करने का अधिकार देना, लेकिन ऐसे पुनः उपयोग किए जा सकने वाले क्रेडेंशियल अपनी अवसंरचना में जगह-जगह बिखेरने से बचना।
इस उत्पाद से टीमें तय कर सकती हैं कि कौन-सी सेवा किसी क्रेडेंशियल को प्राप्त कर सकती है और उस अनुरोध के लिए मानवीय या बहु-पक्षीय मंज़ूरी ज़रूरी होगी या नहीं। वित्तीय ऐप्लिकेशन में इसका मतलब हो सकता है कि अधिकृत ट्रेडिंग बैकएंड को एक्सचेंज की API कुंजी दी जाए, लेकिन उसे AI सहायक की बातचीत और निष्पादन परिवेश से दूर रखा जाए।
क्रेडेंशियल तक पहुँच को एन्क्लेव की सुरक्षा-सीमा के भीतर रखना
पर्यावरण चर या कॉन्फ़िगरेशन फ़ाइलों में रखे क्रेडेंशियल सॉफ़्टवेयर के लिए इस्तेमाल करना सुविधाजनक बनाते हैं, लेकिन उन्हें पढ़ने वाली प्रक्रिया से छेड़छाड़ होने पर उनकी सामग्री उजागर हो सकती है। वॉल्ट से भंडारण और पहुँच नियंत्रण को एक जगह केंद्रीकृत किया जा सकता है; फिर भी यह सवाल बना रहता है कि क्रेडेंशियल किस बिंदु पर पढ़ने योग्य होता है और उस समय किन प्रणालियों पर भरोसा करना पड़ता है।
Managed Secrets प्राधिकरण-जाँच Turnkey के सुरक्षित एन्क्लेव के भीतर करता है। क्लाइंट किसी सीक्रेट को आयात करने से पहले एन्क्रिप्ट करता है और एन्क्लेव उसे भंडारण के लिए दोबारा एन्क्रिप्ट करता है। अनुरोध आने पर एन्क्लेव संबंधित नीतियों और मंज़ूरियों की जाँच करता है, फिर परिणाम को इच्छित प्राप्तकर्ता की कुंजी के लिए एन्क्रिप्ट करता है। अनुरोध करने वाली सेवा और प्राप्तकर्ता सेवा अलग-अलग हो सकती हैं।
यह अलगाव अहम है। कोई ऐप्लिकेशन काम शुरू कर सकता है और मंज़ूरियाँ जुटा सकता है, लेकिन इससे उसे उस क्रेडेंशियल को डिक्रिप्ट करने की क्षमता नहीं मिलती जिसका इस्तेमाल काम पूरा करने के लिए किया जाएगा। मंज़ूरी देने वाले के हस्ताक्षर से क्रेडेंशियल जारी करने की अनुमति मिलती है; इससे जारी किए गए सीक्रेट तक पहुँच अपने-आप नहीं मिल जाती।
आयात और निर्यात के पीछे की क्रिप्टोग्राफी
Turnkey का सुरक्षित चैनल संबंधी दस्तावेज़ हाइब्रिड पब्लिक की एन्क्रिप्शन (HPKE) पर आधारित प्रोटोकॉल का वर्णन करता है। इसमें सार्वजनिक-कुंजी आधारित कुंजी-सहमति को प्रमाणित एन्क्रिप्शन के साथ जोड़ा जाता है, ताकि संवेदनशील सामग्री मध्यवर्ती प्रणालियों से होकर सिफरटेक्स्ट के रूप में भेजी जा सके। आयात के दौरान क्लाइंट एन्क्लेव द्वारा हस्ताक्षरित कुंजी-सामग्री की पुष्टि करता है, जबकि निर्यात के दौरान हस्ताक्षरित अनुरोध में दी गई सार्वजनिक कुंजी के लिए सामग्री एन्क्रिप्ट की जाती है।
प्राप्तकर्ता की कुंजियाँ एक ही बार इस्तेमाल करने के लिए बनाई जाती हैं। Turnkey बताता है कि क्लाइंट को स्वयं इस नियम का पालन करना होगा: प्रोटोकॉल किसी त्रुटिपूर्ण क्लाइंट को अपनी लक्षित कुंजी का दोबारा उपयोग करने से नहीं रोक सकता। इसलिए एन्क्लेव के साथ-साथ क्लाइंट का कार्यान्वयन भी सुरक्षा मॉडल का हिस्सा है।
Managed Secrets के उत्पाद पृष्ठ के अनुसार, हर सीक्रेट को संग्रहीत अवस्था में AES-256-GCM से एन्क्रिप्ट किया जाता है। इसका API अलग-अलग क्रेडेंशियल और कई सीक्रेट के अनुरोध—दोनों का समर्थन करता है। अनुरोधित सीक्रेट में से किसी एक के लिए भी प्राधिकरण न होने पर बैच निर्यात पूरा का पूरा विफल हो जाता है, जिससे आंशिक रूप से मंज़ूर बंडल जारी नहीं हो पाता।
प्राप्तकर्ता अब भी क्यों अहम है
“एजेंट क्रेडेंशियल देखे बिना उनका इस्तेमाल कर सकते हैं” कहने का मतलब एकीकरण का एक तरीका है, यह गारंटी नहीं कि हर प्राप्तकर्ता प्रक्रिया सादा पाठ पढ़ने में असमर्थ रहेगी। Turnkey का डेवलपर दस्तावेज़ स्पष्ट रूप से बताता है कि सादा पाठ एन्क्लेव के भीतर और सीक्रेट आयात या निर्यात करने वाले क्लाइंट पर मौजूद हो सकता है।
अगर प्राप्तकर्ता की कुंजी किसी अलग निष्पादन सेवा के पास है, तो वह क्रेडेंशियल को डिक्रिप्ट करके इस्तेमाल कर सकती है और उसे मॉडल से दूर रख सकती है। अगर एजेंट के अपने रनटाइम के पास वह कुंजी है, तो वह रनटाइम उसे डिक्रिप्ट कर सकता है। इसलिए प्राप्तकर्ता, उसकी मेमोरी और उसके लॉग की सुरक्षा करना अब भी ज़रूरी है।
एक दूसरी सीमा भी है: नीतियाँ अनुरोध के संदर्भ की जाँच कर सकती हैं—जैसे चेकआउट डोमेन के बारे में किया गया दावा—लेकिन Turnkey स्वतंत्र रूप से यह पुष्टि नहीं करता कि दावा सही है। हस्ताक्षरित दावा यह स्थापित करता है कि उसे किसने किया। उस दावे को वास्तविक कार्रवाई से जोड़ने के लिए ऐप्लिकेशन को अब भी भरोसेमंद जाँचों की ज़रूरत होती है।
कार्यप्रवाह के साथ बदल सकने वाली मंज़ूरियाँ
टीमें सीधे क्रेडेंशियल प्राप्त करने की अनुमति दे सकती हैं, अनुरोध पर किसी व्यक्ति की मंज़ूरी अनिवार्य कर सकती हैं या एजेंट की कई भूमिकाओं के बीच सहमति माँग सकती हैं। मूल सीक्रेट को दोबारा आयात किए बिना नीतियाँ बदली जा सकती हैं। इससे कार्यप्रवाह कड़ी निगरानी के साथ शुरू हो सकता है और बाद में चुनिंदा अनुरोध स्वचालित किए जा सकते हैं।
Turnkey की प्रोग्राम योग्य पहुँच मार्गदर्शिका में ब्राउज़र एजेंट और भुगतान एजेंट को किसी अनुरोध पर सह-हस्ताक्षर करते दिखाया गया है। कार्ड का विवरण केवल भुगतान एजेंट को मिलता है, जिसे वह डिक्रिप्ट कर सकता है। मंज़ूरी देने से पहले ब्राउज़र वाला घटक जाँचता है कि प्रस्तावित डोमेन उस पृष्ठ से मेल खाता है जिसका वह उपयोग कर रहा है। यह उदाहरण दिखाता है कि केवल दो मंज़ूरियाँ गिनने के बजाय अलग-अलग भूमिकाएँ और सत्यापन अधिक अहम क्यों हैं।
एजेंट की भूमिकाओं के लिए सीमित दायरे वाले, समय-सीमा समाप्त होने वाले सत्र क्रेडेंशियल इस्तेमाल किए जा सकते हैं, जिससे संचालक किसी एक चल रहे इंस्टेंस की पहुँच रद्द कर सकते हैं। हालाँकि, भविष्य की पहुँच रद्द करने से वह सीक्रेट मिटाया नहीं जा सकता जिसे प्राप्तकर्ता पहले ही डिक्रिप्ट कर चुका हो; इसके बाद क्रेडेंशियल बदलना एक अलग परिचालन नियंत्रण बना रहता है।
वॉलेट अवसंरचना से वित्तीय स्वचालन तक
Turnkey की मौजूदा सुरक्षा संरचना AWS Nitro Enclaves का उपयोग करती है और हार्डवेयर-आधारित पृथक्करण को पुनरुत्पादित किए जा सकने वाले बिल्ड तथा दूरस्थ सत्यापन के साथ जोड़ती है। पुनरुत्पादकता से सॉफ़्टवेयर बिल्ड की तुलना की जा सकती है, जबकि सत्यापन इस बात का प्रमाण देता है कि एन्क्लेव में कौन-सा कोड चल रहा है। Managed Secrets इस बुनियाद को ब्लॉकचेन लेन-देन पर हस्ताक्षर करने वाली कुंजियों से आगे की अन्य साख तक विस्तारित करता है।
कंपनी ट्रेडिंग फ़र्मों, फिनटेक बैकएंड, AI एजेंट विकसित करने वालों और MPC कस्टोडियन को इसके लक्षित उपयोगकर्ताओं के रूप में पहचानती है। एक्सचेंज की साख और OAuth टोकन लगातार सेवा तक पहुँच बनाए रखने में मदद करते हैं; वहीं, की-शेयर बैकअप और पुनर्प्राप्ति कुंजियाँ लचीलेपन को सुनिश्चित करती हैं। ये अलग-अलग उपयोग हैं, जिनमें मंज़ूरी देने और प्राप्तकर्ता तय करने की ज़रूरतें भी अलग होती हैं—भले ही इनके लिए एक ही भंडारण ढाँचे का इस्तेमाल हो।
वित्तीय प्रौद्योगिकी टीमों के लिए इसका महत्त्व यह है कि कार्रवाई का अनुरोध करने, पहुँच को मंज़ूरी देने और उपयोग योग्य साख प्राप्त करने के बीच अधिक स्पष्ट विभाजन होता है। Managed Secrets इस विभाजन के लिए बुनियादी ढाँचा उपलब्ध कराता है। इससे मिलने वाली सुरक्षा सीमित दायरे वाली नीतियों, भरोसेमंद मंज़ूरीकर्ताओं और उस सेवा की मज़बूत सुरक्षा पर निर्भर करती है जो अंततः गोपनीय जानकारी का उपयोग करती है।
