સુરક્ષા પરીક્ષણ માટે ઍક્સેસ હેન્ડઓફ: વ્યાપ્તિ, ખાતાં અને રદ
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 )'
રોકાયેલા પરીક્ષણ ડેટાનું નિરાકરણ કરો, પછી શરૂઆતમાં સંમત અહેવાલ પ્રક્રિયા દ્વારા સુધારણા ટ્રૅક કરો. અહેવાલમાં પર્યાવરણ, ઍક્સેસ સ્તર, વ્યાપ્તિ અને મર્યાદાઓ જણાવવી જોઈએ, કારણ કે તે એક મૂલ્યાંકનના તારણો નોંધે છે અને સાઇટ સુરક્ષિત છે તેવું કાયમી નિવેદન નથી.
રદ રેકોર્ડને હેન્ડઓફ રેકોર્ડ સાથે રાખો. આગલું એન્ગેજમેન્ટ ખૂલે ત્યારે તમે જાણવા માંગો છો કે ગયા વખતે નક્કી શું દૂર કરાયું અને કોણે મંજૂરી આપી, યાદશક્તિથી ચિત્ર ફરી બનાવવાને બદલે.