VPC റിമോട്ട് ആക്സസ് സ്വീകരിക്കാൻ നിരസിക്കൽ പരിശോധനകൾ വേണം

റിമോട്ട് ആക്സസിന്റെ സ്വീകരണം പ്രതീക്ഷിക്കുന്ന ഫലങ്ങളുടെ പട്ടികയാണ്, പ്രവർത്തിക്കുന്ന പേജിന്റെ സ്ക്രീൻഷോട്ട് അല്ല. ഓരോ ഗ്രൂപ്പിനും എന്ത് വിജയിക്കണം, എന്ത് പരാജയപ്പെടണം എന്ന് എഴുതുക, തുടർന്ന് നിയന്ത്രിത സമയപരിധിയിൽ സമർപ്പിത പരിശോധനാ ഐഡന്റിറ്റികൾ ഉപയോഗിച്ച് രണ്ടും പ്രവർത്തിപ്പിക്കുക. അതിർത്തി തെളിയിക്കുന്നത് നിരസിക്കലുകളാണ്; വിജയകരമായ ലോഗിൻ ടണൽ നിലവിലുണ്ടെന്ന് മാത്രം തെളിയിക്കുന്നു. ഇതെല്ലാം ഇതിനകം തിരഞ്ഞെടുത്ത VPN ഉൽപ്പന്നത്തോടൊപ്പം പ്രവർത്തിക്കുന്നു.

പരിശോധനകൾക്ക് പ്രത്യേക അക്കൗണ്ടുകൾ ഉപയോഗിക്കുക, പരിശോധനാ ഐഡന്റിറ്റിയെ യഥാർത്ഥ ഒഴിവാക്കലായി ആരും തെറ്റിദ്ധരിക്കാതിരിക്കാൻ ലേബൽ ചെയ്യുക.

അതിർത്തി പ്രതീക്ഷിക്കുന്ന ഫലങ്ങളായി എഴുതുക

ഘടകങ്ങളിൽ നിന്നല്ല, റോളുകളിൽ നിന്ന് തുടങ്ങുക: ആർക്ക് ഏത് സേവനം, എവിടെ നിന്ന്, ഏത് ഐഡന്റിറ്റിയോടെ വേണം. ഒരു ഉദാഹരണ VPC എടുക്കുക: ഒരു ഗ്രൂപ്പിന് HTTPS വഴി സ്റ്റേജിംഗ് വേണം, മറ്റൊന്നിന് പ്രൊഡക്ഷൻ ഡാറ്റാബേസ് വേണം, മൂന്നാമത്തെ ചെറിയ ഗ്രൂപ്പ് ഗേറ്റ്‌വേ തന്നെ നിയന്ത്രിക്കുന്നു. ഓരോ വരിക്കും പ്രതീക്ഷിക്കുന്ന അനുമതിയും പ്രതീക്ഷിക്കുന്ന നിരസിക്കലും ലഭിക്കുന്നു, പ്രവർത്തിക്കാൻ പാടില്ലാത്ത അയൽ സേവനവും അയൽ അക്കൗണ്ടും ഉൾപ്പെടെ. ആ പട്ടികയാണ് സ്വീകരണ മാനദണ്ഡം, പരിശോധനകൾ നടത്താത്തവർക്കും അത് പരിശോധിക്കാം.

ഡാറ്റാബേസ് ലോഗിൻ നെറ്റ്‌വർക്ക് പാതയിൽ നിന്ന് വേർതിരിച്ച് പരിശോധിക്കുക. എത്തിച്ചേരാവുന്ന TCP പോർട്ട് അംഗീകരിക്കാത്ത ഡാറ്റാബേസ് അക്കൗണ്ടിനെ വിജയിപ്പിക്കരുത്, VPN അംഗത്വം ക്ലൗഡ് IAM റോൾ സൃഷ്ടിക്കുകയോ അഡ്മിനിസ്ട്രേറ്റീവ് API ആക്സസ് നൽകുകയോ ചെയ്യരുത്. ഇവ മൂന്ന് സ്വതന്ത്ര നിയന്ത്രണങ്ങളാണ്, അവ സ്വതന്ത്രമായി പരാജയപ്പെടുന്നു.

റൂട്ട് അംഗീകാരമല്ല

റൂട്ട് ഒരു പാത സാധ്യമാക്കുന്നു; അത് അനുമതി നൽകുന്നില്ല. റൂട്ട് തടഞ്ഞുവയ്ക്കുന്നത് ലക്ഷ്യസ്ഥാനത്ത് നടപ്പാക്കുന്ന നിയന്ത്രണത്തിന് ദുർബലമായ പകരമാണ്, കാരണം ക്ലയന്റിന് എപ്പോഴും സ്വന്തം റൂട്ട് ചേർക്കാം. സുരക്ഷാ ഗ്രൂപ്പ്, ഡാറ്റാബേസ് അനുവാദം, ആപ്ലിക്കേഷന്റെ സ്വന്തം അംഗീകാരം എന്നിവയാണ് തീരുമാനിക്കുന്ന നിയന്ത്രണങ്ങളായി തുടരുന്നത്. ഒരു പരിശോധന അപ്രതീക്ഷിതമായി വിജയിക്കുമ്പോൾ, ക്ലയന്റിന് നൽകാൻ ഉദ്ദേശിച്ച റൗട്ടിംഗ് പട്ടികയല്ല, ആദ്യം ലക്ഷ്യസ്ഥാനത്തിന്റെ നയം നോക്കുക.

