ആപ്പ് mTLS, SSO എന്നിവ ഉപയോഗിക്കുമ്പോൾ നിങ്ങൾക്ക് ഇനിയും സൈറ്റ് VPN വേണോ?
നിങ്ങളുടെ ആപ്പ് ലോഗിൻ ഒരിക്കലും ഉൾക്കൊള്ളാത്ത ചാനലുകളിലൂടെ നടന്ന്, സ്വകാര്യ നെറ്റ്‌വർക്ക് ആക്‌സസ് അനാവശ്യമാണോ അതോ ഇപ്പോഴും ഹോസ്റ്റിലേക്കുള്ള ഏക വഴിയാണോ എന്ന് തീരുമാനിക്കുക.
നിങ്ങൾ mTLS വഴി സൈൻ ഇൻ ചെയ്യുന്നു, ഡാഷ്‌ബോർഡ് ലോഡ് ചെയ്യുന്നു, സൈറ്റ് VPN ഇപ്പോൾ അനാവശ്യമാണ് എന്ന അവകാശവാദം രാത്രി രണ്ട് മണിക്ക് ഒരു ഡാറ്റാബേസ് പുനഃസ്ഥാപിക്കേണ്ടിവരുന്നതുവരെ മാത്രം ന്യായയുക്തമായി തോന്നുന്നു. ആപ്പിന്റെ TLS അതിർത്തി ഒരു ചാനലിനെ മാത്രം വിവരിക്കുന്നു. ഹോസ്റ്റ്, ഡാറ്റാബേസ്, ബാക്കപ്പ് ലക്ഷ്യം, ക്ലൗഡ് അക്കൗണ്ട് എന്നിവയ്ക്ക് ഓരോന്നിനും സ്വന്തം പ്രവേശന പാതയും സ്വന്തം ഐഡന്റിറ്റിയും സ്വന്തം അംഗീകാരക്കാരനും ഉണ്ട്, അവയിൽ ഒന്നും വിജയകരമായ ലോഗിൻ ഉപയോഗിച്ച് പരിശോധിക്കപ്പെടുന്നില്ല.
ലോഗിൻ സ്ക്രീനിൽ നിന്ന് പുറത്തേക്ക് നടക്കുക
ഒരു സാധാരണ ഉപയോക്താവിനെപ്പോലെ സൈൻ ഇൻ ചെയ്ത് അഭ്യർത്ഥന സ്പർശിക്കുന്ന ഓരോ ചുവടും എഴുതുക: ബ്രൗസർ, എഡ്ജ്, ആപ്ലിക്കേഷൻ ശ്രോതാവ്, സെഷൻ സംഭരണി, ബാക്കെൻഡ് API. ഓരോ ചുവടിനും ഒരു ഉടമയും ഒരു പ്രാമാണീകരണ തീരുമാനവും ഉണ്ട്. ഇപ്പോൾ ഹോസ്റ്റ് പാച്ച് ചെയ്യുന്ന വ്യക്തിക്കും രാത്രി ബാക്കപ്പ് എഴുതുന്ന ജോലിക്കും ഈ നടത്തം ആവർത്തിക്കുക. ആ പാതകൾ സാധാരണയായി ആദ്യ ചുവട്ടിൽ തന്നെ വേർപിരിയുന്നു.
ആ വേർപിരിയലാണ് ഉത്തരം നൽകാൻ യോഗ്യമായ ചോദ്യം. ആ രണ്ടാം നടത്തത്തിലെ ഓരോ ചാനലിനും സ്വതന്ത്രമായി നിൽക്കുന്ന പ്രവേശന, അധികാര നയം ഉണ്ടെങ്കിൽ മാത്രമേ സൈറ്റ് VPN അനാവശ്യമാകൂ.
ആപ്പ് ലോഗിൻ ഒരിക്കലും ഉൾക്കൊള്ളാത്ത അഞ്ച് ചാനലുകൾ
താഴെയുള്ള പട്ടിക ഒരു ഇൻവെന്ററി ടെംപ്ലേറ്റാണ്, വിന്യാസ പരിശോധനാ പട്ടികയല്ല. രണ്ടാം നിര നിങ്ങളുടെ പരിസ്ഥിതി ഇന്ന് യഥാർത്ഥത്തിൽ നടപ്പിലാക്കുന്നതുകൊണ്ട് നിറയ്ക്കുക.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
ഒരു ഐഡന്റിറ്റി ദാതാവ് പങ്കിടുന്നത് ഈ അധികാരങ്ങളെ ഒന്നിപ്പിക്കുന്നില്ല. API അഭ്യർത്ഥന അയയ്ക്കാൻ അനുവാദമുള്ള ഉപയോക്താവിന് അതിലൂടെ VM ഡിസ്ക് മാറ്റാനോ ആപ്പിന്റെ ക്രെഡൻഷ്യലുകൾ ഉപയോഗിച്ച് ഡാറ്റാബേസ് പുനഃസ്ഥാപിക്കാനോ അധികാരമില്ല. NIST പൂജ്യ-വിശ്വാസ വാസ്തുവിദ്യാ സംഗ്രഹത്തിൽ കൃത്യമായി ഈ കാരണത്താൽ വിഭവ പ്രാമാണീകരണവും അധികാരവും നെറ്റ്‌വർക്ക് സ്ഥാനത്തിൽ നിന്ന് വേർതിരിച്ച് നിർത്തുന്നു.
ടിക്കറ്റ് വായിക്കാൻ കഴിയുന്ന പിന്തുണാ എൻജിനീയർക്ക് അതിലൂടെ അതിന് പിന്നിലുള്ള ഹോസ്റ്റിൽ ഒരു കൺസോൾ തുറക്കാൻ അധികാരമില്ല.
പകരം സാധ്യത അടച്ചിരിക്കുമ്പോൾ മാത്രമാണ് പാത യഥാർത്ഥമാകുന്നത്
സ്വകാര്യ അഡ്മിനിസ്ട്രേറ്റീവ് ശ്രോതാക്കളിലേക്കുള്ള എത്തിച്ചേരൽ പരിമിതപ്പെടുത്തുന്നത് സൈറ്റ് VPN-ന് ന്യായമായ പകരമാണ്, എന്നാൽ പരിമിതി നടപ്പിലാക്കണം, വരച്ചിടാൻ മാത്രം പാടില്ല. സാധാരണ പരാജയം ആരും ഓർമ്മിച്ചിട്ടില്ലാത്ത ഒരു ബദൽ ശ്രോതാവാണ്: എല്ലാ ഇന്റർഫേസുകളിലും ഇപ്പോഴും ബന്ധിപ്പിച്ചിരിക്കുന്ന സേവനം, കരാറുകാരനുവേണ്ടി തുറന്ന സുരക്ഷാ ഗ്രൂപ്പ് നിയമം, ഇന്റർനെറ്റിൽ നിന്ന് എത്താവുന്ന മാനേജ്മെന്റ് പോർട്ട്.
ഡയഗ്രമുകളല്ല, ശ്രോതാക്കൾ പരിശോധിക്കുക. ഹോസ്റ്റിൽ ss -ltnp ഉപയോഗിച്ച് യഥാർത്ഥത്തിൽ എന്താണ് ബന്ധിപ്പിച്ചിരിക്കുന്നതെന്ന് പട്ടികപ്പെടുത്തി, അഡ്മിനിസ്ട്രേറ്റീവ് പോർട്ടുകൾ സ്വകാര്യ വിലാസത്തിലാണെന്ന് ഉറപ്പാക്കുക. ക്ലൗഡ് കൺസോളിൽ വർക്ക്‌ലോഡ് സബ്‌നെറ്റിന്റെ ഇൻബൗണ്ട് നിയമങ്ങൾ വായിച്ച്, അഡ്മിനിസ്ട്രേറ്റീവ് ആയ ഏതെങ്കിലും കാര്യത്തിൽ 0.0.0.0/0 ഉണ്ടോ എന്ന് നോക്കുക. തുടർന്ന് സ്വകാര്യ പാതയ്ക്ക് പുറത്തുനിന്ന് കണക്ഷൻ പരീക്ഷിക്കുക, കാരണം ആ പരീക്ഷണമാണ് ചോദ്യത്തിന് ഉത്തരം നൽകുന്നത്.
SSH-ൽ ലോകത്തിന് തുറന്ന ഒരൊറ്റ നിയമം ടണൽ രൂപകൽപ്പനയുടെ എല്ലാ വാദങ്ങളും റദ്ദാക്കുന്നു.
രൂപകൽപ്പനകൾ താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് ഭൂപടം എഴുതുക
ഇൻവെന്ററിയുടെ ഓരോ വരിക്കും ആരാണ് ഐഡന്റിറ്റികൾ അംഗീകരിക്കുന്നത്, ആരാണ് ആക്‌സസ് നിയമങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നത്, ആരെങ്കിലും പോകുമ്പോൾ ആരാണ് ക്രെഡൻഷ്യലുകൾ നീക്കുന്നത്, പാത തന്നെ തകരുമ്പോൾ ആരാണ് പുനഃസ്ഥാപനം കൈകാര്യം ചെയ്യുന്നത് എന്ന് രേഖപ്പെടുത്തുക. ഓരോ വരിക്കും നാല് പേരുകൾ മതി, ഉത്തരം പങ്കിട്ട അക്കൗണ്ടും മൂന്ന് വർഷം പഴക്കമുള്ള ഒരു വിക്കി പേജുമായ വരികൾ പുറത്തുകൊണ്ടുവരാൻ.
തുടർന്ന് ഓരോ ചാനലിനും ഒരു അനുമതിയും ഒരു നിരസനവും സാധൂകരിക്കുക. അനുമതി തെളിയിക്കുന്നത് ഉദ്ദേശിച്ച ഐഡന്റിറ്റിക്ക് ഉദ്ദേശിച്ച പാതയിലൂടെ വിഭവത്തിൽ എത്താൻ കഴിയുമെന്നാണ്. നിരസനം തെളിയിക്കുന്നത് സമാനമായ ഐഡന്റിറ്റിക്ക് എത്താൻ കഴിയില്ലെന്നാണ്, ആളുകൾ ഒഴിവാക്കുന്ന പരീക്ഷണം അതാണ്, അതുകൊണ്ടാണ് ബദൽ ശ്രോതാക്കൾ ഓഡിറ്റുകളെ അതിജീവിക്കുന്നത്. നിർദ്ദേശിച്ച രൂപകൽപ്പനയെ ഈ ഫലങ്ങളുമായി താരതമ്യം ചെയ്യുക, ആപ്പിന്റെ TLS കോൺഫിഗറേഷനുമായി അല്ല, അത് ഇവയിൽ ഒന്നും ഒരിക്കലും പരിശോധിച്ചിട്ടില്ല.
സൈറ്റ് VPN ഇപ്പോഴും തന്റെ സ്ഥാനം നേടുന്നിടം
വിഭവത്തിന് ഓരോ അഭ്യർത്ഥനയ്ക്കും സ്വന്തം പ്രാമാണീകരണം ഇല്ലാത്തപ്പോൾ ടണലോ ഇടുങ്ങിയ ഗേറ്റ്‌വേയോ ആണ് ശരിയായ ഉത്തരം: ഡാറ്റാബേസ് അറ്റകുറ്റപ്പണി പോർട്ടുകൾ, ബാക്കപ്പ് ലക്ഷ്യങ്ങൾ, ഹൈപ്പർവൈസർ കൺസോളുകൾ, ബാൻഡിന് പുറത്തുള്ള മാനേജ്മെന്റ്. ആ ശ്രോതാക്കൾ നെറ്റ്‌വർക്കിനെ വിശ്വസിക്കുന്നു, അതിനാൽ വിളിക്കുന്നയാളെ പ്രാമാണീകരിക്കേണ്ടത് നെറ്റ്‌വർക്കാണ്.
ഇത് ഏക ഉത്തരമല്ല. ഓരോ വിഭവത്തിനും അധികാരം അവസാനിപ്പിക്കുന്ന ഗേറ്റ്‌വേ മുഴുവൻ സബ്‌നെറ്റിലുമുള്ള ടണലിനേക്കാൾ ഇടുങ്ങിയതാകാം, പങ്കിട്ട ജമ്പ് ഹോസ്റ്റിനേക്കാൾ മികച്ച ഓഡിറ്റ് ട്രെയിലും വിടുന്നു.
ജോലിയുടെ ക്രമം: ഇൻവെന്ററി പൂർത്തിയാക്കുക, ബദലുകൾ അടയ്ക്കുക, ഓരോ വരിക്കും ഒരു നിരസനം സാധൂകരിക്കുക, അതിനുശേഷം മാത്രം ടണൽ ഒഴിവാക്കുക. ഒരു വരിക്ക് നിരസനം സൃഷ്ടിക്കാൻ കഴിയില്ലെങ്കിൽ, കഴിയുന്നതുവരെ സ്വകാര്യ പാത നിലനിർത്തുക.