ഫീൽഡ് ഉപകരണം, TLS, VPN: ഏത് അതിർത്തി എന്തിനെ സംരക്ഷിക്കുന്നു

ഫീൽഡ് ഉപകരണം ഒരു സേവനത്തിലേക്ക് കണക്ഷൻ തുറക്കുന്നു, ഡിസൈൻ ചോദ്യം VPN-ഉം TLS-ഉം തമ്മിലുള്ള തിരഞ്ഞെടുപ്പായി വരുന്നു. ഈ ചട്ടക്കൂട് തെറ്റാണ്, കാരണം രണ്ടും വ്യത്യസ്ത ജോലികൾ ചെയ്യുന്നു. TLS ആപ്ലിക്കേഷന്റെ അന്ത്യബിന്ദുവിനെ ആധികാരികമാക്കുകയും സംഭാഷണം സംരക്ഷിക്കുകയും ചെയ്യുന്നു; എന്നാൽ VPN എത്തിച്ചേരാനുള്ള കഴിവ് നിയന്ത്രിക്കുകയും സമപ്രായക്കാര്ക്കിടയിലെ പാക്കറ്റുകൾ സംരക്ഷിക്കുകയും ചെയ്യുന്നു. ഉപകരണത്തിൽ നിന്ന് പുറത്തേക്ക് കണക്ഷൻ പിന്തുടരുക; ഓരോ പാളിക്കും സ്വന്തം ഉത്തരമുണ്ട്.

TLS എവിടെ അവസാനിക്കുന്നു എന്ന് പറയാനാകിലെങ്കിൽ, ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ എന്തിനെ വിശ്വസിക്കുന്നു എന്നും പറയാനാകില്ല.

TLS യഥാർത്ഥത്തിൽ എവിടെ അവസാനിക്കുന്നു എന്ന് കണ്ടെത്തുക

ഉപകരണത്തിന്റെ ആപ്ലിക്കേഷനിൽ നിന്ന് തുടങ്ങി ഹാൻഡ്ഷേക്ക് പൂർത്തിയാക്കുന്ന പ്രക്രിയ വരെ കണക്ഷൻ പിന്തുടരുക. ഒരു പ്രോക്സി മെയിൻഫ്രേമിന് മുൻപ് TLS അവസാനിപ്പിച്ചാൽ, സംരക്ഷിത പാത പ്രോക്സിയിൽ അവസാനിക്കുന്നു. ബാക്കിയുള്ള ചുവടിന് അതിന്റേതായ രേഖപ്പെടുത്തിയ സംരക്ഷണം വേണം.

അനുമാനത്തിന്റെ അടിസ്ഥാനത്തിൽ ഇതിനെ അറ്റം മുതൽ അറ്റം വരെ എന്ന് വിളിക്കുന്നതാണ് ഡിസൈൻ അവലോകനം ഒരു വിടവ് അംഗീകരിക്കുന്ന വഴി. അവസാനബിന്ദുവും വിശ്വാസ അടിസ്ഥാനവും ഒരേ രേഖാചിത്രത്തിൽ വരയുക.

TLS ഇരു ദിശകളിലും അഭ്യർത്ഥനകളും പ്രതികരണങ്ങളും വഹിക്കുന്നു, അതിനാൽ ദ്വിദിശാ ആപ്ലിക്കേഷന് സ്വഭാവികമായി TLS-ന് പകരം VPN ആവശ്യമില്ല. വിപരീതവും ശരിയാണ്: അതേ ഉപകരണത്തിലെ മറ്റ് പ്രോട്ടോക്കോളുകൾക്ക് വിന്യാസത്തിന് ഇപ്പോഴും VPN ആവശ്യമായി വന്നേക്കാം.

ഉപകരണം എന്ത് ആധികാരികമാക്കണം എന്ന് തീരുമാനിക്കുക

സെർവർ ഐഡന്റ്റിറ്റി പരിശോധനയും ഉദ്ദേശിച്ച വിശ്വാസവേരുകളും ക്രമീകരിക്കുക. ഓരോ ഉപകരണവും സ്വന്തം ഐഡന്റ്റിറ്റി തെളിയിക്കേണ്ടതുണ്ടെങ്കിൽ, പിന്തുണയുള്ള ക്ലയന്റ് പ്രമാണീകരണ മാത്രക തിരഞ്ഞെടുക്കുകയും ഓരോ ഉപകരണത്തിനും വെവ്വേറെ ക്രെഡൻഷ്യൽ രജിസ്റ്റർ ചെയ്യുകയും ചെയ്യുക. പങ്കിട്ട ക്രെഡൻഷ്യൽകൾ ഒരു മോഷ്ടിച്ച ഉപകരണത്തെ മുഴുവന് സംഘത്തിന്റെ പ്രശ്നമാക്കുന്നു.

അയക്കുന്നതിന് മുൻപ് കീ സംരക്ഷണം, പുതുക്കൽ, റദ്ദാക്കൽ, വീണ്ടെടുക്കൽ എന്നിവ ആസൂത്രണം ചെയ്യുക. പരാജയപ്പെട്ട പുതുക്കലിന് ശേഷം വീണ്ടും രജിസ്റ്റർ ചെയ്യാനാകാത്ത ഫീൽഡ് ഉപകരണം സ്ഥലസന്ദർശനമായി മാറുന്നു, ആ ചെലവ് ഹാൻഡ്ഷേക്കിനേക്കാൽ ഡിസൈനിനെ രൂപപ്പെടുത്തുന്നു.

