Uso de grupos de Microsoft Entra para administrar asignaciones de roles

Con Microsoft Entra ID P1 o P2, puedes crear grupos asignables a roles y asignar roles de Microsoft Entra a estos grupos. Esta característica simplifica la administración de roles, garantiza un acceso coherente y hace que los permisos de auditoría sean más sencillos. La asignación de roles a un grupo en lugar de personas permite agregar o quitar fácilmente usuarios de un rol y crea permisos coherentes para todos los miembros del grupo. También puedes crear roles personalizados con permisos específicos y asignarlos a grupos.

Motivo para asignar roles a grupos

Considera el ejemplo en el que la empresa Contoso ha contratado a personas en distintas zonas geográficas para administrar y restablecer las contraseñas de los empleados de su organización de Microsoft Entra. En lugar de solicitar a un administrador de roles con privilegios que asigne el rol de administrador del departamento de soporte técnico a cada persona individualmente, se puede crear el grupo "Administradores_soporte técnico_Contoso" y asignarle el rol. Cuando los usuarios se unen al grupo, se les asigna el rol de forma indirecta. Después, el flujo de trabajo de gobernanza existente puede encargarse del proceso de aprobación y la auditoría de la pertenencia al grupo para asegurarse de que solo los usuarios legítimos sean miembros del grupo, a fin de asignarles el rol de administrador del departamento de soporte técnico.

Funcionamiento de las asignaciones de roles a grupos

Para asignar un rol a un grupo, debes crear un grupo de seguridad o de Microsoft 365 con la propiedad isAssignableToRole establecida en true. En el centro de administración Microsoft Entra, establece la opción Los roles de Microsoft Entra se pueden asignar a un grupo en Sí. En cualquier caso, puedes asignar al grupo uno o varios roles de Microsoft Entra de la misma manera que asignas roles a los usuarios.

Restricciones para grupos a los que se pueden asignar roles

Los grupos a los que se pueden asignar roles tienen las restricciones siguientes:

• Solo puedes establecer la propiedad isAssignableToRole o la opción Los roles de Microsoft Entra se pueden asignar a un grupo para los nuevos grupos.
• La propiedad isAssignableToRole es inmutable. Una vez que se crea un grupo con esta propiedad establecida, ya no se puede modificar.
• No se puede convertir un grupo existente en un grupo al que se pueden asignar roles.
• Se puede crear un máximo de 500 grupos a los que se pueden asignar roles en una sola organización de Microsoft Entra (inquilino).

Maneras de proteger grupos a los que se pueden asignar roles

Si se asigna un rol a un grupo, cualquier administrador de TI que pueda administrar los grupos de pertenencia dinámica también podría administrar indirectamente la pertenencia a ese rol. Por ejemplo, supongamos que se asigna a un grupo llamado Contoso_User_Administrators el rol de administrador de usuarios. Un administrador de Exchange que puede modificar los grupos de pertenencia dinámica podría agregarse a sí mismo al grupo Contoso_User_Administrators y, de esta forma, convertirse en administrador de usuarios. Como puedes ver, un administrador podría elevar sus privilegios de una forma no prevista.

Solo se puede asignar un rol a los grupos que tengan la propiedad isAssignableToRole establecida en true en el momento de la creación. Esta propiedad es inmutable. Una vez que se crea un grupo con esta propiedad establecida, ya no se puede modificar. No se puede establecer la propiedad en un grupo existente.

Los grupos a los que se pueden asignar roles están diseñados para ayudar a evitar posibles infracciones mediante las restricciones siguientes:

• Debes tener asignado al menos el rol Administrador de roles con privilegios para poder crear un grupo asignable a roles.
• El tipo de pertenencia para los grupos a los que se pueden asignar roles debe ser Asignado y no puede ser un grupo dinámico de Microsoft Entra. El rellenado automático de grupos de pertenencia dinámica podría dar lugar a la adición de una cuenta no deseada al grupo y, por tanto, a la asignación del rol.
• De forma predeterminada, los administradores de roles con privilegios pueden administrar la pertenencia de un grupo asignable a roles, pero pueden delegar la administración de estos grupos agregando propietarios al grupo.
• Para Microsoft Graph, se requiere el permiso RoleManagement.ReadWrite.Directory para poder administrar la pertenencia de grupos a los que se pueden asignar roles. El permiso Group.ReadWrite.All no funcionará.
• Para evitar la elevación de privilegios, se te debe asignar al menos el rol Administrador de autenticación con privilegios para cambiar las credenciales, restablecer la MFA o modificar atributos confidenciales para los miembros y propietarios de un grupo asignable a funciones.
• No se admite la anidación de grupos. No se puede agregar un grupo como miembro de un grupo al que se pueden asignar roles.

Uso de PIM para que un grupo sea apto para una asignación de roles

Si no quieres que los miembros del grupo tengan acceso permanente al rol, puedes usar Microsoft Entra Privileged Identity Management (PIM) para que un grupo sea apto para una asignación de roles. Cada miembro del grupo es apto para activar la asignación de roles durante un tiempo fijo.

Nota:

En el caso de los grupos que se usan para elevar a roles de Microsoft Entra, recomendamos requerir un proceso de aprobación para las asignaciones de miembros elegibles. Las asignaciones que se pueden activar sin aprobación pueden plantearle un riesgo de seguridad por parte de administradores con menos privilegios. Por ejemplo, el administrador del departamento de soporte técnico tiene permiso para restablecer las contraseñas de un usuario que reúna las características para ello.

Escenarios no admitidos

No se admiten los escenarios siguientes:

• Asignar roles de Microsoft Entra (integrados o personalizados) a grupos locales.

Problemas conocidos

A continuación, de indican los problemas conocidos con los grupos a los que se pueden asignar roles:

• Solo clientes con licencia de Microsoft Entra ID P2: incluso después de eliminar el grupo, aún se muestra un miembro apto del rol en la interfaz de usuario de PIM. Funcionalmente, no hay ningún problema; es solo un problema de caché en el Centro de administración de Microsoft Entra.
• Usa el nuevo Centro de administración de Exchange para la asignación de roles mediante los grupos de pertenencia dinámica. El antiguo Centro de administración de Exchange no es compatible aún con esta característica. Si se requiere acceso al centro de administración de Exchange, asigna el rol apto directamente al usuario (no a través de grupos a los que se pueden asignar roles). Los cmdlets de PowerShell de Exchange funcionan según lo previsto.
• Si se asigna un rol Administrador a un grupo al que se pueden asignar roles en lugar de a usuarios individuales, los miembros del grupo no podrán acceder a reglas, organizaciones o carpetas públicas en el nuevo Centro de administración de Exchange. La solución alternativa consiste en asignar el rol directamente a los usuarios en lugar del grupo.
• El portal de Azure Information Protection (el portal clásico) todavía no reconoce la pertenencia al rol mediante el grupo. Puedes migrar a la plataforma de etiquetado de confidencialidad unificada y, después, usar el portal de cumplimiento de Microsoft Purview a fin de utilizar las asignaciones de grupos para administrar roles.

Requisitos de licencia

El uso de esta característica requiere una licencia Microsoft Entra ID P1. Privileged Identity Management para la activación de roles cuando es necesario requiere una licencia de Microsoft Entra ID Premium P2. Para obtener la licencia correcta para sus requisitos, consulta Comparación de las características con disponibilidad general de las ediciones Gratis y Premium.

Pasos siguientes

• Creación de un grupo al que se pueden asignar roles
• Asignación de roles de Microsoft Entra a grupos