के VPN लगले ब्राउजिङ इतिहास देखाउन सक्छ? प्रमाणले के सिद्ध गर्छ
एउटा सत्र लग, एउटा रिजोल्भर प्रश्न र एउटा प्रवाह अभिलेखले फरक कुरा सिद्ध गर्छन्। प्रश्न छान्नुहोस्, पहिचान र समय जोड्नुहोस्, अनि देखिएको कुरा मात्र भन्नुहोस्।
दुई लेखापरीक्षण प्रश्न सुन्दा उस्तै लाग्छन् तर फरक किसिमको प्रमाण चाहिन्छ। यो ठेगानामा कुन सत्रले सम्पर्क गर्यो भन्ने कुरा जडान र प्रवाह अभिलेखबाट भन्न सकिन्छ। यो पृष्ठ कुन व्यक्तिले खोल्यो भन्ने कुरा सामान्यतया भन्न सकिँदैन, कम्तीमा ती अभिलेखबाट त होइन। प्रश्न छान्नुअघि सङ्कलक छान्नु भनेको सञ्जाल टोलीले अन्ततः होस्टनामलाई ब्राउजिङ इतिहासका रूपमा प्रस्तुत गर्ने तरिका हो।
लेखापरीक्षणले सिद्ध गर्नुपर्ने घटनाबाट सुरु गर्नुहोस्
विषय, क्रियापद र समय भएको वाक्यका रूपमा प्रश्न लेख्नुहोस्। त्यो एउटै अनुशासनले सत्र अभिलेख र पृष्ठ हेराइबीचको खाडल उजागर गर्छ। सत्र लगले एक पहिचान स्वीकार गरिएको, निश्चित अवधिका लागि, अभिलेखित नीतिअन्तर्गत दिइएको ठेगानासहित भन्ने कुरा सिद्ध गर्छ, तर कसैले कुन पृष्ठ पढ्यो भन्ने कुरा सिद्ध गर्न सक्दैन, किनकि उसले अनुरोध कहिल्यै देखेन।
सङ्कलन डिजाइन गर्नुअघि अवलोकनलाई नाम दिनुहोस्। भ्रमण गरिएको साइटको नाममा राखिएको तर वास्तवमा समाधान भएको नाम भण्डारण गर्ने फिल्ड भविष्यको त्रुटि हो, सुविधा होइन। फिल्डका नामहरू ती छान्ने मानिसभन्दा लामो समय टिक्छन्, त्यसैले निष्कर्षभन्दा प्रमाणको वर्णन गर्ने नाम छान्नुहोस्।
प्रत्येक अभिलेखले के समर्थन गर्न सक्छ र के सक्दैन
लगभग हरेक लेखापरीक्षण डिजाइनमा चार किसिमका अभिलेख देखिन्छन्, र प्रत्येकले फरक प्रश्नको उत्तर दिन्छ। प्रतिवेदनमा पनि र पाइपलाइनमा पनि तिनलाई अलग राख्नुहोस्, किनकि तिनलाई मिसाउँदा नै रक्षायोग्य निष्कर्ष लज्जास्पद बन्छ।
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
अन्तिम स्तम्भलाई बीचको जत्तिकै ध्यानले पढ्नुहोस्। प्रवाह अभिलेखले ठेगाना र पोर्टको वर्णन गर्छ, र ठेगानाको उल्टो खोजले ब्राउजरले प्रयोग गरेको नाम पुनर्निर्माण गर्दैन, किनकि एउटै ठेगानामा धेरै असम्बन्धित साइटहरू बस्न सक्छन्। रिजोल्भर प्रश्नले प्रश्न सोधिएको कुरा सिद्ध गर्छ, पृष्ठ देखाइएको कुरा होइन। TLS वार्ताका क्रममा देखिने होस्टनाम पनि इन्क्रिप्टेड अनुरोध मार्ग होइन।
यीमध्ये प्रत्येक वास्तविक अवलोकन हो, र तीमध्ये कुनै पनि मानिसले अनुमान गर्ने अवलोकन होइन। आफ्नै इन्क्रिप्टेड रिजोल्भरमा अडिग ब्राउजर निगरानीको दायराबाहिर बस्छ, र लगिङले नदेखेको कुरा विश्लेषणले फेरि फेला पार्न सक्दैन। त्यो खाडल प्रतिवेदनमा फुटनोट नभई स्पष्ट सीमाका रूपमा उल्लेख हुनुपर्छ।
अनुमानित खोज र क्यासमा रहेका उत्तरहरू
ब्राउजरहरू अग्रिम रूपमा नामहरू समाधान गर्छन्, कहिलेकाहीँ केही पनि लोड नगरी। तिनीहरूले क्यासबाट उत्तर दिन्छन् र तपाईंले हेरिरहनुभएको रिजोल्भरकहाँ नयाँ प्रश्न पठाउँदैनन्, जसको अर्थ प्रश्न नहुनु भ्रमण नहुनु होइन। यी दुवै व्यवहारले DNS लग र ब्राउजिङ इतिहासबीचको सोझो समीकरण तोड्छन्।
DNS over HTTPS ले दोस्रो सीमा थप्छ: आफ्नै रिजोल्भर भएको ब्राउजर वा पाहुना अनुप्रयोगले संस्थाको लगरलाई केही पनि सोध्दैन। ठ्याक्कै लेनदेन अनुप्रयोगका आफ्नै घटनाबाट वा तपाईंले स्पष्ट रूपमा समर्थन गर्नुभएको लगिङ भएको प्रोक्सीबाट मात्र आउँछ। साधारण HTTPS CONNECT सुरुङले प्रोक्सीलाई भित्रका पृष्ठ मार्गहरूको कुनै झलक दिँदैन। सञ्जालको स्वामित्व भनेको अनुप्रयोगको विश्वास मोडेल चुपचाप बदल्ने अनुमति होइन।
ठेगाना सत्रको हो, व्यक्तिको होइन
सुरुङ दायराको ठेगाना बोकेको प्रवाह अभिलेख उत्तर नभई सुरुवाती बिन्दु हो। त्यो ठेगाना र समयलाई त्यस क्षण सक्रिय सत्र असाइनमेन्टसँग जोड्नुहोस्, किनकि त्यही ठेगाना एक घण्टापछि अर्को सत्रलाई दिन सकिन्छ। स्थिर ठेगाना त्यो सम्बन्ध कायम राख्ने एउटा तरिका हो, एक मात्र होइन।
जहाँ अनुवादको चरणले सेन्सरभन्दा माथि धेरै उपकरणलाई एउटै स्रोत ठेगानामा समेट्छ, त्यहाँ जोडाइले साझा गेटवे सत्रको नाम मात्र भन्न सक्छ। साझा खाता वा धेरै व्यक्तिले प्रयोग गर्ने प्रमाणपत्रले सञ्जाल डेटा जतिसुकै पूर्ण देखिए पनि श्रेयको सटीकता सीमित गर्छ। दुवै प्रतिवेदनमा पछिका चेतावनी नभई सीमाका रूपमा राख्नुपर्छ।
समय क्षेत्र, घडीको स्रोत, अवलोकन बिन्दु र बीचका हरेक अनुवाद सीमा अभिलेख गर्नुहोस्। अनुपस्थितिलाई उपस्थिति जत्तिकै ध्यान चाहिन्छ, किनकि अभिलेख नहुनुको अर्थ प्रवाह प्रविष्टि म्याद सकिएको, सेन्सरले प्याकेट कहिल्यै नदेखेको वा अनुप्रयोग लग बन्द गरिएको हुन सक्छ।
भनिएको उद्देश्यका लागि डिजाइन गर्नुहोस्, अनि पाइपलाइन प्रमाणित गर्नुहोस्
प्रश्न तय भएपछि कुन फिल्ड आवश्यक छन्, कसले पढ्न सक्छ र कति समय राखिन्छ भन्ने परिभाषित गर्नुहोस्। भण्डारण सस्तो छ भनेर बढी सङ्कलन गर्नु अनुसन्धानभन्दा लामो समय टिक्ने दायित्व सिर्जना गर्छ। RFC 6973 मा रहेको गोपनीयता ढाँचाले सहसम्बन्ध, गलत श्रेय र अनावश्यक सङ्कलनलाई पछिको सोच नभई डिजाइनका समस्या मान्छ।
म्यापिङ र अभिलेखलाई एउटै वस्तुका रूपमा सुरक्षित राख्नुहोस्, किनकि प्रत्येक अलग हुँदा जोडीभन्दा धेरै कम संवेदनशील हुन्छ। त्यसपछि तपाईंलाई उत्पन्न गर्न अनुमति भएको र पहिले नै बुझेको गतिविधिविरुद्ध डिजाइन प्रमाणित गर्नुहोस्, प्रतिवेदनले भर पर्ने सबैभन्दा सानो प्रश्न प्रयोग गरेर। ज्ञात घटना पुनः उत्पादन गर्न नसक्ने पाइपलाइनले अज्ञात घटना पनि पुनः उत्पादन गर्दैन। प्रमाणले समर्थन गर्ने घटना, प्रमाणले दिने शब्दमै लेख्नुहोस्, र ठूलो निष्कर्ष पाठकले आफैं निकालून्।
निष्कर्षको छेउमै सीमाहरू लेख्नुहोस्: के जोडियो, के अनुवाद भयो र कुन लग चुप रह्यो। आफ्नै सीमा बताउने निष्कर्ष आत्मविश्वासी सारांशले सहन नसक्ने समीक्षा सहन्छ। प्रमाण र प्रमाणबारेको कथा यही फरक हो।