Geplande taak of menselijke login: welke identiteit moet de API zien?

Een geplande taak en een persoon bij een loginprompt roepen dezelfde API aan met andere inloggegevens, een andere levensduur en andere eigenaren. De taak heeft een netwerkpad, een applicatie-identiteit en een set rechten nodig; de persoon heeft een login, een tweede factor en een sessie nodig. De twee mengen levert automatisering op die breekt zodra het wachtwoord van de persoon verandert, of een multifactorbeleid dat net ver genoeg is verzwakt om een cron-taak in leven te houden.

Drie poorten die op één lijken

Een bronadresregel vraagt waar het verzoek vandaan kwam. Authenticatie vraagt wie er belt en welke bewijzen zijn gepresenteerd. Autorisatie vraagt of deze principal deze bewerking mag uitvoeren. Een VPN verandert alleen de eerste van de drie, en wel voor elk proces op de host en niet alleen voor de taak, dus houd de drie observaties gescheiden in het incidentverslag.

Daarom kan het wisselen van het uitgangsknooppunt een afwijzing op bronadres verhelpen en een ongeldig token ongemoeid laten. Daarom maakt een geldig API-token een privé-eindpunt ook niet bereikbaar vanuit een taak die er geen route naartoe heeft.

Het interactieve pad is een slecht automatiseringssjabloon

Het scripten van iemands login is verleidelijk omdat het één keer werkt. Het script bewaart een wachtwoord, misschien een eenmalige-wachtwoordseed, en is daarna afhankelijk van een uitdaging die ontworpen is om een mens te vereisen. De huidige best practice voor OAuth-beveiliging, RFC 9700, verbiedt de resource-owner-password-credentials-grant en legt uit waarom die slecht past bij tweefactor- en meertrapsauthenticatie.

Het ondersteunde alternatief is meestal een vertrouwelijke-clientflow waarin de autorisatieserver de applicatie authenticeert en een token uitgeeft. De client-credentials-grant in RFC 6749 sectie 4.4 is daar een voorbeeld van. Dat die bestaat betekent niet dat elke API hem accepteert, of dat een door de gebruiker gedelegeerde taak erdoor vervangen kan worden, want dat zijn vragen voor de diensteigenaar. Vraag welk onbeheerd model de dienst ondersteunt voordat u code schrijft.

Waar de VPN nog thuishoort

Een VPN kan het netwerkpad leveren dat een privé-API vereist, en dat is een legitieme rol. Hij authenticeert de taak niet bij de applicatie en begrenst niet wat de taak mag doen. Een gedeeld uitgangsadres identificeert bovendien de host en niet de taak, dus een allowlist-vermelding voor dat adres laat elk proces door dat erop draait.

Draait de taak op een gedeelde runner, dan is dat onderscheid eerder belangrijker dan minder belangrijk. Een andere workflow op dezelfde host erft de route en het adres, en de API kan de twee niet onderscheiden. Het is dezelfde zwakte als een gedeeld wachtwoord, één laag lager gelegd. Leg de beperking waar de applicatie haar kan afdwingen, en isoleer de runner als u de allowlist niet strakker kunt maken.

Vergelijk de twee ontwerpen eerlijk

Een menselijke login geeft u een echt persoon, een echte tweede factor en een controleerbare sessie, en hij kan niet onbeheerd draaien. Een applicatie-identiteit geeft u onbeheerde uitvoering, een controleerbare scope en een referentie die u kunt roteren, en zij kan niet handelen voor een gebruiker die niets heeft gedelegeerd. Geen van beide is een zwakkere versie van de andere; ze beantwoorden verschillende vragen. Kies door te vragen of de taak zonder iemand aanwezig moet draaien, en of de bewerking aan een specifieke gebruiker moet worden toegeschreven.

Zijn beide antwoorden ja, dan heeft het ontwerp een delegatiemodel nodig in plaats van een geleend wachtwoord. Schrijf die beslissing op waar de volgende beheerder haar vindt.

Wat u voor de overdracht moet verifiëren

Voer één toegestane bewerking en één vereiste weigering uit vanaf de echte worker, en bewaar beide resultaten. Test daarna een verlopen referentie en het gedrag wanneer het netwerkpad niet beschikbaar is, want dat zijn de twee storingen die iemand 's nachts wakker maken.

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

Noteer de principal, de scope, de rotatie-eigenaar en de uitvoeringsomgeving naast dat resultaat. Dat verslag is wat de volgende rotatie routine maakt in plaats van een incident. Het is ook het deel waar een auditor om vraagt.