VPN के ज़रिये पार्टनर की HSM पहुँच: कुंजी संक्रियाएँ परिभाषित करें

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

ठोस मामले को सामने रखें: पार्टनर एक नामित कुंजी से हस्ताक्षर के लिए स्वीकृत दस्तावेज़ जमा करता है, और कुछ नहीं। नीचे सब कुछ उसी एक वाक्य से निकलता है।

पहुँच, पहचान और कुंजी नीति तीन द्वार हैं

VPN कॉन्सेंट्रेटर तय करता है कि कौन सुरंग खोल सकता है और किन पतों को छू सकता है। HSM स्वयं तय करता है कि उसके सामने प्रस्तुत कौन-सा उपयोगकर्ता रिकॉर्ड लॉग इन कर सकता है। फिर कुंजी नीति तय करती है कि वह उपयोगकर्ता रिकॉर्ड एक विशिष्ट कुंजी के साथ क्या कर सकता है। पहले द्वार से गुज़रने पर बाकी दो जैसे थे वैसे ही रहते हैं, इसलिए सफल हैंडशेक बहुत कम साबित करता है और इसलिए पार्टनर उपकरण तक पहुँचकर भी हर संक्रिया में विफल हो सकता है।

आवश्यकताएँ लिखने से पहले हर द्वार को एक स्वामी सौंपें। जब दूसरे का कोई स्वामी न हो, तो आम परिणाम यह होता है कि व्यापक HSM प्रशासक पहचान दे दी जाती है क्योंकि वही एकमात्र क्रेडेंशियल है जो काम करता है।

द्वार एक: पार्टनर को दिया जाने वाला नेटवर्क पथ

स्वीकृत क्लाइंट या सेवा, उसे ज़रूरी गंतव्य, और वह प्रोटोकॉल तथा पोर्ट बताएँ जिस पर वह सेवा सुनती है। फिर VPN की ओर से पहुँच को उसी जोड़ी तक दोनों दिशाओं में सीमित करें, वापसी पथ सहित, ताकि नीति ऐसा वाक्य बने जिसे आप पार्टनर को पढ़कर सुना सकें। गेटवे प्रशासन, HSM प्रबंधन इंटरफ़ेस और असंबंधित आंतरिक सिस्टम सामान्य पार्टनर पहुँच से बाहर रहने चाहिए, केवल डिफ़ॉल्ट रूट से बाहर नहीं।

समर्पित सेगमेंट उन पारगमनों को दृश्य बनाता है, पर सेगमेंट का नाम कुछ भी लागू नहीं करता। ट्रैफ़िक को उसी नियंत्रण से गुज़रना होगा जिससे आप सोचते हैं कि वह गुज़रता है। पार्टनर से कनेक्शन स्वीकार करना यह कथन भी नहीं है कि पार्टनर की हर मशीन भरोसेमंद है।

द्वार दो: HSM के सामने वास्तव में कौन प्रमाणित होता है

VPN पहचान और HSM पहचान अलग ऑब्जेक्ट हैं, जब तक कोई समर्थित एकीकरण उन्हें जानबूझकर न जोड़े। PKCS#11 क्लाइंट के साथ, एप्लिकेशन पार्टनर के होस्ट पर कहीं संग्रहीत क्रेडेंशियल के साथ स्लॉट के विरुद्ध लॉगिन करता है, और वही लॉगिन HSM मूल्यांकन करता है।

AWS CloudHSM उपयोगी संदर्भ है क्योंकि उसका दस्तावेज़ीकरण दोनों को अलग रखता है: HSM उपयोगकर्ता IAM उपयोगकर्ताओं से अलग हैं, और उपयोगकर्ता प्रकार तय करता है कि खाता क्या कर सकता है। क्रिप्टो अधिकारी उपयोगकर्ताओं और कुंजियों का प्रबंधन करता है पर वह पहचान नहीं है जो क्रिप्टोग्राफ़िक संक्रियाएँ करती है, जबकि क्रिप्टो उपयोगकर्ता उन्हें प्रबंधित किए बिना कुंजियाँ इस्तेमाल कर सकता है। यही विभाजन वह आकार है जो आप दूसरे विक्रेता के उपकरण पर भी चाहते हैं, जहाँ भूमिकाओं के नाम अलग होंगे।

