Parte 2: Necesidades de autenticación en este escenario de ejemplo

Parte anterior: Introducción y antecedentes

En este escenario de ejemplo, la aplicación principal tiene tres requisitos de autenticación distintos:

• Azure Key Vault

  La aplicación debe autenticarse con Azure Key Vault para recuperar una clave de API almacenada de forma segura necesaria para llamar a un servicio de terceros.

• API de terceros

  Una vez recuperada la clave de API, la aplicación la usa para autenticarse con la API externa de terceros.

• Almacenamiento de colas de Azure

  Después de procesar la solicitud, la aplicación debe autenticarse con Azure Queue Storage para poner en cola un mensaje para el procesamiento asincrónico o diferido.

Estas tareas requieren que la aplicación administre tres conjuntos de credenciales:

• Dos para los recursos de Azure (Key Vault y Storage)

• Uno para un servicio externo (API de terceros)

Desafíos de autenticación clave

La creación de aplicaciones en la nube seguras requiere un control cuidadoso de las credenciales, especialmente cuando hay varios servicios implicados. En este escenario de ejemplo se presentan varios desafíos críticos:

• Dependencia circular en Key Vault

  La aplicación usa Azure Key Vault para almacenar de forma segura secretos, como claves de API de terceros o credenciales de Azure Storage. Sin embargo, para recuperar esos secretos, la aplicación debe autenticarse primero con Key Vault. Esto crea un problema circular: la aplicación necesita credenciales para acceder a Key Vault, pero esas credenciales deben almacenarse de forma segura. Sin una solución segura, esto podría provocar credenciales codificadas de forma segura o configuraciones no seguras en entornos de desarrollo.

• Control seguro de claves de API de terceros

  Después de recuperar la clave de API de Key Vault, la aplicación debe usarla para llamar a un servicio externo de terceros. Esta clave debe manipularse con cuidado extremo.

  • Nunca se codifica de forma rígida en archivos de configuración o código fuente
  • Nunca se registró en stdout, stderr ni en los registros de la aplicación
  • Solo se mantiene en la memoria y se accede a él en tiempo de ejecución, justo antes de usar
  • Se gestiona rápidamente una vez completada la solicitud

  Si no se siguen estas prácticas, aumenta el riesgo de pérdida de credenciales o uso no autorizado.

• Protección de las credenciales de Azure Queue Storage

  Para escribir mensajes en Azure Queue Storage, la aplicación normalmente necesita una cadena de conexión o un token de acceso compartido. Estas credenciales:

  • Debe almacenarse en una ubicación segura, como Key Vault.
  • No debe aparecer en registros, trazas ni herramientas de desarrollo
  • Solo se debe tener acceso a ellos a través de mecanismos de tiempo de ejecución seguros
  • Requerir una configuración de RBAC adecuada si se usa la identidad administrada

• Flexibilidad del entorno

  La aplicación debe ejecutarse de forma confiable en entornos de desarrollo local y producción en la nube, con el mismo código base y la misma lógica condicional mínima.

  Esto significa lo siguiente:

  • No hay secretos específicos del entorno insertados en el código
  • No es necesario alternar manualmente las credenciales ni las rutas de acceso lógicas
  • Uso coherente de la autenticación basada en identidades entre entornos

autenticación de Azure-First con el identificador de Entra de Microsoft

A medida que las aplicaciones en la nube se escalan en complejidad e integran con más servicios, la autenticación segura y simplificada se convierte en esencial. Azure ofrece un modelo de identidad "primero en Azure" a través de Microsoft Entra ID, lo que permite la administración unificada de identidades e integración sin problemas con los servicios de Azure para la autenticación segura y sin credenciales.

En lugar de administrar manualmente secretos o incrustar credenciales en el código de aplicación, una práctica propensa a riesgos de seguridad, el identificador de Entra de Microsoft permite que las aplicaciones se autentiquen de forma segura mediante identidades administradas.

Las principales ventajas de las identidades administradas de Microsoft Entra son:

• Sin secretos en el código

  Las aplicaciones ya no requieren cadenas de conexión codificadas de forma codificada, secretos de cliente ni claves.

• Identidad integrada para aplicaciones

  Azure puede asignar automáticamente una identidad administrada a la aplicación, lo que permite el acceso seguro a los servicios, como Key Vault, Storage y SQL sin credenciales adicionales.

• Coherencia del entorno

  El mismo código y modelo de identidad funcionan tanto en entornos de desarrollo local como hospedados en Azure mediante DefaultAzureCredential del SDK de Azure.

Flujo de identidad específico del entorno

Las aplicaciones que usan microsoft Entra ID para la autenticación se benefician de un modelo de identidad flexible que funciona perfectamente en entornos de desarrollo locales y hospedados en Azure. Esta coherencia se logra mediante el SDK de DefaultAzureCredentialAzure, que selecciona automáticamente el método de identidad adecuado en función del entorno.

Entorno de Azure

Cuando la aplicación se implementa en Azure:

• Una identidad administrada se asigna automáticamente a la aplicación.
• Azure controla el ciclo de vida de emisión de tokens y credenciales internamente, sin secretos manuales necesarios.
• La aplicación usa el control de acceso basado en roles (RBAC) Role-Based o las directivas de acceso de Key Vault para acceder a los servicios.

Entorno de desarrollo locales

Durante el desarrollo local:

• Una entidad de servicio actúa como identidad de la aplicación.
• Los desarrolladores se autentican mediante la CLI de Azure (az login), las variables de entorno o las integraciones de Visual Studio/VS Code.
• El mismo código de aplicación se ejecuta sin modificaciones; solo cambia el origen de la identidad.

En ambos entornos, los SDK de Azure usan el DefaultAzureCredential, que abstrae el origen de identidad y selecciona automáticamente el método correcto.

Procedimientos recomendados para el desarrollo seguro

Aunque es posible establecer secretos como variables de entorno (por ejemplo, a través de Azure App Settings), este enfoque tiene desventajas:

• Debe replicar manualmente secretos en entornos locales.
• Existe el riesgo de que los secretos se filtren hacia el control de código fuente.
• Es posible que se requiera lógica adicional para diferenciar entre entornos.

En su lugar, el enfoque recomendado es:

• Use Key Vault para almacenar claves de API de terceros y otros secretos.
• Asigne una identidad administrada a la aplicación implementada.
• Use una entidad de servicio para el desarrollo local y asígnele los mismos derechos de acceso.
• Use DefaultAzureCredential en el código para abstraer la lógica de autenticación.
• Evite almacenar o registrar credenciales.

Flujo de autenticación en la práctica

Este es el funcionamiento de la autenticación en tiempo de ejecución:

• El código crea una DefaultAzureCredential instancia.
• Utiliza esta credencial para instanciar un cliente (por ejemplo, SecretClient, QueueServiceClient).
• Cuando la aplicación invoca un método (por ejemplo, get_secret()), el cliente usa la credencial para autenticar la solicitud.
• Azure comprueba la identidad y comprueba si tiene el rol o la directiva correctos para realizar la operación.

Este flujo garantiza que la aplicación pueda acceder de forma segura a los servicios de Azure sin insertar secretos en archivos de código o configuración. También permite cambiar sin problemas entre el desarrollo local y la implementación en la nube sin cambiar la lógica de autenticación.

parte 3: implementación de api de terceros >>>