साठवलेला VPN पासवर्ड: तो कोण आणि कधी डिक्रिप्ट करू शकतो

जो VPN क्लायंट त्याच्या XML मध्ये एन्क्रिप्ट केलेला पासवर्ड दाखवतो, त्याने तुम्हाला जवळपास काहीही सांगितले नाही। त्या रूपात मूल्य साधा मजकूर म्हणून साठवले जात नाही एवढेच सिफरटेक्स्ट सांगतो। तो कोण डिक्रिप्ट करू शकतो, कोणत्या कीने आणि कोणत्या वापरकर्ता संदर्भात, हेच ते प्रश्न आहेत जे साठवणूक उपयुक्त आहे की नाही हे ठरवतात। फाइल सुरक्षित किंवा असुरक्षित म्हणण्यापूर्वी त्यांना उत्तर द्या।

कोणती वस्तू साठवली जाते ते निश्चित करा

उत्पादनाच्या दस्तऐवजीकृत साठवणूक मॉडेलपासून सुरुवात करा। क्लायंट पुनर्प्राप्त करण्यायोग्य पासवर्ड, टोकन किंवा क्रेडेन्शियल स्टोअरचा संदर्भ साठवू शकतो आणि प्रत्येकाचे उघड होणे वेगळे असते। XML घटकाचे नाव हे डिझाइन नाही आणि base64 सारखी दिसणारी मालिका देखील एन्क्रिप्शनचा पुरावा नाही।

कनेक्ट होताना कोणता घटक मूल्य वाचतो ते विक्रेता किंवा प्रशासकाला विचारा।

त्यानंतर दस्तऐवजीकृत असल्यास संरक्षण API ओळखा। Windows मध्ये, CryptProtectData एन्क्रिप्ट करणाऱ्या वापरकर्त्याच्या लॉगऑन क्रेडेन्शियलपासून मिळवलेल्या कीने डेटा संरक्षित करतो आणि त्याचा मशीन-व्याप्ती पर्याय कोण डिक्रिप्ट करू शकतो हे बदलतो। व्याप्ती का महत्त्वाची आहे याचे हे ठोस उदाहरण आहे। कोणताही विशिष्ट VPN क्लायंट ती API वापरतो याचा हा पुरावा नाही।

चोरलेली प्रत रनटाइम वापरापासून वेगळी करा

तुम्हाला न विचारता पुन्हा कनेक्ट होणाऱ्या क्लायंटला क्रेडेन्शियल पुनर्प्राप्त करण्याचा समर्थित मार्ग आवश्यक आहे। बॅकअप प्रतीचे संरक्षण ती क्षमता काढून टाकत नाही। योग्य वापरकर्ता संदर्भात चालणारा कोणताही कार्यक्रम तोच मार्ग वापरू शकतो, म्हणूनच एंडपॉइंट स्वतः विश्वास सीमेच्या आत आहे। फाइल परवानग्या आणि प्रक्रिया विशेषाधिकार ती सीमा अरुंद करतात; ती काढून टाकत नाहीत।

ऑफलाइन फाइलबद्दलचा दावा सहसा हाच फरक चुकीचा समजतो। विश्रांतीतील एन्क्रिप्शन खात्याशिवाय एक फाइल कॉपी करणाऱ्याला थांबवू शकते। खात्याच्या रूपात चालणारा कोड थांबवत नाही।

दोन्ही विधाने एकाच वेळी खरी असू शकतात आणि घटना प्रतिसादादरम्यान दुसरेच महत्त्वाचे असते।

प्रत्यक्षात लागू होणारी प्रवेश नियंत्रणे वाचा

फाइलची ACL आणि त्यावरील डिरेक्टरी तपासा, फक्त फाइल मोड नाही। Windows मध्ये वापरकर्ता प्रोफाइलच्या प्रभावी परवानग्यांची क्लायंटच्या सेवा किंवा नियोजित कार्याच्या परवानग्यांशी तुलना करा। एका वापरकर्त्यासाठी संरक्षित रहस्य प्रशासकापासून स्वयंचलितपणे संरक्षित नसते आणि स्वयंचलितपणे त्याला उघड देखील होत नाही।

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

कोणती ओळख क्लायंट चालवते ते नोंदवा, कारण तीच ओळख डिक्रिप्शनचा विषय आहे।

व्यवस्थापित ताफ्यासाठी संबंधित नियंत्रण फाइल नसून उपकरण व्यवस्थापन असू शकते। क्रेडेन्शियल एस्क्रोमध्ये ठेवले जाते का, दूरून रद्द करता येते का आणि उपकरण हरवल्यावर प्रक्रिया काय आहे ते विचारा।

डिक्रिप्शन चाचण्याऐवजी उघड होण्याची योजना करा

मुद्दा सिद्ध करण्यासाठी अपरिचित एक्स्ट्रॅक्शन साधन फाइलवर चालवू नका। ते चालू शकते, प्रोफाइल खराब करू शकते आणि कोणत्याही परिस्थितीत पुरावे बदलते। पडताळणी खरोखर आवश्यक असल्यास दस्तऐवजीकृत डिझाइन आणि अधिकृत मूल्यांकन वापरा।

उघड होणे सिद्ध झाल्यास ओळखीच्या मालकाकडे क्रेडेन्शियल बदला।

साठवलेली नोंद हटवणे म्हणजे रद्द करणे नाही। ते त्या क्लायंटला पुन्हा मूल्य देण्यापासून रोखू शकते आणि आधीच घेतलेल्या प्रती किंवा आधीच अधिकृत सत्राबद्दल काहीही करत नाही। क्रेडेन्शियल बदला, मालक जे सत्र संपुष्टात आणू शकतो ते संपुष्टात आणा आणि काय कधी बदलले ते नोंदवा।

विक्रेता पुनरावलोकनासाठी प्रश्न

कोणते रहस्य साठवले जाते, कोणता घटक ते वापरतो, कोणती वापरकर्ता किंवा मशीन की त्याचे संरक्षण करते, सामान्य वापर आणि बॅकअपवर कोणती प्रवेश नियंत्रणे लागू होतात आणि साठवण्याचे धोरण व दूरस्थ अवैधीकरण कसे हाताळले जाते ते विचारा। ती पाच उत्तरे डिझाइन वर्णन करतात; XML नाही।

पुढील पुनरावलोकनकर्त्याने सराव पुन्हा करू नये म्हणून उत्तरे तैनाती नोंदीसोबत ठेवा।

साठवलेले क्रेडेन्शियल सोय आणि उघड होणे यातील देवघेव आहे। देवघेव जाणीवपूर्वक करा आणि कोणी ती स्वीकारली ते लिहा।