Ajastatud töö või inimene sisselogimisel: millist identiteeti peaks API nägema?

Ajastatud töö ja sisselogimiseviiba ees seisev inimene kutsuvad sama API-t erinevate volitustega, erineva eluea ja erinevate omanikega. Töö vajab võrguteed, rakenduse identiteeti ja õiguste kogumit; inimene vajab sisselogimist, teist faktorit ja sessiooni. Kahe segamine toodab automatiseerimise, mis läheb katki iga kord, kui inimese parool muutub, või mitmefaktorilise poliitika, mida on nõrgendatud täpselt nii palju, et cron-töö püsiks elus.

Kolm väravat, mis näevad välja nagu üks

Lähteraadressi reegel küsib, kust päring tuli. Autentimine küsib, kes helistab ja millised tõendid esitati. Autoriseerimine küsib, kas see subjekt tohib seda toimingut teha. VPN muudab ainult esimest kolmest ja muudab seda hosti iga protsessi jaoks, mitte ainult töö jaoks, seepärast hoidke kolm vaatlust intsidendi kirjes eraldi.

Seepärast võib väljumissõlme vahetamine parandada lähteraadressi tõttu tekkinud keeldumise ja jätta kehtetu loa puutumata. Seepärast ei tee kehtiv API-luba privaatset lõpp-punkti kättesaadavaks tööst, millel pole sinna marsruuti.

Interaktiivne tee on halb automatiseerimise mall

Inimese sisselogimise skriptimine on ahvatlev, sest see töötab korra. Skript salvestab parooli, võib-olla ühekordse parooli seemne, ja sõltub seejärel väljakutsest, mis on mõeldud inimest nõudma. OAuthi praegune parim turvapraktika, RFC 9700, keelab resource-owner-password-credentials-i loa ja selgitab, miks see sobib halvasti kahefaktorilise ja mitmeastmelise autentimisega.

Toetatud alternatiiv on tavaliselt konfidentsiaalse kliendi voog, kus autoriseerimisserver autendib rakenduse ja väljastab loa. RFC 6749 jaotise 4.4 client-credentials-i luba on üks näide. Selle olemasolu ei tähenda, et iga API selle vastu võtab, ega seda, et kasutaja delegeeritud ülesande saaks sellega asendada, sest need on küsimused teenuse omanikule. Küsige, millist järelevalveta mudelit teenus toetab, enne kui koodi kirjutate.

Kuhu VPN ikka kuulub

VPN võib pakkuda võrguteed, mida privaatne API nõuab, ja see on legitiimne roll. See ei autendi tööd rakenduse ees ega piira, mida töö tohib teha. Jagatud väljundadress identifitseerib ka hosti, mitte tööd, seega lubatud loendisse kantud kirje selle aadressi kohta laseb sisse iga protsessi, mis sellel töötab.

Kui töö jookseb jagatud jooksutajal, on see erinevus pigem olulisem kui vähem oluline. Teine töövoog samal hostil pärib marsruudi ja aadressi ning API ei suuda neid kahte eristada. See on sama nõrkus nagu jagatud parool, ühe kihi võrra allapoole viidud. Pange piirang sinna, kus rakendus saab seda jõustada, ja isoleerige jooksutaja, kui te ei saa lubatud loendit kitsamaks teha.

Võrrelge kahte kavandit ausalt

Inimese sisselogimine annab teile tõelise inimese, tõelise teise faktori ja auditeeritava sessiooni ning ei saa töötada järelevalveta. Rakenduse identiteet annab teile järelevalveta täitmise, ülevaatatava ulatuse ja volituse, mida saate pöörata, ning ei saa tegutseda kasutaja eest, kes pole midagi delegeerinud. Kumbki pole teise nõrgem versioon; nad vastavad erinevatele küsimustele. Valige, küsides, kas ülesanne peab jooksma ilma kellegi kohaloluta ja kas toiming tuleb omistada kindlale kasutajale.

Kui mõlemad vastused on jah, vajab kavand delegeerimismudelit, mitte laenatud parooli. Kirjutage see otsus sinna, kus järgmine hooldaja selle leiab.

Mida enne üleandmist kontrollida

Käivitage üks lubatud toiming ja üks nõutav keeldumine tegelikust töötajast ning hoidke mõlemad tulemused alles. Seejärel testige aegunud volitust ja käitumist, kui võrgutee pole saadaval, sest need on kaks riket, mis kedagi öösel äratavad.

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

Kirjutage subjekt, ulatus, pööramise omanik ja täitmiskeskkond selle tulemuse kõrvale. Just see kirje teeb järgmise pööramise rutiiniks, mitte intsidendiks. See on ka osa, mida audiitor küsib.