Preparación de una revisión del acceso de los usuarios a una aplicación

  • Artículo

Microsoft Entra ID Governance le permite equilibrar la productividad de los empleados y la seguridad que necesita su organización con la visibilidad y los procesos adecuados. Proporciona funcionalidades que garantizan que las personas adecuadas tienen el acceso adecuado a los recursos adecuados.

Las organizaciones con requisitos de cumplimiento o planes de administración de riesgos tienen aplicaciones confidenciales o críticas para la empresa. La confidencialidad de la aplicación puede basarse en su propósito o en los datos que contiene, como información financiera o información personal de los clientes de la organización. Normalmente solo un subconjunto de todos los usuarios de la organización estará autorizado para acceder a estas aplicaciones y solo se debe permitir el acceso en función de los requisitos empresariales documentados. Microsoft Entra ID se puede integrar con muchas aplicaciones SaaS populares, aplicaciones locales y aplicaciones que desarrolle su organización mediante las interfaces de API y el protocolo estándar. A través de estas interfaces, Microsoft Entra ID puede ser el origen fidedigno para controlar quién tiene acceso a esas aplicaciones. A medida que integre las aplicaciones con Microsoft Entra ID, puede usar las revisiones de acceso para volver a certificar a los usuarios que tienen acceso a esas aplicaciones y quitar el acceso a los usuarios que ya no lo necesitan. También puede usar otras características, incluidos los términos de uso, el acceso condicional y la administración de derechos, para controlar el acceso a las aplicaciones, como se describe en Cómo controlar el acceso a las aplicaciones de su entorno.

Requisitos previos para revisar el acceso

Para usar Microsoft Entra ID para una revisión del acceso a una aplicación, debe tener una de las siguientes licencias en el inquilino:

  • Microsoft Entra ID P2 o Microsoft Entra ID Governance
  • Licencia de Enterprise Mobility + Security (EMS) E5

Aunque el uso de la característica de revisiones de acceso no requiere que los usuarios tengan asignadas esas licencias para usar la característica, deberá tener suficientes puestos de licencia. Para obtener más información, consulte Escenarios de licencia de ejemplo para las revisiones de acceso.

Además, aunque no es necesario para revisar el acceso a una aplicación, también se recomienda revisar periódicamente la pertenencia a roles de directorio con privilegios que tienen la capacidad de controlar el acceso de otros usuarios a todas las aplicaciones. Los administradores de Global Administrator, Identity Governance Administrator, User Administrator, Application Administrator, Cloud Application Administrator y Privileged Role Administrator pueden realizar cambios en los usuarios y sus asignaciones de roles de aplicación, por lo que debe asegurarse de que se ha programado la revisión de acceso de estos roles de directorio.

Determinación de cómo se integra la aplicación con Microsoft Entra ID

Para que las revisiones de acceso se utilicen para una aplicación, ésta debe estar primero integrada con Microsoft Entra ID y representada en su directorio. Para que una aplicación se integre en Microsoft Entra ID, se debe cumplir uno de dos requisitos:

  • La aplicación se basa en Microsoft Entra ID para el inicio de sesión único federado y Microsoft Entra ID controla la emisión de tokens de autenticación. Si Microsoft Entra ID es el único proveedor de identidades para la aplicación, solo los usuarios que están asignados a uno de los roles de la aplicación en Microsoft Entra ID pueden iniciar sesión en ella. Los usuarios a los que una revisión deniega el acceso, pierden su asignación de roles de aplicación y ya no pueden obtener un nuevo token para iniciar sesión en la aplicación.
  • La aplicación se basa en listas de usuarios o grupos que Microsoft Entra ID proporciona a la aplicación. Este cumplimiento podría realizarse a través de un protocolo de aprovisionamiento, como System for Cross-Domain Identity Management (SCIM), mediante la aplicación que consulta Microsoft Entra ID a través de Microsoft Graph, Microsoft Entra aprovisiona usuarios en la base de datos o grupos de la aplicación que se escriben en AD DS. Los usuarios a los que la revisión deniega el acceso, pierden su asignación de roles de aplicación o pertenencia a grupo y, cuando esos cambios están disponibles para la aplicación, los usuarios ya no tendrán acceso.

