Schemalagd uppgift eller mänsklig inloggning: vilken identitet ska API:et se?

En schemalagd uppgift och en person vid en inloggningsprompt anropar samma API med olika autentiseringsuppgifter, olika livslängd och olika ägare. Uppgiften behöver en nätverksväg, en applikationsidentitet och en uppsättning behörigheter; personen behöver en inloggning, en andra faktor och en session. Att blanda de två ger automatisering som går sönder varje gång personens lösenord ändras, eller en multifaktorpolicy försvagad precis lagom för att hålla en cron-uppgift vid liv.

Tre portar som ser ut som en

En källadressregel frågar var förfrågan kom ifrån. Autentiseringen frågar vem som ringer och vilka bevis som lades fram. Auktoriseringen frågar om denna principal får utföra denna operation. En VPN ändrar bara den första av de tre, och den ändrar den för varje process på värden och inte bara för uppgiften, så håll de tre observationerna åtskilda i incidentrapporten.

Det är därför ett byte av utgångsnod kan åtgärda en avvisning på källadressen och lämna en ogiltig token orörd. Det är också därför en giltig API-token inte gör en privat slutpunkt nåbar från en uppgift som saknar väg dit.

Den interaktiva vägen är en dålig mall för automatisering

Att skripta en persons inloggning är frestande eftersom det fungerar en gång. Skriptet lagrar ett lösenord, kanske ett engångslösenordsfrö, och beror sedan på en utmaning som är utformad att kräva en människa. OAuth:s bästa nuvarande säkerhetspraxis, RFC 9700, förbjuder resource-owner-password-credentials-bidraget och förklarar varför det passar dåligt med tvåfaktors- och flerstegetsautentisering.

Det stödda alternativet är vanligtvis ett flöde för konfidentiell klient där auktoriseringsservern autentiserar applikationen och utfärdar en token. Client-credentials-bidraget i RFC 6749 avsnitt 4.4 är ett exempel. Att det finns betyder inte att varje API accepterar det, eller att en användardelegerad uppgift kan ersättas av det, för det är frågor till tjänstens ägare. Fråga vilken oövervakad modell tjänsten stöder innan du skriver kod.

Där VPN fortfarande hör hemma

En VPN kan tillhandahålla den nätverksväg ett privat API kräver, och det är en legitim roll. Den autentiserar inte uppgiften mot applikationen och avgränsar inte vad uppgiften får göra. En delad utgångsadress identifierar också värden och inte uppgiften, så en post i tillåtelselistan för den adressen släpper in varje process som kör på den.

Om uppgiften körs på en delad runner är den skillnaden viktigare snarare än mindre viktig. Ett annat arbetsflöde på samma värd ärver vägen och adressen, och API:et kan inte skilja de två. Det är samma svaghet som ett delat lösenord, flyttad ett lager ned. Sätt begränsningen där applikationen kan upprätthålla den, och isolera runnern om du inte kan göra tillåtelselistan snävare.

Jämför de två designerna ärligt

En mänsklig inloggning ger dig en riktig person, en riktig andra faktor och en granskningsbar session, och den kan inte köras oövervakad. En applikationsidentitet ger dig oövervakad körning, en granskningsbar omfattning och en autentiseringsuppgift du kan rotera, och den kan inte agera för en användare som inte har delegerat något. Ingen av dem är en svagare version av den andra; de svarar på olika frågor. Välj genom att fråga om uppgiften måste köras utan någon närvarande, och om operationen måste tillskrivas en viss användare.

Om båda svaren är ja behöver designen en delegeringsmodell i stället för ett lånat lösenord. Skriv ned det beslutet där nästa underhållare hittar det.

Vad som ska verifieras före överlämningen

Kör en tillåten operation och en obligatorisk avvisning från den faktiska workern, och spara båda resultaten. Testa sedan en utgången autentiseringsuppgift och beteendet när nätverksvägen inte är tillgänglig, för det är de två fel som väcker någon på natten.

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

Notera principalen, omfattningen, rotationsägaren och körningsmiljön bredvid det resultatet. Den anteckningen är det som gör nästa rotation rutinmässig i stället för en incident. Det är också den del en revisor frågar efter.