VPN વપરાશકર્તાનામ લોગ પાઇપલાઇનમાંથી ક્યાં અદૃશ્ય થાય છે?

સત્રો ડેશબોર્ડ પર દેખાય છે જ્યારે વપરાશકર્તાનામ કૉલમ ખાલી રહે છે, અને પહેલી વૃત્તિ પાર્સરને દોષ આપવાની હોય છે. એ વૃત્તિ ત્રણ પહેલાના તબક્કા છોડી દે છે જ્યાં મૂલ્ય ખોવાઈ શક્યું હોઈ શકે. ગેટવે નીતિ અનુસાર ઓળખ છુપાવી શકે છે, ઇન્જેશન નિયમ તેને અનુક્રમણિકા પહેલાં કાઢી શકે છે, અને શોધ સમયનું નિષ્કર્ષણ ફક્ત તેનું નામ આપવામાં નિષ્ફળ જઈ શકે છે. સુધારો એના પર આધાર રાખે છે કે તમે કઈ સીમાને જવાબદાર સાબિત કરી શકો છો, તેથી ઉપયોગી કામ સરખામણી છે, રૂપરેખાંકન નહીં.

ડેશબોર્ડથી નહીં, એક ઘટનાથી શરૂ કરો

એક જ પ્રમાણીકરણ ઘટના પસંદ કરો અને લખો કે તેને શું ઓળખે છે: ગેટવેનું મોડેલ અને આવૃત્તિ, પ્રમાણીકરણ પદ્ધતિ, ઘટના ઓળખકર્તા, સમયચિહ્ન અને સ્રોત સરનામું. વપરાશકર્તાનામ બરાબર તે રીતે ઉમેરો જે રીતે વ્યક્તિએ ટાઇપ કર્યું હતું, મોટા-નાના અક્ષરો સહિત, કારણ કે અક્ષર-સંવેદનશીલ શોધ હાજર ક્ષેત્રને છુપાવી શકે છે. પછીની દરેક સરખામણી માટે તે ઘટનાને સંદર્ભ ગણો.

ઘટનાના પ્રકારો એક જ સ્કીમા વહેંચતા નથી. નિષ્ફળ પ્રયાસ, ક્લાયંટ વગરનું સફળ લોગિન અને ટનલ ફરી જોડાવું એ દરેક અલગ ક્ષેત્રો બનાવી શકે છે, અને કેટલાક ગેટવે ઓળખ છોડી દે છે જ્યારે પ્રયાસ વપરાશકર્તા પ્રમાણીકરણ સુધી પહોંચ્યો જ ન હોય. તેથી એક ઘટના પ્રકારમાં ખાલી કૉલમ પાઇપલાઇન સમસ્યાનો નબળો પુરાવો છે.

સાચા કર્મચારી ખાતાને બદલે મંજૂર પરીક્ષણ ઓળખ સાથે કામ કરો, અને સરખામણીને લોગ ડેટા પર પહેલેથી લાગુ એક્સેસ નિયમોની અંદર જ રાખો. ફક્ત નમૂનો મેળવવા માટે વિગતવાર પ્રમાણીકરણ લોગિંગ વ્યાપકપણે ચાલુ કરવું એ સિસ્ટમને બદલે છે જેને તમે માપવા માગો છો.

ચાર સીમાઓ ક્રમમાં સરખાવો

મૂલ્ય ચારમાંથી એક બિંદુએ અદૃશ્ય થઈ શકે છે. દરેક બિંદુનો અલગ માલિક અને અલગ સુધારો છે.

જ્યાં મૂલ્ય અદૃશ્ય થાય તે પહેલી સીમા પર થોભો. ઉપકરણના દૃશ્ય અને કાચી નકલ વચ્ચેની અસંગતિ પરિવહન અથવા સંગ્રાહક રૂપરેખાંકન તરફ ઇશારો કરે છે; ત્યાં સરખાપણું પણ અનુક્રમિત ઘટનામાં મૂલ્ય ગેરહાજર હોવું રૂપાંતરણ તરફ ઇશારો કરે છે; અનુક્રમિત ઘટનામાં મૂલ્ય હાજર પણ ડેશબોર્ડ પર ગેરહાજર હોવું નિષ્કર્ષણ અથવા ક્વેરી તરફ ઇશારો કરે છે.

આ ક્રમ મહત્વનો છે કારણ કે દરેક પછીનો તબક્કો ફક્ત માહિતી ગુમાવી શકે છે, તેને ક્યારેય પુનઃસ્થાપિત કરી શકતો નથી. રેગ્યુલર એક્સપ્રેશન એ શબ્દમાળા પાછી લાવી શકતું નથી જેને પહેલાના તબક્કે પ્લેસહોલ્ડરથી બદલી નાખી હતી, અને ગોપનીયતા સેટિંગ એ મૂલ્ય સમજાવી શકતું નથી જે ક્યારેય મોકલાયું જ ન હતું.

સ્રોત પર છુપાવવું નીતિ છે, પાર્સરની ભૂલ નહીં

Ciscoનું ASA લોગિંગ દસ્તાવેજીકરણ વપરાશકર્તાનામ છુપાવવાને રૂપરેખાંકિત વર્તન તરીકે વર્ણવે છે, જેમાં અમાન્ય અથવા અજાણ્યા વપરાશકર્તાનામો કેવી રીતે રજૂ થાય છે તે પણ સમાવેશ થાય છે. તેથી સ્રોત ઘટનામાં છુપાવેલી ઓળખ બરાબર એ જ હોઈ શકે જે ગોપનીયતા નીતિ માગે છે, અને તેને પાર્સિંગ નિષ્ફળતા તરીકે ગણવાથી એવી વિનંતી થાય છે જે નિયંત્રણને નબળું કરે છે.

