സുരക്ഷാ പരിശോധനയുടെ ആക്സസ് കൈമാറ്റം: പരിധി, അക്കൗണ്ടുകൾ, റദ്ദാക്കൽ
VPN ക്രെഡൻഷ്യലുകൾ ആവശ്യപ്പെടുന്ന പരിശോധകന് പരിധി നിർവചിച്ച കൈമാറ്റമാണ് വേണ്ടത്, അധിക ലോഗിൻ അല്ല. അനുമതി ഗേറ്റ് ചെയ്യുക, ലക്ഷ്യങ്ങൾ പേരിടുക, അക്കൗണ്ടുകൾ നൽകുക, പിന്നീട് റദ്ദാക്കുക.
ഒരു പരിശോധകൻ ഗേറ്റ്വേ വിലാസവും ആന്തരിക DNS വിശദാംശങ്ങളും VPN ക്രെഡൻഷ്യലുകളും ആവശ്യപ്പെടുന്നു, ആവശ്യകത «ആക്സസ് വേണം» എന്ന വിഷയത്തോടെ നിങ്ങൾക്ക് കൈമാറുന്നു. ആവശ്യകത മാത്രം ഇത് ആന്തരിക വിലയിരുത്തലാണോ, പ്രാമാണീകരിച്ച ആപ്ലിക്കേഷൻ പരിശോധനയാണോ, അല്ലെങ്കിൽ ആരോ പരിധി തെറ്റിദ്ധരിച്ച ഒരു പൊതു വെബ്സൈറ്റ് ജോലിയാണോ എന്ന് പറയുന്നില്ല. കൈമാറ്റം ഓരോ ഘട്ടത്തിലും ഒരു ഗേറ്റോടുകൂടി ക്രമമായി നടത്തി തുറക്കാത്ത ആദ്യ ഗേറ്റിൽ നിർത്തുക. അത് അവ്യക്തമായ ആവശ്യകതയെ നിങ്ങൾക്ക് അനുമതി നൽകാനും കൈമാറാനും പിന്നീട് റദ്ദാക്കാനും കഴിയുന്ന ഒന്നാക്കി മാറ്റുന്നു.
ക്രെഡൻഷ്യലുകളിൽ നിന്നല്ല, അനുമതിയിൽ നിന്ന് തുടങ്ങുക
നിങ്ങളുടെ ഇൻബോക്സിൽ നിന്ന് ഏതെങ്കിലും വിലാസം പുറത്തുപോകുന്നതിന് മുൻപ് ലക്ഷ്യങ്ങളുടെ ഉടമ ആരെന്നും അവയിൽ പരിശോധന അനുവദിക്കാൻ ആർക്ക് അധികാരമുണ്ടെന്നും വ്യക്തമാക്കുക. നിങ്ങളുടെ സ്ഥാപനം ഇതിനകം ഉപയോഗിക്കുന്ന ഏർപ്പാടിന്റെ കോൺടാക്റ്റ് വഴി പരിശോധകനെ സ്ഥിരീകരിക്കുക, ഇമെയിൽ കൈമാറിയ വ്യക്തി വഴിയല്ല. ഉപഭോക്തൃബന്ധം ഒരു അക്കൗണ്ടിൽ നിന്ന് എത്താവുന്ന എല്ലാ സിസ്റ്റവും പരിശോധിക്കാനുള്ള അനുമതിയല്ല, ഒപ്പം വാങ്ങൽ ഓർഡർ പരിധി രേഖയുമല്ല.
അംഗീകരിച്ച ലക്ഷ്യം ഒരു വാക്യത്തിൽ എഴുതി കൈമാറ്റത്തിന്റെ അടുത്ത് സൂക്ഷിക്കുക. «ഉപഭോക്തൃ പോർട്ടലിന്റെ പ്രാമാണീകരണം വിലയിരുത്തുക», «ആന്തരിക നെറ്റ്വർക്ക് വിലയിരുത്തുക» എന്നിവ തികച്ചും വ്യത്യസ്ത പാക്കേജുകളിലേക്കാണ് നയിക്കുന്നത്, ഒപ്പം വ്യത്യാസം വിതരണത്തിന് മുൻപ് തീരുമാനിക്കണം, ഒരു കണ്ടെത്തൽ വന്നതിന് ശേഷമല്ല. ജോലിക്ക് നടുവിൽ ആവശ്യകത വളരുമ്പോൾ ചൂണ്ടിക്കാണിക്കാൻ ഈ വാക്യം നിങ്ങൾക്ക് ഒന്ന് നൽകുന്നു.
പാതയിൽ ഒരു ഹോസ്റ്റിംഗ് ദാതാവോ മറ്റൊരു മൂന്നാം കക്ഷിയോ ഉണ്ടെങ്കിൽ അവരുടെ ആവശ്യകതകൾ നിങ്ങളുടെ സൗകര്യത്തിന് മുൻപ് വരുന്നു. അവരുടെ അനുമതിയില്ലാതെ മറ്റൊരാളുടെ അടിസ്ഥാനസൗകര്യം പരിശോധിക്കുന്നത് അതിൽ പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷൻ പരിശോധിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്ത പ്രശ്നമാണ്.
കാഴ്ചപ്പാടും ലക്ഷ്യങ്ങളും പേരിടുക
വിലയിരുത്തൽ ഉത്തരം നൽകാൻ ശ്രമിക്കുന്ന ചോദ്യമാണ് കാഴ്ചപ്പാട്, ഒപ്പം പരിശോധകൻ ഉപയോഗിക്കാൻ പദ്ധതിയിടുന്ന ഏതൊരു ഉപകരണത്തെക്കാളും അത് ആക്സസ് പാക്കേജ് നിർണ്ണയിക്കുന്നു. പൊതു പ്രാമാണീകരിക്കാത്ത പരിശോധനയ്ക്ക് ഒരു URL-ഉം സമയവിൻഡോയും വേണം. പ്രാമാണീകരിച്ച പരിശോധനയ്ക്ക് പരിധിയിലുള്ള നിർദ്ദിഷ്ട റോളുകൾക്ക് സമർപ്പിത അക്കൗണ്ടുകൾ വേണം, ആന്തരിക വിലയിരുത്തലിന് വ്യക്തമായ ലക്ഷ്യശ്രേണികളുള്ള നിർവചിച്ച പ്രവേശന കേന്ദ്രം വേണം.
| Viewpoint | What you hand over | What it does not authorize |
|---|---|---|
| Public website | Approved URL, TLS hostname, testing window | Internal network entry, adjacent hosts |
| Authenticated app | URL plus per-role test accounts | Other tenants, admin consoles outside scope |
| Private staging | Named private path and test accounts | Production systems behind the same gateway |
| Internal network | Entry point and written target ranges | Anything outside those ranges, including the gateway itself |
ടണൽ എവിടെ പ്രവേശിക്കുന്നു എന്നത് അതിന് പിന്നിൽ ഏത് ആപ്ലിക്കേഷൻ ഉണ്ടെന്ന വസ്തുതയല്ല, ഒപ്പം അത് പ്രവേശന കേന്ദ്രം അന്വേഷിക്കാൻ ഒരിക്കലും അനുമതി നൽകുന്നുമില്ല. കൈമാറ്റത്തിൽ അത് വ്യക്തമായി പറയുക, കാരണം ഒരു കണ്ടെത്തൽ തർക്കത്തിലാകുമ്പോൾ «ആ സബ്നെറ്റിലേക്ക് നീ എനിക്ക് ആക്സസ് തന്നു» എന്ന വാക്യം വേഗം വരും. ലിഖിത ലക്ഷ്യപ്പട്ടിക മാത്രമാണ് പിന്നീട് അത് തീരുമാനിക്കുന്നത്.
URL-നൊപ്പം TLS ഹോസ്റ്റ്നാമം നൽകുക. വെറും IP വിലാസം പരിശോധകനെ പേര് ഊഹിക്കാൻ നിർബന്ധിക്കുന്നു, ഊഹിച്ച പേര് കൈമാറ്റപ്പിശകിന് പകരം കണ്ടെത്തലായി റിപ്പോർട്ട് ചെയ്യുന്ന സർട്ടിഫിക്കറ്റ് പിശകുകൾ ഉണ്ടാക്കുന്നു.
കാലാവധിയോടെ സമർപ്പിത ഐഡന്റിറ്റികൾ നൽകുക
ഈ ഏർപ്പാടിന് മാത്രമായി നിലനിൽക്കുന്ന അക്കൗണ്ടുകൾ ഒരുക്കുക; ഒരു ജീവനക്കാരന്റെ ദൈനംദിന ലോഗിൻ കടം കൊടുക്കരുത്. സമ്മതിച്ച ജോലികൾക്ക് നെറ്റ്വർക്ക് എത്തിച്ചേരലും ആപ്ലിക്കേഷൻ അനുമതികളും ക്രമീകരിക്കുക, പിന്തുണയുള്ള പാതയിലൂടെ പ്രാമാണീകരണ രജിസ്ട്രേഷൻ ഒരുക്കുക, ഒപ്പം റദ്ദാക്കലിന് ഉത്തരവാദിയായ പേരെടുത്ത വ്യക്തിയോടൊപ്പം കാലാവധി തീയതി ചേർക്കുക. ക്രെഡൻഷ്യലുകൾ സമ്മതിച്ച സുരക്ഷിത ചാനലിലൂടെ, ചുറ്റും കൈമാറുന്ന പരിധി രേഖയിൽ നിന്ന് വേർതിരിച്ച് നൽകുക.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
ആര് എന്ത് എപ്പോൾ സ്വീകരിച്ചു എന്ന് രേഖപ്പെടുത്തുക. നിയന്ത്രിത കൈമാറ്റവും ആർക്കും കണ്ടെത്താനാകാത്ത പങ്കിട്ട പാസ്വേഡും തമ്മിലുള്ള വ്യത്യാസമാണ് ആ രേഖ, ഒപ്പം ഒരു സംഭവത്തിന് ശേഷം എല്ലാവരും ആദ്യം ആവശ്യപ്പെടുന്നതും അതാണ്. ചാറ്റ് ത്രെഡിലല്ല, പരിധി രേഖയോടൊപ്പം സൂക്ഷിക്കുക, സ്വീകർത്താവിന്റെ അടുത്ത് വിതരണ ചാനൽ കുറിക്കുക. സമയമുദ്രയുള്ള ഒരു വരി എപ്പോഴും ഓർമ്മയെ തോൽപ്പിക്കുന്നു.
കാലാവധി ഫീൽഡ് അവസാന സംരക്ഷണമാണ്, പദ്ധതിയല്ല. അവസാനം ആരെങ്കിലും നെറ്റ്വർക്ക് പാതയും ആപ്ലിക്കേഷൻ റോളും നീക്കം ചെയ്യണം, കാരണം ഇപ്പോഴും എത്താവുന്ന നെറ്റ്വർക്കിൽ കാലാവധി കഴിഞ്ഞ ലോഗിൻ റദ്ദാക്കിയ ആക്സസ് അല്ല.
വിൻഡോ തുറക്കുന്നതിന് മുൻപ് കൈമാറ്റം പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുക
പരിശോധകന്റെ ആദ്യ ചാട്ടം നിങ്ങൾ തന്നെ നടത്തുക, അദ്ദേഹത്തിന്റെ സ്ഥാനത്തോട് കഴിയുന്നത്ര അടുത്ത നിലയിൽ നിന്ന്. പേര് പരിഹരിക്കുക, സർട്ടിഫിക്കറ്റിന്റെ ഐഡന്റിറ്റി പരിശോധിക്കുക, പാത അയൽവാസിയല്ല, ഉദ്ദേശിച്ച വിലാസത്തിൽ എത്തുന്നു എന്ന് സ്ഥിരീകരിക്കുക.
dig +short app.example.com openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates ip route get 10.60.0.25
പാതയ്ക്ക് ഒരു ലക്ഷ്യത്തിൽ എത്താൻ കഴിയുന്നില്ലെങ്കിൽ, പരിശോധകനെ ബദൽ വഴി കണ്ടെത്താൻ അനുവദിക്കുന്നതിന് പകരം നിർത്തി കൈമാറ്റം യോജിപ്പിക്കുക. തൽക്ഷണ എത്തിച്ചേരലാണ് ഒരു വിലയിരുത്തൽ നിശബ്ദമായി അതിന്റെ പരിധിക്ക് പുറത്തേക്ക് വളരുന്ന വഴി, ഒപ്പം പിന്നീട് അത് ഏതാണ്ട് ഒരിക്കലും രേഖപ്പെടുത്തപ്പെടുന്നുമില്ല.
ക്രെഡൻഷ്യലുകൾക്കൊപ്പം പ്രവർത്തന കോൺടാക്റ്റ്, അനുവദിച്ച മണിക്കൂറുകൾ, ഒഴിവാക്കിയ പ്രവർത്തനങ്ങൾ, നിർത്തൽ വ്യവസ്ഥകൾ എന്നിവ അയയ്ക്കുക. 02:00-ന് ആരെയും എത്താൻ കഴിയാത്ത പരിശോധകൻ നിങ്ങൾ അനുമതി നൽകാത്ത ഒരു തീരുമാനം എടുക്കും, ആ തീരുമാനം പരിധിക്കുള്ളിലായിരുന്നതുപോലെ റിപ്പോർട്ടിൽ വിവരിക്കപ്പെടും.
NIST SP 800-115 സാങ്കേതിക വിലയിരുത്തലിനെ ആസൂത്രിത പരിശോധനയും തുടർന്ന് വിശകലനവും ലഘൂകരണവുമായി ചട്ടക്കൂട്ടുന്നു, ഈ കൈമാറ്റം പിന്തുടരുന്നത് അതേ രൂപമാണ്. മുകളിലെ ഗേറ്റുകൾ ഒരു പിന്തുണാ എൻജിനീയറിനുള്ള എഡിറ്റോറിയൽ ഡിസൈൻ തീരുമാനങ്ങളാണ്, ആ പ്രസിദ്ധീകരണത്തിൽ നിന്ന് ഉദ്ധരിച്ച ചെക്ക്ലിസ്റ്റല്ല.
ആക്സസ് നീക്കം ചെയ്ത് ഏർപ്പാട് അവസാനിപ്പിക്കുക
വിതരണത്തിന്റെ വിപരീത ക്രമത്തിൽ റദ്ദാക്കുക: ആപ്ലിക്കേഷൻ റോളുകൾ, പിന്നെ നെറ്റ്വർക്ക് ആക്സസ്, പിന്നെ ഐഡന്റിറ്റി തന്നെ. ബട്ടൺ വാഗ്ദാനം ചെയ്തത് കൺസോൾ ചെയ്തു എന്ന് കരുതുന്നതിന് പകരം ഓരോ ഘട്ടവും സ്ഥിരീകരിക്കുക. സെഷനുകൾ കൊല്ലുന്നതിന് മുൻപ് അക്കൗണ്ട് ലോക്ക് ചെയ്യുക, അല്ലെങ്കിൽ സെഷൻ പഴയ പാതയിലൂടെ വീണ്ടും പ്രാമാണീകരിക്കും. പിന്നെ അടച്ചു എന്ന് പ്രഖ്യാപിക്കുന്നതിന് മുൻപ് സ്ഥാപിത കണക്ഷനുകൾ ഒരിക്കൽകൂടി പരിശോധിക്കുക.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
സൂക്ഷിച്ച പരിശോധനാ ഡാറ്റ തീർപ്പാക്കുക, പിന്നെ തുടക്കത്തിൽ സമ്മതിച്ച റിപ്പോർട്ടിംഗ് പ്രക്രിയയിലൂടെ പരിഹാരം പിന്തുടരുക. റിപ്പോർട്ടിൽ പരിസ്ഥിതി, ആക്സസ് നില, പരിധി, പരിമിതികൾ എന്നിവ പറയണം, കാരണം അത് ഒരു വിലയിരുത്തലിന്റെ കണ്ടെത്തലുകൾ രേഖപ്പെടുത്തുന്നു, സൈറ്റ് സുരക്ഷിതമാണെന്ന സ്ഥിരമായ പ്രസ്താവനയല്ല.
റദ്ദാക്കൽ രേഖ കൈമാറ്റ രേഖയോടൊപ്പം സൂക്ഷിക്കുക. അടുത്ത ഏർപ്പാട് തുറക്കുമ്പോൾ കഴിഞ്ഞ തവണ കൃത്യമായി എന്താണ് നീക്കിയതെന്നും ആരാണ് അനുമതി നൽകിയതെന്നും നിങ്ങൾക്ക് അറിയണം, ഓർമ്മയിൽ നിന്ന് ചിത്രം പുനർനിർമ്മിക്കാനല്ല.