क्या 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 लॉग और ब्राउज़िंग इतिहास के बीच के भोले समीकरण को तोड़ते हैं।
HTTPS पर DNS दूसरी सीमा जोड़ता है: अपने रिज़ॉल्वर वाला ब्राउज़र या अतिथि ऐप संगठन के लॉगर से कभी कुछ नहीं पूछता। सटीक लेन-देन केवल ऐप की अपनी घटनाओं से या ऐसे प्रॉक्सी से आते हैं जिसका लॉगिंग आप स्पष्ट रूप से समर्थन करते हैं। सादा HTTPS CONNECT टनल प्रॉक्सी को उसके अंदर के पृष्ठ पथों की कोई झलक नहीं देता। नेटवर्क का स्वामित्व ऐप के भरोसा मॉडल को चुपचाप बदलने की अनुमति नहीं है।
पता एक सत्र का है, व्यक्ति का नहीं
टनल-रेंज का पता ले जाने वाला फ़्लो रिकॉर्ड उत्तर नहीं, शुरुआती बिंदु है। उस पते और समय-चिह्न को उस क्षण सक्रिय सत्र आवंटन से जोड़ें, क्योंकि वह पता एक घंटे बाद किसी अन्य सत्र को आवंटित हो सकता है। स्थिर पता-निर्धारण उस संबंध को बनाए रखने का एक तरीका है, एकमात्र नहीं।
जहां अनुवाद चरण सेंसर के ऊपर की ओर कई उपकरणों को एक स्रोत पते में समेटता है, वहां जोड़ केवल साझा गेटवे सत्र का नाम ले सकता है। साझा खाता या कई लोगों द्वारा उपयोग किया गया प्रमाणपत्र नेटवर्क डेटा कितना भी पूरा दिखे, एट्रिब्यूशन को सीमित करता है। दोनों रिपोर्ट में बाद की चेतावनी नहीं, सीमा के रूप में होने चाहिए।
समय क्षेत्र, घड़ी का स्रोत, अवलोकन बिंदु और उनके बीच की हर अनुवाद सीमा दर्ज करें। अनुपस्थिति उपस्थिति जितनी ही देखभाल की हकदार है, क्योंकि छूटा हुआ रिकॉर्ड इसका अर्थ हो सकता है कि फ़्लो प्रविष्टि की आयु पूरी हो गई, सेंसर ने पैकेट कभी नहीं देखा, या ऐप लॉग बंद था।
घोषित उद्देश्य के लिए डिज़ाइन करें, फिर पाइपलाइन साबित करें
प्रश्न तय होने के बाद, तय करें कि कौन-से फ़ील्ड आवश्यक हैं, कौन उन्हें पढ़ सकता है और कितने समय तक रखे जाते हैं। संग्रहण सस्ता है इसलिए अधिक एकत्र करना जांच से अधिक जीने वाली ज़िम्मेदारी बनाता है। RFC 6973 में निहित गोपनीयता मॉडल सहसंबंध, गलत एट्रिब्यूशन और अनावश्यक संग्रह को बाद के विचार नहीं, डिज़ाइन की समस्याएं मानता है।
मैपिंग और रिकॉर्ड को एक ही वस्तु की तरह बचाएं, क्योंकि अकेले में प्रत्येक जोड़ी से बहुत कम संवेदनशील है। फिर डिज़ाइन को ऐसी गतिविधि के विरुद्ध सत्यापित करें जिसे उत्पन्न करने की अनुमति आपको है और आप पहले से समझते हैं, रिपोर्ट जिस सबसे छोटी क्वेरी पर निर्भर करेगी उसी से। जो पाइपलाइन ज्ञात घटना को दोहरा नहीं सकती वह अज्ञात घटना भी नहीं दोहराएगी। साक्ष्य जिस घटना का समर्थन करते हैं उसे उन शब्दों में बताएं जिनकी साक्ष्य अनुमति देते हैं, और बड़े निष्कर्ष तक पहुंचना पाठक के लिए छोड़ दें।
निष्कर्ष के बगल में सीमाएं लिखें: क्या जोड़ा गया, क्या अनूदित हुआ और कौन-सा लॉग चुप रहा। जो निष्कर्ष अपनी सीमाएं बताता है वह ऐसी समीक्षा पार करता है जिसे आत्मविश्वासी सारांश पार नहीं करता। साक्ष्य और साक्ष्य की कहानी के बीच यही अंतर है।