Si no se cumplen ninguno de esos criterios para una aplicación, ya que la aplicación no se basa en Microsoft Entra ID, las revisiones de acceso se pueden seguir usando, pero habrá algunas limitaciones. Los usuarios que no están en Microsoft Entra ID o que no estén asignados a los roles de aplicación en Microsoft Entra ID no se incluirán en la revisión. Además, los cambios para quitar a los usuarios con acceso denegado no podrán enviarse automáticamente a la aplicación si no hay ningún protocolo de aprovisionamiento que admita la aplicación. En su lugar, la organización debe tener un proceso para enviar los resultados de una revisión completada a la aplicación.

Para permitir que se atienda a una amplia variedad de aplicaciones y requisitos de TI con Microsoft Entra ID, existen varios patrones de cómo se puede integrar una aplicación con Microsoft Entra ID. Cada patrón usa diferentes artefactos de Microsoft Entra. En el siguiente diagrama de flujo se muestra cómo seleccionar entre tres patrones de integración (A, B y C), que son adecuados para que las aplicaciones los usen con la gobernanza de identidades. Saber qué patrón se usa para una aplicación determinada le ayuda a configurar los recursos adecuados en Microsoft Entra ID para que estén listos para la revisión de acceso.

Flowchart for application integration patterns

Patrón Patrón de integración de aplicaciones Pasos para preparar una revisión de acceso
A La aplicación admite el inicio de sesión único federado, Microsoft Entra ID es el único proveedor de identidades y la aplicación no se basa en notificaciones de grupo o rol. En este patrón, configurará que la aplicación requiera asignaciones de roles de aplicación individuales y que los usuarios se asignen a la aplicación. Después, para realizar la revisión, creará una única revisión de acceso para la aplicación de los usuarios asignados a este rol de aplicación. Cuando se complete la revisión, si se denegó el acceso a un usuario, se quitará del rol de aplicación. Microsoft Entra ID ya no emitirá ese usuario con tokens de federación y el usuario no podrá iniciar sesión en esa aplicación.
B Si la aplicación usa notificaciones de grupo además de las asignaciones de roles de aplicación. Una aplicación puede usar la pertenencia a grupo de Microsoft Entra o Active Directory, distinta de los roles de aplicación para expresar el acceso más preciso. Aquí puede elegir, en función de los requisitos empresariales, que se revisen los usuarios que tienen asignaciones de roles de aplicación o que se revisen los usuarios con pertenencias a grupos. Si los grupos no proporcionan cobertura de acceso completa, en particular si los usuarios pueden tener acceso a la aplicación incluso si no son miembros de esos grupos, se recomienda revisar las asignaciones de roles de aplicación, como en el patrón A anterior.
C Si la aplicación no se basa únicamente en Microsoft Entra ID para el inicio de sesión único federado, pero admite el aprovisionamiento, a través de SCIM o a través de actualizaciones de una tabla de usuarios de SQL o de un directorio LDAP que no sea de AD, o es compatible con un protocolo de aprovisionamiento SOAP o REST. En este patrón, configurará Microsoft Entra ID para aprovisionar a los usuarios con asignaciones de roles de aplicación a la base de datos o directorio de la aplicación, actualizará las asignaciones de roles de aplicación en Microsoft Entra ID con una lista de los usuarios que actualmente tengan acceso y, a continuación, creará una única revisión de acceso de las asignaciones de roles de aplicación. Para más información, vea Gobernanza de los usuarios existentes de una aplicación para actualizar las asignaciones de roles de aplicación en Microsoft Entra ID.

Otras opciones

