Autenticación sin secretos para recursos de Azure

2025-05-13

Las contraseñas y las claves de seguridad eran la base de la seguridad digital durante décadas, pero ya no pueden mantenerse al día con las amenazas modernas. La autenticación sin secretos, alineada con el modelo de confianza cero, desplaza el control de acceso y la comprobación del usuario a un enfoque sin credenciales. La autenticación sin secreto implica diseñar aplicaciones seguras en la nube sin depender de credenciales compartidas tradicionales, como contraseñas, certificados, secretos o claves de seguridad. La autenticación sin secreto proporciona las siguientes ventajas:

Riesgos reducidos de credenciales: al eliminar contraseñas, la autenticación sin secretos mitiga los riesgos asociados con el robo de credenciales, los ataques de suplantación de identidad y los ataques por fuerza bruta. Este enfoque usa elementos de identidad verificables, como biometría, certificados digitales y tokens de hardware.
Control de acceso simplificado: mejora la seguridad y simplifica la experiencia del usuario al confiar en mecanismos que comprueban la identidad verdadera en lugar de secretos compartidos. Esto se alinea con los principios de Confianza cero comprobando cada solicitud de acceso en función de la identidad verdadera.
Experiencia mejorada del usuario final: los usuarios se benefician de un proceso de autenticación más seguro y sin problemas, lo que reduce la necesidad de restablecimientos de contraseña y mejora la satisfacción general del usuario.

En este artículo se explora la autenticación sin secretos en Azure, sus ventajas y cómo implementarla en varios escenarios, incluidas las aplicaciones cliente, la comunicación entre servicios de Azure y las cargas de trabajo externas.

Desafíos de seguridad de contraseñas y secretos

Las contraseñas y otros secretos deben usarse con precaución, y los desarrolladores nunca deben colocarlas en una ubicación no segura. Muchas aplicaciones se conectan a servicios de bases de datos de back-end, caché, mensajería y eventos mediante nombres de usuario, contraseñas y claves de acceso. Si se expone, estas credenciales podrían usarse para obtener acceso no autorizado a información confidencial, como un catálogo de ventas que creó para una próxima campaña o datos de clientes que deben ser privados.

La inserción de contraseñas en una propia aplicación presenta un riesgo de seguridad enorme por muchas razones, incluida la detección a través de un repositorio de código. Muchos desarrolladores externalizan estas contraseñas mediante variables de entorno para que las aplicaciones puedan cargarlas desde diferentes entornos. Sin embargo, esto solo cambia el riesgo del propio código a un entorno de ejecución. Cualquier persona que obtenga acceso al entorno puede robar contraseñas, lo que a su vez aumenta el riesgo de filtración de datos.

Desafíos de seguridad de las claves

El uso de claves criptográficas en el desarrollo de aplicaciones de Azure presenta varios desafíos que pueden complicar tanto la seguridad como la eficacia operativa. Un problema importante es las complejidades clave de la administración, que implican las tareas complicadas de rotar, distribuir y almacenar de forma segura las claves en varios servicios y entornos. Este proceso continuo requiere recursos dedicados y puede aumentar significativamente los costos operativos debido a la necesidad de mantenimiento y supervisión normales. Además, existen riesgos de seguridad sustanciales asociados a la exposición o uso indebido de claves, ya que el acceso no autorizado debido a claves filtradas puede poner en peligro la información confidencial. Además, los métodos de autenticación basados en claves a menudo carecen de la escalabilidad y la flexibilidad necesarias para entornos dinámicos, lo que dificulta la adaptación a los requisitos cambiantes y las operaciones de escalado de forma eficaz. Estos desafíos resaltan la importancia de adoptar métodos de autenticación más seguros y eficaces, como identidades administradas, para mitigar los riesgos y simplificar las operaciones.

La aplicación cliente (orientada al usuario) accede a los recursos protegidos de Microsoft Entra.

Características como la autenticación multifactor (MFA) son una excelente manera de proteger su organización, pero los usuarios a menudo se frustran con la capa de seguridad adicional además de tener que recordar sus contraseñas. Los métodos de autenticación sin contraseña son más cómodos porque la contraseña se quita y se reemplaza por algo que tiene o algo que es o sabe.

Cada organización tiene necesidades diferentes en lo que respecta a la autenticación. Microsoft Entra ID y Azure Government integran las siguientes opciones de autenticación sin contraseña:

Windows Hello para empresas
Credencial de plataforma para macOS
Inicio de sesión único de plataforma (PSSO) para macOS con autenticación con tarjeta inteligente
Microsoft Authenticator
Claves de paso (FIDO2)
Autenticación basada en certificados

Para más información, lea Inicio de sesión sin contraseña de Microsoft Entra.

Servicio de Azure a Azure (dentro de Azure)

