Provisión de credenciales de identidad de aplicación cuando no hay ningún usuario
Cuando usted, como desarrollador, está creando aplicaciones que no son de usuario, no tiene un usuario que pueda solicitar un nombre de usuario y una contraseña o autenticación multifactor (MFA). Debe proporcionar la identidad de la aplicación por sí sola. En este artículo, se explica por qué el procedimiento recomendado para las credenciales de cliente de Confianza cero para servicios (aplicaciones que no son de usuario) en Azure es el uso de identidades administradas para recursos de Azure.
Problemas con las cuentas de servicio
Usar una "cuenta de servicio" (crear una cuenta de usuario y usarla para un servicio) no es una buena solución. Microsoft Entra ID no usa el concepto de cuenta de servicio. Cuando los administradores crean cuentas de usuario para un servicio y, a continuación, comparten contraseñas con desarrolladores, no es seguro. No es un servicio que pueda ofrecerse sin contraseña ni aplicar MFA. En lugar de usar una cuenta de usuario como cuenta de servicio, la mejor solución es usar una de las siguientes opciones de credenciales de cliente.
Opciones de credenciales de cliente
Hay cuatro tipos de credenciales de cliente que pueden identificar una aplicación.
- Clave secreta
- Certificado
- Identidades administradas para recursos de Azure
- Credenciales federadas
¿Clave secreta o certificado?
Las claves secretas son aceptables cuando tiene una infraestructura de administración de secretos sofisticada (como Azure Key Vault) en su empresa. Sin embargo, las claves secretas en escenarios en los que el profesional de TI genera una clave secreta y, a continuación, se la envía por correo electrónico a un desarrollador que, a continuación, podría almacenarla en una ubicación no segura, como una hoja de cálculo, hace que las claves secretas no estén protegidas correctamente.
Las credenciales de cliente basadas en un certificado son más seguras que las claves secretas. Los certificados se administran mejor, ya que no son el secreto en sí. El secreto no forma parte de una transmisión. Cuando se usa una clave secreta, el cliente envía el valor real de la clave secreta a Microsoft Entra ID. Cuando se usa un certificado, la clave privada del certificado nunca abandona el dispositivo. Incluso si alguien intercepta, descodifica y descifra la transmisión, el secreto sigue siendo seguro porque la parte interceptante no tiene la clave privada.
Procedimiento recomendado: usar las identidades administradas para recursos de Azure
A la hora de desarrollar servicios (aplicaciones que no son de usuario) en Azure, las identidades administradas para recursos de Azure proporcionan una identidad administrada automáticamente en Microsoft Entra ID. La aplicación puede autenticarse en cualquier servicio que admita la autenticación de Microsoft Entra, sin necesidad de tener credenciales. No es necesario administrar los secretos, porque no existe la posibilidad de perderlos o controlarlos incorrectamente. Los secretos no se pueden interceptar porque no se mueven a través de la red. Si va a crear servicios en Azure, el procedimiento recomendado son las identidades administradas para recursos de Azure.
Pasos siguientes
- En el artículo Tipos de identidad y de cuenta para aplicaciones únicas y multiinquilino se explica cómo puede elegir si la aplicación solo permite a los usuarios de su inquilino de Microsoft Entra, cualquier inquilino de Microsoft Entra o usuarios con cuentas personales de Microsoft.
- El artículo Desarrollo de la estrategia de permisos de aplicación le ayuda a decidir sobre el enfoque de permisos de aplicación para la administración de credenciales.
- En Provisión de credenciales de identidad de aplicación cuando no hay ningún usuario se explica por qué las identidades administradas para recursos de Azure el procedimiento recomendado para proporcionar credenciales de cliente para servicios (aplicaciones que no son de usuario).
- Procedimientos recomendados de autorización le ayuda a implementar los mejores modelos de autorización, permisos y consentimiento para las aplicaciones.
- Use los procedimientos recomendados de desarrollo para la administración de identidad y acceso de confianza cero en el ciclo de vida de desarrollo de las aplicaciones para crear aplicaciones seguras.
- Creación de aplicaciones con un enfoque de confianza cero para la identidad proporciona información general sobre los permisos y los procedimientos recomendados de acceso.