ચોક્કસ રજૂઆત આવૃત્તિ અને સંદેશ પ્રકાર પર આધાર રાખે છે. એક ઘટના પ્લેસહોલ્ડર ધરાવી શકે છે, બીજી ક્ષેત્ર સંપૂર્ણપણે છોડી શકે છે, અને પ્રમાણીકરણ નિષ્ફળતામાં ક્યારેય નામ ન પણ હોય. દરેક ગેરહાજર ઓળખ પર જૂનો બગ રિપોર્ટ લાગુ કરવાને બદલે ચોક્કસ ઘટના માટે દસ્તાવેજીકૃત વર્તન ચકાસો.

જ્યારે છુપાવવું ઇરાદાપૂર્વક હોય, ત્યારે પ્રશ્ન ક્ષેત્ર કેવી રીતે પુનઃસ્થાપિત કરવું એમાંથી બદલાઈને એ થાય છે કે ઓડિટ જરૂરિયાત બીજી રીતે પૂરી કરી શકાય કે નહીં. સત્ર ઓળખકર્તા, નાના જૂથ પાસે રહેલું નિયંત્રિત ઓળખ મેપિંગ, અથવા સાંકડું અધિકૃત ઘટના ફીડ ઘણી વાર દરેક પ્રયાસ કરેલું વપરાશકર્તાનામ દરેક લોગ વાચક સામે મૂક્યા વિના જરૂરિયાત પૂરી કરે છે.

અનુક્રમણિકા પહેલાંનું અનામીકરણ પાછું વાળી શકાતું નથી

ઘટના પ્રક્રિયા વિશેનું Splunkનું દસ્તાવેજીકરણ sed અભિવ્યક્તિઓ અને રૂપાંતરણો દ્વારા અનામીકરણનું વર્ણન કરે છે જે અનુક્રમણિકા પહેલાં ડેટા ફરી લખે છે અથવા દૂર કરે છે. બરાબર એ જ સ્થાન મુખ્ય મુદ્દો છે: કાચી ઘટના અંદર આવતી વખતે બદલાય છે, તેથી શોધ સમયના નિષ્કર્ષણ પાસે શોધવા જેવું કંઈ રહેતું નથી.

અનુક્રમણિકા સમયનું સંપાદન અને શોધ સમયનું ક્ષેત્ર નિષ્કર્ષણ અલગ સમસ્યાઓ ઉકેલે છે. સંપાદન મર્યાદિત કરે છે કે મૂલ્ય કોણ ક્યારેય જોઈ શકે; નિષ્કર્ષણ ફક્ત નક્કી કરે છે કે ક્વેરી કયું નામ વાપરે. હેશિંગ એ મધ્યમ વિકલ્પ છે જે સહસંબંધ જાળવે છે, પણ નાના વપરાશકર્તાનામ અવકાશ પર સ્થિર હેશ ત્યારે પણ ઓળખ આપે છે જ્યારે કોઈ તેની સામે સંભવિત નામો ચકાસી શકે.

જો સંગ્રહિત ઘટનામાં હજી ઓળખ હોય, તો સમસ્યા નીચેની તરફ છે: સ્રોત પ્રકાર, લાઇન ભંગાણ, વિભાજક સંચાલન, ક્ષેત્ર ઉપનામો અથવા ક્વેરી પોતે. આ સામાન્ય પાર્સિંગ સુધારા છે અને તે ગોપનીયતા સીમાને સ્પર્શતા નથી.

સીમા સાથે મેળ ખાતો સુધારો પસંદ કરો

ત્રણ શરતો પ્રતિસાદ નક્કી કરે છે. પ્રથમ, શું ગોપનીયતા નીતિ ઓળખને બાકાત રાખવા માગે છે? બીજું, શું ઓડિટ અથવા તપાસ પ્રક્રિયાને ઓળખ, ઉપનામ, કે ફક્ત સત્રની જરૂર છે? ત્રીજું, મૂલ્ય કઈ સીમા પર જરૂરી છે — સંગ્રહ, સંગ્રહણ કે રજૂઆત?

જો નીતિ બાકાત રાખવા માગે, તો નિયંત્રણ નહીં, જરૂરિયાત અથવા રજૂઆત બદલો. જો નીતિ ઓળખને મંજૂરી આપે પણ સંગ્રહ તેને છોડી દે, તો સંગ્રાહક સુધારો અને કાચી ઘટના ખાતરી કરો. જો સંગ્રહણ અકબંધ હોય, તો નિષ્કર્ષણ સુધારો અને શરૂઆતમાં કેદ કરેલી મંજૂર ઘટના સામે તેની કસોટી કરો.

ફેરફાર રેકોર્ડમાં સીમાનું નામ આપીને તપાસ પૂરી કરો: સ્રોત પર છુપાવેલી, ઇન્જેશન દરમિયાન દૂર કરેલી, અથવા નિષ્કર્ષણથી ચૂકી ગયેલી. એ એક વાક્ય આગલા ઇજનેરને કહે છે કે પહેલાં ક્યાં જોવું, અને તે ડેશબોર્ડની ફરિયાદને શાંતિથી બંધ કરેલી ગોપનીયતા સુવિધામાં ફેરવાતી અટકાવે છે.