નિર્ધારિત કામ કે માનવ લોગિન: API ને કઈ ઓળખ જોવી જોઈએ?

એક નિર્ધારિત કામ અને લોગિન પ્રોમ્પ્ટ પર ઊભેલી વ્યક્તિ એક જ API ને અલગ ક્રેડેન્શિયલ, અલગ જીવનકાળ અને અલગ માલિકો સાથે બોલાવે છે. કામને નેટવર્ક પાથ, એપ્લિકેશન ઓળખ અને પરવાનગીઓનો સમૂહ જોઈએ; વ્યક્તિને લોગિન, બીજું પરિબળ અને સેશન જોઈએ. બંનેને ભેગા કરવાથી એવું ઓટોમેશન બને છે જે વ્યક્તિનો પાસવર્ડ બદલાય ત્યારે તૂટી પડે છે, અથવા cron કામ જીવતું રાખવા પૂરતું નબળું કરેલું બહુ-પરિબળ નીતિ બને છે.

એક જેવા દેખાતા ત્રણ દરવાજા

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

એટલે કે એગ્રેસ નોડ બદલવાથી સ્રોત-સરનામાનું નકાર સુધરી શકે છે અને અમાન્ય ટોકન અસ્પૃશ્ય રહી શકે છે. એટલે જ માન્ય API ટોકન પણ એવા કામથી ખાનગી એન્ડપોઇન્ટ સુધી પહોંચી શકાય એવું બનાવતું નથી જેની ત્યાં કોઈ રૂટ નથી.

ઇન્ટરેક્ટિવ પાથ ઓટોમેશન માટે ખરાબ ટેમ્પલેટ છે

વ્યક્તિના લોગિનને સ્ક્રિપ્ટ કરવું લલચાવનારું છે કારણ કે તે એક વાર કામ કરે છે. સ્ક્રિપ્ટ પાસવર્ડ, કદાચ એક-વારના પાસવર્ડનું બીજ સંગ્રહે છે, અને પછી એવા પડકાર પર નિર્ભર રહે છે જે માનવ જરૂરી હોવાની રીતે રચાયેલો છે. OAuth માટેની હાલની શ્રેષ્ઠ સુરક્ષા પદ્ધતિ, RFC 9700, resource-owner-password-credentials અનુદાનને પ્રતિબંધિત કરે છે અને સમજાવે છે કે તે બે-પરિબળ અને બહુ-પગલાં પ્રમાણીકરણ સાથે ખરાબ રીતે કેમ બંધ બેસે છે.

સમર્થિત વિકલ્પ સામાન્ય રીતે ગુપ્ત-ક્લાયંટ પ્રવાહ છે જેમાં અધિકૃતિ સર્વર એપ્લિકેશનને પ્રમાણિત કરે છે અને ટોકન આપે છે. RFC 6749 ના વિભાગ 4.4 માંનું client-credentials અનુદાન એક ઉદાહરણ છે. તેનું અસ્તિત્વ એનો અર્થ નથી કે દરેક API તેને સ્વીકારે છે, અથવા વપરાશકર્તાએ ડેલિગેટ કરેલું કાર્ય તેનાથી બદલી શકાય છે, કારણ કે એ સેવાના માલિક માટેના પ્રશ્નો છે. કોડ લખતા પહેલાં પૂછો કે સેવા કયું બિન-દેખરેખ મોડેલ સમર્થન આપે છે.

VPN હજી ક્યાં બંધ બેસે છે

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

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

બંને ડિઝાઇનની પ્રામાણિકતાથી સરખામણી કરો

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

જો બંને જવાબ હા હોય, તો ડિઝાઇનને ઉછીનાવાળા પાસવર્ડને બદલે ડેલિગેશન મોડેલની જરૂર છે. તે નિર્ણય ત્યાં લખો જ્યાં આગલો સંભાળનાર તેને શોધી શકે.

હસ્તાંતરણ પહેલાં શું ચકાસવું

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

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

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