Պլանավորված աշխատանք, թե՞ մարդու մուտք. ո՞ր ինքնությունը պետք է տեսնի API-ն

Պլանավորված աշխատանքը և մուտքի հուշումի մոտ կանգնած մարդը կանչում են նույն API-ն տարբեր հավատարմագրերով, տարբեր կյանքի տևողությամբ և տարբեր սեփականատերերով։ Աշխատանքին պետք է ցանցային ուղի, հավելվածի ինքնություն և թույլտվությունների հավաքածու. մարդուն պետք է մուտք, երկրորդ գործոն և սեսիա։ Երկուսը խառնելը ստեղծում է ավտոմատացում, որը կոտրվում է ամեն անգամ, երբ փոխվում է մարդու գաղտնաբառը, կամ բազմագործոն քաղաքականություն, որը թուլացվել է այնքան, որ cron աշխատանքը կենդանի մնա։

Երեք դարպաս, որոնք նման են մեկին

Աղբյուրի հասցեի կանոնը հարցնում է՝ որտեղից է եկել հարցումը։ Նույնականացումը հարցնում է՝ ով է զանգում և ինչ ապացույցներ են ներկայացվել։ Լիազորումը հարցնում է՝ կարո՞ղ է այս սուբյեկտը կատարել այս գործողությունը։ VPN-ն փոխում է միայն երեքից առաջինը, և փոխում է այն հոսթի յուրաքանչյուր պրոցեսի համար, ոչ միայն աշխատանքի, ուստի միջադեպի արձանագրության մեջ երեք դիտարկումները պահեք առանձին։

Այդ պատճառով ելքի հանգույցը փոխելը կարող է ուղղել աղբյուրի հասցեի պատճառով մերժումը և անվավեր թոքենը թողնել անձեռնմխելի։ Այդ պատճառով էլ վավեր API թոքենը մասնավոր վերջնակետը հասանելի չի դարձնում այն աշխատանքից, որն այնտեղ ուղի չունի։

Ինտերակտիվ ուղին վատ ձևանմուշ է ավտոմատացման համար

Մարդու մուտքը սկրիպտավորելը գրավիչ է, որովհետև այն մեկ անգամ աշխատում է։ Սկրիպտը պահում է գաղտնաբառ, գուցե մեկանգամյա գաղտնաբառի սերմ, ապա կախված է մարտահրավերից, որը նախագծված է մարդ պահանջելու համար։ OAuth-ի անվտանգության ներկա լավագույն պրակտիկան՝ RFC 9700, արգելում է resource-owner-password-credentials շնորհումը և բացատրում, թե ինչու այն վատ է համապատասխանում երկգործոն և բազմաքայլ նույնականացմանը։

Աջակցվող այլընտրանքը սովորաբար գաղտնի հաճախորդի հոսք է, որտեղ լիազորող սերվերը նույնականացնում է հավելվածը և թողարկում թոքեն։ RFC 6749-ի 4.4 բաժնի client-credentials շնորհումը դրա օրինակներից մեկն է։ Դրա գոյությունը չի նշանակում, որ ամեն API ընդունում է այն, կամ որ օգտատիրոջ կողմից վերապահված առաջադրանքը կարելի է փոխարինել դրանով, քանի որ դրանք հարցեր են ծառայության սեփականատիրոջը։ Հարցրեք, թե ինչ չհսկվող մոդել է աջակցում ծառայությունը, նախքան կոդ գրելը։

Որտեղ է VPN-ը դեռ տեղին

VPN-ը կարող է ապահովել ցանցային ուղին, որը պահանջում է մասնավոր API-ն, և դա օրինական դեր է։ Այն չի նույնականացնում աշխատանքը հավելվածի առջև և չի սահմանափակում, թե ինչ կարող է անել աշխատանքը։ Համօգտագործվող ելքի հասցեն նույնպես նույնականացնում է հոսթը, ոչ թե աշխատանքը, ուստի այդ հասցեի թույլատրելի ցանկի գրառումը թույլ է տալիս դրա վրա աշխատող յուրաքանչյուր պրոցեսի։

Եթե աշխատանքը գործում է համօգտագործվող runner-ում, այդ տարբերությունը ավելի շուտ կարևոր է, քան պակաս կարևոր։ Նույն հոսթի մեկ այլ աշխատահոսք ժառանգում է ուղին և հասցեն, և API-ն չի կարող տարբերել երկուսին։ Սա նույն թուլությունն է, ինչ համօգտագործվող գաղտնաբառը՝ մեկ շերտ ներքև տեղափոխված։ Սահմանափակումը դրեք այնտեղ, որտեղ հավելվածը կարող է պարտադրել այն, և մեկուսացրեք runner-ը, եթե չեք կարող ավելի նեղացնել թույլատրելի ցանկը։

Համեմատեք երկու նախագծերը ազնվորեն

Մարդու մուտքը ձեզ տալիս է իրական մարդ, իրական երկրորդ գործոն և ստուգելի սեսիա, և այն չի կարող աշխատել առանց հսկողության։ Հավելվածի ինքնությունը ձեզ տալիս է առանց հսկողության կատարում, վերանայելի շրջանակ և պտտվող հավատարմագիր, և այն չի կարող գործել այն օգտատիրոջ փոխարեն, ով ոչինչ չի վերապահել։ Ոչ մեկը մյուսի ավելի թույլ տարբերակը չէ. նրանք պատասխանում են տարբեր հարցերի։ Ընտրեք՝ հարցնելով, թե արդյոք առաջադրանքը պետք է գործի առանց որևէ մեկի ներկայության, և արդյոք գործողությունը պետք է վերագրվի կոնկրետ օգտատիրոջ։

Եթե երկու պատասխաններն էլ այո են, նախագծին պետք է վերապահման մոդել, այլ ոչ փոխառված գաղտնաբառ։ Գրեք այդ որոշումը այնտեղ, որտեղ կգտնի այն հաջորդ սպասարկողը։

Ինչ ստուգել հանձնելուց առաջ

Կատարեք մեկ թույլատրված գործողություն և մեկ պարտադիր մերժում իրական աշխատողից, և պահեք երկու արդյունքները։ Այնուհետև փորձարկեք ժամկետանց հավատարմագիրը և վարքը, երբ ցանցային ուղին հասանելի չէ, քանի որ դրանք այն երկու խափանումներն են, որոնք գիշերը արթնացնում են ինչ-որ մեկին։

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

Գրանցեք սուբյեկտը, շրջանակը, պտտման սեփականատերը և կատարման միջավայրը այդ արդյունքի կողքին։ Այդ գրառումն է, որ հաջորդ պտտումը դարձնում է առօրյա, ոչ միջադեպ։ Դա նաև այն մասն է, որ խնդրում է աուդիտորը։