Planlagt job eller menneskeligt login: hvilken identitet skal API’et se?

Et planlagt job og en person ved en loginprompt kalder det samme API med forskellige legitimationsoplysninger, forskellige levetider og forskellige ejere. Jobbet har brug for en netværkssti, en applikationsidentitet og et sæt tilladelser; personen har brug for et login, en anden faktor og en session. At blande de to giver automatisering, der går i stykker, hver gang personens adgangskode ændres, eller en multifaktorpolitik svækket lige nok til at holde et cron-job i live.

Tre porte, der ligner én

En kildeadresseregel spørger, hvor anmodningen kom fra. Godkendelse spørger, hvem der ringer, og hvilke beviser der blev fremlagt. Autorisation spørger, om denne principal må udføre denne handling. En VPN ændrer kun den første af de tre, og den ændrer den for hver proces på værten og ikke kun for jobbet, så hold de tre observationer adskilt i hændelsesrapporten.

Det er derfor, at et skift af udgangsknuden kan rette en afvisning på kildeadressen og lade et ugyldigt token være urørt. Det er også derfor, at et gyldigt API-token ikke gør et privat endepunkt tilgængeligt fra et job uden rute dertil.

Den interaktive vej er en dårlig skabelon til automatisering

At skripte en persons login er fristende, fordi det virker én gang. Scriptet gemmer en adgangskode, måske et engangskodefrø, og afhænger derefter af en udfordring, der er designet til at kræve et menneske. OAuths bedste nuværende sikkerhedspraksis, RFC 9700, forbyder resource-owner-password-credentials-grantet og forklarer, hvorfor det passer dårligt til to-faktor- og flertrinsgodkendelse.

Det understøttede alternativ er normalt et fortroligt klientflow, hvor autorisationsserveren godkender applikationen og udsteder et token. Client-credentials-grantet i RFC 6749 afsnit 4.4 er et eksempel. At det findes, betyder ikke, at hvert API accepterer det, eller at en brugerdelegeret opgave kan erstattes af det, for det er spørgsmål til tjenesteejeren. Spørg, hvilken uovervåget model tjenesten understøtter, før du skriver kode.

Hvor VPN stadig hører til

En VPN kan levere den netværkssti, et privat API kræver, og det er en legitim rolle. Den godkender ikke jobbet over for applikationen og afgrænser ikke, hvad jobbet må gøre. En delt udgangsadresse identificerer også værten og ikke jobbet, så en tilladelseslistepost for den adresse lukker hver proces ind, der kører på den.

Hvis jobbet kører på en delt runner, er den forskel vigtigere snarere end mindre vigtig. En anden arbejdsgang på samme vært arver ruten og adressen, og API’et kan ikke skelne de to. Det er den samme svaghed som en delt adgangskode, flyttet et lag ned. Sæt begrænsningen, hvor applikationen kan håndhæve den, og isoler runneren, hvis du ikke kan gøre tilladelseslisten strammere.

Sammenlign de to design ærligt

Et menneskeligt login giver dig en rigtig person, en rigtig anden faktor og en reviderbar session, og det kan ikke køre uovervåget. En applikationsidentitet giver dig uovervåget udførelse, et gennemskueligt omfang og en legitimationsoplysning, du kan rotere, og den kan ikke handle for en bruger, der ikke har delegeret noget. Ingen af dem er en svagere version af den anden; de besvarer forskellige spørgsmål. Vælg ved at spørge, om opgaven skal køre uden nogen til stede, og om handlingen skal tilskrives en bestemt bruger.

Hvis begge svar er ja, har designet brug for en delegeringsmodel frem for en lånt adgangskode. Skriv den beslutning ned, hvor den næste vedligeholder finder den.

Hvad der skal verificeres før overdragelsen

Kør én tilladt handling og én påkrævet afvisning fra den faktiske worker, og gem begge resultater. Test derefter en udløbet legitimationsoplysning og adfærden, når netværksstien ikke er tilgængelig, for det er de to fejl, der vækker nogen om natten.

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

Notér principalen, omfanget, rotationsejeren og kørselsmiljøet ved siden af det resultat. Den registrering er det, der gør den næste rotation rutinemæssig i stedet for en hændelse. Det er også den del, en revisor spørger efter.