Saltar al contenido principal
Todos los artículos
Tips de seguridad

· 9 min de lectura · Kimetai Engineering

Un modelo de identidad para actores no humanos: DIDs, VCs y el humano que respalda

La mayoría de las automatizaciones en producción se autentican igual: una API key de vida larga, copiada en un nodo, compartida por quien la necesite. Eso no es una identidad. Es una contraseña sin nombre asociado — y es la razón de que nadie pueda responder después quién autorizó una acción.

Por qué una clave no es una identidad

Una credencial que merezca el nombre responde a cuatro cosas: quién es este actor, qué tiene permitido hacer, quién responde por él y si eso sigue siendo cierto ahora mismo. Una API key no responde a ninguna. No la puede verificar un tercero sin preguntar al sistema que la emitió, no lleva alcance más allá de lo que asuma la plataforma destino, y no tiene caducidad que nadie siga.

DIDs y Credenciales Verificables, en breve

Un Identificador Descentralizado W3C es un nombre estable vinculado a una clave pública. Una Credencial Verificable es una afirmación firmada sobre el titular de ese identificador — emitida por alguien, acotada, fechada y revocable. La propiedad que importa aquí es la verificabilidad offline: el sistema receptor puede comprobar la firma sin confiar en la automatización que la presenta, y sin una llamada de vuelta a nosotros.

verifiable_credential

did:
did:kimetai:acme:7f3a…c2e1
type:
deterministic_workflow · n8n
backed_by:
maria.lopez@acme.eu
scope:
finance.payables · read+authorize
status:
● active · revocación: global, <5s

El campo que cambia la conversación: backed_by

Cada credencial debería nombrar a una persona. No un equipo, no un buzón, no «IT» — una persona a la que se le puede preguntar por qué existe esta automatización y que hereda la obligación cuando se comporta mal. No es una preferencia filosófica: es lo que hace atribuible una traza de auditoría, y la atribución es lo que piden de verdad las normativas en vigor.

Una automatización sin humano que la respalde es una obligación sin destinatario.

También le da al offboarding un significado que hoy no tiene. Cuando alguien se va, se le desactiva la cuenta de usuario y sus automatizaciones siguen corriendo con una credencial de servicio que nadie revisa. Con un responsable nombrado, la salida plantea una pregunta que hay que responder: ¿quién asume esto, o se para?

Qué hacer sin reconstruir nada

  • Asigna un dueño con nombre a cada automatización del inventario antes de darle una credencial.
  • Acota las credenciales a la acción, no a la plataforma: «crear pago hasta 5.000 € a proveedores aprobados», no «acceso total a la API».
  • Rota automáticamente y haz global la revocación — un sitio, segundos, no un ticket por plataforma.
  • Federa con el proveedor de identidad que ya usas (Okta, Entra ID, Google Workspace) para que el humano que respalda sea un empleado real y actual.

Nada de esto exige reescribir la automatización. La identidad se sitúa delante, en la solicitud de autorización — que es también donde corresponde la decisión de política.