Seguridad de jerarquía para controlar acceso

El modelo de seguridad de jerarquía es una extensión de los modelos de seguridad existentes que usan unidades de negocio, roles de seguridad, recursos compartidos y equipos. Se puede utilizar con todos los demás modelos de seguridad existentes. La seguridad de jerarquía proporciona un acceso más específico a registros de una organización y ayuda a reducir los costos de mantenimiento.

Por ejemplo, en situaciones complejos, puede empezar creando varias unidades de negocio y luego agregar la seguridad de jerarquía. Esta seguridad añadida proporciona un acceso más granular a los datos con muchos menos costos de mantenimiento que numerosas unidades de negocio podrían requerir.

Modelos de seguridad de jerarquía de gerente y de puestos

Dos modelo de seguridad se pueden usar para jerarquías: la jerarquía de administrador y la jerarquía de posición. Con la jerarquía del gerente, un gerente debe encontrarse dentro de la misma unidad de negocio que el informe, o en la unidad de negocio matriz de la unidad de negocio del informe, para tener acceso a los datos del informe. La jerarquía de posición permite el acceso a los datos a través de unidades de negocio. Si se trata de una organización financiera, puede preferir el modelo de jerarquía de Administrador, para evitar que los administradores accedan a los datos fuera de sus unidades de negocio. Sin embargo, si forma parte de una organización de servicio al cliente y desea que los gerentes tengan acceso a casos gestionados por diferentes unidades de negocio, la jerarquía de posición puede funcionar mejor para usted.

Jerarquía de administrador

El modelo de seguridad jerárquico de administrador se basa en la cadena de administración o la estructura de subordinados directos, donde la relación del administrador y del subordinado se establece mediante el campo Jefe en la tabla de usuario del sistema. Con este modelo de seguridad, los administradores podrán tener acceso a los datos a los que los tienen acceso sus subordinados. Pueden hacer trabajos en nombre de sus subordinados directos o acceder a información que necesite aprobación.

Para un informe no directo dentro de la misma cadena de mando del gerente, un gerente tiene acceso de solo lectura a los datos del informe no directo. Para un informe directo, el administrador tiene acceso de Lectura, Escritura, Anexar, Anexar a los datos del informe. Para ilustrar el modelo de seguridad de jerarquía de administrador, observemos el diagrama siguiente. El director general puede leer o actualizar los datos del vicepresidente de ventas y los datos del vicepresidente de servicio. Sin embargo, el director general puede leer únicamente los datos del jefe de ventas y los datos del jefe de servicio, así como los datos de ventas y soporte técnico. Puede restringir con más detalle la cantidad de datos accesibles para un gerente. La profundidad se utiliza para limitar cuántos niveles tiene un administrador con acceso de solo lectura a los datos de sus reportes. Por ejemplo, si la profundidad está establecida en 2, el director general puede ver los datos del vicepresidente de ventas, del vicepresidente de servicio y los jefes de ventas y servicio. Sin embargo, el director general no ve los datos de ventas o los datos de soporte técnico.

Captura de pantalla que muestra la jerarquía de administradores. Esta jerarquía incluye al director ejecutivo, vicepresidente de ventas, vicepresidente de servicio, gerentes de ventas, gerentes de servicio, ventas y soporte.

Es importante observar que si un subordinado directo tiene un nivel de acceso de seguridad más alto a una tabla que su jefe, es posible que el jefe no pueda ver todos los registros a los que el subordinado tiene acceso. El siguiente ejemplo muestra este aspecto.

• Una sola unidad de negocio tiene tres usuarios: Usuario 1, Usuario 2 y Usuario 3.

• El Usuario 2 es subordinado directo de Usuario 1.

• El Usuario 1 y el Usuario 3 tienen acceso de lectura a nivel de usuario en la tabla de Cuentas. Este nivel de acceso permite a los usuarios tener acceso a los registros de los que son propietarios, los registros que se comparten con el usuario y los registros compartidos con el equipo del que es miembro el usuario.

• El Usuario 2 tiene acceso de lectura a unidades de negocio en la tabla Cuenta. Este acceso permite que el usuario 2 vea todas las cuentas de la unidad de negocio, incluidas todas las cuentas propiedad del usuario 1 y el usuario 3.

• El usuario 1, como jefe directo del usuario 2, tiene acceso a las cuentas pertenecientes o compartidas con el usuario 2, incluidas las cuentas que se comparten o son propiedad de otros equipos del usuario 2. Sin embargo, el usuario 1 no tiene acceso a las cuentas del usuario 3, aunque el subordinado directo puede tener acceso a las cuentas de usuario 3.

Jerarquía de posición

