Compartir a través de


Control del acceso mediante la migración de un modelo de roles organizativos a Microsoft Entra Identity Governance

El control de acceso basado en rol (RBAC) proporciona un marco para clasificar usuarios y recursos de TI. Este marco le permite hacer explícita su relación y los derechos de acceso que son adecuados de acuerdo con esa clasificación. Por ejemplo, mediante la asignación a un usuario de atributos que especifican su puesto y las asignaciones de proyectos, se puede conceder acceso al usuario a las herramientas necesarias para el trabajo y los datos que necesita para participar en un proyecto determinado. Cuando el usuario asume un trabajo diferente y asignaciones de proyecto diferentes, cambiar los atributos que especifican el puesto y los proyectos del usuario bloquea automáticamente el acceso a los recursos que solo son necesarios para el puesto anterior del usuario.

En Microsoft Entra ID, puede usar modelos de roles de varias maneras para administrar el acceso a gran escala mediante la gobernanza de identidades.

  • Puede usar paquetes de acceso para representar roles de la organización en su organización, como "representante de ventas". Un paquete de acceso que representa ese rol organizativo incluiría todos los derechos de acceso que normalmente un representante de ventas podría necesitar en varios recursos.
  • Las aplicaciones pueden definir sus propios roles. Por ejemplo, si tuviera una aplicación de ventas y esa aplicación incluyera el rol de aplicación "vendedor" en su manifiesto, podría incluir ese rol desde el manifiesto de la aplicación en un paquete de acceso. Las aplicaciones también pueden usar grupos de seguridad en escenarios en los que un usuario podría tener varios roles específicos de la aplicación simultáneamente.
  • Puede usar roles para delegar el acceso administrativo. Si tiene un catálogo para todos los paquetes de acceso necesarios para las ventas, puede asignar a algún usuario que sea responsable de ese catálogo, asignándole un rol específico del catálogo.

En este artículo se describe cómo modelar roles organizativos mediante paquetes de acceso de administración de derechos, de modo que pueda migrar las definiciones de roles a Microsoft Entra ID para aplicar el acceso.

Migración de un modelo de roles organizativos

En la tabla siguiente se muestra cómo los conceptos de las definiciones de roles organizativos con los que podría estar familiarizado en otros productos corresponden a las funcionalidades de la administración de derechos.

Concepto en el modelado de roles organizativos Representación en la administración de derechos
Administración de roles delegados Delegación en los creadores de catálogos
Recopilación de permisos en una o varias aplicaciones Creación de un paquete de acceso con roles de recursos
Restricción de la duración del acceso que proporciona un rol Establecimiento de la configuración del ciclo de vida de directivas de un paquete de acceso para tener una fecha de expiración
Asignación individual a un rol Creación de una asignación directa a un paquete de acceso
Asignación de roles a los usuarios en función de las propiedades (por ejemplo, su departamento) Establecimiento de la asignación automática a un paquete de acceso
Los usuarios pueden solicitar y recibir aprobación para un rol Configuración de las opciones de directiva de quién puede solicitar un paquete de acceso
Acceso a la recertificación de los miembros de rol Establecimiento de la configuración de revisión de acceso periódica en una directiva de paquete de acceso
Separación de tareas entre roles Definición de dos o más paquetes de acceso como incompatibles

Por ejemplo, una organización puede tener un modelo de roles organizativos existente similar a la tabla siguiente.

Nombre de rol Permisos que proporciona el rol Asignación automática al rol Asignación al rol basada en solicitud Separación de comprobaciones de tareas
SalesPerson Miembro del equipo de Ventas No None
Administrador de soluciones de ventas Permisos del rol de aplicación Vendedor y Administrador de soluciones en la aplicación Ventas None Un vendedor puede solicitar, requiere la aprobación del administrador y revisión trimestral. El solicitante no puede ser un Administrador de cuenta de ventas
Administrador de cuentas de ventas Permisos del rol de aplicación Vendedor y Administrador de cuentas en la aplicación Ventas None Un vendedor puede solicitar, requiere la aprobación del administrador y revisión trimestral. La solicitud no puede ser de Administrador de cuenta de ventas
Soporte técnico de ventas Mismos permisos que un Vendedor None Cualquier persona que no sea vendedor puede hacer la solicitud, requiere la aprobación del administrador y una revisión trimestral El solicitante no puede ser un Vendedor

Esto podría representarse en Microsoft Entra Identity Governance como un catálogo de paquetes de acceso que contiene cuatro paquetes de acceso.

Paquete de acceso Roles de recursos Directivas Paquetes de acceso incompatibles
SalesPerson Miembro del equipo de Ventas Asignación automática
Administrador de soluciones de ventas Rol de aplicación de Administrador de soluciones en la aplicación Ventas Basada en solicitudes Administrador de cuentas de ventas
Administrador de cuentas de ventas Rol de aplicación de Administrador de cuentas en la aplicación Ventas Basada en solicitudes Administrador de soluciones de ventas
Soporte técnico de ventas Miembro del equipo de Ventas Basada en solicitudes SalesPerson

En las secciones siguientes se describe el proceso de migración y la creación de los artefactos de Microsoft Entra y Microsoft Entra Identity Governance para implementar el acceso equivalente de un modelo de roles organizativos.

