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 que la aplicación recupera la clave de API, usa la clave 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 conjuntos para recursos de Azure (Key Vault y Storage)

• Un conjunto 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. Esta situación crea un problema circular: la aplicación necesita credenciales para acceder a Key Vault, pero debe almacenar esas credenciales de forma segura. Sin una solución segura, este problema podría provocar credenciales codificadas de forma dura 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. Controle esta clave con cuidado extremo:

  • Nunca lo codifique de forma fija en el código fuente ni en los archivos de configuración
  • Nunca lo registre en stdout, stderr o registros de aplicación
  • Mantenerla solo en la memoria y acceder a ella en tiempo de ejecución, justo antes de usar
  • Eliminarlo 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.

  Este requisito significa:

  • No insertar secretos específicos del entorno en el código
  • No cambiar manualmente las credenciales ni las rutas lógicas
  • Uso de la autenticación basada en identidades de forma coherente entre entornos

Autenticación prioritaria para Azure con Microsoft Entra ID

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 Azure-first a través de Microsoft Entra ID, lo que permite la administración unificada de identidades e integración sin problemas con Azure servicios para la autenticación segura y sin credenciales.

En lugar de administrar manualmente secretos o insertar credenciales en el código de aplicación( una práctica propensa a riesgos de seguridad), Microsoft Entra ID permite a las aplicaciones autenticarse 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, por lo que puede acceder de forma segura a servicios como Key Vault, Storage y SQL sin credenciales adicionales.

• Coherencia del entorno

  El mismo código y modelo de identidad funcionan tanto en el desarrollo local como en entornos alojados en Azure mediante el uso de 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. El SDK de Azure DefaultAzureCredential proporciona esta coherencia seleccionando automáticamente el método de identidad adecuado en función del entorno.

Entorno de Azure

Al implementar la aplicación en Azure:

• La aplicación obtiene automáticamente una identidad administrada.
• Azure administra el ciclo de vida de las credenciales y la emisión de tokens internamente, por lo que no es necesario controlar ningún secreto.
• La aplicación accede a los servicios mediante Role-Based Access Control (RBAC) o directivas de acceso de Key Vault.

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 las integraciones de CLI de Azure (az login), variables de entorno o Visual Studio/VS Code.
• El mismo código de aplicación se ejecuta sin modificaciones: solo cambia el origen de identidad.

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

Procedimientos recomendados para el desarrollo seguro

Aunque puede establecer secretos como variables de entorno (por ejemplo, a través de App de Azure Configuración), este enfoque tiene desventajas:

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

En su lugar, use el siguiente enfoque:

• 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.
• Use esta credencial para crear instancias de 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 >>>