Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Las aplicaciones pueden usar la biblioteca de identidades de Azure para autenticarse en el identificador de Microsoft Entra, que concede acceso a los servicios y recursos de Azure. Este requisito de autenticación se aplica si la aplicación se implementa en Azure, se hospeda en el entorno local o se ejecuta localmente en una estación de trabajo para desarrolladores. En las secciones siguientes se describen los enfoques recomendados para autenticar una aplicación en el identificador de Microsoft Entra en distintos entornos al usar las bibliotecas cliente del SDK de Azure.
Enfoque recomendado para la autenticación de aplicaciones
La autenticación basada en tokens a través de Microsoft Entra ID es el enfoque recomendado para autenticar aplicaciones en Azure, en lugar de usar cadenas de conexión o opciones basadas en claves. El módulo cliente de Identidad de Azure para Go proporciona autenticación basada en tokens y permite que las aplicaciones se autentiquen en recursos de Azure tanto si la aplicación se ejecuta localmente, en Azure como en un servidor local.
Ventajas de la autenticación basada en tokens
La autenticación basada en tokens ofrece las siguientes ventajas sobre las cadenas de conexión:
- La autenticación basada en tokens garantiza que solo las aplicaciones específicas destinadas a acceder al recurso de Azure pueden hacerlo, mientras que cualquiera o cualquier aplicación con una cadena de conexión puede conectarse a un recurso de Azure.
- La autenticación basada en tokens permite limitar aún más el acceso a los recursos de Azure solo a los permisos específicos necesarios para la aplicación. Este enfoque sigue el principio de privilegios mínimos. Por el contrario, una cadena de conexión concede derechos completos al recurso de Azure.
- Al usar una identidad administrada para la autenticación basada en tokens, Azure controla las funciones administrativas automáticamente, por lo que no tiene que preocuparse por tareas como proteger o rotar secretos. Esta característica hace que la aplicación sea más segura porque no hay ninguna cadena de conexión ni secreto de aplicación que se pueda poner en peligro.
- Las cadenas de conexión son funcionalmente equivalentes a las credenciales y requieren un control especial para evitar la pérdida accidental. Debe almacenarlos de forma segura (por ejemplo, en Azure Key Vault) y nunca incluirlos directamente en el código ni subirlos al control de versiones. Microsoft Secure Future Initiative (SFI) prohíbe el uso de cadenas de conexión y secretos similares de larga duración, ya que se pueden usar para poner en peligro la aplicación si no se administra cuidadosamente.
- La biblioteca de identidades de Azure adquiere y administra los tokens de Microsoft Entra.
Limite el uso de cadenas de conexión a escenarios en los que la autenticación basada en tokens no sea una opción, aplicaciones de prueba de concepto iniciales o prototipos de desarrollo que no tengan acceso a datos confidenciales o de producción. Cuando sea posible, use los tipos de credenciales de la biblioteca de identidades de Azure para autenticarse en los recursos de Azure.
Autenticación en distintos entornos
El tipo de autenticación basada en tokens que usa una aplicación para autenticarse en los recursos de Azure depende de dónde se ejecute la aplicación. En el diagrama siguiente se proporcionan instrucciones para distintos escenarios y entornos:
Cuando una aplicación:
- Hospedado en Azure: la aplicación debe autenticarse en los recursos de Azure mediante una identidad administrada. Para obtener más información, consulte autenticación en entornos de servidor.
- Ejecución local durante el desarrollo: la aplicación puede autenticarse en Azure mediante una entidad de servicio de aplicación para el desarrollo local o las credenciales de Azure del desarrollador. Para obtener más información, consulte autenticación durante el desarrollo local.
- Hospedado localmente: la aplicación debe autenticarse para los recursos de Azure mediante un principal de servicio de aplicación o, en el caso de Azure Arc, una identidad administrada. Para obtener más información, consulte autenticación en entornos de servidor.
Autenticación para aplicaciones hospedadas en Azure
Al hospedar la aplicación en Azure, puede usar identidades administradas para autenticarse en recursos de Azure sin necesidad de administrar credenciales. Hay dos tipos de identidades administradas: asignadas por el usuario y asignadas por el sistema.
Uso de una identidad administrada asignada por el usuario
Cree una identidad administrada asignada por el usuario como un recurso de Azure independiente. Puede asignarlo a uno o varios recursos de Azure, lo que permite que esos recursos compartan la misma identidad y permisos. Para autenticarse mediante una identidad administrada asignada por el usuario, cree la identidad, asígnela al recurso de Azure y, a continuación, configure la aplicación para que use esta identidad para la autenticación especificando su identificador de cliente, identificador de recurso o identificador de objeto.
Uso de una identidad administrada asignada por el sistema
Habilite una identidad administrada asignada por el sistema directamente en un recurso de Azure. La identidad está vinculada al ciclo de vida de ese recurso y se elimina automáticamente cuando se elimina el recurso. Para autenticarse mediante una identidad administrada asignada por el sistema, habilite la identidad en el recurso de Azure y configure la aplicación para que use esta identidad para la autenticación.
Autenticación durante el desarrollo local
Durante el desarrollo local, puede autenticarse a los recursos de Azure mediante las credenciales de desarrollador o un principal del servicio. Este método de autenticación le permite probar la lógica de autenticación de la aplicación sin implementarla en Azure.
Uso de credenciales de desarrollador
Puede usar sus propias credenciales de Azure para autenticarse en los recursos de Azure durante el desarrollo local. Normalmente, se usa una herramienta de desarrollo, como la CLI de Azure, que puede proporcionar a la aplicación los tokens necesarios para acceder a los servicios de Azure. Este método es cómodo, pero solo debe usarse con fines de desarrollo.
Uso de una entidad de servicio
Puede crear un principal de servicio en un inquilino de Microsoft Entra para representar una aplicación y usarlo para autenticarse en los recursos de Azure. Puede configurar su aplicación para usar credenciales de entidad de servicio durante el desarrollo local. Este método es más seguro que usar credenciales de desarrollador y está más cerca de cómo se autentica la aplicación en producción. Sin embargo, sigue siendo menos ideal que usar una identidad administrada debido a la necesidad de secretos.
Autenticación para aplicaciones hospedadas en el entorno local
En el caso de las aplicaciones hospedadas en el entorno local, puede usar una entidad de servicio para autenticarse en los recursos de Azure. Este método implica crear una entidad de servicio en microsoft Entra ID, asignarle los permisos necesarios y configurar la aplicación para que use sus credenciales. Con este método, la aplicación local puede acceder de forma segura a los servicios de Azure.