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 अभिव्यक्ति र रूपान्तरणमार्फत अनामीकरणको वर्णन गर्छ। ठ्याक्कै त्यही स्थान मुख्य कुरा हो: कच्चा घटना भित्र आउँदै बदलिन्छ, त्यसैले खोजको समयको निकासीलाई खोज्न केही बाँकी रहँदैन।
अनुक्रमण-समयको सम्पादन र खोज-समयको फिल्ड निकासीले फरक समस्या समाधान गर्छन्। सम्पादनले मान कसैले पनि देख्न सक्ने कुरालाई सीमित गर्छ; निकासीले क्वेरीले कुन नाम प्रयोग गर्छ मात्र निर्णय गर्छ। ह्यासिङ सहसम्बन्ध जोगाउने मध्यम विकल्प हो, तर सानो प्रयोगकर्तानाम क्षेत्रमा स्थिर ह्यासले, कसैले यसका विरुद्ध सम्भावित नाम परीक्षण गर्न सक्दा, अझै पहिचान दिन्छ।
यदि भण्डारित घटनामा अझै पहिचान छ भने समस्या तलतिर छ: स्रोत प्रकार, लाइन विभाजन, विभाजक व्यवस्थापन, फिल्ड उपनाम वा क्वेरी आफैं। यी सामान्य पार्सिङ सुधार हुन् र गोपनीयता सीमालाई छुँदैनन्।
सीमासँग मिल्ने सुधार छान्नुहोस्
तीन सर्तले प्रतिक्रिया निर्धारण गर्छन्। पहिलो, के गोपनीयता नीतिले पहिचान बाहिर राख्न खोजेको हो? दोस्रो, के लेखापरीक्षण वा अनुसन्धान प्रक्रियालाई पहिचान, उपनाम, वा सत्र मात्र चाहिन्छ? तेस्रो, मान कुन सीमामा चाहिन्छ — सङ्कलन, भण्डारण वा प्रस्तुति?
नीतिले बाहिर राख्न खोजेको भए नियन्त्रण होइन, आवश्यकता वा प्रस्तुति बदल्नुहोस्। नीतिले पहिचान अनुमति दिन्छ तर सङ्कलनले त्यसलाई छोडिदिन्छ भने सङ्कलक सुधार्नुहोस् र कच्चा घटना पुष्टि गर्नुहोस्। भण्डारण अक्षत छ भने निकासी सुधार्नुहोस् र सुरुमा कैद गरिएको स्वीकृत घटनाविरुद्ध त्यसको परीक्षण गर्नुहोस्।
परिवर्तन अभिलेखमा सीमाको नाम राखेर अनुसन्धान टुङ्ग्याउनुहोस्: स्रोतमा लुकाइएको, अन्तर्ग्रहणमा हटाइएको, वा निकासीले छुटेको। त्यो एउटा वाक्यले अर्को इन्जिनियरलाई पहिले कहाँ हेर्ने भन्ने बताउँछ, र ड्यासबोर्डको गुनासो चुपचाप बन्द गरिएको गोपनीयता सुविधामा परिणत हुनबाट रोक्छ।