કામચલાઉ IP પરવાનગી-યાદીની લિંક: પરવાનગી ખરેખર શું સ્વીકારે છે

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

નક્કી કરો કે પરવાનગી કયા પ્રશ્નનો જવાબ આપે છે

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

વપરાશકર્તા-કેન્દ્રિત એપ્લિકેશન માટે સરનામા-સ્વીકૃતિ પસંદ કરવાથી ખરી અધિકૃતિની સમસ્યા બીજે ખસી જાય છે, અને પછી પોર્ટલ એવા અંતર માટે દોષ વારસામાં મેળવે છે જે તેણે કદી બંધ કર્યું નહોતું.

સર્વર પર વિનંતી મર્યાદિત કરો

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

પછી ચકાસો કે પોર્ટલ અને સેવા એક જ સ્રોત જુએ છે. વિભાજિત ટનલિંગ, એક પ્રોક્સી હોપ અને IPv4 સામે IPv6 બે ગંતવ્યોને બે અલગ સરનામાં આપી શકે છે, તેથી એક માર્ગથી સક્રિય કરેલી પરવાનગી પછીની વિનંતીને આવરી ન પણ લે.

સ્થાપિત કરતાં પહેલાં પરવાનગી બતાવો

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

પુષ્ટિ સામાન્ય ક્રોસ-સાઇટ અને ઉદ્ગમ સંરક્ષણો સાથેની સ્થિતિ-બદલતી વિનંતી હોવી જોઈએ. ટોકન એકવાર વપરાય તેવું હોવું જોઈએ અને નિયમ સ્થાપિત થાય તે ક્ષણે જ પરમાણુ રીતે વપરાઈ જવું જોઈએ, અને રેકોર્ડમાં માલિક, સેવા, સરનામું, પરવાનગી ઓળખાંક અને સમાપ્તિ કાચું ટોકન કદી લોગ કર્યા વિના નોંધાવું જોઈએ.

ટોકનની પહોંચ નિયમ જેટલી જ કાળજી માગે છે. સમાપ્ત થયેલી કે પહેલેથી વપરાયેલી લિંક જે હજી નિયમ બનાવે છે તે એ જ ચાવીથી લગાવેલું બીજું દરવાજું છે.

પરવાનગી જીવંત હોય ત્યારે પણ સરનામું વહેંચાય છે

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

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

ચાર પ્રકરણો અને બંને સરનામા-કુટુંબોની કસોટી કરો

પરવાનગી એટલી જ સારી છે જેટલાં ચાર પ્રકરણો તે ઝીલે છે: નવી મંજૂર વિનંતી, બિનમંજૂર વિનંતીકર્તા, એ જ લિંકનું પુનરાવર્તન અને સમાપ્તિ પછીની એ જ વિનંતી.

પછી દરેક કુટુંબની અલગ કસોટી કરો, કારણ કે સેવા જે સ્રોત-સરનામું જુએ છે તે તેમની વચ્ચે અલગ હોઈ શકે છે.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

ઉપયોગી પરિણામ એ સામાન્ય વપરાશકર્તા-અધિકૃતિ હેઠળનો કામચલાઉ, ઓડિટપાત્ર સ્વીકૃતિ-નિર્ણય છે, પહેલું ક્લિક કરનારનું નામ ધરાવતું કાયમી દ્વાર નહીં.