VPN પાછળનું SaaS એડમિન વિસ્તાર: કયા સરનામા પર ભરોસો કરવો?

જાહેર SaaS પૃષ્ઠો દરેક માટે ખુલ્લાં રહી શકે છે, જ્યારે તેમની પાછળની એડમિન ઑપરેશન્સ VPNની બહારના દરેકને નકારે છે. આ શક્ય બનાવતી પદ્ધતિ કોઈ છુપાયેલું મેનુ કે અલગ લોગિન પૃષ્ઠ નથી; તે વિનંતી પહોંચાડનારા નેટવર્ક માર્ગ પરની ચકાસણી છે. સરનામાનો પુરાવો ખોટો મળે તો ચકાસણી કાં તો સાચા એડમિનને બહાર રાખે છે અથવા હેડર લખી શકે તેવા કોઈને પણ અંદર લે છે. ઓરિજિન ખરેખર શું મેળવે છે તેનાથી શરૂ કરો.

ટનલ પછી ઓરિજિન ખરેખર શું મેળવે છે

જ્યારે બ્રાઉઝર એવા VPN દ્વારા જાહેર સાઇટ પર પહોંચે છે જે ઇન્ટરનેટ ટ્રાફિક પણ વહન કરે છે, ત્યારે ગેટવે કનેક્શન નીકળતા પહેલા તેનું ભાષાંતર કરે છે. SaaS ગેટવેનું જાહેર ઇગ્રેસ સરનામું જુએ છે, સામાન્ય રીતે એક સરનામું કે નાની શ્રેણી, અને લેપટોપનું ટનલ સરનામું ક્યારેય જોતું નથી. એટલે 10.90.0.42 ને મંજૂર યાદીમાં ઉમેરવું નિષ્ફળ જાય છે, અને એટલે આખું RFC 1918 ઉમેરવું વધુ જોરથી નિષ્ફળ જાય છે: બીજું તમારા સુધી પહોંચી શકે તેવા દરેક ખાનગી નેટવર્કને અંદર લે છે. શરત લાયક એકમાત્ર સરનામું એ છે જે તમારી સંસ્થા ખરેખર એક્ઝિટ પર ધરાવે છે.

curl -s https://ifconfig.me
dig +short admin.example.com

સ્પ્લિટ ટનલિંગ આ ધારણાને શાંતિથી તોડે છે. જો VPN ફક્ત ખાનગી ઑફિસ માર્ગો વહન કરે, તો જાહેર એડમિન હોસ્ટનામની વિનંતી સ્થાનિક ISP દ્વારા બહાર જાય છે અને ઓરિજિન રહેણાંક સરનામું જુએ છે. કનેક્ટેડ VPN આઇકન આ ચોક્કસ ગંતવ્ય વિશે કંઈ સાબિત કરતું નથી, તેથી ટનલને નહીં, ગંતવ્યને ચકાસો.

જો એક્ઝિટ સરનામું વપરાશકર્તા દીઠ બદલાય છે, તો કોઈ પણ નીતિ લખતા પહેલા થોભો અને રૂટિંગ સુધારો. ફક્ત કેટલાક એડમિન સાથે મેળ ખાતી શરત કોઈ શરત ન હોવા કરતાં ખરાબ છે, કારણ કે તે ઘટના સુધી સમસ્યા છુપાવે છે.

ફક્ત તે પ્રોક્સી પર ભરોસો કરો જે સરનામું ફરીથી લખે છે

મોટાભાગની જાહેર સાઇટ્સ CDN કે રિવર્સ પ્રોક્સી પાછળ હોય છે, તેથી ઓરિજિનનું સોકેટ સરનામું તે ફ્રન્ટએન્ડનું છે, મુલાકાતીનું નહીં. ફ્રન્ટએન્ડ સામાન્ય રીતે મૂળ સરનામું હેડરમાં મોકલે છે, અને તે હેડર હુમલાખોરના નિયંત્રણમાં હોય છે સિવાય કે ઓરિજિન તેને ફક્ત જાણીતા પ્રોક્સીઓથી સ્વીકારે. વિશ્વસનીય સ્રોતોની યાદી સ્પષ્ટ રીતે કન્ફિગર કરો અને ઓરિજિનને બીજે ક્યાંયથી પણ અગમ્ય બનાવો. તે બીજા અડધા વિના હુમલાખોર પ્રોક્સીને છોડીને હેડર સીધો મોકલે છે.

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

એ જ તર્ક PROXY પ્રોટોકોલને લાગુ પડે છે: તે ફક્ત ત્યારે જ વિશ્વસનીય છે જ્યારે શ્રોતા એવા ઇન્ટરફેસ સાથે બંધાયેલો હોય જ્યાં પ્રોક્સી પહોંચી શકે અને બીજું કંઈ નહીં. ખૂટતું સરનામા સંદર્ભ સુરક્ષિત ચકાસણીને નિષ્ફળ કરવી જોઈએ, ડિફૉલ્ટ મંજૂરીમાં પડવું નહીં. ગેરહાજર હેડર વિશ્વસનીય માર્ગનો પુરાવો નથી.

