Identidad administrada para autenticación sin contraseñas

Tradicionalmente, las aplicaciones se conectan a servicios de Azure como Storage o Key Vault mediante cadenas de conexión o claves de API almacenadas en archivos de configuración o variables de entorno. Estas credenciales pueden confirmarse accidentalmente en el control de código fuente, quedar expuestas en los registros o ser robadas durante una brecha de seguridad. Managed Identity elimina por completo la necesidad de que las aplicaciones almacenen credenciales; en su lugar, Azure emite y rota un token en nombre del recurso, y la aplicación simplemente solicita a Azure el token actual en tiempo de ejecución.

Una identidad administrada es una entidad de servicio gestionada automáticamente en Microsoft Entra ID y vinculada a un recurso de Azure, como una VM, App Service o Function App. La plataforma de Azure crea y mantiene las credenciales de la identidad y las rota periódicamente, por lo que el código nunca gestiona una contraseña o un secreto. Las aplicaciones que se ejecutan en el recurso llaman al punto de conexión de Azure Instance Metadata Service (IMDS) en http://169.254.169.254 para obtener un token OAuth de corta duración, que después presentan a los servicios de Azure.

Existen dos tipos de identidad administrada: asignada por el sistema, vinculada a un único recurso de Azure; se crea al habilitarla en el recurso y se elimina automáticamente cuando se elimina el recurso. La identidad asignada por el usuario es una identidad independiente de Entra ID que se crea por separado y después se asocia a uno o varios recursos de Azure. Las identidades asignadas por el usuario son útiles cuando varios servicios, como varias Function Apps, necesitan compartir la misma identidad y los mismos permisos de RBAC, ya que evitan duplicar las asignaciones de roles.

Después de habilitar una identidad administrada, debe concederle permisos de RBAC sobre el recurso de Azure de destino. Por ejemplo, para permitir que un App Service lea blobs, asigne el rol Storage Blob Data Reader a la identidad administrada de App Service en la cuenta de almacenamiento. Las asignaciones de RBAC siguen el principio de mínimo privilegio: conceda únicamente los permisos mínimos necesarios. No asigne nunca Owner ni Contributor a una identidad administrada, salvo que sea absolutamente necesario.

El Azure SDK proporciona una clase DefaultAzureCredential que prueba automáticamente varios métodos de autenticación en orden: variables de entorno, identidad de carga de trabajo, identidad administrada, Azure CLI, Visual Studio y otros. Cuando la aplicación se ejecuta en Azure, ya sea en App Service, una VM o una Function App, DefaultAzureCredential utiliza automáticamente la identidad administrada sin cambios en el código. De forma local, los desarrolladores se autentican mediante su sesión de Azure CLI. Esta única clase de credenciales funciona en todos los entornos sin lógica condicional.

Un patrón habitual consiste en utilizar una identidad administrada para acceder en tiempo de ejecución a los secretos de Azure Key Vault. En lugar de almacenar la contraseña de una base de datos en la configuración de la aplicación, se almacena en Key Vault y se concede a la identidad administrada de la aplicación el rol Key Vault Secrets User en ese almacén. Al iniciarse, la aplicación obtiene el secreto de Key Vault mediante DefaultAzureCredential. Este patrón garantiza que los secretos nunca se almacenen en el código, los archivos de configuración ni las variables de entorno; existen únicamente en Key Vault y se obtienen de forma efímera.

Azure SQL Database admite la autenticación de Entra ID, lo que significa que una identidad administrada puede autenticarse en SQL sin nombre de usuario ni contraseña. Para habilitarla, establezca un administrador de Entra ID en el servidor SQL; después, ejecute una instrucción CREATE USER en la base de datos de destino para el nombre para mostrar de la identidad administrada y asígnele el rol de base de datos adecuado. La aplicación se conecta mediante DefaultAzureCredential del Azure SDK y un token de acceso con ámbito https://database.windows.net/, sin utilizar contraseñas.

En Azure Kubernetes Service, los pods individuales pueden obtener tokens de identidad administrada mediante Workload Identity, el sucesor de AAD Pod Identity. Se crea una identidad administrada asignada por el usuario, se federa con el emisor OIDC de AKS, se anota la cuenta de servicio de Kubernetes y el webhook de Azure Workload Identity inyecta las variables de entorno necesarias para que DefaultAzureCredential del pod pueda obtener un token. Esto amplía la autenticación sin contraseñas a los microservicios contenerizados sin almacenar secretos en objetos Secret de Kubernetes.

Aunque las credenciales de las identidades administradas son invisibles para los desarrolladores, se registran todos los eventos de emisión de tokens y de acceso a los recursos. Los registros de inicio de sesión de Entra ID registran cada solicitud de token realizada por una identidad administrada, incluido el recurso al que se accede, la hora y si la solicitud tuvo éxito. Los registros de actividad de Azure Storage y los registros de auditoría de Key Vault registran las operaciones específicas realizadas mediante el token. Estos registros son esenciales para las auditorías de seguridad y las investigaciones de incidentes relacionados con identidades administradas.

Si su aplicación utiliza actualmente cadenas de conexión o claves de API, migre a una identidad administrada en tres pasos: Paso 1: habilite una identidad administrada en el recurso de proceso. Paso 2: asigne los roles de RBAC adecuados a la identidad en cada servicio de destino. Paso 3: actualice el código de la aplicación para utilizar DefaultAzureCredential en lugar de la cadena de conexión. Elimine la cadena de conexión de la configuración de App Service y de Key Vault una vez verificada la migración. Normalmente, esta migración puede completarse con cambios mínimos en el código de las aplicaciones modernas que utilizan Azure SDK.

Managed Identity ofrece cuatro ventajas de seguridad clave frente a la autenticación basada en credenciales: ningún almacenamiento de credenciales: no hay nada que robar ni confirmar accidentalmente. Rotación automática: Azure rota los certificados subyacentes sin tiempo de inactividad. Permisos con ámbito: las identidades reciben únicamente los roles de RBAC que necesitan, conforme al principio de mínimo privilegio. Registro de auditoría completo: todos los intentos de acceso se registran en Entra ID y en los registros de auditoría del servicio al que se accede. Para cualquier nueva integración con un servicio de Azure, la identidad administrada debería ser el enfoque de autenticación predeterminado.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que la identidad administrada elimina las credenciales almacenadas al asignar a los recursos de Azure una identidad de Entra ID administrada automáticamente; que DefaultAzureCredential del Azure SDK usa de forma transparente la identidad administrada en Azure y las credenciales del desarrollador en el entorno local; y que las asignaciones de roles de RBAC en los servicios de destino controlan a qué puede acceder la identidad. A continuación, exploraremos Azure Service Bus para implementar mensajería desacoplada entre componentes de aplicaciones.