दो-कारक प्रमाणीकरण वाले वर्चुअल VPN गेटवे के लिए स्वीकृति जाँचें

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

आपूर्तिकर्ता को इस तैनाती के बारे में क्या पुष्टि करनी चाहिए

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

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

सिद्ध करें कि दूसरा कारक दूसरा कारक है

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

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

कुछ तोड़ने से पहले उत्तीर्णता-शर्त लिखें

नीचे दी गई तालिका शीट का वह हिस्सा है जो आपूर्तिकर्ता के संपर्क में टिकता है, क्योंकि हर पंक्ति आश्वासन के बजाय साक्ष्य माँगती है। पूर्वाभ्यास से पहले उत्तीर्णता-शर्त भरें, और बिना साक्ष्य वाली पंक्ति को असफल पंक्ति मानें। पाँच चरण बताते हैं कि गेटवे को क्या करना है।

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

प्रतिलिपि पर अभ्यास करें, जीवंत गेटवे पर नहीं

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

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

आपकी टीम जो कार्यभार चलाएगी उसे मापें

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

शीट तब पूरी होती है जब हर चरण के पास साक्ष्य हो और हर साक्ष्य के पास तिथि। किसी द्वारा बनाए रखा गया उपकरण, हर पंक्ति के साक्ष्य के साथ, टिक किए गए खानों की सबसे लंबी सूची से अलग खरीद है।