Identidades administradas en lugar de claves

Cuando una aplicación corre dentro de una plataforma de nube, la plataforma puede asignarle una identidad propia y entregarle credenciales temporales cuando las pide, sin que la aplicación guarde ninguna clave. La documentación de Microsoft Entra lo resume así para su plataforma: no hay que gestionar credenciales y ni siquiera son accesibles para quien administra la aplicación. Otras nubes tienen mecanismos equivalentes con otros nombres. La idea es la misma: el secreto no vive en un archivo, así que no se puede filtrar desde ahí.

Hidrosur fija una regla: una identidad administrada solo es posible si la carga corre en la plataforma y el destino acepta esa identidad. Si una de las dos condiciones falla, la carga sigue con una credencial. La tabla cargas trae la respuesta ya evaluada en la columna identidad_administrada.

No se migra todo a la vez. El criterio de Hidrosur es empezar por la carga que accede a datos de clientes, porque es donde una fuga cuesta más. Consulta los criterios y cruza con las cargas que sí pueden migrar.

Una identidad administrada depende de que la carga corra en la plataforma que la entrega. Una que corre en el centro de datos propio, o en el servicio de un tercero, no la recibe sin más. Entre las que no pueden migrar, una se distingue porque el motivo es dónde corre y no a quién llama: está en el servidor del centro de datos de la empresa.

Las cargas que no pueden migrar siguen necesitando un secreto, y ahí se aplica todo lo visto en el módulo: se guarda en una bóveda y no en el código, tiene dueño, se rota según la política y se le dan solo los permisos que usa. Una identidad administrada no elimina el trabajo de gobierno de las claves, lo reduce a lo que no tiene alternativa.