പിന്തുണയുള്ള ലൈബ്രറിയും നിലവിലെ മാർഗ്ഗനിർദ്ദേശങ്ങളും ഉപയോഗിക്കുക. ആധുനിക TLS വിന്യാസ മാർഗ്ഗനിർദ്ദേശങ്ങൾ TLS 1.0, 1.1 എന്നിവയിലെ ചർച്ച നിരോധിക്കുന്നു, പഴയ ഡിസൈൻ കുട്ടിപ്പഴയിലെ TLSv1 പരാമർശം ആവശ്യകതയല്ല.

ഹാൻഡ്ഷേക്ക് പരാജയപ്പെട്ടാൽ അടയക്കുക

പരാജയപ്പെട്ട ഹാൻഡ്ഷേക്കോ ഐഡന്റ്റിറ്റി പരിശോധനയോ നിശ്ശബ്ദമായി യഥാർത്ഥ പ്ലെയിൻടെക്സ്റ്റ് പ്രോട്ടോക്കോളിലേക്ക് മടങ്ങരുതുത്. ആ മടങ്ങിപ്പോക്കാണ് TLS ജോലി അടയക്കേണ്ടിയിരുന്ന ദുർബലത. പരാജയം ഉപകരണ ഓപ്പറേറ്ററ്ക്കും സേവനത്തിനും ദൃശ്യമാക്കുക, സെൻസിറ്റീവ് പ്രവർത്തനങ്ങൾക്ക് സംരക്ഷിത ചാനൽ നിർബന്ധമാക്കുക. തുടർന്ന് ആധികാരികമാക്കിയ ഉപകരണത്തിന് എന്ത് ചെയ്യാം എന്ന് ആപ്ലിക്കേഷൻ അനുമതി തീരുമാനിക്കട്ടെ.

കണക്ഷന്റെ ആയുസ്സ്, ഫ്രേയിംംഗ്, സമയപരിധികൾ, വീണ്ടും ശ്രമിക്കുന്ന സ്വഭാവം എന്നിവ കരാർട്ടിന്റെ ഭാഗമായി നിർവചിക്കുക. എൻക്രിപ്ഷൻ ആവർത്തിച്ചുള്ള കമാൻഡിനെ സുരക്ഷിതമാക്കുന്നുമില്ല, അനിശ്ചിതമായ മുൻ പ്രവർത്തനത്തിന് ശേഷമുള്ള വീണ്ടും ശ്രമത്തിന് ആപ്ലിക്കേഷൻ തലത്തിലുള്ള ഉത്തരം വേണം.

മടങ്ങിപ്പോക്ക് നിയമം എഴുതുക. “ഹാൻഡ്ഷേക്ക് പരാജയപ്പെട്ടാൽ അത് TLS ഇല്ലാതെ വീണ്ടും കണക്ഷൻ ചെയ്യുന്നു” എന്നത് ഒരു ഡിസൈൻ തീരുമാനമാണ്, അത് വ്യക്തമായിരിക്കണം.

VPN-ന് ചെയ്യാനാകുന്ന ജോലി മാത്രം നൽകുക

VPN എത്തിച്ചേരാനുള്ള കഴിവ് പരിമിതപ്പെടുത്തുകയും സ്വന്തം സമപ്രായക്കാരൻ വരെ പാക്കറ്റുകൾ സംരക്ഷിക്കുകയും ചെയ്യാം. TLS തിരഞ്ഞെടുത്ത അന്ത്യബിന്ദുവുമായുള്ള ആപ്ലിക്കേഷന്റെ ബന്ധം സംരക്ഷിക്കുന്നു. അവയുടെ അവസാനബിന്ദുക്കൾ വ്യത്യസ്തമായേക്കാം, ഒന്നും അന്ത്യബിന്ദുവിന്റെ സംഭരിച്ച ഡേറ്റയോ ഭരണപരമായ ആക്സസോ സുരക്ഷിതമാക്കുന്നില്ല.

ഒരു സംവിധാനം വേഗമേറിയതാണെന്ന് അനുമാനിക്കുന്നതിന് പകരം യഥാർത്ഥ ഉപകരണത്തിൽ ഹാൻഡ്ഷേക്കിന്റെ ചെലവ്, സ്ഥിരമായ സന്ദേശകൈമാറ്റം, വീണ്ടും കണക്ഷൻ ചെയ്യൽ എന്നിവ അളക്കുക. തുടർന്ന് പ്രധാനമായ നാല് കേസുകൾ പരിശോധിക്കുക: ഉദ്ദേശിച്ച കൈമാറ്റം, തെറ്റായ സെർവർ ഐഡന്റ്റിറ്റി, അനധികൃത ഉപകരണം, അനിശ്ചിത പ്രവർത്തനത്തിന് ശേഷമുള്ള വീണ്ടും കണക്ഷൻ. ഉപകരണം കാണിക്കുന്ന പിശക് ഉൾപ്പെടുത്തി ഓരോ കേസിന്റെയും ഫലം രേഖപ്പെടുത്തുക.