Administración de identidad y acceso de aplicaciones
En este artículo se describen las consideraciones y recomendaciones que los propietarios y desarrolladores de aplicaciones pueden usar para diseñar la administración de identidad y acceso para aplicaciones nativas de la nube.
Si el equipo migra o crea aplicaciones nativas de la nube, debe tener en cuenta los requisitos de autenticación y acceso para las aplicaciones. Estos requisitos determinan cómo los usuarios se autentican en las aplicaciones y cómo se autentican los recursos de la aplicación entre sí, por ejemplo, cuando una aplicación web accede a una base de datos SQL.
En el área de diseño automatización de la plataforma y DevOps, se recomienda que el equipo de la aplicación realice la transición de las cargas de trabajo a venta de suscripciones. Como parte del proceso de venta de suscripciones, el equipo de la aplicación debe proporcionar requisitos de identidad y acceso al equipo de la plataforma para que puedan crear las suscripciones adecuadas. Los propietarios de aplicaciones son responsables de la administración de identidad y acceso de aplicaciones individuales. Deben administrar su aplicación mediante los servicios centralizados que proporciona el equipo de la plataforma.
Consideraciones de diseño
Para ayudar a reducir el riesgo de acceso no autorizado a las aplicaciones, incorpore las siguientes consideraciones al diseño.
Hay varios estándares de autenticación y autorización, como OAuth 2.0, OpenID Connect, tokens web JSON (JWT) y SAML (lenguaje de marcado de aserción de seguridad). Determine qué estándares de autenticación y autorización se van a usar para la aplicación.
Al solicitar una zona de aterrizaje de aplicaciones al equipo de la plataforma, puede ayudar a garantizar que creen las suscripciones adecuadas haciéndoles las siguientes preguntas:
¿Cómo se autenticarán los usuarios finales y accederán a la aplicación?
¿Quién necesita permisos de control de acceso basado en roles (RBAC) para los recursos y servicios que utiliza la aplicación?
¿Los roles integrados existentes cubren los requisitos de acceso RBAC, tanto para el plano de control como para el plano de datos, o es necesario crear nuevos roles personalizados?
¿Ha implementado el equipo de plataforma alguna directiva de cumplimiento que pueda causar problemas con la aplicación?
¿Qué componentes de la aplicación deben comunicarse entre sí?
¿Hay algún requisito para acceder a los recursos compartidos, como Microsoft Entra Domain Services, que se implementan en la zona de aterrizaje de la plataforma?
Azure Key Vault e identidades administradas
Las infracciones de seguridad de los recursos de la nube pública suelen tener su origen en la filtración de credenciales insertadas en código u otro texto. Puede usar identidades administradas y Key Vault para implementar el acceso mediante programación y ayudar a reducir el riesgo de robo de credenciales.
Si la aplicación o la carga de trabajo requieren un servicio para almacenar de forma segura las credenciales, puede usar Key Vault para administrar secretos, claves y certificados.
Para evitar tener credenciales en el código, puede usar identidades administradas con máquinas virtuales de Azure para autenticarse en cualquier servicio que admita la autenticación de Microsoft Entra ID. Para obtener más información, consulte Uso de identidades administradas para recursos de Azure en una máquina virtual para adquirir un token de acceso.
Las identidades administradas proporcionan una entidad de identidad administrada automáticamente que las aplicaciones y recursos utilizan al conectarse a los recursos que admiten la autenticación de Microsoft Entra ID. Las aplicaciones pueden usar identidades administradas para obtener tokens de Microsoft Entra ID sin necesidad de administrar credenciales.
Puede usar identidades administradas asignadas por el sistema o asignadas por el usuario.
Es fácil confundir cómo las entidades de servicio y las identidades administradas acceden a los recursos de Azure. Para comprender la diferencia entre los dos, consulte Desmitificación de entidades de servicio: identidades administradas.
Siempre que sea posible, use identidades administradas para admitir la autenticación en lugar de usar entidades de servicio y registros de aplicaciones de Microsoft Entra ID. Debe tener los roles RBAC de administrador de aplicaciones o desarrollador de aplicaciones para crear entidades de servicio y registros de aplicaciones. Estos roles con privilegios normalmente se asignan al equipo de la plataforma o al equipo de identidades. Use identidades administradas para eliminar la necesidad de que el equipo de plataforma cree entidades de servicio y registros de aplicaciones para el equipo de la aplicación.
Puede usar identidades administradas para autenticarse en cualquier servicio que admita la autenticación de Microsoft Entra. Sin embargo, no todos los servicios admiten identidades administradas para acceder a otros servicios. Para algunos servicios, puede ser necesario almacenar las credenciales. Debe almacenar credenciales de forma segura, evitar compartir credenciales con otros servicios y seguir el principio de privilegios mínimos. Para obtener más información, consulte Servicios de Azure que pueden usar identidades administradas para acceder a otros servicios.
Puede usar identidades administradas con máquinas virtuales (VM) de Azure para autenticarse en cualquier servicio que admita la autenticación de Microsoft Entra ID. Para obtener más información, consulte Uso de identidades administradas para recursos de Azure en una máquina virtual para adquirir un token de acceso.
Hay restricciones en el traslado de recursos con identidades administradas entre suscripciones y regiones. Por ejemplo, puede mover recursos entre suscripciones o regiones para una fusión, adquisición o repatriación de recursos por motivos de soberanía de datos.
Si un recurso de Azure tiene identidades asignadas por el usuario o por el sistema, no puede transferir el recurso a otra suscripción o región de Azure. Debe eliminar las identidades administradas antes de mover el recurso. Después de moverlas, debe volver a crear las identidades administradas y asignarlas al recurso. Para obtener más información, consulte Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción.
Si mueve una suscripción de un directorio a otro, no se conservan las identidades administradas. Debe mover el recurso y volver a crear manualmente las identidades administradas.
De forma similar a las asignaciones de roles RBAC de usuario, siga el principio de privilegios mínimos al conceder a una identidad administrada acceso a un recurso.
Usuarios externos
Puede evaluar escenarios que impliquen la configuración de usuarios, clientes o asociados externos para que puedan acceder a los recursos. Determine si estos escenarios implican configuraciones de Microsoft Entra B2B o Azure Active Directory B2C (Azure AD B2C). Para obtener más información, consulte Información general sobre Microsoft Entra ID.
Recomendaciones de diseño
Tenga en cuenta las siguientes recomendaciones al diseñar la administración de identidad y acceso de las aplicaciones.
OpenID Connect
Si el equipo de aplicaciones usa canalizaciones de integración continua y entrega continua (CI/CD) para implementar aplicaciones mediante programación, configure la autenticación de OpenID Connect en los servicios de Azure. OpenID Connect usa un token temporal sin credenciales para autenticarse en los servicios de Azure. Para más información, consulte Federación de identidades de carga de trabajo.
Si OpenID Connect no es compatible, cree una entidad de servicio y asigne los permisos necesarios para permitir la implementación del código de la infraestructura o la aplicación. Para obtener más información, consulte el módulo de formación Autenticación de la canalización de implementación de Azure mediante entidades de servicio.
Control de acceso basado en atributos
Para restringir aún más el acceso y evitar el acceso no autorizado a los datos, use el control de acceso basado en atributos (ABAC) donde se admita, por ejemplo, con Azure Blob Storage.
Acceso a máquinas virtuales
Siempre que sea posible, use Microsoft Entra ID para controlar el acceso a las máquinas virtuales de Azure. Use Microsoft Entra ID en lugar de la autenticación local para proporcionar acceso a las máquinas virtuales, aprovechando el acceso condicional de Microsoft Entra, el registro de auditoría y la autenticación multifactor de Microsoft Entra (MFA). Esta configuración reduce el riesgo de que los atacantes aprovechen los servicios de autenticación local no seguros. Para obtener más información, consulte Inicio de sesión en una máquina virtual Linux en Azure mediante Microsoft Entra ID y OpenSSH e Inicio de sesión en una máquina virtual Windows en Azure mediante Microsoft Entra ID, incluido sin contraseña.
Plataforma de identidad de Microsoft
Cuando los desarrolladores crean una aplicación nativa de la nube, deben usar la Plataforma de identidades de Microsoft para desarrolladores como proveedor de identidades para sus aplicaciones. La plataforma de identidades de Microsoft proporciona un servicio de autenticación compatible con el estándar OpenID Connect que los desarrolladores pueden usar para autenticar varios tipos de identidad, entre las que se incluyen:
Cuentas profesionales o educativas (aprovisionadas mediante Microsoft Entra ID)
Cuentas de Microsoft personales (Skype, Xbox, Outlook.com)
Cuentas de redes sociales o locales, mediante Microsoft Entra ID
La lista de comprobación Procedimientos recomendados y recomendaciones de la plataforma de identidades de Microsoft proporciona instrucciones sobre cómo integrar de forma eficaz la aplicación con la plataforma de identidades de Microsoft.
Identidades administradas
Para habilitar el acceso entre recursos de Azure que no necesitan usar credenciales, use identidades administradas.
No debe compartir credenciales ni identidades administradas entre varios entornos o aplicaciones. Por ejemplo, no use identidades para recursos de producción ni recursos de desarrollo/pruebas, ni siquiera para la misma aplicación. Cree credenciales independientes para cada instancia de una aplicación para reducir la probabilidad de que una instancia de prueba en peligro afecte a los datos de producción. Las credenciales independientes también facilitan la revocación de credenciales cuando ya no son necesarias.
Cuando haya un requisito para usar identidades administradas a escala, use una identidad administrada asignada por el usuario para cada tipo de recurso de cada región. Este enfoque impide la renovación de identidades. Por ejemplo, el agente de Azure Monitor requiere una identidad administrada en máquinas virtuales de Azure supervisadas, lo que puede hacer que Microsoft Entra ID cree (y elimine) un número considerable de identidades. Puede crear identidades administradas asignadas por el usuario una vez y compartirlas entre varias máquinas virtuales. Use Azure Policy para implementar esta recomendación.
Key Vault
Puede usar Key Vault para administrar los secretos, claves y certificados que usan las aplicaciones.
Para administrar el acceso a secretos (plano de datos) y para el acceso administrativo (plano de control), use RBAC.
Para controlar el acceso de la aplicación a Key Vault, use identidades administradas.
Debe usar almacenes de claves independientes para cada entorno de aplicación (desarrollo, preproducción, producción) en cada región. Use RBAC para administrar el acceso a secretos, claves y certificados (operaciones del plano de datos) y el acceso a Key Vault (plano de control). Implemente almacenes de claves que tengan secretos de aplicación en las zonas de aterrizaje de la aplicación.
Proxy de aplicación de Microsoft Entra
Para acceder a las aplicaciones que usan la autenticación local de forma remota a través de Microsoft Entra ID, use el proxy de aplicación de Microsoft Entra. El proxy de aplicación de Microsoft Entra proporciona acceso remoto seguro a las aplicaciones web locales, incluidas las aplicaciones que usan protocolos de autenticación más antiguos. Después de un inicio de sesión único en Microsoft Entra ID, los usuarios pueden acceder a las aplicaciones locales y en la nube mediante una dirección URL externa o un portal de aplicaciones interno.
Puede implementar el proxy de aplicación de Microsoft Entra como una sola instancia en un inquilino de Microsoft Entra ID. Para la configuración se necesita al menos el rol de Microsoft Entra ID con privilegios de administrador de aplicaciones. Si su organización usa la democratización de la suscripción como modelo de asignación de roles, es posible que los propietarios de aplicaciones no tengan los permisos necesarios para configurar el proxy de aplicación de Microsoft Entra. En este caso, el equipo de la plataforma debe configurar el proxy de aplicación de Microsoft Entra para el propietario de la aplicación.
Si usa canalizaciones de implementación de CI/CD con permisos suficientes, los propietarios de aplicaciones pueden configurar el proxy de aplicación de Microsoft Entra mediante la API de Microsoft Graph.
Si la aplicación usa protocolos heredados, como Kerberos, asegúrese de que la zona de aterrizaje de la aplicación tenga conectividad de red con controladores de dominio en la suscripción de la plataforma de identidades de Microsoft.