VPN लॉग का संरक्षण: इसे संख्या से नहीं, घटना से जोड़ें
संरक्षण घटना, सामग्री और नीति का पालन करता है, किसी सार्वभौमिक समयसीमा का नहीं। हर प्रति खोजें, विस्तृत संग्रह रोकें और एक छोटा रिकॉर्ड रखें।
कोई वास्तव में नहीं पूछता कि VPN लॉग कितने समय तक रखना है; लोग पूछते हैं कि लॉग किस काम का है, और उसका उत्तर ही तारीख तय करता है। एक ही घटना से अलग-अलग आयु वाली दो फ़ाइलें निकल सकती हैं, और उन्हें एक ही नीति मानने से एक साथ अधिक संरक्षण और साक्ष्य की हानि दोनों होती हैं। जब कारण अज्ञात था तब लिया गया डीबग निर्यात उस पंक्ति जैसी वस्तु नहीं है जो निगरानी भंडार में होती है। उद्देश्य से शुरू करें, फिर तारीख चुनें।
तारीख चुनने से पहले चार प्रश्नों का उत्तर दें
चार प्रश्न तय करते हैं कि फ़ाइल रहेगी या नहीं: क्या घटना अभी खुली है, फ़ाइल में क्या है, इसे किसे पढ़ना है, और लागू नीति क्या माँगती है। इसी क्रम में उत्तर दें और संरक्षण की तारीख स्वयं निकल आती है। तर्क एक तालिका में बैठता है:
| Question | How it moves the answer |
|---|---|
| Incident state | An open investigation justifies a protected original; a closed one rarely does |
| Content | Connection identifiers, internal names and addresses raise the cost of a leak |
| Audience | Who retrieves it, and whether a redacted excerpt would serve them instead |
| Policy floor | The applicable service or organizational rule, which overrides a shorter reasoning |
जब तक घटना खुली है, एक संरक्षित मूल प्रति रखें ताकि बाद में घटनाओं की तुलना कर सकें या सहायता प्रश्न का उत्तर दे सकें, और उसे लिखित रूप में एक स्वामी और एक उद्देश्य दें। प्रतिक्रिया दल से बाहर के किसी भी व्यक्ति के लिए छोटा संपादित अंश आमतौर पर पर्याप्त होता है, और पूर्ण निर्यात की तुलना में इसकी रक्षा करना बहुत आसान है। मूल प्रति और अंश अलग-अलग दर्शकों वाली अलग वस्तुएँ हैं, और इन्हें मिलाना ही एक साथ अधिक संरक्षण और साक्ष्य की हानि पैदा करता है। नीति एक न्यूनतम सीमा तय करती है, इसलिए यदि वह आपके तर्क से अधिक समय माँगती है, तो नीति जीतती है।
घटना को रिकॉर्ड से बंद करें, निर्यात से नहीं
टिकट में चार पंक्तियों का रिकॉर्ड लिखें: लक्षण, क्लाइंट और संस्करण, वह एकमात्र त्रुटि पंक्ति जिसने इसे पहचाना, और समाधान। और कुछ संलग्न न करें, क्योंकि निर्यात आपके लिए था और रिकॉर्ड अगले व्यक्ति के लिए है।
रिकॉर्ड के पढ़े जाने की संभावना भी अधिक है: पूर्ण निर्यात मुख्यतः उसी की सेवा करता है जिसने उसे लिया, और वह व्यक्ति पहले से जानता है कि क्या हुआ। रिकॉर्ड वहीं रखें जहाँ अगली घटना में खोजा जाएगा, जिसका अर्थ आमतौर पर टिकट होता है, तारीख के नाम वाला फ़ोल्डर नहीं। यदि रिकॉर्ड को कनेक्शन पहचानकर्ता उजागर किए बिना पता लगाने योग्य होना है, तो केस संख्या संदर्भ वहन कर सकती है। यदि कोई प्रश्न अभी खुला है, तो मूल प्रति ऊपर के संरक्षित-प्रति नियम के अंतर्गत रहती है; रिकॉर्ड बन जाने के बाद बाकी सब जा सकता है।
एक मिटाने से पहले हर प्रति खोजें
निर्यात फ़ोल्डर में देखें, फिर घटना विंडो के जर्नल में, फिर टिकट के अनुलग्नकों में, फिर बैकअप कैटलॉग में, फिर निगरानी भंडार में। यदि वही कनेक्शन पहचानकर्ता पाँचवें स्थान पर मिलता है, तो सूची गलत थी। जर्नल ही आम आश्चर्य है, क्योंकि जब आप निर्यात पढ़ रहे थे तब भी वह संग्रह करता रहा।
फ़ाइलों को हाथ से अनलिंक करने के बजाय समर्थित रोटेशन और विलोपन पथ का उपयोग करें। जो फ़ाइल अभी खुली है वह निर्देशिका प्रविष्टि गायब होने के बाद भी अपना संग्रहण रखती है, इसलिए विलोपन पूरा दिखता है और कुछ भी मुक्त नहीं करता। यह गोपनीयता का लेबल पहने संग्रहण दोष है, और यह दोनों में से कोई लक्ष्य पूरा नहीं करता।
विलोपन सत्यापित करने से पहले संग्रह रोकें
अस्थायी विस्तृत संग्रह को उस ऐप्लिकेशन के माध्यम से रोकें जो उसका स्वामी है, उसकी आउटपुट फ़ाइल संपादित करके नहीं। भूला हुआ डीबग सेटिंग पुराने रिकॉर्ड हटने के बाद भी नए रिकॉर्ड लिखता रहता है, जो आपके द्वारा अभी किए गए काम को चुपचाप रद्द कर देता है। याद रखे गए मान के बजाय वास्तविक लॉगिंग स्तर जाँचें। फिर पुष्टि करें कि जो बचा है वह संरक्षित है और केवल इच्छित लोग ही उसे पुनः प्राप्त कर सकते हैं।
सिद्धांत डेटा-न्यूनीकरण है: जो घोषित उद्देश्य को चाहिए, उसे उतने समय तक रखें जितना उसे चाहिए, और उससे अधिक नहीं, जैसा कि RFC 6973 गोपनीयता मार्गदर्शन इसे प्रस्तुत करता है। उद्देश्य के बिना रखी गई फ़ाइल समय-मुद्रा वाली देनदारी है। निर्णय तब पूरा होता है जब आप फ़ाइल, उसका उद्देश्य, उसका स्वामी और उसकी अंतिम तिथि बता सकें।