Administración del acceso a una aplicación
La integración de una aplicación en el sistema de identidades de la organización conlleva desafíos en la administración del acceso, la evaluación de uso y los informes. Los administradores de TI o el personal del departamento de soporte técnico suelen necesitar supervisar el acceso a las aplicaciones. La asignación de acceso puede caer en un equipo de TI general o divisional, pero lo ideal es que los responsables de la toma de decisiones empresariales estén implicados, dando aprobación antes de que el departamento de TI complete el proceso.
Otras organizaciones invierten en integración con un sistema automatizado existente de administración de identidades y acceso, como Control de acceso basado en rol (RBAC) o Control de acceso basado en atributos (ABAC). Tanto la integración como el desarrollo de reglas tienden a ser procesos especializados y caros. La supervisión o los informes sobre cualquiera de los enfoques de administración tiene su propia inversión independiente, costosa y compleja.
¿Cómo ayuda Microsoft Entra ID?
Microsoft Entra ID admite una amplia administración de acceso para las aplicaciones configuradas, lo que permite a las organizaciones lograr fácilmente las directivas de acceso adecuadas, que van desde la asignación automática basada en atributos (escenarios ABAC o RBAC) hasta la delegación, pasando por la administración por parte del administrador. Con Microsoft Entra ID, se pueden conseguir fácilmente directivas complejas al combinar varios modelos de administración para una sola aplicación, e incluso se pueden volver a usar las reglas de administración entre aplicaciones con las mismas audiencias.
Con Microsoft Entra ID, los informes de asignación y uso están totalmente integrados, lo que permite a los administradores informar fácilmente sobre el estado y los errores de asignación, e incluso del uso.
Asignación de usuarios y grupos a una aplicación
La asignación de aplicaciones de Microsoft Entra se centra en dos modos de asignación principales:
Asignación individual: un administrador de TI con permisos de Administrador de aplicaciones en la nube en el directorio puede seleccionar cuentas de usuario individuales y concederles acceso a la aplicación.
Asignación basada en grupos (requiere Microsoft Entra ID P1 o P2): un administrador de TI con permisos de Administrador en la nube en el directorio puede asignar un grupo a la aplicación. El acceso de usuarios específicos viene determinado por si son miembros del grupo en el momento en que intentan acceder a la aplicación. Es decir, un administrador puede crear eficazmente una regla de asignación que indique "cualquier miembro actual del grupo asignado tiene acceso a la aplicación". Con esta opción de asignación, los administradores pueden beneficiarse de cualquiera de las opciones de administración de grupos de Microsoft Entra, incluidos grupos de pertenencia dinámica basados en atributos, grupos de sistemas externos (por ejemplo, Active Directory local o Workday), o grupos administrados por el administrador o autoadministrados. Un único grupo se puede asignar fácilmente a varias aplicaciones, lo que garantiza que las aplicaciones con afinidad de asignación puedan compartir reglas de asignación y así reducir la complejidad de la administración en general.
Nota:
No se admiten las pertenencias a grupos anidados para la asignación basada en grupos para aplicaciones en este momento.
Con estos dos modos de asignación, los administradores pueden lograr cualquier enfoque de administración de asignaciones deseable.
Requerir la asignación del usuario a una aplicación
Con algunos tipos de aplicaciones, existe la opción de requerir que los usuarios estén asignados a la aplicación. Al hacerlo, se impide que todos los usuarios puedan iniciar sesión, salvo aquellos que se asignen expresamente a la aplicación. Los siguientes tipos de aplicaciones admiten esta opción:
- Aplicaciones configuradas para el inicio de sesión único (SSO) federado con autenticación basada en SAML
- Aplicaciones Application Proxy que usan la autenticación previa de Microsoft Entra
- Aplicaciones, que se basan en la plataforma de aplicaciones de Microsoft Entra que usan la autenticación de OAuth 2.0 o OpenID Connect después de que un usuario o administrador dé su consentimiento a esa aplicación. Determinadas aplicaciones empresariales ofrecen más control sobre quién puede iniciar sesión.
Cuando se requiere la asignación de usuarios, solo podrán iniciar sesión los usuarios que se asignen a la aplicación (ya sea a través de una asignación directa de usuarios o según la pertenencia a grupos). Estos pueden acceder a la aplicación desde el portal Mis aplicaciones o a través de un vínculo directo.
Cuando no se requiere la asignación de usuarios, los usuarios sin asignar no ven la aplicación en mis aplicaciones, pero todavía pueden iniciar sesión en la propia aplicación (también conocida como inicio de sesión iniciado por SP) o pueden usar la Dirección URL de acceso de usuario en la página Propiedades de la aplicación’(también conocida como inicio de sesión iniciado por IDP). Para obtener más información sobre cómo requerir configuraciones de asignación de usuarios, consulta Configuración de una aplicación.
Esto no afecta a si una aplicación aparece o no en Aplicaciones. Las aplicaciones aparecen en el portal de los usuarios Mis aplicaciones una vez que se asigna un usuario o grupo a la aplicación.
Nota:
Cuando en una aplicación se necesita la asignación, no se permite el consentimiento del usuario para esa aplicación. Esto es así incluso si los usuarios hubieran dado su consentimiento para esa aplicación. Asegúrate de conceder consentimiento de administrador en todo el inquilino a las aplicaciones en las que sea necesaria la asignación.
En algunas aplicaciones, la opción para requerir la asignación de usuarios no está disponible en las propiedades de la aplicación. En estos casos, puedes usar PowerShell para establecer la propiedad appRoleAssignmentRequired en la entidad de servicio.
Determinación de la experiencia del usuario para acceder a las aplicaciones
Microsoft Entra ID ofrecevarias formas personalizables de implementar aplicaciones para los usuarios finales de su organización:
- Microsoft Entra Aplicaciones
- Iniciador de la aplicación Microsoft 365
- Inicio de sesión directo en aplicaciones (service-pr)
- Vínculos profundos a aplicaciones federadas, con contraseña o existentes
Puedes decidir si los usuarios asignados a una aplicación empresarial pueden verla en la página Aplicaciones y en el iniciador de aplicaciones de Microsoft 365.
Ejemplo: Asignación de aplicación compleja con Microsoft Entra ID
Considere una aplicación como Salesforce. En muchas organizaciones, Salesforce se usa principalmente en los equipos de ventas y marketing. A menudo, los miembros del equipo de marketing tienen acceso con privilegios elevados a Salesforce, mientras que los miembros del equipo de ventas obtienen acceso limitado. En muchos casos, una amplia población de trabajadores de la información obtiene acceso restringido a la aplicación. Las excepciones a estas reglas complican el asunto. Con frecuencia, es prerrogativa de los equipos líderes de marketing o de ventas conceder acceso a un usuario o cambiar su rol independientemente de estas reglas genéricas.
Con Microsoft Entra ID, las aplicaciones como Salesforce se pueden preconfigurar para el inicio de sesión único (SSO) y el aprovisionamiento automatizado. Después de configurar la aplicación, un administrador puede realizar la acción puntual de crear y asignar los grupos adecuados. En este ejemplo, un administrador puede ejecutar las siguientes asignaciones:
grupos dinámicos para representar automáticamente a todos los miembros de los equipos de ventas y marketing con atributos como departamento o rol:
- Todos los miembros de los grupos de marketing se asignarían al rol "marketing" en Salesforce.
- Todos los miembros de los grupos de equipo de ventas se asignarían al rol "ventas" en Salesforce. Para afinar más, se podrían usar varios grupos que representan los equipos de ventas regionales asignados a diferentes roles de Salesforce.
Para habilitar el mecanismo de excepciones, se podría crear un grupo de autoservicio para cada rol. Por ejemplo, el grupo de "excepción de marketing de Salesforce" se puede crear como un grupo de autoservicio. El grupo se puede asignar al rol de marketing de Salesforce y los integrantes del equipo de liderazgo de marketing se pueden convertir en propietarios. Los miembros del equipo de liderazgo de marketing podrían agregar o quitar usuarios, establecer una directiva de unión o incluso aprobar o rechazar solicitudes de unión de usuarios individuales. Este mecanismo se admite a través de una experiencia adecuada del trabajador de la información que no requiere entrenamiento especializado para propietarios o miembros.
En este caso, todos los usuarios asignados se aprovisionarían automáticamente en Salesforce. A medida que se agregan a diferentes grupos, su asignación de roles se actualiza en Salesforce. Los usuarios pueden detectar Salesforce y acceder a esta aplicación mediante el portal Mis aplicaciones, los clientes web de Office o navegando a su página de inicio de sesión organizativa de Salesforce. Los administradores pueden ver fácilmente el estado de uso y asignación mediante los informes de Microsoft Entra ID.
Los administradores pueden emplear el acceso condicional de Microsoft Entra para establecer directivas de acceso para roles específicos. Estas directivas pueden incluir si se permite el acceso fuera del entorno corporativo e incluso los requisitos de la autenticación multifactor o de los dispositivo para obtener acceso en diversos casos.
Acceso a aplicaciones de Microsoft
Las aplicaciones de Microsoft (como Exchange, SharePoint, Yammer, etc.) se asignan y administran de forma un poco diferente a las aplicaciones SaaS que no son de Microsoft u otras aplicaciones, que se integran con Microsoft Entra ID para el inicio de sesión único.
Hay tres maneras principales en que un usuario puede acceder a una aplicación publicada por Microsoft.
En el caso de aplicaciones de Microsoft 365 u otros conjuntos de aplicaciones de pago, a los usuarios se les concede acceso mediante la asignación de licencias o mediante la funcionalidad de asignación de licencias basada en grupo.
Para las aplicaciones que Microsoft o una organización que no es de Microsoft publican libremente para que los usen, se puede conceder acceso a los usuarios a través de consentimiento del usuario. Los usuarios inician sesión en la aplicación con su cuenta profesional o educativa de Microsoft Entra, que les permite tener acceso a un conjunto limitado de datos en sus cuentas.
En el caso de las aplicaciones que Microsoft o una organización que no es de Microsoft publican libremente para que los usen, también se puede conceder acceso a los usuarios a través de consentimiento del administrador. Esto significa que un administrador ha determinado que todos los usuarios de la organización pueden usar la aplicación, por lo que inician sesión en la aplicación con un Rol de administrador de roles con privilegios y conceden acceso a todos los miembros de la organización.
Algunas aplicaciones combinan estos métodos. Por ejemplo, algunas aplicaciones de Microsoft forman parte de una suscripción a Microsoft 365, pero siguen requiriendo consentimiento.
Los usuarios pueden acceder a las aplicaciones de Microsoft 365 a través de sus portales de Office 365 correspondientes. También puede mostrar u ocultar las aplicaciones de Microsoft 365 en la página Aplicaciones con el botón de alternancia de visibilidad de Office 365 en Configuración de usuario en su directorio.
Al igual que con las aplicaciones empresariales, puede asignar usuarios a determinadas aplicaciones de Microsoft a través del centro de administración de Microsoft Entra o mediante PowerShell.
Impedir el acceso a las aplicaciones a través de cuentas locales
Microsoft Entra ID permite a su organización configurar el inicio de sesión único para proteger cómo los usuarios se autentican en las aplicaciones con acceso condicional, autenticación multifactor, etc. Algunas aplicaciones tienen históricamente su propio almacén de usuarios local y permiten a los usuarios iniciar sesión en la aplicación mediante credenciales locales o un método de autenticación de copia de seguridad específico de la aplicación, en lugar de usar el inicio de sesión único. Estas funcionalidades de aplicación podrían usarse incorrectamente y permitir que los usuarios conserven el acceso a las aplicaciones incluso después de que ya no estén asignadas a la aplicación en Microsoft Entra ID o ya no puedan iniciar sesión en Microsoft Entra ID, y podrían permitir que los atacantes intenten poner en peligro la aplicación sin aparecer en los registros de Microsoft Entra ID. Para asegurarse de que los inicios de sesión en estas aplicaciones están protegidos por Microsoft Entra ID:
- Identifique qué aplicaciones conectadas al directorio para el inicio de sesión único permiten a los usuarios finales omitir el inicio de sesión único con una credencial de aplicación local o un método de autenticación de copia de seguridad. Deberá revisar la documentación proporcionada por el proveedor de aplicaciones para comprender si esto es posible y qué opciones de configuración están disponibles. A continuación, en esas aplicaciones, deshabilite la configuración que permite a los usuarios finales omitir el inicio de sesión único. Para probar la experiencia del usuario final, abra un explorador en InPrivate, conéctese a la página de inicio de sesión de las aplicaciones, proporcione la identidad de un usuario en el inquilino y compruebe que no hay ninguna opción para iniciar sesión que no sea a través de Microsoft Entra.
- Si la aplicación proporciona una API para administrar contraseñas de usuario, quite las contraseñas locales o establezca una contraseña única para cada usuario mediante las API. Esto impedirá que los usuarios finales inicien sesión en la aplicación con credenciales locales.
- Si la aplicación proporciona una API para administrar usuarios, configure el aprovisionamiento de usuarios de Microsoft Entra en esa aplicación para deshabilitar o eliminar cuentas de usuario cuando los usuarios ya no estén en el ámbito de la aplicación o el inquilino.