શરતને દરેક સુરક્ષિત ઑપરેશન સાથે જોડો

ચકાસણીને એ મંજૂરી સીમા પર મૂકો જેમાંથી દરેક સુરક્ષિત ઑપરેશન પસાર થાય છે, મેનુ રેન્ડર કરતા પૃષ્ઠમાં નહીં. રૂટ જૂથો, મિડલવેર કે નીતિ સ્તર બધા કામ કરે છે; પ્રતિ હેન્ડલર નકલ કામ કરતી નથી, કારણ કે આગામી ત્રિમાસિકમાં કોઈ ઉમેરે તે હેન્ડલર પાસે તે હશે નહીં.

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

એ જ સીમાએ JSON API, એક્સપોર્ટ, સહી કરેલા ડાઉનલોડ URL અને WebSocket હેન્ડશેક પણ આવરી લેવા જોઈએ, કારણ કે તેમાંથી કોઈને પણ પહેલા HTML પૃષ્ઠની વિનંતી કરવાની જરૂર નથી. VPN ચાલુ હતું ત્યારે બનાવેલી ડાઉનલોડ લિંક પછી પણ માન્ય રહે છે સિવાય કે ડાઉનલોડ એન્ડપૉઇન્ટ ફરી ચકાસે. લાંબા સમયના સેશનને પણ પુનર્મૂલ્યાંકનનો નિયમ જોઈએ, નહીંતર એક પ્રમાણિત વિનંતી કાયમી મુક્તિ બની જાય છે. ડિફૉલ્ટ નકાર એ જ એકમાત્ર સેટિંગ છે જે કર્મચારી બદલાવમાં ટકી રહે છે.

શેર કરેલી કેશ ચકાસણીની આસપાસનો બીજો માર્ગ છે. જે કેશમાં પહેલેથી સુરક્ષિત પ્રતિસાદ છે તે ઓરિજિનનો સંપર્ક કર્યા વિના તેને પરોસી શકે છે, તેથી એડમિન પ્રતિસાદને ખાનગી તરીકે ચિહ્નિત કરો અને તેમને શેર કરેલા સંગ્રહની બહાર રાખો. જો કેશે તેમને પરોસવા જ પડે, તો ઍક્સેસ ચકાસણી પરોસતા પહેલા ચાલવી જોઈએ, જેનો સામાન્ય અર્થ એ છે કે તે કોઈ પણ રીતે શેર કરેલી કેશ હોઈ શકે નહીં.

તમે હમણાં જ બંધ કરેલા બાયપાસ ચકાસો

સુખી માર્ગને નહીં, મેટ્રિક્સનો અભ્યાસ કરો: VPN દ્વારા એક એડમિન, તે જ એડમિન તેના વિના, બિન-એડમિન તેના દ્વારા, અને બનાવટી સરનામા હેડર. સીધી-ઓરિજિન વિનંતી અને કેશ કરેલા પ્રતિસાદની વિનંતી ઉમેરો, કારણ કે આ બે જ ફ્રન્ટએન્ડને સંપૂર્ણપણે છોડી દે છે.

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

દરેક વિનંતીએ નીતિ વચન આપે તે સ્થિતિ પરત કરવી જોઈએ, અને લોગમાં કયો સરનામા પુરાવો વપરાયો તે નોંધાવું જોઈએ. IPv6 અલગથી આવરો, કારણ કે ડ્યુઅલ-સ્ટેક ઓરિજિન તમે ચકાસ્યા તેના કરતાં અલગ સ્રોત કુટુંબ જોઈ શકે છે. સામાન્ય ગ્રાહક ઑપરેશન્સને VPNની બહાર કાર્યરત રાખો, નહીંતર ગ્રાહક પહેલી વાર ફરિયાદ કરે ત્યારે ફેરફાર પાછો ખેંચાઈ જશે. દરેક પંક્તિનું અપેક્ષિત પરિણામ ચલાવતા પહેલા લખો, જેથી આશ્ચર્યજનક પાસ દેખાય.

ઇગ્રેસ સરનામું મંજૂર નેટવર્ક માર્ગ સાબિત કરે છે, વ્યક્તિ કે સંચાલિત ઉપકરણ નહીં. તેને પ્રમાણીકરણ અને પરવાનગીની બાજુમાં એક શરત તરીકે રાખો, અને એડમિન વિસ્તાર આખા ઉત્પાદનને ફક્ત-VPN સેવામાં ફેરવ્યા વિના સાંકડો રહે છે. તે વિભાજન એ ડિઝાઇન છે, તેની મર્યાદા નથી.