Zakazani posao ili ljudska prijava: koji identitet API treba da vidi?

Zakazani posao i osoba pred ekranom za prijavu pozivaju isti API s različitim vjerodajnicama, različitim trajanjem i različitim vlasnicima. Poslu treba mrežni put, identitet aplikacije i skup dozvola; osobi treba prijava, drugi faktor i sesija. Miješanje to dvoje stvara automatizaciju koja se kvari kad god se promijeni lozinka osobe, ili politiku više faktora oslabljenu taman toliko da cron posao ostane živ.

Tri kapije koje izgledaju kao jedna

Pravilo izvorišne adrese pita odakle je zahtjev došao. Autentifikacija pita ko zove i koji su dokazi predstavljeni. Autorizacija pita smije li ovaj subjekt izvršiti ovu operaciju. VPN mijenja samo prvu od tri i mijenja je za svaki proces na hostu, a ne samo za posao, zato tri zapažanja držite odvojeno u zapisu o incidentu.

Zato promjena izlaznog čvora može popraviti odbijanje zbog izvorišne adrese i ostaviti nevažeći token netaknut. Zato i važeći API token ne čini privatnu krajnju tačku dostupnom iz posla koji do nje nema rutu.

Interaktivni put je loš šablon za automatizaciju

Skriptiranje ljudske prijave je primamljivo jer radi jednom. Skripta čuva lozinku, možda i sjeme jednokratne lozinke, a zatim zavisi od izazova osmišljenog da zahtijeva čovjeka. Najbolja trenutna sigurnosna praksa za OAuth, RFC 9700, zabranjuje dodjelu resource-owner-password-credentials i objašnjava zašto se loše uklapa u dvofaktorsku i višekoračnu autentifikaciju.

Podržana alternativa obično je tok povjerljivog klijenta u kojem server za autorizaciju autentifikuje aplikaciju i izdaje token. Dodjela client-credentials iz RFC 6749, odjeljak 4.4, jedan je primjer. Njeno postojanje ne znači da je svaki API prihvata, ni da se zadatak delegiran od korisnika njome može zamijeniti, jer su to pitanja za vlasnika usluge. Pitajte koji model bez nadzora usluga podržava prije nego što napišete kod.

Gdje VPN još ima mjesto

VPN može osigurati mrežni put koji privatni API zahtijeva, i to je legitimna uloga. On ne autentifikuje posao pred aplikacijom i ne određuje obim onoga što posao smije raditi. Dijeljena izlazna adresa takođe identifikuje host, a ne posao, pa unos na listi dozvoljenih za tu adresu propušta svaki proces koji na njoj radi.

Ako posao radi na dijeljenom runneru, ta razlika je važnija, a ne manje važna. Drugi tok rada na istom hostu nasljeđuje rutu i adresu, a API ne može razlikovati njih dvoje. To je ista slabost kao dijeljena lozinka, pomjerena jedan sloj niže. Stavite ograničenje tamo gdje ga aplikacija može provesti i izolujte runner ako listu dozvoljenih ne možete suziti.

Uporedite dva dizajna iskreno

Ljudska prijava daje vam stvarnu osobu, stvarni drugi faktor i sesiju koja se može revidirati, ali ne može raditi bez nadzora. Identitet aplikacije daje vam izvršavanje bez nadzora, obim koji se može pregledati i vjerodajnicu koju možete rotirati, ali ne može djelovati za korisnika koji ništa nije delegirao. Nijedno nije slabija verzija drugog; ona odgovaraju na različita pitanja. Birajte pitajući mora li zadatak raditi bez ikoga prisutnog i mora li se operacija pripisati određenom korisniku.

Ako su oba odgovora da, dizajnu treba model delegiranja, a ne posuđena lozinka. Zapišite tu odluku gdje će je naći sljedeći održavalac.

Šta provjeriti prije predaje

Pokrenite jednu dozvoljenu operaciju i jedno obavezno odbijanje sa stvarnog runnera i sačuvajte oba rezultata. Zatim testirajte isteklu vjerodajnicu i ponašanje kad mrežni put nije dostupan, jer su to dva kvara koja nekoga bude noću.

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

Zapišite subjekt, obim, vlasnika rotacije i okruženje izvršavanja uz taj rezultat. Taj zapis čini sljedeću rotaciju rutinom, a ne incidentom. To je i dio koji traži revizor.