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

જો તમે કહી ન શકો કે TLS ક્યાં સમાપ્ત થાય છે, તો તમે કહી ન શકો કે એપ્લિકેશન ખરેખર શું ભરોસો કરે છે.

TLS ખરેખર ક્યાં સમાપ્ત થાય છે તે શોધો

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

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

TLS બન્ને દિશામાં વિનંતીઓ અને પ્રતિભાવો વહન કરે છે, તેથી દ્વિદિશાત્મક એપ્લિકેશનને સ્વાભાવિક રીતે TLS ના બદલે VPN ની જરૂર હોતી નથી. ઊલટું પણ સાચું છે: જમાવટને એ જ ઉપકરણ પર અન્ય પ્રોટોકોલ માટે હજી પણ VPN ની જરૂર પડી શકે છે.

ઉપકરણે શું પ્રમાણિત કરવું જોઈએ તે નક્કી કરો

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

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

સમર્થિત લાઇબ્રેરી અને વર્તમાન માર્ગદર્શન વાપરો. TLS જમાવટ માટે આધુનિક માર્ગદર્શન TLS 1.0 અને 1.1 પર વાટાઘાટ પ્રતિબંધિત કરે છે, અને જૂની ડિઝાઇન નોંધમાં TLSv1 નો ઉલ્લેખ જરૂરિયાત નથી.

હેન્ડશેક નિષ્ફળ થાય ત્યારે બંધ રાખો

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

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

પુનરાગમનનો નિયમ લખો. “હેન્ડશેક નિષ્ફળ થાય તો તે TLS વગર ફરી જોડાય છે” એ ડિઝાઇન નિર્ણય છે, અને તે સ્પષ્ટ હોવો જોઈએ.

VPN ને ફક્ત એ જ કામ આપો જે તે કરી શકે

VPN પહોંચનક્ષમતા મર્યાદિત કરી શકે છે અને પોતાના સાથી સુધી પેકેટનું રક્ષણ કરી શકે છે. TLS પસંદ કરેલા અંતિમ બિંદુ સાથે એપ્લિકેશનનો સંબંધ રક્ષે છે. તેમના સમાપ્તિ બિંદુ અલગ હોઈ શકે છે, અને બંન્નેમાંથી કોઈ અંતિમ બિંદુનો સંગ્રહિત ડેટા કે વહીવટી ઍક્સેસ સુરક્ષિત કરતું નથી.

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

સંબંધિત લેખો