Planlagt jobb eller menneskelig innlogging: hvilken identitet skal API-et se?

En planlagt jobb og en person ved en innloggingsforespørsel kaller det samme API-et med ulike legitimasjoner, ulik levetid og ulike eiere. Jobben trenger en nettverkssti, en applikasjonsidentitet og et sett med tillatelser; personen trenger en innlogging, en andre faktor og en økt. Å blande de to gir automatisering som bryter hver gang personens passord endres, eller en multifaktorpolicy svekket akkurat nok til å holde en cron-jobb i live.

Tre porter som ser ut som én

En kildeadresseregel spør hvor forespørselen kom fra. Autentisering spør hvem som ringer og hvilke bevis som ble lagt fram. Autorisasjon spør om denne prinsipalen kan utføre denne operasjonen. En VPN endrer bare den første av de tre, og den endrer den for hver prosess på verten og ikke bare for jobben, så hold de tre observasjonene atskilt i hendelsesrapporten.

Det er derfor et bytte av utgangsnode kan rette en avvisning på kildeadressen og la et ugyldig token være urørt. Det er også derfor et gyldig API-token ikke gjør et privat endepunkt tilgjengelig fra en jobb som ikke har rute dit.

Den interaktive veien er en dårlig mal for automatisering

Å skripte en persons innlogging er fristende fordi det virker én gang. Skriptet lagrer et passord, kanskje et engangspassordfrø, og avhenger deretter av en utfordring som er laget for å kreve et menneske. OAuths beste gjeldende sikkerhetspraksis, RFC 9700, forbyr resource-owner-password-credentials-tildelingen og forklarer hvorfor den passer dårlig til tofaktor- og flertrinnsautentisering.

Det støttede alternativet er vanligvis en fortrolig klientflyt der autorisasjonsserveren autentiserer applikasjonen og utsteder et token. Client-credentials-tildelingen i RFC 6749 avsnitt 4.4 er ett eksempel. At den finnes betyr ikke at hvert API godtar den, eller at en brukerdelegert oppgave kan erstattes av den, for det er spørsmål til tjenesteeieren. Spør hvilken uovervåket modell tjenesten støtter før du skriver kode.

Hvor VPN fortsatt hører hjemme

En VPN kan levere nettverksstien et privat API krever, og det er en legitim rolle. Den autentiserer ikke jobben overfor applikasjonen, og den avgrenser ikke hva jobben kan gjøre. En delt utgangsadresse identifiserer også verten og ikke jobben, så en tillatelseslistepost for den adressen slipper inn hver prosess som kjører på den.

Hvis jobben kjører på en delt runner, er den forskjellen viktigere snarere enn mindre viktig. En annen arbeidsflyt på samme vert arver ruten og adressen, og API-et kan ikke skille de to. Det er samme svakhet som et delt passord, flyttet ett lag ned. Sett begrensningen der applikasjonen kan håndheve den, og isoler runneren hvis du ikke kan gjøre tillatelseslisten strammere.

Sammenlign de to designene ærlig

En menneskelig innlogging gir deg en ekte person, en ekte andre faktor og en økt som kan revideres, og den kan ikke kjøre uovervåket. En applikasjonsidentitet gir deg uovervåket kjøring, et gjennomgåelig omfang og en legitimasjon du kan rotere, og den kan ikke handle for en bruker som ikke har delegert noe. Ingen av dem er en svakere versjon av den andre; de svarer på ulike spørsmål. Velg ved å spørre om oppgaven må kjøre uten noen til stede, og om operasjonen må tilskrives en bestemt bruker.

Hvis begge svarene er ja, trenger designet en delegeringsmodell i stedet for et lånt passord. Skriv den beslutningen ned der neste vedlikeholder finner den.

Hva som må verifiseres før overlevering

Kjør én tillatt operasjon og én påkrevd avvisning fra den faktiske workeren, og ta vare på begge resultatene. Test deretter en utløpt legitimasjon og oppførselen når nettverksstien ikke er tilgjengelig, for det er de to feilene som vekker noen om natten.

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

Noter prinsipalen, omfanget, rotasjonseieren og kjøremiljøet ved siden av det resultatet. Den registreringen er det som gjør den neste rotasjonen rutinemessig i stedet for en hendelse. Det er også den delen en revisor spør etter.