Los patrones de integración enumerados en la sección anterior son aplicables a aplicaciones SaaS de terceros, o aplicaciones desarrolladas por o para su organización.

  • Algunos servicios en línea de Microsoft, como Exchange Online, usan licencias. Aunque las licencias del usuario no se pueden revisar directamente, si usa asignaciones de licencias basadas en grupos, con grupos con usuarios asignados, puede revisar las pertenencias a esos grupos en su lugar.
  • Algunas aplicaciones usan el consentimiento de usuario delegado para controlar el acceso a Microsoft Graph u otros recursos. Como los consentimientos de cada usuario no están controlados por un proceso de aprobación, los consentimientos no se pueden revisar. En su lugar, puede revisar quién puede conectarse a la aplicación a través de directivas de acceso condicional, que podrían basarse en asignaciones de roles de aplicación o pertenencias a grupos.
  • Si la aplicación no admite protocolos de federación o aprovisionamiento, necesitará un proceso para aplicar manualmente los resultados cuando se complete la revisión. En el caso de una aplicación que solo admita la integración del inicio de sesión único con contraseña, si se quita una asignación de aplicación cuando se completa una revisión, la aplicación no se mostrará en la página myapps del usuario, pero no impedirá que un usuario que ya conozca la contraseña pueda seguir iniciando sesión en la aplicación. Para las aplicaciones locales, consulte Gobierno de usuarios de una aplicación que no admite el aprovisionamiento. Para aplicaciones SaaS, pida al proveedor de SaaS que se incorpore a la galería de aplicaciones para la federación o el aprovisionamiento mediante la actualización de su aplicación para que admita un protocolo estándar.

Comprobación que la aplicación está lista para la revisión

Ahora que ha identificado el patrón de integración de la aplicación, compruebe que la aplicación tal como está representada en Microsoft Entra ID está lista para su revisión.

  1. Inicie sesión en el Centro de administración de Microsoft Entra al menos como Administrador de Identity Governance.

  2. Vaya a >Identidad>Aplicaciones>Aplicaciones empresariales.

  3. Aquí puede comprobar si la aplicación está en la lista de aplicaciones empresariales del inquilino.

  4. Si la aplicación aún no aparece en la lista, compruebe si la aplicación está disponible en la galería de aplicaciones para las aplicaciones que se pueden integrar para el inicio de sesión único (SSO) federado o el aprovisionamiento. Si está en la galería, use los tutoriales para configurar la aplicación para la federación y, si admite el aprovisionamiento, configure también la aplicación para el aprovisionamiento.

  5. Si la aplicación aún no aparece en la lista, pero usa grupos de seguridad de AD y es una aplicación web, y la configuración de la aplicación se puede cambiar para que busque diferentes grupos de seguridad en AD, agregue la aplicación para el acceso remoto a través de Application Proxy, mueva la pertenencia de los grupos de seguridad de AD existentes a nuevos grupos de Microsoft Entra y configure la escritura diferida de grupos en AD. Después, actualice la aplicación para comprobar los nuevos grupos de AD creados por la escritura diferida de grupos, como se describe en Gobernanza de aplicaciones basadas en Active Directory local (Kerberos).

  6. Si la aplicación aún no aparece en la lista, pero usa grupos de seguridad de AD y es una aplicación web, y la configuración de la aplicación no se puede cambiar para que busque diferentes grupos de seguridad en AD, agregue la aplicación para el acceso remoto a través de Application Proxy, mueva la pertenencia de los grupos de seguridad de AD existentes a los nuevos grupos de Microsoft Entra y configure la escritura diferida de grupos en AD. Después, actualice los grupos de seguridad de AD existentes que la aplicación comprobaba para incluir los nuevos grupos como miembro, como se describe en Gobernanza de aplicaciones basadas en Active Directory local (Kerberos).

  7. Si la aplicación aún no aparece en la lista, usa grupos de seguridad de AD y no es una aplicación web, y la configuración de la aplicación se puede cambiar para que busque diferentes grupos de seguridad en AD, mueva la pertenencia de los grupos de seguridad de AD existentes a nuevos grupos de Microsoft Entra y configure la escritura diferida de grupos en AD. Después, actualice la aplicación para comprobar los nuevos grupos de AD creados por la escritura diferida de grupos, como se describe en Gobernanza de aplicaciones basadas en Active Directory local (Kerberos). Continúe con la sección siguiente.

  8. Si la aplicación aún no aparece en la lista, usa grupos de seguridad de AD y no es una aplicación web, y la configuración de la aplicación no se puede cambiar para que busque diferentes grupos de seguridad en AD, mueva la pertenencia de los grupos de seguridad de AD existentes a nuevos grupos de Microsoft Entra y configure la escritura diferida de grupos en AD. Después, actualice los grupos de seguridad de AD existentes que la aplicación comprobaba para incluir los nuevos grupos como miembro, como se describe en Gobernanza de aplicaciones basadas en Active Directory local (Kerberos). Continúe con la sección siguiente.

  9. Una vez que la aplicación esté en la lista de aplicaciones empresariales del inquilino, seleccione la aplicación en la lista.

  10. Cambie a la pestaña Propiedades. Compruebe que la opción ¿Asignación de usuarios? está establecida en Sí. Si se establece en No, todos los usuarios del directorio, incluidas las identidades externas, pueden acceder a la aplicación y no puede revisar el acceso a la aplicación.

    Screenshot that shows planning app assignments.

  11. Cambie a la pestaña Roles y administradores. En esta pestaña, se muestran los roles administrativos, que conceden derechos para controlar la representación de la aplicación en Microsoft Entra ID, no los derechos de acceso en la aplicación. Para cada rol administrativo que tenga permisos para permitir el cambio de la integración o asignaciones de la aplicación, y tenga una asignación a ese rol administrativo, asegúrese de que solo los usuarios autorizados estén en ese rol.

  12. Cambie a la pestaña Aprovisionamiento. Si el aprovisionamiento automático no está configurado, Microsoft Entra ID no tendrá manera de notificar a la aplicación cuando se quite el acceso de un usuario si se le deniega durante la revisión. Es posible que el aprovisionamiento no sea necesario para algunos patrones de integración, si la aplicación está federada y se basa únicamente en Microsoft Entra ID como proveedor de identidades o si usa grupos de AD DS. Sin embargo, si la integración de la aplicación es el patrón C y la aplicación no admite el SSO federado con Microsoft Entra ID como único proveedor de identidades, debe configurar el aprovisionamiento de Microsoft Entra ID para la aplicación. El aprovisionamiento será necesario para que Microsoft Entra ID pueda quitar automáticamente de la aplicación a los usuarios revisados después de completada la revisión y este paso de eliminación se puede realizar a través de un cambio enviado desde Microsoft Entra ID a la aplicación a través de SCIM, LDAP, SQL, SOAP o REST.

