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 अभिव्यक्ती आणि रूपांतरणांद्वारे अनामीकरणाचे वर्णन करते। तेच स्थान मुख्य मुद्दा आहे: कच्चा इव्हेंट आत येतानाच बदलतो, त्यामुळे शोधेच्या वेळच्या उत्खननाला शोधायला काहीच उरत नाही।
अनुक्रमण-वेळचे संपादन आणि शोध-वेळचे फील्ड उत्खनन वेगवेगळ्या समस्या सोडवतात। संपादन मूल्य कोणीही पाहू शकतो याला मर्यादा घालते; उत्खनन क्वेरी कोणते नाव वापरते हे फक्त ठरवते। हॅशिंग सहसंबंध टिकवणारा मधला पर्याय आहे, पण लहान वापरकर्तानाव जागेवरचा स्थिर हॅश, कोणी त्याच्याविरुद्ध संभाव्य नावे तपासू शकत असल्यास तरीही ओळख देतो।
साठवलेल्या इव्हेंटमध्ये अजूनही ओळख असेल, तर समस्या पुढे आहे: स्रोत प्रकार, ओळीचे विभाजन, विभाजक हाताळणी, फील्ड उपनावे किंवा क्वेरी स्वतः। हे सामान्य पार्सिंग दुरुस्त्या आहेत आणि त्या गोपनीयता सीमेला स्पर्श करत नाहीत।
सीमेशी जुळणारी दुरुस्ती निवडा
तीन अटी प्रतिसाद ठरवतात। पहिली, गोपनीयता धोरण ओळख वगळण्याचा हेतू धरते का? दुसरी, ऑडिट किंवा तपास प्रक्रियेला ओळख, टोपणनाव, की फक्त सत्र आवश्यक आहे? तिसरी, मूल्य कोणत्या सीमेवर आवश्यक आहे — संग्रह, साठवण की सादरीकरण?
धोरण वगळण्याचा हेतू धरत असेल, तर नियंत्रण नाही, आवश्यकता किंवा सादरीकरण बदला। धोरण ओळखीला परवानगी देते पण संग्रह ती गमावतो, तर संग्राहक दुरुस्त करा आणि कच्च्या इव्हेंटची खात्री करा। साठवण अखंड असेल, तर उत्खनन दुरुस्त करा आणि सुरुवातीला टिपलेल्या मंजूर इव्हेंटविरुद्ध त्याची चाचणी करा।
बदल नोंदीत सीमेचे नाव देऊन तपास संपवा: स्रोतावर मुखवटा घातलेली, अंतर्ग्रहणादरम्यान काढलेली, किंवा उत्खननाने सुटलेली। ते एक वाक्य पुढील अभियंत्याला आधी कुठे पाहावे ते सांगते, आणि डॅशबोर्डची तक्रार शांतपणे बंद केलेल्या गोपनीयता सुविधेत बदलण्यापासून रोखते।