Feina programada o inici de sessió humà: quina identitat ha de veure l’API?

Una feina programada i una persona davant l’indicador d’inici de sessió criden la mateixa API amb credencials diferents, vides diferents i propietaris diferents. La feina necessita un camí de xarxa, una identitat d’aplicació i un conjunt de permisos; la persona necessita un inici de sessió, un segon factor i una sessió. Barrejar les dues coses produeix una automatització que es trenca sempre que canvia la contrasenya de la persona, o una política multifactor debilitada just prou per mantenir viva una feina cron.

Tres portes que semblen una de sola

Una regla d’adreça d’origen pregunta d’on ve la petició. L’autenticació pregunta qui truca i quines proves s’han presentat. L’autorització pregunta si aquest subjecte pot dur a terme aquesta operació. Una VPN només canvia la primera de les tres, i la canvia per a cada procés de l’amfitrió i no només per a la feina, així que manteniu les tres observacions separades al registre de l’incident.

Per això canviar el node de sortida pot arreglar un rebuig per adreça d’origen i deixar intacte un testimoni no vàlid. També per això un testimoni d’API vàlid no fa que una punta privada sigui abastable des d’una feina que no hi té ruta.

El camí interactiu és una mala plantilla d’automatització

Programar l’inici de sessió d’una persona és temptador perquè funciona un cop. El script desa una contrasenya, potser una llavor de contrasenya d’un sol ús, i després depèn d’un repte dissenyat per exigir una persona. La millor pràctica actual de seguretat d’OAuth, la RFC 9700, prohibeix la concessió resource-owner-password-credentials i explica per què encaixa malament amb l’autenticació de dos factors i de diversos passos.

L’alternativa admesa sol ser un flux de client confidencial en què el servidor d’autorització autentica l’aplicació i emet un testimoni. La concessió client-credentials de la RFC 6749, secció 4.4, n’és un exemple. Que existeixi no vol dir que tota API l’accepti, ni que una tasca delegada per un usuari s’hi pugui substituir, perquè aquestes són preguntes per al propietari del servei. Pregunteu quin model sense supervisió admet el servei abans d’escriure cap codi.

On encara hi cap la VPN

Una VPN pot proporcionar el camí de xarxa que exigeix una API privada, i aquest és un paper legítim. No autentica la feina davant de l’aplicació ni delimita què pot fer la feina. Una adreça de sortida compartida també identifica l’amfitrió i no la feina, així que una entrada a la llista de permisos per a aquesta adreça admet cada procés que hi corre.

Si la feina corre en un executor compartit, aquesta distinció importa més aviat més que menys. Un altre flux de treball al mateix amfitrió hereta la ruta i l’adreça, i l’API no pot distingir-ne les dues. És la mateixa feblesa que una contrasenya compartida, baixada un nivell. Poseu la restricció on l’aplicació la pugui fer complir, i aïlleu l’executor si no podeu acotar més la llista de permisos.

Compareu els dos dissenys amb honestedat

Un inici de sessió humà us dona una persona real, un segon factor real i una sessió auditable, i no pot funcionar sense supervisió. Una identitat d’aplicació us dona execució sense supervisió, un abast revisable i una credencial que podeu rotar, i no pot actuar per a un usuari que no ha delegat res. Cap de les dues no és una versió més feble de l’altra; responen preguntes diferents. Trieu preguntant si la tasca ha de córrer sense ningú present i si l’operació s’ha d’atribuir a un usuari concret.

Si totes dues respostes són sí, el disseny necessita un model de delegació i no una contrasenya manllevada. Escriviu aquesta decisió allà on la trobi el proper mantenidor.

Què cal verificar abans del lliurament

Executeu una operació permesa i una denegació obligatòria des del treballador real, i guardeu tots dos resultats. Després proveu una credencial caducada i el comportament quan el camí de xarxa no està disponible, perquè aquestes són les dues fallades que desvetllen algú a la nit.

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

Anoteu el subjecte, l’abast, el propietari de la rotació i l’entorn d’execució al costat d’aquell resultat. Aquest registre és el que fa que la rotació següent sigui rutina i no un incident. També és la part que demana un auditor.