Definición de directivas organizativas para controlar el acceso a las aplicaciones en su entorno
Una vez que hayas identificado una o más aplicaciones que deseas usar Microsoft Entra ID para controlar el acceso, escribe las directivas de la organización para determinar qué usuarios deben tener acceso y cualquier otra restricción que el sistema debe proporcionar.
Selección de las aplicaciones y sus roles en el ámbito
Las organizaciones con requisitos de cumplimiento o planes de administración de riesgos tienen aplicaciones confidenciales o críticas para la empresa. Si esta aplicación es una aplicación existente en tu entorno, es posible que ya hayas documentado las directivas de acceso con respecto a quién "debe tener acceso" a esta aplicación. Si no es así, es posible que tengas que consultar con varias partes interesadas, como los equipos de administración de riesgos y cumplimiento, para asegurarte de que las directivas que se usan para automatizar las decisiones de acceso son adecuadas para tu escenario.
Recopila los roles y permisos que proporciona cada aplicación. Algunas aplicaciones pueden tener un solo rol, por ejemplo, una aplicación que solo tiene el rol "Usuario". Las aplicaciones más complejas pueden presentar múltiples roles que se administrarán a través de Microsoft Entra ID. Normalmente, estos roles de aplicación crean amplias restricciones en el acceso que tendría un usuario con ese rol dentro de la aplicación. Por ejemplo, una aplicación que tiene un rol de administrador puede tener dos roles: "Usuario" y "Administrador". Otras aplicaciones también pueden depender de membresías de grupos o reclamos para verificaciones de roles más detalladas, que se pueden proporcionar a la aplicación desde Microsoft Entra ID en el aprovisionamiento o reclamos emitidos utilizando protocolos SSO de federación, o escritos en AD como membresía de un grupo de seguridad. Finalmente, puede haber roles específicos de la aplicación que no aparecen en Microsoft Entra ID; tal vez la aplicación no permite definir los administradores en Microsoft Entra ID, sino que depende de sus propias reglas de autorización para identificar a los administradores. SAP Cloud Identity Services solo tiene un rol, usuario, disponible para la asignación.
Nota:
Si estás utilizando una aplicación de la galería de aplicaciones de Microsoft Entra que admite el aprovisionamiento, entonces Microsoft Entra ID puede importar roles definidos en la aplicación y actualizar automáticamente el manifiesto de la aplicación con los roles de la aplicación, una vez que se configura el aprovisionamiento.
Selecciona qué roles y grupos con pertenencia se van a controlar en Microsoft Entra ID. En función de los requisitos de cumplimiento y administración de riesgos, las organizaciones suelen dar prioridad a esos roles de aplicación o grupos que proporcionan acceso con privilegios o acceso a información confidencial.
Definición de la directiva de la organización con requisitos previos y otras restricciones para el acceso a la aplicación
En esta sección, anotarás las directivas organizativas que planeas usar para determinar el acceso a la aplicación. Puedes registrar esta información en una tabla de una hoja de cálculo, por ejemplo.
| Rol de aplicación | Requisito previo para el acceso | Aprobadores | Duración predeterminada del acceso | Restricciones en la separación de obligaciones | Directivas de acceso condicional |
|---|---|---|---|---|---|
| Ventas del oeste | Miembro del equipo de ventas | responsable del usuario | Revisión anual | No puede tener acceso a Ventas del este | Para el acceso se requiere autenticación multifactor (MFA) y que el dispositivo esté registrado. |
| Ventas del oeste | Cualquier empleado que no sea de ventas | jefe del departamento de ventas | 90 días | N/A | Para el acceso se requiere MFA y que el dispositivo esté registrado. |
| Ventas del oeste | Representante de ventas que no sea empleado | jefe del departamento de ventas | 30 días | N/A | Para el acceso se requiere MFA. |
| Ventas del este | Miembro del equipo de ventas | responsable del usuario | Revisión anual | No puede tener acceso a Ventas del oeste | Para el acceso se requiere MFA y que el dispositivo esté registrado. |
| Ventas del este | Cualquier empleado que no sea de ventas | jefe del departamento de ventas | 90 días | N/A | Para el acceso se requiere MFA y que el dispositivo esté registrado. |
| Ventas del este | Representante de ventas que no sea empleado | jefe del departamento de ventas | 30 días | N/A | Para el acceso se requiere MFA. |
Si ya tiene una definición de rol de organización, consulte cómo migrar un rol organizativo para obtener más información.
Identifique si hay requisitos previos, estándares que un usuario debe cumplir antes de concederles acceso a una aplicación. Por ejemplo, en circunstancias normales, solo los empleados a tiempo completo o los de un departamento o centro de costos determinado deben tener acceso a la aplicación de un departamento en particular. Además, puede que sea necesario aplicar la directiva de administración de derechos para usuarios de algún otro departamento que solicitan acceso con el fin de tener uno o varios aprobadores adicionales. Aunque tener varias fases de aprobación puede ralentizar el proceso general de obtención de acceso por parte de un usuario, estas fases adicionales garantizan que las solicitudes de acceso sean adecuadas y las decisiones responsables. Por ejemplo, las solicitudes de acceso por parte de un empleado podrían tener dos fases de aprobación, la primera por el responsable del usuario solicitante y la segunda por uno de los propietarios de recursos responsables de los datos contenidos en la aplicación.
Determine cuánto debe durar el acceso aprobado para un usuario y cuándo debería desaparecer ese acceso. En el caso de muchas aplicaciones, un usuario puede conservar el acceso indefinidamente, hasta que ya no esté afiliado a la organización. En algunas situaciones, el acceso puede estar vinculado a proyectos o hitos concretos, de modo que cuando finalice el proyecto, el acceso se quite automáticamente. O bien, si solo unos pocos usuarios usan una aplicación mediante una directiva, puede configurar revisiones trimestrales o anuales del acceso de todos los usuarios mediante esa directiva, para que haya supervisión periódica.
Si la organización está administrando el acceso ya con un modelo de roles organizativo, planee incorporar ese modelo de roles organizativo a Microsoft Entra ID. Es posible que tenga un rol organizativo definido que asigne acceso basado en la propiedad de un usuario, como su posición o departamento. Estos procesos pueden garantizar que los usuarios pierdan el acceso cuando ya no sea necesario, incluso si no hay una fecha de finalización del proyecto determinada previamente.
Pregunte si hay restricciones en la separación de obligaciones. Por ejemplo, suponga que tiene una aplicación con dos roles de aplicación, Ventas del oeste y Ventas del este, y quiere asegurarse de que un usuario solo pueda tener un territorio de ventas a la vez. Incluya una lista de los pares de roles de aplicación que son incompatibles para la aplicación, de modo que, si un usuario tiene un rol, no se le permita solicitar el segundo.
Seleccione la directiva de acceso condicional adecuada para el acceso a la aplicación. Se recomienda analizar las aplicaciones y agruparlas en aplicaciones que tengan los mismos requisitos de recursos para los mismos usuarios. Si esta es la primera aplicación SSO federada que integra con Gobierno de Microsoft Entra ID para el control de identidad, es posible que deba crear una nueva política de acceso condicional para expresar restricciones, como requisitos de autenticación multifactor (MFA) o acceso basado en ubicación. Puede configurar los usuarios que es necesario que acepten los términos de uso. Consulte Planeamiento de una implementación de acceso condicional para conocer más consideraciones sobre cómo definir una directiva de acceso condicional.
Determine cómo se deben controlar las excepciones a los criterios. Por ejemplo, una aplicación normalmente solo puede estar disponible para los empleados designados, pero un auditor o proveedor puede necesitar acceso temporal a un proyecto específico. O bien, un empleado que viaja puede requerir acceso desde una ubicación que normalmente está bloqueada, ya que su organización no tiene presencia allí. En estas situaciones, también puede optar por tener una directiva de administración de derechos para su aprobación que pueda tener diferentes fases, o un límite de tiempo diferente, o un aprobador diferente. Es posible que un proveedor que haya iniciado sesión como usuario invitado en su inquilino de Microsoft Entra no tenga un administrador, por lo que sus solicitudes de acceso podrían ser aprobadas por un patrocinador de su organización, un propietario de recurso o un responsable de seguridad.
Como las partes interesadas están revisando la política organizacional sobre quién debe tener acceso, puede comenzar a integrar la aplicación con Microsoft Entra ID. De esa manera, en un paso posterior estará listo para implementar las políticas aprobadas por la organización para el acceso en Microsoft Entra ID Governance.