La jerarquía de posición no se basa en la estructura de subordinados directos, como la jerarquía de administrador. Un usuario no tiene que ser administrador de otro usuario para acceder a los datos del usuario. Como administrador, usted define diferentes posiciones de trabajo en la organización y las organizará en la jerarquía de posición. Luego, puede agregar usuarios a cualquier posición determinada, o, como también decimos, etiquetar un usuario con una posición específica. Un usuario solo puede ser etiquetado con una posición en una jerarquía determinada, no obstante, una ubicación se puede usar para varios usuarios. Los usuarios en las posiciones más elevadas de la jerarquía tienen acceso a los datos de los usuarios en las posiciones inferiores, dentro de la ruta ancestral directa. Las posiciones directas más altas tienen acceso de Lectura, Escritura, Anexar, Anexar a a los datos de las posiciones inferiores en la ruta de antecesores directos. Las posiciones más altas no directas tienen acceso de solo lectura a los datos de las posiciones inferiores en la ruta jerárquica de antecesores directos.

Veamos el diagrama siguiente para ilustrar el concepto de ruta de antecesores directos. La posición del gerente de ventas tiene acceso a los datos de ventas; sin embargo, no tiene acceso a los datos de soporte técnico, que se encuentran en una ruta de ancestro diferente. Lo mismo se aplica para la posición del administrador de servicio. No tiene acceso a los datos de ventas, que están en la ruta de ventas. Como en la jerarquía de gestión, puede limitar la cantidad de datos accesibles por posiciones más altas mediante la profundidad. La profundidad limita el número de niveles de profundidad a los que una posición superior tiene acceso de solo lectura, a los datos de las posiciones inferiores de la ruta de antecedentes directos. Por ejemplo, si la profundidad está establecida en 3, la posición de director general puede ver todos los datos desde las posiciones de vicepresidente de ventas y vicepresidente de servicio hasta las posiciones de ventas y soporte técnico.

Captura de pantalla que muestra la jerarquía de Posición. Esta jerarquía incluye al director ejecutivo, vicepresidente de ventas, vicepresidente de servicio, gerentes de ventas, gerentes de servicio, ventas y soporte.

Configurar la seguridad jerárquica

Para configurar la seguridad de la jerarquía, asegúrese de tener el permiso de administador del sistema para actualizar la configuración.

• Siga los pasos de la sección Visualización del perfil de usuario.
• ¿No tiene los permisos adecuados? Póngase en contacto con el administrador del sistema.

La seguridad de jerarquía se desactiva de forma predeterminada. Complete los siguientes pasos para habilitar la seguridad de jerarquía.

1. Inicie sesión en el centro de administración de Power Platform como administrador (administrador de Dynamics 365 o administrador de Microsoft Power Platform).

2. En el panel de navegación, seleccione Administrar.

3. En el panel Administrar , seleccione Entornos y, a continuación, seleccione un entorno de la lista.

4. Vaya a ConfiguraciónUsuarios + PermisosSeguridad de jerarquía.

5. En Modelo de jerarquía, seleccione Habilitar modelo de jerarquía de administrador o Habilitar modelo de jerarquía de posición, dependiendo de sus requisitos.

   Importante

   Para hacer cambios en la seguridad de jerarquía, debe tener el privilegio para cambiar la configuración de seguridad de la jerarquía.

   En el área de Gestión de Tabla de Jerarquía, todas las tablas del sistema están habilitadas para la seguridad de jerarquía de manera predeterminada, pero puede excluir tablas específicas de la jerarquía. Para excluir tablas específicas del modelo de jerarquía, desactive las marcas de verificación junto al nombre de la tablas que quiera excluir y guarde los cambios.

   Captura de pantalla de la página Seguridad de jerarquía en Configuración de entornos.

6. Establezca la Profundidad en un valor deseado para limitar el número de niveles de profundidad a los que un gerente tiene acceso de solo lectura a los datos de sus informes.

   Por ejemplo, si la profundidad es igual 2, un administrador solo puede tener acceso a sus cuentas y las cuentas de los subordinados que se encuentren dos niveles por debajo. En nuestro ejemplo, si inicia sesión en aplicaciones de participación del cliente como vicepresidente de ventas no administrador, solo verá las cuentas activas de los usuarios como se muestra:

   Captura de pantalla que muestra el acceso de lectura para el VP de Ventas y otros puestos.

   Nota

   Mientras la seguridad de jerarquía concede al vicepresidente de ventas acceso a los registros en el rectángulo rojo, puede obtenerse acceso adicional en función del rol de seguridad que tenga el vicepresidente de ventas.

Configuración de las jerarquías de gerente y puesto