Al autenticarse entre recursos de Azure (autenticación de servicio a servicio), el enfoque recomendado es usar identidades administradas para recursos de Azure. Sin embargo, al autenticar y acceder a los recursos entre inquilinos, debe configurar una identidad administrada como una credencial de identidad federada en una aplicación.

Accede a los recursos protegidos de Microsoft Entra (mismo inquilino)

Para escenarios en los que necesite autenticación entre servicios de recursos de Azure y los recursos se encuentran en el mismo locatario, las identidades administradas y la clase DefaultAzureCredential de la biblioteca cliente de Identidad de Azure son la opción recomendada para este propósito.

Una identidad administrada es una identidad que se puede asignar a un recurso de proceso de Azure (por ejemplo, Azure Virtual Machines, Azure Functions o Azure Kubernetes) o a cualquier servicio de Azure que admita identidades administradas. Una vez asignada una identidad administrada en el recurso de cómputo, se puede autorizar para acceder a recursos de dependencia descendente, como una cuenta de almacenamiento, una base de datos SQL, Cosmos DB, etc. Las identidades administradas reemplazan secretos como claves de acceso o contraseñas y certificados u otras formas de autenticación para las dependencias de servicio a servicio.

Para más información, lea ¿Qué son las identidades administradas para los recursos de Azure?.

Implemente DefaultAzureCredential y las identidades administradas en su aplicación para crear conexiones sin necesidad de contraseña a los servicios de Azure a través de Microsoft Entra ID y el control de acceso basado en roles (RBAC). DefaultAzureCredential admite varios métodos de autenticación y determina automáticamente qué se debe usar en tiempo de ejecución. Este enfoque permite que la aplicación use diferentes métodos de autenticación en distintos entornos (desarrollo local frente a producción) sin implementar código específico del entorno.

Para más información sobre el uso DefaultAzureCredential y una identidad administrada en la aplicación, consulte Configuración de conexiones sin secreto entre aplicaciones y servicios de Azure.

Accede a los recursos protegidos de Microsoft Entra (entre inquilinos)

Las identidades administradas se recomiendan para escenarios en los que se necesita autenticación entre servicios entre recursos de Azure. Sin embargo, no se admiten identidades administradas para cuando se accede a recursos entre inquilinos (aplicaciones multiinquilino). Anteriormente, creó una aplicación multiinquilino con un secreto de cliente o certificado como credenciales para autenticar y acceder a los recursos en varios inquilinos. Esto le deja con riesgos significativos en torno a la exposición de secretos y agrega la carga de almacenar, rotar y mantener los ciclos de vida de los certificados.

Las cargas de trabajo de Azure ahora pueden usar identidades administradas como credenciales de identidad federada para acceder de forma segura a los recursos protegidos de Microsoft Entra entre inquilinos sin depender de secretos ni certificados.

Para más información, consulte Configuración de una aplicación para confiar en una identidad administrada.

El servicio de Azure accede a recursos protegidos externos o que no son de Microsoft Entra

En el caso de las cargas de trabajo de Azure que autentican y acceden a recursos que no están protegidos por los servicios de Microsoft Entra o Azure que requieren una contraseña, un secreto, una clave o un certificado para el acceso, no puede usar directamente identidades administradas. En este caso, use Azure Key Vault para almacenar las credenciales del recurso de destino. Utilizar una identidad administrada de su carga de trabajo para recuperar las credenciales de la bóveda de claves y acceder al recurso de destino utilizando las credenciales.

Para más información, lea Autenticar en Key Vault en código.

La carga de trabajo externa (fuera de Azure) accede a los recursos protegidos de Microsoft Entra.

Cuando una carga de trabajo de software se ejecuta fuera de Azure (por ejemplo, un centro de datos local, en la máquina del desarrollador o en otra nube) y necesita acceder a los recursos de Azure, no puede usar una identidad administrada de Azure directamente. En el pasado, registraría una aplicación con la plataforma de identidad de Microsoft y usaría un secreto de cliente o un certificado para que la aplicación externa inicie sesión. Estas credenciales suponen un riesgo para la seguridad y se deben almacenar de forma segura y cambiar periódicamente. También corre el riesgo de tiempo de inactividad del servicio si las credenciales expiran.

La federación de identidades de carga de trabajo se utiliza para configurar una identidad administrada asignada por el usuario o un registro de aplicaciones en Microsoft Entra ID, de manera que confíen en tokens de un proveedor externo de identidades (IdP), como GitHub o Google. Una vez creada esa relación de confianza, la carga de trabajo de software externa intercambia tokens de confianza desde el IdP externo por tokens de acceso de la plataforma de identidad de Microsoft. La carga de trabajo de software utiliza ese token de acceso para acceder a los recursos protegidos de Microsoft Entra a los que se ha concedido acceso a la carga de trabajo. Se elimina la carga de mantenimiento de administrar manualmente las credenciales y elimina el riesgo de filtración de secretos o de que los certificados expiren.

Para más información, consulte Federación de identidades de carga de trabajo.