VPN લોગની જાળવણી: તેને સંખ્યા સાથે નહીં, ઘટના સાથે જોડો
જાળવણી ઘટના, સામગ્રી અને નીતિને અનુસરે છે, કોઈ સાર્વત્રિક સમયમર્યાદાને નહીં. દરેક નકલ શોધો, વિગતવાર સંગ્રહ બંધ કરો અને ટૂંકું રેકોર્ડ રાખો.
કોઈ ખરેખર પૂછતું નથી કે VPN લોગ કેટલા સમય સુધી રાખવો જોઈએ; તેઓ પૂછે છે કે લોગ શેના માટે છે, અને તેનો જવાબ તારીખ નક્કી કરે છે. એક ઘટનામાંથી જુદા જુદા આયુષ્યવાળી બે ફાઇલો નીકળી શકે છે, અને તેમને એક નીતિ તરીકે ગણવાથી એકસાથે વધુ પડતી જાળવણી અને પુરાવાની ખોટ થાય છે. કારણ અજાણ હતું ત્યારે લેવાયેલી ડિબગ એક્સપોર્ટ મોનિટરિંગ સ્ટોરની એક લાઇન જેવી જ કલાકૃતિ નથી. ઉદ્દેશથી શરૂ કરો, પછી તારીખ પસંદ કરો.
તારીખ પસંદ કરતા પહેલાં ચાર પ્રશ્નોના જવાબ આપો
ચાર પ્રશ્નો નક્કી કરે છે કે ફાઇલ રહેશે કે નહીં: ઘટના હજી ખુલ્લી છે કે નહીં, ફાઇલમાં શું છે, તેને કોને વાંચવાની જરૂર છે, અને લાગુ નીતિ શું માગે છે. આ ક્રમમાં જવાબ આપો અને જાળવણીની તારીખ જાતે નીકળી આવે છે. તર્ક એક કોષ્ટકમાં બેસે છે:
| Question | How it moves the answer |
|---|---|
| Incident state | An open investigation justifies a protected original; a closed one rarely does |
| Content | Connection identifiers, internal names and addresses raise the cost of a leak |
| Audience | Who retrieves it, and whether a redacted excerpt would serve them instead |
| Policy floor | The applicable service or organizational rule, which overrides a shorter reasoning |
ઘટના ખુલ્લી હોય ત્યાં સુધી એક સુરક્ષિત મૂળ નકલ રાખો જેથી પછી ઘટનાઓની તુલના કરી શકો અથવા સહાય પ્રશ્નનો જવાબ આપી શકો, અને તેને લેખિતમાં માલિક અને ઉદ્દેશ આપો. પ્રતિસાદ ટીમની બહારની કોઈપણ વ્યક્તિ માટે ટૂંકો સંપાદિત અંશ સામાન્ય રીતે પૂરતો હોય છે, અને સંપૂર્ણ એક્સપોર્ટ કરતાં તેનો બચાવ કરવો ઘણો સરળ છે. મૂળ નકલ અને અંશ અલગ પ્રેક્ષકો સાથેની અલગ કલાકૃતિઓ છે, અને તેમને ભેગા કરવાથી જ વધુ પડતી જાળવણી અને પુરાવાની ખોટ એકસાથે થાય છે. નીતિ ન્યૂનતમ મર્યાદા નક્કી કરે છે, તેથી જો તે તમારા તર્ક કરતાં વધુ સમય માગે, તો નીતિ જીતે છે.
ઘટના રેકોર્ડ સાથે બંધ કરો, એક્સપોર્ટ સાથે નહીં
ટિકિટમાં ચાર લાઇનનો રેકોર્ડ લખો: લક્ષણ, ક્લાયન્ટ અને આવૃત્તિ, જે એક માત્ર ભૂલ લાઇને તેને ઓળખી, અને સુધારો. બીજું કંઈ જોડશો નહીં, કારણ કે એક્સપોર્ટ તમારા માટે હતી અને રેકોર્ડ આગલી વ્યક્તિ માટે છે.
રેકોર્ડ વંચાવાની શક્યતા પણ વધારે છે: સંપૂર્ણ એક્સપોર્ટ મુખ્યત્વે જેણે તે લીધી તેની જ કામ આવે છે, અને તે વ્યક્તિ પહેલેથી જાણે છે કે શું થયું. રેકોર્ડ ત્યાં રાખો જ્યાં આગલી ઘટનામાં શોધ થશે, જેનો અર્થ સામાન્ય રીતે ટિકિટ હોય છે, તારીખના નામનું ફોલ્ડર નહીં. જો રેકોર્ડને કનેક્શન ઓળખકર્તા જાહેર કર્યા વિના ટ્રેસ કરી શકાય તેવું હોવું જોઈએ, તો કેસ નંબર સંદર્ભ લઈ શકે છે. જો કોઈ પ્રશ્ન હજી ખુલ્લો હોય, તો મૂળ નકલ ઉપરના સુરક્ષિત-નકલ નિયમ હેઠળ રહે છે; રેકોર્ડ અસ્તિત્વમાં આવે પછી બાકીનું બધું જઈ શકે છે.
એક ભૂંસતા પહેલાં દરેક નકલ શોધો
એક્સપોર્ટ ફોલ્ડરમાં જુઓ, પછી ઘટનાની વિન્ડો માટેના જર્નલમાં, પછી ટિકિટની જોડાણોમાં, પછી બેકઅપ કેટલોગમાં, પછી મોનિટરિંગ સ્ટોરમાં. જો એ જ કનેક્શન ઓળખકર્તા પાંચમા સ્થાને મળે, તો યાદી ખોટી હતી. જર્નલ સામાન્ય આશ્ચર્ય છે, કારણ કે તમે એક્સપોર્ટ વાંચતા હતા ત્યારે પણ તે સંગ્રહ કરતું રહ્યું.
ફાઇલો જાતે છૂટી કરવાને બદલે સમર્થિત રોટેશન અને ભૂંસવાનો માર્ગ વાપરો. જે ફાઇલ હજી ખુલ્લી છે તે ડિરેક્ટરી એન્ટ્રી અદૃશ્ય થયા પછી પણ તેનું સ્ટોરેજ રાખે છે, તેથી ભૂંસવું પૂર્ણ દેખાય છે અને કંઈ મુક્ત થતું નથી. તે ગોપનીયતાનું લેબલ પહેરેલી સ્ટોરેજ ખામી છે, અને તે બંનેમાંથી કોઈ ધ્યેય પૂરો કરતું નથી.
ભૂંસવાની ખાતરી કરતા પહેલાં સંગ્રહ બંધ કરો
કામચલાઉ વિગતવાર સંગ્રહ તેની માલિકી ધરાવતી એપ્લિકેશન દ્વારા બંધ કરો, તેની આઉટપુટ ફાઇલ સંપાદિત કરીને નહીં. ભૂલી ગયેલું ડિબગ સેટિંગ જૂના રેકોર્ડ દૂર થયા પછી પણ નવા રેકોર્ડ લખતું રહે છે, જે તમે હમણાં કરેલું કામ ચૂપચાપ રદ કરે છે. તમે યાદ રાખેલા મૂલ્યને બદલે વાસ્તવિક લોગિંગ સ્તર તપાસો. પછી ખાતરી કરો કે જે બાકી છે તે સુરક્ષિત છે અને ફક્ત ઇચ્છિત લોકો જ તેને પાછું મેળવી શકે છે.
સિદ્ધાંત ડેટા-ન્યૂનતમીકરણ છે: જાહેર ઉદ્દેશને જે જોઈએ તે જેટલો સમય જોઈએ તેટલો રાખો, વધુ નહીં, જેમ RFC 6973 ગોપનીયતા માર્ગદર્શિકા તેને રજૂ કરે છે. ઉદ્દેશ વિના રાખવામાં આવેલી ફાઇલ સમય-છાપ સાથેની જવાબદારી છે. નિર્ણય ત્યારે પૂરો થાય છે જ્યારે તમે ફાઇલ, તેનો ઉદ્દેશ, તેનો માલિક અને તેની અંતિમ તારીખ જણાવી શકો.