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.
Cuando una aplicación necesita acceder a un recurso de Azure como Azure Storage, Azure Key Vault o los servicios de mensajería de Azure, la aplicación debe autenticarse en Azure. Este requisito es cierto para todas las aplicaciones, independientemente de si se implementan en Azure, se implementan en el entorno local o en desarrollo en una estación de trabajo para desarrolladores local. En este artículo se describen los enfoques recomendados para autenticar una aplicación en Azure cuando se usa el SDK de Azure para C++.
Enfoque recomendado de autenticación de aplicaciones
Use la autenticación basada en tokens en lugar de cadenas de conexión para las aplicaciones cuando se autentiquen en recursos de Azure. La biblioteca cliente de Identidad de Azure para C++ proporciona clases que admiten la autenticación basada en tokens. Estas clases permiten que las aplicaciones se autentiquen sin problemas en los recursos de Azure, tanto si la aplicación está en desarrollo local, implementada en Azure como si se implementa en un servidor local.
El tipo específico de autenticación basada en tokens que usa una aplicación para autenticarse en los recursos de Azure depende de dónde se ejecuta la aplicación. Los tipos de autenticación basada en tokens se muestran en el diagrama siguiente.
- Cuando un desarrollador ejecuta una aplicación durante el desarrollo local: La aplicación se autentica en Azure mediante una entidad de servicio de aplicación para el desarrollo local o las credenciales de Azure del desarrollador. Estas opciones se describen en la sección Autenticación durante el desarrollo local.
- Cuando una aplicación se hospeda en Azure: La aplicación se autentica en recursos de Azure mediante una identidad administrada. Esta opción se describe en la sección Autenticación en entornos de servidor.
- Cuando una aplicación se hospeda e implementa de forma local: La aplicación se autentica en recursos de Azure mediante una entidad de servicio de aplicación. Esta opción se describe en la sección Autenticación en entornos de servidor.
DefaultAzureCredential
La clase DefaultAzureCredential proporcionada por la biblioteca cliente de Identidad de Azure permite a las aplicaciones usar diferentes métodos de autenticación en función del entorno en el que se ejecutan. De este modo, las aplicaciones se pueden promover desde entornos de desarrollo local a entornos de prueba y a producción sin cambios en el código.
Configure el método de autenticación adecuado para cada entorno y DefaultAzureCredential
detecte y use automáticamente ese método de autenticación. El uso de DefaultAzureCredential
se prefiere sobre la codificación manual de la lógica condicional o las marcas de características para usar diferentes métodos de autenticación en distintos entornos.
Los detalles sobre el uso de la DefaultAzureCredential
clase se describen en la sección Uso de DefaultAzureCredential en una aplicación.
Ventajas de la autenticación basada en tokens
Use la autenticación basada en tokens en lugar de usar cadenas de conexión al compilar aplicaciones para Azure. La autenticación basada en tokens ofrece las siguientes ventajas sobre la autenticación con cadenas de conexión:
- Los métodos de autenticación basados en tokens descritos en este artículo le permiten establecer los permisos específicos necesarios para la aplicación en el recurso de Azure. Esta práctica sigue el principio de privilegios mínimos. Por el contrario, una cadena de conexión concede derechos completos al recurso de Azure.
- Cualquiera o cualquier aplicación con una cadena de conexión puede conectarse a un recurso de Azure, pero los métodos de autenticación basados en tokens limitan el acceso al recurso solo a las aplicaciones diseñadas para acceder al recurso.
- Con una identidad administrada, no hay ningún secreto de aplicación que almacenar. La aplicación es más segura porque no hay ninguna cadena de conexión ni secreto de aplicación que se pueda poner en peligro.
- El paquete azure-identity adquiere y administra tokens de Microsoft Entra automáticamente, lo que hace que el uso de la autenticación basada en tokens sea tan fácil de usar como una cadena de conexión.
Limite el uso de cadenas de conexión para aplicaciones de prueba de concepto iniciales o prototipos de desarrollo que no tengan acceso a la producción ni a los datos confidenciales. De lo contrario, las clases de autenticación basadas en tokens disponibles en la biblioteca cliente de Identidad de Azure siempre se prefieren cuando se autentican en los recursos de Azure.
Autenticación en entornos de servidor
Cuando se hospeda en un entorno de servidor, a cada aplicación se le asigna una identidad de aplicación única por entorno donde se ejecuta la aplicación. En Azure, una identidad de aplicación se representa mediante un principal de servicio. Este tipo especial de entidad de seguridad identifica y autentica las aplicaciones en Azure. El tipo de principal de servicio que se debe utilizar para tu app depende de dónde se esté ejecutando.
Método de autenticación | Descripción |
---|---|
Aplicaciones hospedadas en Azure | Las aplicaciones hospedadas en Azure deben usar un principal de servicio de identidad administrada. Las identidades administradas están diseñadas para representar la identidad de una aplicación hospedada en Azure y solo se pueden usar con aplicaciones hospedadas en Azure. Por ejemplo, a una aplicación web de Django hospedada en Azure App Service se le asignaría una identidad administrada. La identidad administrada asignada a la aplicación se usaría para autenticar la aplicación en otros servicios de Azure. Las aplicaciones que se ejecutan en Azure Kubernetes Service (AKS) pueden usar una credencial de identidad de carga de trabajo. Esta credencial se basa en una identidad administrada que tiene una relación de confianza con una cuenta de servicio de AKS. |
Aplicaciones hospedadas fuera de Azure (por ejemplo, aplicaciones locales) |
Las aplicaciones hospedadas fuera de Azure (por ejemplo, aplicaciones locales) que necesitan conectarse a los servicios de Azure deben usar una entidad de servicio de aplicación. Un principal de servicio de aplicación representa la identidad de la aplicación en Azure y se crea a través del proceso de registro de la aplicación. Por ejemplo, considere una aplicación web de Django hospedada localmente que use Azure Blob Storage. Crearías un principal de servicio de aplicación para la app mediante el proceso de registro de aplicaciones. Los AZURE_CLIENT_ID , AZURE_TENANT_ID y AZURE_CLIENT_SECRET se almacenarían como variables de entorno que leerá la aplicación en tiempo de ejecución y permitirán que la aplicación se autentique en Azure mediante la entidad de servicio de la aplicación. |
Autenticación durante el desarrollo local
Cuando una aplicación se ejecuta en la estación de trabajo de un desarrollador durante el desarrollo local, todavía debe autenticarse en los servicios de Azure usados por la aplicación. Hay dos estrategias principales para autenticar aplicaciones en Azure durante el desarrollo local:
Método de autenticación | Descripción |
---|---|
Cree objetos dedicados de entidades de servicio de aplicación que se usarán durante el desarrollo local. | En este método, los objetos principales de servicios de aplicación dedicados se configuran mediante el proceso de registro de aplicaciones para su uso durante el desarrollo local. A continuación, la identidad de la entidad de servicio se almacena como variables de entorno a las que debe acceder la aplicación cuando se ejecuta en el desarrollo local. Este método permite asignar los permisos de recursos específicos necesarios para la aplicación a los objetos de entidad de servicio que usan los desarrolladores durante el desarrollo local. Esta práctica garantiza que la aplicación solo tiene acceso a los recursos específicos que necesita y replica los permisos que tendrá la aplicación en producción. La desventaja de este enfoque es la necesidad de crear objetos de entidad de servicio independientes para cada desarrollador que trabaja en una aplicación. |
Autentíque la aplicación en Azure mediante las credenciales del desarrollador durante el desarrollo local. | En este método, un desarrollador debe iniciar sesión en Azure desde la CLI de Azure, Azure PowerShell o la CLI para desarrolladores de Azure en su estación de trabajo local. A continuación, la aplicación puede acceder a las credenciales del desarrollador desde el almacén de credenciales y usar esas credenciales para acceder a los recursos de Azure desde la aplicación. Este método tiene la ventaja de una configuración más sencilla porque un desarrollador solo necesita iniciar sesión en su cuenta de Azure a través de una de las herramientas de desarrollo mencionadas anteriormente. La desventaja de este enfoque es que la cuenta del desarrollador probablemente tenga más permisos de los que requiere la aplicación. Como resultado, la aplicación no replica con precisión los permisos con los que se ejecutará en producción. |
Uso de DefaultAzureCredential en una aplicación
DefaultAzureCredential es una secuencia opinada y ordenada de mecanismos para autenticarse en Microsoft Entra ID. Cada mecanismo de autenticación es una clase que implementa el protocolo TokenCredential y se conoce como credencial. En tiempo de ejecución, DefaultAzureCredential
intenta autenticarse con la primera credencial. Si esa credencial no puede adquirir un token de acceso, se intenta utilizar la siguiente credencial de la secuencia, y así sucesivamente hasta que se obtenga correctamente un token de acceso. De este modo, la aplicación puede usar credenciales diferentes en distintos entornos sin escribir código específico del entorno.
Para usar DefaultAzureCredential
en una aplicación de C++, añada el paquete azure-identity a su aplicación mediante vcpkg.
vcpkg add port azure-identity-cpp
A continuación, agregue lo siguiente en el archivo CMake:
find_package(azure-identity-cpp CONFIG REQUIRED)
target_link_libraries(<your project name> PRIVATE Azure::azure-identity)
Se accede a los servicios de Azure mediante clases de cliente especializadas de las distintas bibliotecas cliente del SDK de Azure. En el ejemplo de código siguiente se muestra cómo crear instancias de un DefaultAzureCredential
objeto y usarlo con una clase de cliente de Azure SDK. En este caso, es un SecretClient
objeto que se usa para acceder a los secretos de Azure KeyVault.
#include <azure/identity.hpp>
#include <azure/keyvault/secrets.hpp>
int main(){
auto const keyVaultUrl = std::getenv("AZURE_KEYVAULT_URL");
auto credential = std::make_shared<Azure::Identity::DefaultAzureCredential>();
Azure::Security::KeyVault::Secrets::SecretClient secretClient(keyVaultUrl, credential);
}
Cuando el código anterior se ejecuta en la estación de trabajo de desarrollo local, busca en las variables de entorno de una entidad de servicio de aplicación o en las herramientas de desarrollo instaladas localmente, como la CLI de Azure, para un conjunto de credenciales de desarrollador. Cualquier enfoque se puede usar para autenticar la aplicación en los recursos de Azure durante el desarrollo local.
Cuando se implementa en Azure, este mismo código también puede autenticar la aplicación en los recursos de Azure.
DefaultAzureCredential
puede recuperar la configuración del entorno y las configuraciones de identidad administrada para autenticarse en los servicios de Azure automáticamente.