आप जो भी पहचान जारी करें, वह हटाई जा सकने योग्य और उसी बारीकी पर श्रेय-योग्य होनी चाहिए जो आपको आगे चाहिए होगी। कई पार्टनरों में साझा एक परिचालन क्रेडेंशियल नियंत्रण और जवाबदेही को ठीक उसी घटना में कठिन बनाता है जहाँ दोनों सबसे ज़्यादा मायने रखते हैं।

द्वार तीन: कौन-सी कुंजी, और कौन-सी संक्रिया

हस्ताक्षर, डिक्रिप्शन, कुंजी निर्माण, कुंजी रैपिंग और उपयोगकर्ता प्रशासन अलग-अलग अनुमतियाँ हैं और उन्हें अलग-अलग सूचीबद्ध किया जाना चाहिए। PKCS#11 की दृष्टि से, CKA_SENSITIVE और CKA_EXTRACTABLE जैसे गुण बताते हैं कि कुंजी सामग्री उपयोगी रूप में मॉड्यूल से बाहर जा सकती है या नहीं, और वे प्रति उपकरण नहीं बल्कि प्रति कुंजी सेट होते हैं। हार्डवेयर शब्द या सुरंग की उपस्थिति से निर्यात-अयोग्यता का अनुमान लगाने के बजाय कुंजी पर वास्तविक नीति पढ़ें।

फिर व्यावसायिक स्वीकृति खोजें। अगर केवल स्वीकृत दस्तावेज़ों पर ही हस्ताक्षर हो सकते हैं, तो अनुरोध के HSM तक पहुँचने से पहले कौन-सा घटक वह स्वीकृति स्थापित करता है? अधिकृत अनुरोध स्वीकार करने वाला क्रिप्टोग्राफ़िक इंटरफ़ेस नहीं जानता कि दस्तावेज़ की समीक्षा हुई है या नहीं, इसलिए वह जाँच उसके सामने वाली सेवा की ज़िम्मेदारी है।

स्वीकृत क्लाइंट जो समझौता-ग्रस्त हो, अपने क्रेडेंशियल द्वारा वैध रूप से अधिकृत संक्रियाओं का दुरुपयोग भी कर सकता है, बिना कभी निजी कुंजी निकाले। इसलिए संग्रहीत कुंजी सामग्री की रक्षा और कुंजी के उपयोग का नियंत्रण दो स्वीकृति शर्तें हैं, एक नहीं।

अस्वीकृतियाँ स्वीकृति परीक्षण का हिस्सा हैं

अनुमत हस्ताक्षर अनुरोध स्वीकारें, और अस्वीकृतियाँ भी स्वीकारें: अनधिकृत पहचान, असंबंधित कुंजी और पार्टनर के पथ से प्रबंधन संक्रिया। कॉलर, संक्रिया, कुंजी पहचानकर्ता, समय और परिणाम दर्ज करें, और निजी कुंजी सामग्री, क्रेडेंशियल तथा दस्तावेज़ की सामग्री को सामान्य निदान लॉग से बाहर रखें।

पार्टनर के बाहर निकलने, पार्टनर की ओर संदिग्ध समझौते, और नीति परिवर्तन तथा पुनर्प्राप्ति के लिए एक स्वामी नियुक्त करें। रूट बदलने से ऐसे होस्ट पर भरोसा बहाल नहीं होता जो पहले से समझौता-ग्रस्त हो सकता है, इसलिए निरसन को HSM पहचान तक भी पहुँचना होगा।

पूर्ण हुआ VPN हैंडशेक उसी रिकॉर्ड में आता है। वह HSM-विशिष्ट एक भी परिणाम का विकल्प नहीं बन सकता।