सहेजा गया VPN पासवर्ड: इसे कौन और कब डिक्रिप्ट कर सकता है

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

निर्धारित करें कि कौन-सी वस्तु संग्रहीत है

उत्पाद के प्रलेखित भंडारण मॉडल से शुरू करें। क्लाइंट पुनर्प्राप्य पासवर्ड, टोकन या क्रेडेंशियल स्टोर के संदर्भ को संग्रहीत कर सकता है, और हर एक का जोखिम अलग है। XML एलिमेंट का नाम डिज़ाइन नहीं है, और base64 जैसा दिखने वाला स्ट्रिंग भी एन्क्रिप्शन का प्रमाण नहीं है।

विक्रेता या प्रशासक से पूछें कि कनेक्ट के समय कौन-सा घटक मान पढ़ता है।

फिर यदि प्रलेखित हो तो सुरक्षा API पहचानें। Windows में, CryptProtectData डेटा को एन्क्रिप्ट करने वाले उपयोगकर्ता के लॉगऑन क्रेडेंशियल से व्युत्पन्न कुंजी से सुरक्षित करता है, और इसका मशीन-स्तरीय विकल्प बदलता है कि कौन डिक्रिप्ट कर सकता है। यह इस बात का ठोस उदाहरण है कि दायरा क्यों मायने रखता है। यह प्रमाण नहीं है कि कोई विशेष VPN क्लाइंट उस API का उपयोग करता है।

चोरी हुई प्रति को रनटाइम उपयोग से अलग करें

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

यही वह अंतर है जिसे ऑफ़लाइन फ़ाइल का दावा आमतौर पर गलत समझता है। विराम-अवस्था में एन्क्रिप्शन उसे रोक सकता है जो खाते के बिना एक फ़ाइल की प्रति बनाता है। यह उस कोड को नहीं रोकता जो खाते के रूप में चलता है।

दोनों कथन एक साथ सत्य हो सकते हैं, और घटना प्रतिक्रिया के दौरान दूसरा ही मायने रखता है।

वे एक्सेस नियंत्रण पढ़ें जो वास्तव में लागू होते हैं

फ़ाइल का ACL और उसके ऊपर की निर्देशिका जाँचें, केवल फ़ाइल मोड नहीं। Windows में उपयोगकर्ता प्रोफ़ाइल की प्रभावी अनुमतियों की तुलना क्लाइंट की सेवा या निर्धारित कार्य की अनुमतियों से करें। एक उपयोगकर्ता के लिए सुरक्षित रहस्य स्वतः प्रशासक से सुरक्षित नहीं होता, और न ही स्वतः उसके सामने उजागर होता है।

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

दर्ज करें कि कौन-सी पहचान क्लाइंट चलाती है, क्योंकि वही पहचान डिक्रिप्शन का विषय है।

प्रबंधित फ़्लीट के लिए प्रासंगिक नियंत्रण फ़ाइल के बजाय डिवाइस प्रबंधन हो सकता है। पूछें कि क्रेडेंशियल एस्क्रो में रखा जाता है या नहीं, दूर से रद्द किया जा सकता है या नहीं, और डिवाइस खोने पर प्रक्रिया क्या है।

डिक्रिप्शन परखने के बजाय जोखिम की योजना बनाएँ

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

यदि जोखिम सिद्ध हो जाए, तो पहचान के स्वामी के पास क्रेडेंशियल बदलें।

सहेजी गई प्रविष्टि हटाना रद्दीकरण नहीं है। यह उस क्लाइंट को फिर से मान देने से रोक सकता है, और पहले से ली गई प्रति या पहले से अधिकृत सत्र के बारे में कुछ नहीं करता। क्रेडेंशियल बदलें, वे सत्र समाप्त करें जो स्वामी समाप्त कर सकता है, और दर्ज करें कि क्या बदला गया और कब।

विक्रेता समीक्षा के प्रश्न

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

उत्तरों को परिनियोजन रिकॉर्ड के साथ रखें ताकि अगला समीक्षक अभ्यास दोहराए नहीं।

सहेजा गया क्रेडेंशियल सुविधा और जोखिम के बीच सौदा है। यह सौदा जानबूझकर करें, और लिखें कि किसने इसे स्वीकार किया।