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-विशिष्ट एकाही निष्पत्तीची जागा घेऊ शकत नाही।