Načrtovano opravilo ali človeška prijava: katero identiteto naj vidi API?

Načrtovano opravilo in oseba ob pozivu za prijavo kličeta isti API z različnimi poverilnicami, različno življenjsko dobo in različnimi lastniki. Opravilo potrebuje omrežno pot, identiteto aplikacije in nabor dovoljenj; oseba potrebuje prijavo, drugi dejavnik in sejo. Mešanje obojega ustvari avtomatizacijo, ki se zlomi vsakič, ko se spremeni geslo osebe, ali politiko več dejavnikov, oslabljeno ravno toliko, da opravilo cron ostane živo.

Tri vrata, ki izgledajo kot ena

Pravilo izvornega naslova vprašuje, od kod je prišla zahteva. Preverjanje pristnosti vprašuje, kdo kliče in kateri dokazi so bili predloženi. Pooblastitev vprašuje, ali sme ta subjekt izvesti to operacijo. VPN spremeni samo prvo od treh in jo spremeni za vsak proces na gostitelju, ne le za opravilo, zato tri opažanja v zapisu o incidentu držite ločeno.

Zato lahko zamenjava izhodnega vozlišča odpravi zavrnitev zaradi izvornega naslova in pusti neveljaven žeton nedotaknjen. Zato tudi veljaven žeton API ne naredi zasebne končne točke dosegljive iz opravila, ki do nje nima poti.

Interaktivna pot je slab vzorec za avtomatizacijo

Skriptiranje človeške prijave je vabljivo, ker deluje enkrat. Skript shrani geslo, morda seme enkratnega gesla, nato pa je odvisen od izziva, oblikovanega tako, da zahteva človeka. Najboljša veljavna varnostna praksa za OAuth, RFC 9700, prepoveduje dodelitev resource-owner-password-credentials in pojasnjuje, zakaj se slabo ujema z dvofaktorskim in večstopenjskim preverjanjem pristnosti.

Podprta alternativa je običajno tok zaupnega odjemalca, v katerem strežnik za pooblastitev preveri aplikacijo in izda žeton. Dodelitev client-credentials v RFC 6749, razdelek 4.4, je en primer. Njen obstoj ne pomeni, da jo vsak API sprejme, niti da je z njo mogoče nadomestiti opravilo, ki ga je pooblastil uporabnik, ker so to vprašanja za lastnika storitve. Vprašajte, kateri model brez nadzora storitev podpira, preden napišete kodo.

Kje VPN še vedno sodi

VPN lahko zagotovi omrežno pot, ki jo zahteva zasebni API, in to je legitimna vloga. Ne preverja opravila pred aplikacijo in ne določa, kaj sme opravilo početi. Skupni izhodni naslov tudi identificira gostitelja, ne opravila, zato vnos na seznamu dovoljenih za ta naslov spusti vsak proces, ki tam teče.

Če opravilo teče na skupnem izvajalniku, je ta razlika pomembnejša, ne manj pomembna. Drug potek dela na istem gostitelju podeduje pot in naslov, API pa ju ne more ločiti. To je ista slabost kot skupno geslo, prestavljena eno plast niže. Omejitev postavite tja, kjer jo aplikacija lahko uveljavi, in izolirajte izvajalnik, če seznama dovoljenih ne morete bolj zožiti.

Primerjajte oba načrta pošteno

Človeška prijava vam da resnično osebo, resnični drugi dejavnik in revidirljivo sejo, in ne more teči brez nadzora. Identiteta aplikacije vam da izvajanje brez nadzora, pregleden obseg in poverilnico, ki jo lahko zavrtite, in ne more delovati za uporabnika, ki ni ničesar pooblastil. Nobena ni šibkejša različica druge; odgovarjata na različni vprašanji. Izberite tako, da vprašate, ali mora opravilo teči brez nikogar navzočega in ali je treba operacijo pripisati določenemu uporabniku.

Če sta oba odgovora da, načrt potrebuje model pooblastitve, ne izposojeno geslo. To odločitev zapišite tja, kjer jo bo našel naslednji vzdrževalec.

Kaj preveriti pred predajo

Zaženite eno dovoljeno operacijo in eno obvezno zavrnitev iz dejanskega izvajalca in oba rezultata shranite. Nato preizkusite poteklo poverilnico in vedenje, ko omrežna pot ni na voljo, ker sta to dve napaki, ki ponoči koga prebudita.

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

Zapišite subjekt, obseg, lastnika rotacije in okolje izvajanja ob tem rezultatu. Prav ta zapis naredi naslednjo rotacijo rutino in ne incident. To je tudi del, ki ga zahteva revizor.