Cómo las identidades administradas eliminan las contraseñas codificadas en Azure

By Mirko Peters · 2026-08-13

¡Bienvenido de nuevo al blog complementario de nuestro podcast! Si llevas un tiempo desarrollando aplicaciones, seguramente te has topado con el viejo problema de cómo conectar tu código a una base de datos, una API o una cuenta de almacenamiento en la nube…

Automatically translated with AI from the original post. Read the English original

¡Bienvenido de nuevo al blog complementario de nuestro podcast! Si llevas un tiempo desarrollando aplicaciones, seguramente te has topado con el viejo problema de cómo conectar tu código a una base de datos, una API o una cuenta de almacenamiento en la nube. Históricamente, los desarrolladores resolvían esto incluyendo una cadena de conexión, una contraseña de base de datos o un secreto de cliente directamente en un archivo de configuración, en una variable de entorno o, peor aún, codificándolo directamente en el repositorio de código fuente. Mientras la aplicación pudiera leer ese secreto, podía autenticarse y hacer su trabajo. Pero ¿qué ocurre cuando ese código se sube por error a un repositorio público de GitHub? ¿Qué pasa cuando un empleado descontento se marcha, o cuando un atacante consigue acceso de lectura a la configuración de tu aplicación? Al instante, toda tu infraestructura queda comprometida. En la arquitectura de nube moderna, este riesgo es inaceptable. Hoy vamos a profundizar en cómo las identidades administradas en Microsoft Azure eliminan por completo la necesidad de contraseñas codificadas, sustituyendo los secretos estáticos por tokens de acceso dinámicos y de corta duración.

Introducción a la seguridad en la nube y a los secretos codificados

El modelo de seguridad tradicional basado en el perímetro se apoyaba en gran medida en la idea de que, una vez dentro de la red corporativa, se podía confiar en el usuario. Dentro de ese perímetro, las aplicaciones se comunicaban mediante cuentas de servicio estáticas, contraseñas codificadas y tokens de larga duración que rara vez, o nunca, caducaban. Si un atacante lograba atravesar el perímetro, tenía acceso a un tesoro de credenciales estáticas que podían reutilizarse indefinidamente.

La computación en la nube hizo añicos este perímetro. Nuestras cargas de trabajo ahora abarcan entornos multinube, centros de datos locales, plataformas SaaS y funciones sin servidor distribuidas. En este nuevo escenario, la seguridad debe seguir la identidad de la propia carga de trabajo. Los secretos codificados son bombas de relojería: no se rotan automáticamente, son notoriamente difíciles de auditar y no dejan ningún margen de error si se exponen. Para lograr una verdadera seguridad de Confianza Cero, debemos desvincular por completo las credenciales de nuestro código fuente. Necesitamos un mecanismo de autenticación en el que las aplicaciones puedan demostrar quiénes son sin necesidad de conocer ni almacenar una contraseña.

Entender las identidades de usuario frente a las identidades de carga de trabajo en Entra ID

Para entender cómo ha evolucionado la seguridad en la nube, primero debemos ver cómo Microsoft Entra ID gestiona las entidades que acceden a nuestros sistemas. En términos generales, Microsoft Entra ID clasifica las identidades en dos grandes grupos: identidades de usuario e identidades de carga de trabajo.

Las identidades de usuario representan a personas: empleados, socios, contratistas y clientes. Las personas interactúan con los sistemas de forma dinámica y se autentican con métodos pensados para ellas, como contraseñas, Windows Hello para empresas, llaves de seguridad FIDO2 y autenticación multifactor. Las personas olvidan sus contraseñas, caen víctimas de ataques de phishing y necesitan que un administrador restablezca sus contraseñas.

Las identidades de carga de trabajo, en cambio, representan software. Aquí se incluyen aplicaciones, servicios en segundo plano, scripts de automatización, Azure Functions, Logic Apps, canalizaciones de implementación de DevOps y agentes de IA. Las cargas de trabajo no toman café, no hacen clic en correos de phishing y no pueden completar una solicitud interactiva de autenticación multifactor en un smartphone. Necesitan autenticarse de forma no interactiva, programática y continua. Tratar una identidad de carga de trabajo como si fuera una identidad de usuario, asignándole una contraseña estática, es uno de los errores más habituales en la arquitectura en la nube. Las identidades de carga de trabajo requieren sus propios modelos de gobernanza especializados, gestión del ciclo de vida y flujos de autenticación automatizados.

Desmitificando los registros de aplicaciones, las entidades de servicio y las identidades administradas

