Tâche planifiée ou connexion humaine : quelle identité l’API doit-elle voir ?

Une tâche planifiée et une personne devant une invite de connexion appellent la même API avec des identifiants différents, des durées de vie différentes et des propriétaires différents. La tâche a besoin d’un chemin réseau, d’une identité applicative et d’un ensemble de permissions ; la personne a besoin d’une connexion, d’un second facteur et d’une session. Mélanger les deux produit une automatisation qui casse dès que le mot de passe de la personne change, ou une politique multifacteur affaiblie juste assez pour maintenir un job cron en vie.

Trois portes qui n’en font qu’une

Une règle d’adresse source demande d’où vient la requête. L’authentification demande qui appelle et quelles preuves ont été présentées. L’autorisation demande si ce sujet peut effectuer cette opération. Un VPN ne change que la première des trois, et il la change pour chaque processus de l’hôte et pas seulement pour la tâche, alors gardez les trois observations séparées dans le compte rendu d’incident.

C’est pourquoi changer le nœud de sortie peut corriger un rejet dû à l’adresse source et laisser un jeton invalide intact. C’est aussi pourquoi un jeton d’API valide ne rend pas un point de terminaison privé accessible depuis une tâche qui n’a pas de route vers lui.

Le chemin interactif est un mauvais modèle d’automatisation

Scripturer la connexion d’une personne est tentant parce que cela fonctionne une fois. Le script stocke un mot de passe, peut-être une graine de mot de passe à usage unique, puis dépend d’un défi conçu pour exiger un humain. La meilleure pratique de sécurité actuelle pour OAuth, la RFC 9700, interdit l’octroi resource-owner-password-credentials et explique pourquoi il s’accorde mal avec l’authentification à deux facteurs et à plusieurs étapes.

L’alternative prise en charge est généralement un flux de client confidentiel dans lequel le serveur d’autorisation authentifie l’application et émet un jeton. L’octroi client-credentials de la RFC 6749, section 4.4, en est un exemple. Son existence ne signifie pas que toute API l’accepte, ni qu’une tâche déléguée par un utilisateur puisse être remplacée par lui, car ce sont des questions pour le propriétaire du service. Demandez quel modèle sans supervision le service prend en charge avant d’écrire du code.

Où le VPN reste à sa place

Un VPN peut fournir le chemin réseau qu’exige une API privée, et c’est un rôle légitime. Il n’authentifie pas la tâche auprès de l’application et ne délimite pas ce que la tâche peut faire. Une adresse de sortie partagée identifie aussi l’hôte plutôt que la tâche, donc une entrée de liste d’autorisation pour cette adresse admet chaque processus qui y tourne.

Si la tâche tourne sur un runner partagé, cette distinction compte plus, et non moins. Un autre flux de travail sur le même hôte hérite de la route et de l’adresse, et l’API ne peut pas distinguer les deux. C’est la même faiblesse qu’un mot de passe partagé, descendue d’un cran. Placez la restriction là où l’application peut l’imposer, et isolez le runner si vous ne pouvez pas resserrer la liste d’autorisation.

Comparez les deux conceptions honnêtement

Une connexion humaine vous donne une personne réelle, un second facteur réel et une session auditable, et elle ne peut pas fonctionner sans supervision. Une identité applicative vous donne une exécution sans supervision, un périmètre vérifiable et un identifiant que vous pouvez faire tourner, et elle ne peut pas agir pour un utilisateur qui n’a rien délégué. Ni l’une ni l’autre n’est une version plus faible de l’autre ; elles répondent à des questions différentes. Choisissez en demandant si la tâche doit tourner sans personne présente et si l’opération doit être attribuée à un utilisateur précis.

Si les deux réponses sont oui, la conception a besoin d’un modèle de délégation plutôt que d’un mot de passe emprunté. Écrivez cette décision là où le prochain mainteneur la trouvera.

Ce qu’il faut vérifier avant la remise

Exécutez une opération autorisée et un refus obligatoire depuis le worker réel, et conservez les deux résultats. Testez ensuite un identifiant expiré et le comportement lorsque le chemin réseau n’est pas disponible, car ce sont les deux pannes qui réveillent quelqu’un la nuit.

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

Notez le sujet, le périmètre, le propriétaire de la rotation et l’environnement d’exécution à côté de ce résultat. C’est cet enregistrement qui fait de la rotation suivante une routine plutôt qu’un incident. C’est aussi la partie qu’un auditeur réclame.