Para más información, vea Integración de aplicaciones con Microsoft Entra ID.

  1. Si el aprovisionamiento está configurado, seleccione Editar asignaciones de atributos, expanda la sección Asignación y haga clic en Aprovisionar usuarios de Microsoft Entra. Compruebe que, en la lista de asignaciones de atributos, haya una asignación para isSoftDeleted al atributo en el almacén de datos de la aplicación que quiera que Microsoft Entra ID establezca en false cuando un usuario pierde el acceso. Si esta asignación no está presente, Microsoft Entra ID no notificará a la aplicación cuando un usuario se haya quedado fuera del ámbito, como se describe en Cómo funciona el aprovisionamiento.

  2. Si la aplicación admite el inicio de sesión único federado, cambie a la pestaña Acceso condicional. Inspeccione las directivas habilitadas para esta aplicación. Si hay directivas habilitadas que bloquean el acceso y hay usuarios asignados a las directivas, pero no hay otras condiciones, es posible que esos usuarios ya estén bloqueados para poder obtener el inicio de sesión único federado en la aplicación.

  3. Cambie a la pestaña Usuarios y grupos. Esta lista contiene todos los usuarios asignados a la aplicación en Microsoft Entra ID. Si la lista está vacía, se completará inmediatamente una revisión de la aplicación, ya que no hay ninguna tarea que el revisor deba realizar.

  4. Si la aplicación está integrada con el patrón C, deberá confirmar que los usuarios de esta lista sean los mismos que los del almacén de datos interno de las aplicaciones, antes de iniciar la revisión. Microsoft Entra ID no importa automáticamente usuarios ni sus derechos de acceso de una aplicación, aunque puede asignar usuarios a un rol de aplicación a través de PowerShell. Consulte Gobernanza de los usuarios existentes de una aplicación para obtener información sobre cómo incorporar usuarios de diferentes almacenes de datos de aplicaciones a Microsoft Entra ID y asignarlos a un rol de aplicación.

  5. Compruebe si todos los usuarios están asignados al mismo rol de aplicación, como Usuario. Si los usuarios están asignados a varios roles y crea una revisión de acceso de la aplicación, todas las asignaciones a todos los roles de la aplicación se revisarán conjuntamente.

  6. Compruebe la lista de objetos de directorio asignados a los roles para confirmar que no hay grupos asignados a los roles de aplicación. Es posible revisar esta aplicación si hay un grupo asignado a un rol; sin embargo, no se quitará automáticamente del grupo a un usuario que sea miembro del grupo asignado al rol y cuyo acceso se haya denegado. Si la aplicación en sí no se basa en grupos, se recomienda convertir primero la aplicación para que tenga asignaciones de usuario directas, en lugar de miembros de grupos, de forma que se pueda quitar automáticamente la asignación de roles de aplicación a un usuario cuyo acceso se deniegue durante la revisión de acceso. Si la aplicación se basa en grupos y a todos los grupos de la aplicación se les asigna el mismo rol de aplicación, debe revisar las pertenencias a grupos en lugar de revisar las asignaciones de aplicación.