Si has dedicado algún tiempo a configurar aplicaciones en Microsoft Entra ID, seguro que te has topado con tres términos que suelen generar confusión: registros de aplicaciones, entidades de servicio e identidades administradas. Vamos a desglosarlos de forma sencilla.

Un registro de aplicación es la definición global o el plano de tu aplicación. Cuando registras una aplicación en Microsoft Entra ID, estás creando su identidad global en todo el ecosistema multiinquilino. Aquí defines qué permisos podría necesitar la aplicación, qué puntos de conexión de autenticación utiliza y qué URI están asociados a ella. Piensa en el registro de aplicación como la plantilla del pasaporte.

Una entidad de servicio es la instancia local de esa aplicación dentro de un inquilino específico. Si una aplicación es multiinquilino, tendrá un registro de aplicación en el inquilino del editor, pero una entidad de servicio independiente en cada inquilino de cliente donde se implemente y se consienta. La entidad de servicio es donde los administradores asignan realmente los permisos, aplican directivas de acceso condicional y controlan quién puede acceder a la aplicación de forma local. Piensa en la entidad de servicio como el pasaporte ya sellado que se usa para entrar en un país concreto.

Una identidad administrada lleva este concepto un paso más allá, concretamente para los recursos que se ejecutan dentro de Microsoft Azure. En lugar de que un desarrollador tenga que crear manualmente un registro de aplicación, generar un secreto de cliente, almacenar ese secreto en una variable de entorno y escribir código para gestionar el ciclo de vida de la autenticación, Azure se encarga de todo el proceso de forma transparente. Azure crea, gestiona y rota automáticamente las credenciales subyacentes por ti. El desarrollador simplemente indica al recurso de Azure que use su identidad administrada, y Azure se encarga del resto.

Cómo las identidades administradas eliminan las contraseñas y las credenciales codificadas de forma fija

La clave de las identidades administradas está en cómo cambian de raíz la transacción de autenticación. Cuando usas una identidad administrada para un recurso de Azure, como Azure App Service, una máquina virtual o una Azure Function, no hay literalmente ninguna contraseña, secreto ni certificado almacenado en tu código o en la configuración.

Cuando tu aplicación necesita acceder a un recurso protegido, como una base de datos o una API, no busca una contraseña almacenada. En su lugar, la aplicación realiza una llamada local al punto de conexión del Servicio de metadatos de instancias de Azure (IMDS), que solo está disponible de forma segura desde dentro de ese recurso de Azure concreto. La plataforma subyacente del recurso de Azure solicita directamente a Microsoft Entra ID, en nombre de la aplicación, un token web JSON (JWT) de vida corta.

Microsoft Entra ID verifica la identidad del recurso de Azure, emite un token de acceso firmado criptográficamente con una vida útil muy corta (normalmente alrededor de una hora) y lo devuelve a la aplicación. La aplicación utiliza entonces este token para autenticarse en el servicio de destino. Como el token caduca rápidamente, incluso si un atacante consigue interceptarlo, la ventana de vulnerabilidad es extremadamente reducida. Además, como no hay ninguna contraseña estática escrita en el código, no hay nada que un desarrollador pueda filtrar accidentalmente a un repositorio público.

Integración de Azure Key Vault y tokens de acceso de corta duración

Aunque las identidades administradas eliminan la necesidad de contraseñas de aplicación, quizá te preguntes cómo gestionan las aplicaciones los secretos que son realmente externos, como las claves de API de servicios de terceros que no admiten la autenticación de Microsoft Entra. Aquí es donde entra en juego Azure Key Vault, que trabaja codo con codo con las identidades administradas.

En lugar de codificar de forma fija una clave de API de terceros en tu código fuente, almacenas ese secreto de forma segura en Azure Key Vault. Después, concedes a la identidad administrada de tu recurso de Azure permiso para leer secretos de ese Key Vault mediante Azure Role-Based Access Control (RBAC) o directivas de acceso de Key Vault.

Cuando tu aplicación se inicia, utiliza su identidad administrada para autenticarse en Azure Key Vault, recupera dinámicamente en memoria la clave de API de terceros necesaria y la utiliza. En ningún momento se exponen credenciales en el código fuente. La aplicación usa un mecanismo seguro basado en identidad para obtener un secreto, en lugar de depender de una cadena estática incrustada en un archivo de configuración.

Proteger las identidades de carga de trabajo con el mínimo privilegio y la gobernanza