Conexión a Microsoft Entra ID de las aplicaciones cuyos permisos se mencionan en los roles organizativos

Si los roles organizacionales se usan para asignar permisos que controlan el acceso a las aplicaciones SaaS que no son de Microsoft, las aplicaciones locales o sus propias aplicaciones en la nube, entonces deberá conectar las aplicaciones a Microsoft Entra ID.

Para que un paquete de acceso que represente un rol organizativo pueda hacer referencia a los roles de una aplicación como los permisos que se van a incluir en el rol, para una aplicación que tenga varios roles y admita estándares modernos, como SCIM, debe integrar la aplicación con Microsoft Entra ID y asegurarse de que los roles de la aplicación se enumeran en el manifiesto de aplicación.

Aunque la aplicación solo tenga un rol, debe integrarla con Microsoft Entra ID. En el caso de las aplicaciones que no admite SCIM, Microsoft Entra ID puede escribir usuarios en el directorio existente de una aplicación o en la base de datos SQL, o agregar usuarios de AD a un grupo de AD.

Rellenar el esquema de Microsoft Entra utilizado por las aplicaciones y para las reglas de ámbito de usuarios en los roles organizativos

Si las definiciones de roles incluyen declaraciones del tipo "todos los usuarios con estos valores de atributos se asignan automáticamente al rol" o "los usuarios con estos valores de atributos pueden realizar solicitudes", deberá asegurarse de que esos atributos estén presentes en Microsoft Entra ID.

Puede ampliar el esquema de Microsoft Entra y, luego, rellenar esos atributos a partir de AD local, a través de Microsoft Entra Connect o desde un sistema de RR. HH. como Workday o SuccessFactors.

Creación de catálogos para la delegación

Si se delega el mantenimiento continuo de los roles, puede delegar la administración de los paquetes de acceso mediante la creación de un catálogo para cada parte de la organización a la que delegará.

Si tiene varios catálogos para crear, puede usar un script de PowerShell para crear cada uno.

Si no tiene previsto delegar la administración de los paquetes de acceso, puede mantener los paquetes de acceso en un solo catálogo.

Adición de recursos a los catálogos

Ahora que tiene los catálogos identificados, agregue las aplicaciones, grupos o sitios que están incluidos en los paquetes de acceso que representan los roles de la organización a los catálogos.

Si tiene muchos recursos, puede usar un script de PowerShell para agregar cada recurso a un catálogo. Para más información, consulte Creación de un paquete de acceso en la administración de derechos para una aplicación con un solo rol mediante PowerShell.

Creación de paquetes de acceso correspondientes a definiciones de roles organizativos

Cada definición de rol organizativo se puede representar con un paquete de acceso en ese catálogo.

Puede usar un script de PowerShell para crear un paquete de acceso en un catálogo.

Una vez que haya creado un paquete de acceso, vincule uno o más de los roles de los recursos en el catálogo al paquete de acceso. Esto representa los permisos del rol organizativo.

Además, y como parte de ese paquete de acceso, creará una directiva para la asignación directa que se puede usar para realizar un seguimiento de los usuarios que ya tienen asignaciones de roles organizativos individuales.

Creación de asignaciones de paquetes de acceso para asignaciones de roles organizativos individuales existentes

Si algunos de los usuarios ya tienen pertenencia a roles organizacionales, que no recibirían mediante la asignación automática, entonces debe crear asignaciones directas para esos usuarios a los paquetes de acceso correspondientes.

Si tiene muchos usuarios que necesitan asignaciones, puede usar un script de PowerShell para asignar a cada usuario un paquete de acceso. De esta forma, los usuarios se vincularán a la directiva de asignación directa.

Adición de directivas a esos paquetes de acceso para la asignación automática

Si la definición de roles organizativos incluye una regla basada en los atributos del usuario para asignar y quitar el acceso automáticamente en función de esos atributos, puede representarlo mediante una directiva de asignación automática. Un paquete de acceso puede tener como máximo una directiva de asignación automática.

Si tiene muchas definiciones de roles cada una con una definición de rol, puede usar un script de PowerShell para crear cada directiva de asignación automática en cada paquete de acceso.

Establecimiento de los paquetes de acceso como incompatibles para la separación de tareas

Si tiene restricciones de separación de tareas que impiden a un usuario asumir un rol organizativo cuando ya tiene otro, puede evitar que el usuario solicite acceso en la administración de derechos marcando esas combinaciones de paquetes de acceso como incompatibles.

Para cada paquete de acceso que se vaya a marcar como incompatible con otro, puede usar un script de PowerShell para configurar los paquetes de acceso como incompatibles.

Adición de directivas a paquetes de acceso para que los usuarios puedan solicitar

Si los usuarios que aún no tienen un rol organizacional pueden solicitar y recibir aprobación para asumir un rol, también puede configurar la administración de derechos para permitir que los usuarios soliciten un paquete de acceso. Puede agregar directivas adicionales a un paquete de acceso y, en cada directiva, especificar qué usuarios pueden solicitar y quién debe aprobar.

Configuración de revisiones de acceso en directivas de asignación de paquetes de acceso

Si los roles de la organización requieren una revisión periódica de su pertenencia, puede configurar revisiones de acceso periódicas en las directivas de asignación directa y basada en solicitudes.

Pasos siguientes