Punë e planifikuar apo hyrje njerëzore: cilën identitet duhet të shohë API?

Një punë e planifikuar dhe një person në kërkesën e hyrjes thërrasin të njëjtin API me kredenciale të ndryshme, jetëgjatësi të ndryshme dhe pronarë të ndryshëm. Punës i duhet një rrugë rrjeti, një identitet aplikacioni dhe një grup lejesh; personit i duhet një hyrje, një faktor i dytë dhe një sesion. Përzierja e të dyjave prodhon një automatizim që thyhet sa herë që ndryshon fjalëkalimi i personit, ose një politikë me shumë faktorë e dobësuar pikërisht sa duhet për të mbajtur gjallë një punë cron.

Tre porta që duken si një

Një rregull adrese burimi pyet nga ka ardhur kërkesa. Vërtetimi pyet kush po thërret dhe cilat prova u paraqitën. Autorizimi pyet nëse ky subjekt mund ta kryejë këtë operacion. Një VPN ndryshon vetëm të parën nga të treja, dhe e ndryshon për çdo proces në host dhe jo vetëm për punën, ndaj mbajini tre vëzhgimet të ndara në regjistrin e incidentit.

Kjo është arsyeja pse ndryshimi i nyjes së daljes mund të rregullojë një refuzim për shkak të adresës burimore dhe të lërë të paprekur një token të pavlefshëm. Kjo është edhe arsyeja pse një token API i vlefshëm nuk e bën një pikë fundore private të arritshme nga një punë që nuk ka rrugë drejt saj.

Rruga interaktive është një model i dobët automatizimi

Skriptimi i hyrjes së një personi është joshës sepse funksionon një herë. Skripti ruan një fjalëkalim, ndoshta një farë fjalëkalimi njëpërdorimshëm, dhe më pas varet nga një sfidë e krijuar për të kërkuar një njeri. Praktika më e mirë aktuale e sigurisë për OAuth, RFC 9700, ndalon dhënien resource-owner-password-credentials dhe shpjegon pse përshtatet keq me vërtetimin me dy faktorë dhe me shumë hapa.

Alternativa e mbështetur është zakonisht një rrjedhë klienti konfidencial në të cilën serveri i autorizimit vërteton aplikacionin dhe lëshon një token. Dhënia client-credentials në RFC 6749, seksioni 4.4, është një shembull. Ekzistenca e saj nuk do të thotë që çdo API e pranon, as që një detyrë e deleguar nga përdoruesi mund të zëvendësohet me të, sepse ato janë pyetje për pronarin e shërbimit. Pyetni cilin model pa mbikëqyrje mbështet shërbimi përpara se të shkruani kod.

Ku VPN ende ka vend

Një VPN mund të sigurojë rrugën e rrjetit që kërkon një API privat, dhe ky është një rol legjitim. Nuk e vërteton punën tek aplikacioni dhe nuk e kufizon atë që puna mund të bëjë. Një adresë daljeje e përbashkët identifikon gjithashtu hostin dhe jo punën, ndaj një zë në listën e lejuar për atë adresë pranon çdo proces që funksionon mbi të.

Nëse puna funksionon në një ekzekutues të përbashkët, ai dallim ka më shumë rëndësi, jo më pak. Një rrjedhë tjetër pune në të njëjtin host trashëgon rrugën dhe adresën, dhe API nuk mund t'i dallojë të dyja. Është e njëjta dobësi si një fjalëkalim i përbashkët, e zhvendosur një shtresë më poshtë. Vendoseni kufizimin atje ku aplikacioni mund ta zbatojë, dhe izoloni ekzekutuesin nëse nuk mund ta ngushtoni listën e lejuar.

Krahasoni të dyja projektet me ndershmëri

Një hyrje njerëzore ju jep një person të vërtetë, një faktor të dytë të vërtetë dhe një sesion të auditueshëm, dhe nuk mund të funksionojë pa mbikëqyrje. Një identitet aplikacioni ju jep ekzekutim pa mbikëqyrje, një fushë të verifikueshme dhe një kredencial që mund ta rrotulloni, dhe nuk mund të veprojë për një përdorues që nuk ka deleguar asgjë. Asnjëra nuk është version më i dobët i tjetrës; përgjigjen pyetjeve të ndryshme. Zgjidhni duke pyetur nëse detyra duhet të funksionojë pa askënd të pranishëm dhe nëse operacioni duhet t'i atribuohet një përdoruesi të caktuar.

Nëse të dyja përgjigjet janë po, projekti ka nevojë për një model delegimi dhe jo për një fjalëkalim të huazuar. Shkruajeni atë vendim atje ku do ta gjejë mirëmbajtësi i ardhshëm.

Çfarë duhet verifikuar përpara dorëzimit

Kryeni një operacion të lejuar dhe një refuzim të detyrueshëm nga punëtori real, dhe ruani të dyja rezultatet. Më pas provoni një kredencial të skaduar dhe sjelljen kur rruga e rrjetit nuk është e disponueshme, sepse ato janë dy dështimet që zgjojnë dikë natën.

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

Shënoni subjektin, fushën, pronarin e rrotullimit dhe mjedisin e ekzekutimit pranë atij rezultati. Ai regjistrim është ai që e bën rrotullimin e radhës rutinë dhe jo incident. Është gjithashtu pjesa që kërkon një auditues.