La jerarquía de administrador se crea fácilmente utilizando la relación del administrador en el registro del usuario del sistema. Usa el campo de búsqueda 'Manager (ParentsystemuserID)' para especificar el administrador del usuario. Si ya ha creado la jerarquía de posición, también puede etiquetar al usuario con una posición específica en la jerarquía de posición. En el siguiente ejemplo, el comercial depende del gerente de ventas en la jerarquía de gerencia y además tiene la posición de ventas en la jerarquía de puestos.

Captura de pantalla que muestra un registro de usuario de vendedor.

Para agregar un usuario a una posición específica en la jerarquía de posición, use el campo de búsqueda llamado Posición en el formulario del registro del usuario.

Captura de pantalla que muestra cómo agregar un usuario a una posición en Seguridad de jerarquía

Para cambiar la posición en el formulario del registro de usuario, en la barra de navegación, elija Más (...) y seleccione otra posición.

Cambiar posición en la jerarquía de seguridad

Para crear una jerarquía de puestos:

1. Seleccione un entorno y vaya a ConfiguraciónUsuarios + PermisosPosiciones.

   Para cada posición, especifique el nombre de la posición, el elemento principal de la posición, y la descripción. Agregue usuarios a esta posición con el campo de búsqueda llamado Usuarios en esta posición. La imagen siguiente es un ejemplo de la jerarquía de posición con posiciones activas.

   Posiciones activas en la seguridad de la jerarquía

   El ejemplo de los usuarios habilitados con sus correspondientes posiciones se indica en la imagen siguiente.

   Captura de pantalla que muestra usuarios habilitados con puestos asignados.

Editar y actualizar múltiples niveles de registros para informes directos

De forma predeterminada, los gerentes pueden actualizar los registros de sus informes directos y los registros de las personas que reportan a sus informes directos. Básicamente, puedes actualizar registros que tienen hasta tres niveles de profundidad. Puede cambiar la configuración predeterminada completando los siguientes pasos.

1. Instale la herramienta de OrganizationSettingsEditor.
2. Edite la configuración "HierarchyLevelForHierarchyFeature".
3. Introduzca el número de profundidad de nivel directo. Por ejemplo, introduzca 5.
4. Seleccione Actualizar.

Incluir o excluir registros que pertenezcan a un subordinado directo con el estado de usuario deshabilitado.

Los gerentes pueden ver los registros de sus subordinados directos con estado deshabilitado en los entornos donde la seguridad jerárquica estará habilitada a partir del 31 de enero de 2024. Para otros entornos, los registros de los informes directos con estado deshabilitado no se incluyen en la vista del administrador.

Para incluir registros de los informes directos de estado de deshabilitado:

1. Instale la herramienta de OrganizationSettingsEditor.
2. Actualice la configuración AuthorizationEnableHSMForDisabledUsers a verdadero.
3. Deshabilite los modelos de jerarquía.
4. Vuelva a habilitarlos.

Para excluir registros de empleados directos con estatus inhabilitado:

1. Instale la herramienta de OrganizationSettingsEditor.
2. Actualice la configuración "AuthorizationEnableHSMForDisabledUsers" en false.
3. Deshabilite los modelos de jerarquía.
4. Vuelva a habilitarlos.

• Cuando deshabilita y vuelve a habilitar el modelado de jerarquía, la actualización puede llevar tiempo, ya que el sistema necesita volver a calcular el acceso a los registros del administrador.
• Si ve un tiempo de espera, reduzca la cantidad de tablas en la lista Gestión de tablas de jerarquía para incluir solo las tablas que el administrador debe ver. Si el tiempo de espera persiste, envíe un ticket de soporte para solicitar asistencia.
• Los registros del subordinado directo con estado deshabilitado se incluyen si estos registros se comparten con otro subordinado directo que esté activo. Puede excluir estos registros eliminando el recurso compartido.

Consideraciones de rendimiento

Para aumentar el rendimiento, es recomendable:

• Mantenga la seguridad de jerarquía efectiva en 50 usuarios o menos bajo un administrador o puesto. La jerarquía podría tener más de 50 usuarios que reportan a un administrador o posición, pero puede usar la configuración de Profundidad para reducir el número de niveles de acceso de solo lectura y así limitar el número efectivo de usuarios bajo un administrador o posición a 50 usuarios o menos.

• Utilice modelos de seguridad jerárquica con otros modelos de seguridad existentes para escenarios más complejos. No cree demasiadas unidades de negocio. Es mejor que cree menos unidades de negocio y que agregue seguridad jerárquica.

• Mantenga el número de HierarchyLevelForHierarchyFeature en el nivel más bajo de profundidad directa requerido por los requisitos de su negocio para que los gerentes puedan actualizar los registros de sus subordinados directos.

Consulte también

Security en Microsoft Dataverse
Consultar y visualizar datos jerárquicos