Comprobación que los grupos están listos para la revisión

Si la aplicación no depende de grupos, vaya a la sección siguiente. De lo contrario, si la integración de aplicaciones también requiere que se revisen uno o varios grupos, como se describe en el patrón B, compruebe que cada grupo esté listo para la revisión.

  1. Inicie sesión en el Centro de administración de Microsoft Entra al menos como Administrador de Identity Governance.
  2. Vaya a >Grupos.
  3. Busque y seleccione cada grupo de la lista.
  4. En la pestaña Información general, compruebe que Tipo de pertenencia es Asignado y que Origen es Nube. Si la aplicación usa un grupo dinámico o un grupo sincronizado del el entorno local, esas pertenencias a grupos no se pueden cambiar en Microsoft Entra ID. Se recomienda convertir la aplicación en grupos creados en Microsoft Entra ID con pertenencias asignadas y, a continuación, copiar los usuarios miembros en ese nuevo grupo.
  5. Cambie a la pestaña Roles y administradores. En esta pestaña, se muestran los roles administrativos, que conceden derechos para controlar la representación del grupo en Microsoft Entra ID, no los derechos de acceso en la aplicación. En cada rol administrativo que permita cambiar la pertenencia a grupos y que tenga usuarios en ese rol administrativo, asegúrese de que solo los usuarios autorizados estén en ese rol.
  6. Cambie a la pestaña Miembros. Compruebe que los miembros del grupo son usuarios y que no hay miembros que no son de usuario ni grupos anidados. Si no hay miembros de un grupo cuando se inicia la revisión, la revisión de ese grupo se completará inmediatamente.
  7. Cambie a la pestaña Propietarios. Asegúrese de que no se muestran usuarios autorizados como propietarios. Si va a pedir a los propietarios del grupo que realicen la revisión de acceso de un grupo, confirme que el grupo tenga uno o varios propietarios.

Selección de revisores adecuados

Al crear las revisiones de acceso, los administradores pueden elegir uno o más revisores. Todos los revisores pueden llevar a cabo una revisión; y elegir los usuarios que seguirán teniendo acceso a un recurso, o bien eliminarlos.

Normalmente, un propietario de recursos es responsable de realizar una revisión. Si va a crear una revisión de un grupo, como parte de la revisión del acceso de una aplicación integrada en el patrón B, puede seleccionar los propietarios del grupo como revisores. Como las aplicaciones de Microsoft Entra ID no tienen necesariamente un propietario, la opción para seleccionar el propietario de la aplicación como revisor no es posible. En su lugar, al crear la revisión, puede proporcionar los nombres de los propietarios de la aplicación para que sean los revisores.

También puede elegir, al crear una revisión de un grupo o una aplicación, realizar una revisión en varias fases. Por ejemplo, puede seleccionar que el administrador de cada usuario asignado realice la primera fase de la revisión y el propietario del recurso la segunda. De este modo, el propietario del recurso puede centrarse en los usuarios que su administrador ya ha aprobado.

Antes de crear las revisiones, compruebe que tenga suficientes puestos de SKU de Gobierno de id. de Microsoft Entra o Microsoft Entra ID P2 en el inquilino. Además, compruebe que todos los revisores son usuarios activos con direcciones de correo electrónico. Cuando se inician las revisiones de acceso, cada una revisa un correo electrónico desde Microsoft Entra ID. Si el revisor no tiene un buzón, no recibirá el correo electrónico cuando se inicie la revisión ni un recordatorio por correo electrónico. Y, si están bloqueados para poder iniciar sesión en Microsoft Entra ID, no podrán realizar la revisión.

