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.
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 | Sí | 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.
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.