¿Trabajo programado o inicio de sesión humano: qué identidad debe ver la API?

Un trabajo programado y una persona ante un indicador de inicio de sesión llaman a la misma API con credenciales distintas, vidas distintas y propietarios distintos. El trabajo necesita una ruta de red, una identidad de aplicación y un conjunto de permisos; la persona necesita un inicio de sesión, un segundo factor y una sesión. Mezclar ambos produce una automatización que se rompe cada vez que cambia la contraseña de la persona, o una política multifactor debilitada justo lo suficiente para mantener vivo un trabajo cron.

Tres puertas que parecen una sola

Una regla de dirección de origen pregunta de dónde vino la solicitud. La autenticación pregunta quién llama y qué pruebas se presentaron. La autorización pregunta si este sujeto puede realizar esta operación. Una VPN solo cambia la primera de las tres, y la cambia para cada proceso del host y no solo para el trabajo, así que mantenga las tres observaciones separadas en el registro del incidente.

Por eso cambiar el nodo de salida puede corregir un rechazo por dirección de origen y dejar intacto un token inválido. También por eso un token de API válido no hace que un extremo privado sea alcanzable desde un trabajo que no tiene ruta hacia él.

La ruta interactiva es una mala plantilla de automatización

Programar el inicio de sesión de una persona es tentador porque funciona una vez. El script almacena una contraseña, quizá una semilla de contraseña de un solo uso, y luego depende de un desafío diseñado para exigir a un humano. La mejor práctica actual de seguridad de OAuth, la RFC 9700, prohíbe la concesión resource-owner-password-credentials y explica por qué encaja mal con la autenticación de dos factores y de varios pasos.

La alternativa admitida suele ser un flujo de cliente confidencial en el que el servidor de autorización autentica la aplicación y emite un token. La concesión client-credentials de la RFC 6749, sección 4.4, es un ejemplo. Que exista no significa que toda API la acepte, ni que una tarea delegada por un usuario pueda sustituirse por ella, porque esas son preguntas para el propietario del servicio. Pregunte qué modelo sin supervisión admite el servicio antes de escribir código.

Dónde sigue encajando la VPN

Una VPN puede proporcionar la ruta de red que exige una API privada, y ese es un papel legítimo. No autentica el trabajo ante la aplicación ni delimita qué puede hacer el trabajo. Una dirección de salida compartida también identifica al host y no al trabajo, así que una entrada en la lista de permitidos para esa dirección admite a todos los procesos que se ejecuten en él.

Si el trabajo se ejecuta en un runner compartido, esa distinción importa más, no menos. Otro flujo de trabajo en el mismo host hereda la ruta y la dirección, y la API no puede distinguir a los dos. Es la misma debilidad que una contraseña compartida, desplazada una capa hacia abajo. Ponga la restricción donde la aplicación pueda imponerla, y aísle el runner si no puede acotar más la lista de permitidos.

Compare los dos diseños con honestidad

Un inicio de sesión humano le da una persona real, un segundo factor real y una sesión auditable, y no puede ejecutarse sin supervisión. Una identidad de aplicación le da ejecución sin supervisión, un alcance revisable y una credencial que puede rotar, y no puede actuar por un usuario que no ha delegado nada. Ninguno es una versión más débil del otro; responden a preguntas distintas. Elija preguntando si la tarea debe ejecutarse sin nadie presente y si la operación debe atribuirse a un usuario concreto.

Si ambas respuestas son sí, el diseño necesita un modelo de delegación y no una contraseña prestada. Escriba esa decisión donde la encuentre el próximo responsable de mantenimiento.

Qué verificar antes de la entrega

Ejecute una operación permitida y una denegación obligatoria desde el trabajador real, y conserve ambos resultados. Después pruebe una credencial caducada y el comportamiento cuando la ruta de red no está disponible, porque esos son los dos fallos que despiertan a alguien por la noche.

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

Anote el sujeto, el alcance, el propietario de la rotación y el entorno de ejecución junto a ese resultado. Ese registro es lo que convierte la siguiente rotación en rutina y no en incidente. También es la parte que pide un auditor.