VPN उपयोक्तानाम लॉग पाइपलाइन से कहाँ गायब हो जाता है?
लॉग की गोपनीयता नियंत्रण बदलने से पहले गेटवे घटना, संग्राहक की कच्ची प्रति, अनुक्रमित घटना और खोज के समय का फ़ील्ड तुलना करें।
सत्र डैशबोर्ड पर दिखाई देते हैं जबकि उपयोक्तानाम का स्तंभ खाली रहता है, और पहली प्रवृत्ति पार्सर को दोष देना है। यह प्रवृत्ति तीन पहले के चरणों को छोड़ देती है जहाँ मान खो सकता था। एक गेटवे नीति के अनुसार पहचान छिपा सकता है, एक अंतर्ग्रहण नियम उसे अनुक्रमण से पहले मिटा सकता है, और खोज के समय का निष्कर्षण उसका नाम लेने में बस विफल हो सकता है। सुधार इस पर निर्भर है कि आप किस सीमा को उत्तरदायी सिद्ध कर सकते हैं, इसलिए उपयोगी काम तुलना है, विन्यास नहीं।
डैशबोर्ड से नहीं, एक घटना से शुरू करें
एक ही प्रमाणीकरण घटना चुनें और लिखें कि उसे क्या पहचानता है: गेटवे का मॉडल और संस्करण, प्रमाणीकरण विधि, घटना पहचानकर्ता, समयचिह्न और स्रोत पता। उपयोक्तानाम ठीक वैसे ही जोड़ें जैसे व्यक्ति ने लिखा था, बड़े-छोटे अक्षरों सहित, क्योंकि अक्षर-संवेदी खोज किसी मौजूद फ़ील्ड को छिपा सकती है। उस घटना को हर बाद की तुलना के लिए संदर्भ मानें।
घटना के प्रकार एक ही स्कीमा साझा नहीं करते। विफल प्रयास, बिना क्लाइंट का सफल लॉगिन और सुरंग का पुनः जुड़ाव हर एक भिन्न फ़ील्ड बना सकते हैं, और कुछ गेटवे पहचान छोड़ देते हैं जब प्रयास कभी उपयोक्ता प्रमाणीकरण तक नहीं पहुँचा। इसलिए एक घटना प्रकार में खाली स्तंभ पाइपलाइन समस्या का कमज़ोर प्रमाण है।
असली कर्मचारी खाते के बजाय स्वीकृत परीक्षण पहचान के साथ काम करें, और तुलना को उन पहुँच नियमों के भीतर रखें जो लॉग डेटा पर पहले से लागू हैं। केवल नमूना पाने के लिए विस्तृत प्रमाणीकरण लॉगिंग को व्यापक रूप से चालू करना उस प्रणाली को बदल देता है जिसे आप मापना चाहते हैं।
चार सीमाओं की क्रम से तुलना करें
मान चार में से किसी एक बिंदु पर गायब हो सकता है। हर बिंदु का भिन्न स्वामी और भिन्न सुधार है।
| Boundary | What to compare | A gap means |
|---|---|---|
| Gateway event view | The device's own event display and logging policy | The identity was masked or never emitted |
| Collector receive | The raw event as received, before parsing | Transport, filter or source selection dropped it |
| Index-time pipeline | Transforms applied before storage | Redaction or rewriting removed the value |
| Search-time extraction | The field name and regex used by the query | The label does not match the stored key |
जहाँ मान गायब होता है उस पहली सीमा पर रुकें। उपकरण के दृश्य और कच्ची प्रति के बीच असंगति परिवहन या संग्राहक विन्यास की ओर संकेत करती है; वहाँ मेल पर अनुक्रमित घटना में मान का अनुपस्थित होना किसी रूपांतरण की ओर संकेत करता है; अनुक्रमित घटना में मान होना पर डैशबोर्ड पर न होना निष्कर्षण या क्वेरी की ओर संकेत करता है।
यह क्रम महत्वपूर्ण है क्योंकि हर बाद का चरण केवल जानकारी खो सकता है, उसे कभी बहाल नहीं कर सकता। एक रेगुलर एक्सप्रेशन उस स्ट्रिंग को वापस नहीं ला सकता जिसे किसी पहले चरण ने प्लेसहोल्डर से बदल दिया था, और गोपनीयता सेटिंग उस मान को नहीं समझा सकती जो कभी भेजा ही नहीं गया।
स्रोत पर छिपाना नीति है, पार्सर की गलती नहीं
Cisco का ASA लॉगिंग दस्तावेज़ उपयोक्तानाम छिपाने को विन्यासयोग्य व्यवहार के रूप में वर्णित करता है, जिसमें यह भी शामिल है कि अमान्य या अज्ञात उपयोक्तानाम कैसे प्रदर्शित होते हैं। इसलिए स्रोत घटना में छिपाई गई पहचान ठीक वही हो सकती है जो गोपनीयता नीति मांगती है, और उसे पार्सिंग विफलता मानना ऐसी मांग की ओर ले जाता है जो नियंत्रण को कमज़ोर करती है।
सटीक प्रस्तुति संस्करण और संदेश प्रकार पर निर्भर है। एक घटना प्लेसहोल्डर रख सकती है, दूसरी फ़ील्ड को पूरी तरह छोड़ सकती है, और प्रमाणीकरण विफलता में कभी नाम नहीं भी हो सकता है। हर अनुपस्थित पहचान पर पुरानी बग रिपोर्ट लागू करने के बजाय उस विशिष्ट घटना के लिए प्रलेखित व्यवहार जाँचें।
जब छिपाना जानबूझकर हो, तो प्रश्न फ़ील्ड को कैसे बहाल करें से बदलकर यह हो जाता है कि क्या लेखा-परीक्षा आवश्यकता किसी और तरीके से पूरी हो सकती है। सत्र पहचानकर्ता, छोटे समूह के पास रखा नियंत्रित पहचान मैपिंग, या संकीर्ण अधिकृत घटना फ़ीड अक्सर हर प्रयास किए गए उपयोक्तानाम को हर लॉग पाठक के सामने रखे बिना आवश्यकता पूरी कर देते हैं।
अनुक्रमण से पहले का अनामीकरण पूर्ववत नहीं किया जा सकता
घटना प्रसंस्करण पर Splunk का दस्तावेज़ sed अभिव्यक्तियों और रूपांतरणों के माध्यम से अनामीकरण का वर्णन करता है जो अनुक्रमण से पहले डेटा को फिर से लिखते या हटाते हैं। ठीक यही स्थान मुख्य बात है: कच्ची घटना अंदर आते समय बदल दी जाती है, इसलिए खोज के समय के निष्कर्षण के पास खोजने को कुछ नहीं बचता।
अनुक्रमण-समय का संपादन और खोज-समय का फ़ील्ड निष्कर्षण भिन्न समस्याएँ हल करते हैं। संपादन सीमित करता है कि मान कभी कौन देख सकता है; निष्कर्षण केवल तय करता है कि क्वेरी कौन-सा नाम उपयोग करती है। हैशिंग एक मध्यम विकल्प है जो सहसंबंध बनाए रखता है, पर छोटे उपयोक्तानाम स्थान पर स्थिर हैश तब भी पहचान देता है जब कोई उसके विरुद्ध संभावित नाम जाँच सके।
यदि संग्रहीत घटना में अभी भी पहचान है, तो समस्या नीचे की ओर है: स्रोत प्रकार, पंक्ति विभाजन, विभाजक प्रबंधन, फ़ील्ड उपनाम या क्वेरी स्वयं। ये सामान्य पार्सिंग सुधार हैं और ये गोपनीयता सीमा को नहीं छूते।
सीमा से मेल खाने वाला सुधार चुनें
तीन शर्तें प्रतिक्रिया तय करती हैं। पहली, क्या गोपनीयता नीति पहचान को बाहर रखना चाहती है? दूसरी, क्या लेखा-परीक्षा या जाँच प्रक्रिया को पहचान, उपनाम, या केवल सत्र चाहिए? तीसरी, मान किस सीमा पर चाहिए — संग्रह, भंडारण या प्रस्तुति?
यदि नीति बाहर रखना चाहती है, तो नियंत्रण नहीं, आवश्यकता या प्रस्तुति बदलें। यदि नीति पहचान की अनुमति देती है पर संग्रह उसे गिरा देता है, तो संग्राहक सुधारें और कच्ची घटना की पुष्टि करें। यदि भंडारण अक्षत है, तो निष्कर्षण सुधारें और शुरुआत में कैद की गई स्वीकृत घटना के विरुद्ध उसकी परीक्षा करें।
परिवर्तन रिकॉर्ड में सीमा का नाम देकर जाँच समाप्त करें: स्रोत पर छिपाई गई, अंतर्ग्रहण के दौरान हटाई गई, या निष्कर्षण से छूटी। वह एक वाक्य अगले इंजीनियर को बताता है कि पहले कहाँ देखना है, और यह डैशबोर्ड की शिकायत को चुपचाप बंद की गई गोपनीयता सुविधा में बदलने से रोकता है।