VPN જોખમ અહેવાલ અવગણાયો? નિર્ણય લખો, સ્કોર નહીં

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

સ્કોર એ પ્રશ્નનો જવાબ આપે છે જે કોઈએ પૂછ્યો નહોતો

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

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

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

અસ્પષ્ટતા બીજી નિષ્ફળતા છે. “VPN અસુરક્ષિત છે” ઉકેલી શકાતું નથી, કારણ કે તે કહેતું નથી કઈ જમાવટ, કઈ આવૃત્તિ, અથવા કોણ શું સુધી પહોંચી શકે છે. વાચક જે વાક્ય ચકાસી શકે તે ઉપયોગી અહેવાલનું સૌથી નાનું એકમ છે.

દાવાને નાનો કરો જ્યાં સુધી કોઈ તેને ચકાસી ન શકે

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

openvpn --version | head -n 1
dpkg-query -W -f='${Version}\n' openvpn
openssl x509 -in /etc/openvpn/server.crt -noout -enddate

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

દરેક આઉટપુટ ક્યાંથી આવ્યું અને ક્યારે લેવાયું તે નોંધો. “ગેટવે gw1, મંગળવારે એકત્રિત” કહેતી નોંધ શંકાશીલ વ્યક્તિ ફરી ચલાવી શકે; રસપ્રદ લાઇન સુધી કાપેલો સ્ક્રીનશોટ નહીં. ફાઇલ તમારા મશીનમાંથી નીકળે તે પહેલાં કી, ખાનગી સરનામાં અને ખાતાના નામ દૂર કરો.

નોંધને નામવાળા વિકલ્પો વચ્ચેની પસંદગી તરીકે લખો

નિર્ણય-નોંધ ટૂંકી છે કારણ કે તે એક જ કામ કરે છે. આ તે આકાર છે જે હું વાપરું છું, એક કાલ્પનિક મધ્યમ કદની સંસ્થા માટે ભરેલો, જેની દૂરસ્થ પ્રવેશ આવૃત્તિ ટેકાની બહાર ગઈ:

Ask: approve one of two upgrade paths for remote access before 30 June.
Claim: gw1 runs a release that left vendor support in January.
Evidence: version output and vendor notice, attached, collected 14 March.
Option A: upgrade in place, one maintenance window, staff on the current client build.
Option B: replace the gateway, two windows, client reinstall for 180 staff.
Cost of waiting: no security fixes for a service 180 staff use daily.
Owner: platform team. Decision needed from: IT director, by 28 March.

દરેક લાઇન પોતાનું સ્થાન કમાય છે. વિનંતી એક વાક્ય છે અને તેમાં તારીખ છે. દાવો ચકાસી શકાય તેવો છે. વિકલ્પ B એટલા માટે છે કે વિકલ્પ A ઔપચારિકતા નહીં, પસંદગી બને, અને તે ગ્રાહકની ફરી સ્થાપના જણાવે છે કારણ કે એ જ ખર્ચ છે જેને લોકો ઓછો આંકે છે. રાહ જોવાનો ખર્ચ પરિણામ વર્ણવે છે, સંભાવના નહીં.

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

જોખમની સ્વીકૃતિમાં શું હોવું જોઈએ

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

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

ફેરફારનો જવાબદાર અને નિર્ણયનો જવાબદાર અલગ વ્યક્તિ હોય ત્યારે તેમને અલગ રાખો. પ્લેટફોર્મ ટીમ અમલ કરે છે; નિયામક સ્વીકારે છે. નોંધમાં બંને નામ લખવાથી સૌથી સામાન્ય અટકાવ દૂર થાય છે: સારી રીતે તૈયાર કરેલી યોજના એવી વ્યક્તિની રાહ જુએ છે જેણે તે કદી જોઈ નથી.

મોકલતા પહેલાં નોંધને જમાવટ સામે ચકાસો

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

for h in gw1 gw2; do
  ssh "$h" 'openvpn --version | head -n 1; systemctl is-active openvpn@server'
done

જો બે હોસ્ટ સંમત ન થાય, તો નોંધ હવે મિશ્ર કાફલા વિશે છે, જે અલગ અને સામાન્ય રીતે વધુ વિશ્વાસપાત્ર શોધ છે. જો તમે માનતા હતા કે ટ્રાફિક પરોસતો હોસ્ટ પર સેવા નિષ્ક્રિય છે, તો થોભો અને નોંધ ક્યાંય જાય તે પહેલાં યાદી સુધારો.

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