શું VPN લોગ બ્રાઉઝિંગ ઇતિહાસ દર્શાવી શકે? પુરાવા શું સાબિત કરે છે
સેશન લોગ, રિઝોલ્વર ક્વેરી અને ફ્લો રેકોર્ડ અલગ અલગ વસ્તુઓ સાબિત કરે છે. પ્રશ્ન પસંદ કરો, ઓળખ અને સમય જોડો, અને પછી ફક્ત તે જ કહો જે દર્શાવવામાં આવ્યું છે.
ઓડિટના બે પ્રશ્નો સાંભળવામાં સરખા લાગે છે અને અલગ પ્રકારના પુરાવા માંગે છે. કયા સેશને આ સરનામાનો સંપર્ક કર્યો તે કનેક્શન અને ફ્લો રેકોર્ડમાંથી જવાબ આપી શકાય છે. કઈ વ્યક્તિએ આ પૃષ્ઠ ખોલ્યું તે સામાન્ય રીતે નહીં, ઓછામાં ઓછું તે રેકોર્ડમાંથી નહીં. પ્રશ્ન પસંદ કરતાં પહેલાં સંગ્રાહક પસંદ કરવો એ રીતે નેટવર્ક ટીમ હોસ્ટનામને બ્રાઉઝિંગ ઇતિહાસ તરીકે રજૂ કરે છે.
ઓડિટે જે ઘટના સ્થાપિત કરવી છે તેનાથી શરૂ કરો
પ્રશ્નને કર્તા, ક્રિયાપદ અને સમય સાથેના વાક્ય તરીકે લખો. ફક્ત આ શિસ્ત જ સેશન રેકોર્ડ અને પૃષ્ઠ દૃશ્ય વચ્ચેનું અંતર ઉજાગર કરે છે. સેશન લોગ સ્થાપિત કરે છે કે ઓળખને ચોક્કસ સમયગાળા માટે, નોંધાયેલ નીતિ હેઠળ ફાળવેલા સરનામા સાથે સ્વીકારવામાં આવી હતી, અને તે સ્થાપિત કરી શકતું નથી કે કોણે કયું પૃષ્ઠ વાંચ્યું, કારણ કે તેણે વિનંતી ક્યારેય જોઈ નથી.
સંગ્રહની ડિઝાઇન કરતાં પહેલાં અવલોકનને નામ આપો. મુલાકાત લીધેલી સાઇટના નામ પરથી રાખવામાં આવેલું ક્ષેત્ર જે વાસ્તવમાં ઉકેલાયેલું નામ સંગ્રહે છે તે સુવિધા નહીં, ભવિષ્યની ભૂલ છે. ક્ષેત્રના નામ તેમને પસંદ કરનારા લોકો કરતાં વધુ જીવે છે, તેથી એવા નામ પસંદ કરો જે નિષ્કર્ષ નહીં, પુરાવાનું વર્ણન કરે.
દરેક રેકોર્ડ શું ટેકો આપી શકે છે અને શું નહીં
લગભગ દરેક ઓડિટ ડિઝાઇનમાં ચાર પ્રકારના રેકોર્ડ દેખાય છે, અને દરેક અલગ પ્રશ્નનો જવાબ આપે છે. તેમને અહેવાલમાં અને પાઇપલાઇનમાં અલગ રાખો, કારણ કે તેમને ભેગા કરવાથી જ સંરક્ષણીય તારણ શરમજનક બને છે.
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
છેલ્લા કોલમને વચ્ચેના કોલમ જેટલી કાળજીથી વાંચો. ફ્લો રેકોર્ડ સરનામાં અને પોર્ટનું વર્ણન કરે છે, અને સરનામાની વિપરીત શોધ બ્રાઉઝરે વાપરેલું નામ ફરી બનાવતી નથી, કારણ કે એક સરનામું ઘણી અસંબંધિત સાઇટ હોસ્ટ કરી શકે છે. રિઝોલ્વર ક્વેરી સાબિત કરે છે કે પ્રશ્ન પૂછાયો, પૃષ્ઠ દર્શાવાયું તે નહીં. TLS વાટાઘાટ દરમિયાન દેખાતું હોસ્ટનામ પણ એન્ક્રિપ્ટ કરેલી વિનંતીનો માર્ગ નથી.
આમાંથી દરેક વાસ્તવિક અવલોકન છે, અને એક પણ એ અવલોકન નથી જે લોકો ધારે છે. જે બ્રાઉઝર પોતાના એન્ક્રિપ્ટ કરેલા રિઝોલ્વર પર ભાર મૂકે છે તે દેખરેખવાળા વ્યાપની બહાર બેસે છે, અને લોગે ક્યારેય ન જોયું તે વિશ્લેષણ પાછું લાવી શકતું નથી. એ ખાલી જગ્યા અહેવાલમાં પાદટીપ નહીં, જાહેર મર્યાદા તરીકે હોવી જોઈએ.
અગાઉથી કરાયેલી શોધ અને કેશ કરેલા જવાબો
બ્રાઉઝર અગાઉથી નામો ઉકેલે છે, ક્યારેક કંઈ પણ લોડ કર્યા વિના. તેઓ કેશમાંથી પણ જવાબ આપે છે, તમે દેખરેખ રાખતા રિઝોલ્વરને નવી ક્વેરી મોકલ્યા વિના, એટલે કે ક્વેરીની ગેરહાજરી મુલાકાતની ગેરહાજરી નથી. બંને વર્તન DNS લોગ અને બ્રાઉઝિંગ ઇતિહાસ વચ્ચેનું સરળ સમીકરણ તોડે છે.
HTTPS પર DNS બીજી સીમા ઉમેરે છે: પોતાના રિઝોલ્વરવાળું બ્રાઉઝર કે મહેમાન એપ્લિકેશન સંસ્થાના લોગરને ક્યારેય કંઈ પૂછતું નથી. ચોક્કસ વ્યવહારો ફક્ત એપ્લિકેશનની પોતાની ઘટનાઓમાંથી અથવા એવા પ્રોક્સીમાંથી આવે છે જેનું લોગિંગ તમે સ્પષ્ટપણે સમર્થન કરો છો. સાદું HTTPS CONNECT ટનલ પ્રોક્સીને તેની અંદરના પૃષ્ઠ માર્ગોની કોઈ દૃષ્ટિ આપતું નથી. નેટવર્ક ધરાવવું એ એપ્લિકેશનનું વિશ્વાસ મોડેલ ચૂપચાપ બદલવાની પરવાનગી નથી.
સરનામું સેશનનું છે, વ્યક્તિનું નહીં
ટનલ-શ્રેણીનું સરનામું ધરાવતો ફ્લો રેકોર્ડ જવાબ નહીં, શરૂઆતનું બિંદુ છે. એ સરનામું અને સમયચિહ્ન તે ક્ષણે સક્રિય સેશન ફાળવણી સાથે જોડો, કારણ કે એ સરનામું એક કલાક પછી બીજા સેશનને ફાળવી શકાય છે. સ્થિર એડ્રેસિંગ એ સંબંધ જાળવવાનો એક રસ્તો છે, એકમાત્ર નહીં.
જ્યાં અનુવાદનું પગલું સેન્સરની ઉપરના ભાગમાં ઘણા ઉપકરણોને એક સ્રોત સરનામામાં સંકોચે છે, ત્યાં જોડાણ ફક્ત વહેંચાયેલા ગેટવે સેશનનું નામ આપી શકે છે. વહેંચાયેલું ખાતું કે ઘણા લોકો વાપરતું પ્રમાણપત્ર નેટવર્ક ડેટા કેટલો પણ પૂર્ણ દેખાય, એટ્રિબ્યુશન મર્યાદિત કરે છે. બંને અહેવાલમાં પછીની ટીકા નહીં, મર્યાદા તરીકે હોવા જોઈએ.
સમય ક્ષેત્ર, ઘડિયાળનો સ્રોત, અવલોકન બિંદુ અને તેમની વચ્ચેની દરેક અનુવાદ સીમા નોંધો. ગેરહાજરી હાજરી જેટલી જ કાળજી લાયક છે, કારણ કે ખૂટતો રેકોર્ડ એમ બની શકે છે કે ફ્લો એન્ટ્રીની મુદત પૂરી થઈ ગઈ, સેન્સરે પેકેટ ક્યારેય જોયું નહીં, અથવા એપ્લિકેશન લોગ બંધ હતો.
જાહેર હેતુ માટે ડિઝાઇન કરો, પછી પાઇપલાઇન સાબિત કરો
પ્રશ્ન નિશ્ચિત થયા પછી, કયા ક્ષેત્રો જરૂરી છે, કોણ તેમને વાંચી શકે છે અને કેટલા સમય સુધી રાખવામાં આવે છે તે વ્યાખ્યાયિત કરો. સંગ્રહ સસ્તો છે તેથી વધુ એકઠું કરવું એ તપાસ કરતાં વધુ ટકે તેવી જવાબદારી ઊભી કરે છે. RFC 6973 માંનું ગોપનીયતા મોડેલ સહસંબંધ, ખોટા એટ્રિબ્યુશન અને બિનજરૂરી સંગ્રહને પછીના વિચારો નહીં, ડિઝાઇન સમસ્યા તરીકે રજૂ કરે છે.
મેપિંગ અને રેકોર્ડને એક જ વસ્તુ તરીકે સાચવો, કારણ કે દરેક એકલું જોડી કરતાં ઘણું ઓછું સંવેદનશીલ છે. પછી ડિઝાઇનને એવી પ્રવૃત્તિ સામે માન્ય કરો જે પેદા કરવાની તમને પરવાનગી છે અને તમે પહેલેથી સમજો છો, અહેવાલ જે સૌથી નાની ક્વેરી પર આધાર રાખશે તેનો ઉપયોગ કરીને. જે પાઇપલાઇન જાણીતી ઘટના પુનઃઉત્પાદન કરી શકતી નથી તે અજાણી ઘટના પણ કરશે નહીં. પુરાવા જેને ટેકો આપે તે ઘટના, પુરાવા જે શબ્દોની પરવાનગી આપે તેવા શબ્દોમાં જણાવો, અને મોટા નિષ્કર્ષ સુધી પહોંચવાનું વાચકને માટે છોડી દો.
તારણની બાજુમાં મર્યાદાઓ લખો: શું જોડાયું, શું અનુવાદિત થયું અને કયો લોગ શાંત રહ્યો. જે તારણ પોતાની સીમાઓ જાહેર કરે છે તે એવી સમીક્ષા પાર કરે છે જે આત્મવિશ્વાસુ સારાંશ પાર કરતો નથી. પુરાવા અને પુરાવા વિશેની વાર્તા વચ્ચેનો આ જ તફાવત છે.