साझेदारकहाँ कसैले एउटा तोकिएको कुञ्जीले कागजातमा हस्ताक्षर गर्नुपर्छ, र अनुरोध नेटवर्किङको रूपमा आउँछ: उनीहरूले 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-विशेष एउटै नतिजाको ठाउँ लिन सक्दैन।

सम्बन्धित लेखहरू