Eliminar las contraseñas codificadas de forma fija es una gran mejora para la seguridad, pero desplegar identidades administradas no es un modelo operativo del tipo "configúralo y olvídate". Las identidades de carga de trabajo requieren una gobernanza sólida, igual que las cuentas de usuario humanas.

Ante todo, debes seguir estrictamente el principio de mínimo privilegio. No asignes roles de colaborador amplios ni permisos excesivos de Microsoft Graph a una identidad de carga de trabajo solo para que todo funcione más rápido. Si un script de automatización en segundo plano solo necesita leer elementos de un contenedor específico de Azure Storage, concédele el acceso Lector de datos de blobs de almacenamiento únicamente a ese contenedor exacto, y nada más. Si esa identidad de carga de trabajo llegara a verse comprometida, el radio de impacto sería mínimo.

En segundo lugar, necesitas supervisar y auditar tus identidades de carga de trabajo de forma continua. Las organizaciones crean con frecuencia entidades de servicio e identidades administradas para proyectos de prueba de concepto, scripts de automatización e integraciones temporales, y luego los dejan funcionando indefinidamente con privilegios elevados. Implementa revisiones de seguridad periódicas para identificar entidades de servicio huérfanas, cuentas de automatización sin uso y credenciales obsoletas. Aprovechar funciones como Microsoft Entra ID Protection y configurar un registro sólido con Azure Monitor te da visibilidad completa sobre cuándo y cómo tus identidades de carga de trabajo acceden a tu entorno.

Elegir la estrategia de identidad adecuada para cada carga de trabajo en la nube

Con tantas opciones disponibles en el ecosistema de identidades de Microsoft, ¿cómo eliges la estrategia de autenticación adecuada para tu carga de trabajo concreta? La decisión depende, en general, de dónde se ejecuta tu aplicación y de cómo está diseñada.

Si tu código se ejecuta dentro de Microsoft Azure, ya sea en Azure App Services, Azure Functions, máquinas virtuales, Container Instances o Azure Kubernetes Service, tu primera opción debería ser siempre una identidad administrada. Puedes elegir entre una identidad administrada asignada por el sistema (cuyo ciclo de vida está vinculado 1:1 directamente al recurso de Azure) o una identidad administrada asignada por el usuario (que puede crearse de forma independiente y asignarse a varios recursos de Azure para facilitar la administración).

Si tu aplicación se ejecuta fuera de Azure, por ejemplo en servidores locales, en AWS o como parte de un pipeline de CI/CD en GitHub Actions, las identidades administradas que ofrece la infraestructura de Azure no son una opción. En estos escenarios debes aprovechar la federación de identidades de carga de trabajo. Esta permite que las plataformas externas intercambien tokens directamente con Microsoft Entra ID mediante una relación de confianza con OpenID Connect (OIDC), eliminando por completo la necesidad de administrar, rotar o almacenar secretos de cliente de larga duración.

Por último, en el caso de las aplicaciones empresariales personalizadas tradicionales que requieren autenticación de cliente y en las que no son viables ni las identidades administradas ni la federación, los certificados gestionados con cuidado deben tener siempre prioridad sobre los secretos de cliente de larga duración. Combinando Microsoft Entra Workload Identities, Azure Key Vault, los principios de Zero Trust y el acceso con mínimo privilegio, tu organización puede eliminar por completo las contraseñas codificadas en el código y construir una arquitectura en la nube notablemente resistente.

Conclusiones y próximos pasos para la seguridad moderna en la nube

Las contraseñas codificadas en el código y las cadenas de conexión estáticas son reliquias de una época anticuada en la seguridad de TI. Al adoptar Microsoft Entra Workload Identities y las identidades administradas de Azure, podemos eliminar por completo los riesgos asociados a las credenciales incrustadas, proteger nuestros repositorios de código fuente frente a filtraciones accidentales y aplicar un acceso estricto con mínimo privilegio en todas nuestras aplicaciones nativas de la nube. Los tokens de acceso de corta duración garantizan que, aunque un token sea interceptado, su vida útil sea demasiado breve para causar daños duraderos, lo que cambia de forma fundamental nuestra postura de seguridad, de la defensa reactiva a la protección proactiva.

Para profundizar aún más en este tema y escuchar consejos prácticos de implementación de primera mano, no dejes de revisar el episodio de podcast relacionado: Entra Workload Identities - Simply Explained. Escucha cómo desglosamos estos conceptos con más detalle para ayudarte a proteger tus entornos de Azure y Microsoft 365 como un profesional.