അതുകൊണ്ടാണ് നിരസിക്കൽ പരിശോധനകൾ സെർവർ ഭാഗത്തെ ലക്ഷ്യമിടുന്നത്: ആ ഫലങ്ങൾ ക്ലയന്റ് എഡിറ്റ് ചെയ്ത് മാറ്റാൻ കഴിയില്ല.

നിയന്ത്രണം യഥാർത്ഥത്തിൽ ഏത് ഉറവിടമാണ് കാണുന്നത്?

ഒരു നിയന്ത്രണം വിലയിരുത്തുന്ന ഉറവിട വിലാസം ഗേറ്റ്‌വേയുടെ ആർക്കിടെക്ചറിനെ ആശ്രയിച്ചിരിക്കുന്നു. EC2-ൽ ഹോസ്റ്റ് ചെയ്ത ഗേറ്റ്‌വേ ഒരു റൗട്ടഡ് പൂൾ കൈമാറാം, അത് സ്വന്തം വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്യാം, അല്ലെങ്കിൽ NAT-ന് ശേഷം മറ്റൊരു വിലാസം അവതരിപ്പിക്കാം; മാനേജ്ഡ് Client VPN ഒരു സബ്‌നെറ്റുമായി ബന്ധിപ്പിച്ച് സ്വന്തം മോഡൽ പിന്തുടരുന്നു. സുരക്ഷാ ഗ്രൂപ്പുകളും നെറ്റ്‌വർക്ക് ACL-കളും ആ പ്രോസസ്സിംഗിന് ശേഷം വരുന്നത് കാണുന്നു. തെറ്റായ ഉറവിട അനുമാനത്തിനെതിരെ ഒരു നിയമം പരിശോധിക്കുന്നത് ശരിയായി തോന്നുന്നതും തെറ്റായ ട്രാഫിക് അനുവദിക്കുന്നതുമായ അതിർത്തി നിർമ്മിക്കാനുള്ള സാധാരണ മാർഗമാണ്.

ഓരോ ഫലവും ഏറ്റവും ചെറിയ ഉപയോഗപ്രദമായ സംഭവവുമായി ബന്ധിപ്പിക്കുക: ഐഡന്റിറ്റിയും സെഷനും, വിഭവം, പ്രവർത്തനം, സമയം, തീരുമാനം. CloudTrail API വിളി, VPC ഫ്ലോ റെക്കോർഡ്, VPN സെഷൻ ലോഗ് എന്നിവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, അവയിൽ ഒന്നും ഒറ്റയ്ക്ക് ആപ്ലിക്കേഷൻ ഓഡിറ്റല്ല.

ഐഡന്റിറ്റി പിൻവലിച്ച് വീണ്ടും പരിശോധിക്കുക

പിൻവലിക്കലും അതേ പട്ടികയിൽ ഉൾപ്പെടുത്തുക. പരിശോധനാ ഐഡന്റിറ്റി നീക്കം ചെയ്ത് പുതിയ സെഷൻ നിരസിക്കപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക, തുടർന്ന് നിലവിലുള്ള സെഷനുകളെ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നുവെന്ന് വെവ്വേറെ ഉറപ്പാക്കുക, കാരണം അവ വ്യത്യസ്ത ഉടമകളുള്ള വ്യത്യസ്ത സ്വഭാവങ്ങളാണ്. ഗേറ്റ്‌വേ റീസ്റ്റാർട്ട് ചെയ്തതിനോ മാറ്റിയതിനോ ശേഷം എന്ത് സംഭവിക്കുന്നുവെന്ന് പരിശോധിക്കുക, കൈകൊണ്ട് ചേർത്ത ഒഴിവാക്കൽ നിശ്ശബ്ദമായി അപ്രത്യക്ഷമാകാതിരിക്കാനും കൂടുതൽ വിശാലമായി തിരികെ വരാതിരിക്കാനും. അടുത്ത വിന്യാസം വരെ മാത്രം നിലനിൽക്കുന്ന അതിർത്തി അതിർത്തിയല്ല.

ഇവയൊന്നും പാച്ചിംഗ്, വീണ്ടെടുക്കൽ, ക്രെഡൻഷ്യൽ ലൈഫ് സൈക്കിൾ എന്നിവയുടെ ജോലിക്ക് പകരമാകുന്നില്ല. ഇത് ഇടുങ്ങിയ ഒരു വാഗ്ദാനം അളക്കാവുന്നതാക്കുന്നു: ശരിയായ ആളുകൾ ശരിയായ സേവനങ്ങളിൽ എത്തുന്നു, സമീപത്തുള്ള റൂട്ടുകളും അക്കൗണ്ടുകളും മാനേജ്മെന്റ് ഉപരിതലങ്ങളും അനുവാദത്തിന് പുറത്ത് നിൽക്കുന്നു.

പട്ടിക വിന്യാസത്തോടൊപ്പം സൂക്ഷിക്കുക, ഗേറ്റ്‌വേ മാറുമ്പോൾ വീണ്ടും പ്രവർത്തിപ്പിക്കുക. പരിശോധനകൾ വിലകുറഞ്ഞതാണ്; അവയ്ക്ക് പിന്നിലെ അനുമാനങ്ങൾ അല്ല.