Creación de las revisiones

Una vez que haya identificado los recursos, la aplicación y, opcionalmente, uno o varios grupos, en función del patrón de integración y quiénes deben ser los revisores, puede configurar Microsoft Entra ID para iniciar las revisiones.

  1. Para este paso, debe estar en el rol Global administrator o Identity Governance administrator.

  2. En los patrones A y C, creará una revisión de acceso y seleccionará la aplicación. Siga las instrucciones de la guía para crear una revisión de acceso de grupos o aplicaciones, a fin de crear la revisión de las asignaciones de roles de la aplicación.

  3. Si la aplicación está integrada con el patrón B, use la misma guía para crear revisiones de acceso adicionales para cada uno de los grupos.

    Nota

    Si crea una revisión de acceso y habilita los asistentes de decisiones de revisión, el asistente de decisiones variará en función del recurso que se revise. Si el recurso es una aplicación, las recomendaciones se basan en el período de intervalo de 30 días, en función de cuándo haya iniciado sesión el usuario por última vez en la aplicación. Si el recurso es un grupo, las recomendaciones se basan en el intervalo en el que el usuario inició sesión por última vez en cualquier aplicación del inquilino, no solo la aplicación que usa esos grupos.

  4. Cuando se inicie la revisión de acceso, pida a los revisores que proporcionen una entrada. De forma predeterminada, cada uno recibe un correo electrónico de Microsoft Entra ID con un vínculo al panel de acceso, donde pueden revisar la pertenencia a grupos o el acceso a la aplicación.

Visualización de las asignaciones que se actualizan cuando se completan las revisiones

Una vez iniciadas las revisiones, puede supervisar su progreso y actualizar los aprobadores si es necesario, hasta que finalice la revisión. A continuación, puede confirmar que se está quitando, para los usuarios cuyo acceso han denegado los revisores, el acceso de la aplicación.

  1. Supervise las revisiones de acceso, asegurándose de que los revisores realizan selecciones para aprobar o denegar la necesidad de acceso continuado del usuario, hasta que finalice la revisión de acceso.

  2. Si no se seleccionó la aplicación automática cuando se creó la revisión, debe aplicar los resultados de la revisión cuando se complete.

  3. Espere a que el estado de la revisión cambie a Resultado aplicado. Debería esperar ver a los usuarios denegados, si es que los hay, eliminados de la pertenencia al grupo o la asignación de aplicaciones en unos minutos.

  4. Si había configurado previamente el aprovisionamiento de usuarios a la aplicación, cuando se apliquen los resultados, Microsoft Entra ID comenzará a desaprovisionar los usuarios con acceso denegado de la aplicación. Puede supervisar el proceso de desaprovisionamiento de usuarios. Si el aprovisionamiento indica un error con la aplicación, puede descargar el registro de aprovisionamiento para investigar si se produjo un problema con la aplicación.

  5. Si había configurado la escritura diferida de grupos para los grupos revisados, espere hasta que se complete la escritura diferida de grupos en Microsoft Entra Cloud Sync y los cambios se propaguen a todos los controladores de dominio.

  6. Si el aprovisionamiento no se configuró para la aplicación, es posible que tenga que copiar por separado la lista de usuarios con acceso denegado a la aplicación. Por ejemplo, en las revisiones de acceso para un grupo administrado mediante Windows Server AD, use este script de ejemplo de PowerShell. El script describe las llamadas necesarias a Microsoft Graph y exporta los cmdlets de PowerShell de Windows AD para llevar a cabo los cambios.

  7. Si quiere, también puede descargar un informe del historial de revisión de las revisiones completadas.

  8. La cantidad de tiempo en que un usuario al que se ha denegado el acceso continuado pueda seguir usando una aplicación federada dependerá de la duración de la propia sesión de la aplicación y de la vigencia del token de acceso. Si las aplicaciones han usado Kerberos, dado que Kerberos almacena en caché las pertenencias a grupos de un usuario cuando inician sesión en un dominio, es posible que los usuarios sigan teniendo acceso hasta que expiren sus vales de Kerberos. Para más información sobre cómo controlar la duración de los tokens de acceso, consulte Vigencia de los tokens configurables.

Pasos siguientes