Cómo se puede usar la seguridad basada en roles para controlar el acceso a las entidades
En Dynamics 365 Customer Engagement (on-premises) el concepto primario en seguridad basada en roles incluye los privilegios que definen un conjunto de acciones que se pueden realizar en la organización. Por ejemplo, el rol comercial tiene asignado un conjunto de privilegios que son relevantes al rendimiento de las tareas que se definen para ese rol. Todos los usuarios deben ser asignados a uno o más roles predefinidos o personalizados. En Dynamics 365 Customer Engagement (on-premises), los roles también se pueden asignar a los equipos. Cuando se asigna un usuario o un equipo para uno de estos roles, se asigna a la persona o los integrantes del equipo el conjunto de privilegios asociados a este rol. El usuario debe tener asignado por lo menos un rol.
Un privilegio autoriza al usuario para realizar una acción específica en un tipo específico de la entidad. Los privilegios se aplican a una clase completa de objetos, en lugar de a instancias individuales de objetos. Por ejemplo, si un usuario no tiene el privilegio de lectura de cuentas, los intentos del usuario para leer una cuenta generará un error. Un privilegio contiene nivel de acceso que determina los niveles dentro de la organización a la que se aplica un privilegio. Cada privilegio puede tener hasta cuatro niveles de acceso: Básico, Local, Profundo y Global.
Roles
Dynamics 365 Customer Engagement (on-premises) incluye catorce roles predefinidos que reflejan roles de usuario comunes con niveles de acceso definidos para que coincidan con el objetivo de seguridad recomendado de proporcionar acceso a la cantidad mínima de datos empresariales necesarios para el trabajo. Con estos roles se puede implementar rápidamente un sistema de Dynamics 365 Customer Engagement (on-premises) sin que sea necesario definir los propios roles. Sin embargo, se pueden crear roles personalizados mediante roles predefinidos como una plantilla, o bien se puede definir un nuevo conjunto de roles. Para obtener una lista, consulte Lista de roles de seguridad predefinidos.
Cada rol se asocia con un conjunto de privilegios que determina el acceso de usuario o equipo a la información de la compañía.
Puede crear roles en Dynamics 365 Customer Engagement (on-premises) y modificar o quitar esos roles personalizados para que se adapten a las necesidades del negocio. Los roles que cree para su unidad de negocio los heredan todas las unidades de negocio de la jerarquía.
Puede asignar una o más roles a un usuario o equipo. Por ejemplo, un usuario puede tener el rol Jefe de ventas además de ser Representante de servicio de atención al cliente, en cuyo caso ese usuario tiene todos los privilegios de ambos roles.
No se pueden modificar privilegios a nivel de usuario, pero se puede crear un nuevo rol con los privilegios deseados. Por ejemplo, Juan tiene un rol Comercial, por lo que debe aceptar a todos los clientes potenciales asignados a él. Sin embargo, el administrador desea que Juan pueda reasignar los clientes potenciales asignados a John. Como resultado, el administrador tiene que modificar el rol Comercial para permitir esto o crear un nuevo rol que incorpore este privilegio específico y agregue a Juan a este rol. Crear un nuevo rol es la opción recomendada a menos que considere necesario que todos los usuarios asignados al rol Comercial tengan este privilegio adicional.
Privilegios
En Dynamics 365 Customer Engagement (on-premises), hay más de 580 privilegios que están predefinidos en todo el sistema durante la instalación. Un privilegio es un permiso para realizar una acción en Dynamics 365 Customer Engagement (on-premises). Algunos privilegios se aplican en general y algunos en un tipo específico de la entidad.
Dynamics 365 Customer Engagement (on-premises) usa privilegios como base de seguridad subyacente. Los privilegios están "integrados" en el producto y se usan a través de los niveles de la aplicación y de la plataforma. No se pueden agregar o quitar privilegios, o cambiar cómo se usan los privilegios para permitir el acceso a determinadas funciones, pero se pueden crear nuevos roles del conjunto de privilegios existente.
Cada rol define un conjunto de privilegios que determina el acceso de usuario o equipo a la información de la compañía. La plataforma comprueba el privilegio y rechaza la operación si el usuario no tiene el privilegio necesario. Un privilegio se combina con una profundidad o nivel de acceso.
Por ejemplo, el rol Comercial puede incluir los privilegios Read Account
con acceso Basic
y Write Account
con acceso Basic
, mientras que el rol Jefe de ventas puede contener privilegios como Read Account
con acceso Local
y Assign Contact
con acceso Local
.
La mayoría de las entidades tienen un conjunto de posibles privilegios que se pueden agregar a un rol que corresponde a las diversas acciones que se pueden realizar en los registros de ese tiempo de la entidad.
Cada acción en el sistema, y cada mensaje que se describe en la documentación del SDK, necesita uno o varios privilegios para que se deben realizar.
Niveles de acceso
El nivel de acceso o profundidad de privilegio para un privilegio determina, para un tipo de entidad determinada, a qué niveles de la jerarquía de la organización un usuario puede actuar en ese tipo de entidad.
En la siguiente tabla se enumeran los niveles de acceso en Dynamics 365 Customer Engagement (on-premises), empezando por la mayoría de los accesos. El icono aparece en el editor de roles de seguridad de la aplicación web.
Nivel de acceso | Descripción |
---|---|
Global. Este nivel de acceso permite a un usuario tener acceso a todos los registros de la organización, independientemente del nivel jerárquico de unidades de negocio al que pertenece la instancia o el usuario. Los usuarios con nivel de acceso Global, también tienen acceso Profundo, Local y Básico automáticamente. Debido a que este nivel de acceso permite obtener acceso a la información de toda la organización, debe restringirse de modo que cumpla lo estipulado en el plan de seguridad de datos de la organización. Este nivel de acceso generalmente se reserva para directores con autoridad sobre la organización. La aplicación hace referencia a este nivel de acceso como Organización. |
|
Profundo. Este nivel de acceso le da al usuario acceso a los registros de la unidad de negocio del usuario y de todas las unidades de negocio subordinadas a la unidad de negocio del usuario. Los usuarios que tienen el nivel de acceso Profundo, automáticamente tienen también los niveles de acceso Local y Básico. Debido a que este nivel de acceso permite obtener acceso a la información de toda la unidad de negocio y las unidades de negocio subordinadas, debe restringirse de modo que cumpla lo estipulado en el plan de seguridad de datos de la organización. Este nivel de acceso generalmente se reserva para directores con autoridad sobre las unidades de negocio. La aplicación hace referencia a este nivel de acceso como Primario: unidades de negocio secundarias. |
|
Local. Este nivel de acceso le da al usuario acceso a los registros de la unidad de negocio del usuario. Los usuarios que tienen el nivel de acceso Local, automáticamente tienen también el nivel de acceso Básico. Debido a que este nivel de acceso permite obtener acceso a la información de toda la unidad de negocio, debe restringirse de modo que cumpla lo estipulado en el plan de seguridad de datos de la organización. Este nivel de acceso generalmente se reserva para directores con autoridad sobre la unidad de negocio. La aplicación hace referencia a este nivel de acceso como Unidad de negocio. |
|
Básico. Este nivel de acceso permite a un usuario tener acceso a los registro de los que es propietario, los objetos que se han compartido con el usuario y los objetos compartidos con el equipo del que es miembro el usuario. Este es el nivel de acceso típico para representantes de ventas y servicios. La aplicación hace referencia a este nivel de acceso como Usuario. |
|
Ninguno. No se permite ningún acceso. |
Juntándolo todo
Si un usuario tiene el privilegio
Deep Read Account
, el usuario puede leer todas las cuentas de su unidad de negocio y todas las cuentas de las unidades de negocio secundarias de esa unidad de negocio.Si un usuario tiene privilegios
Local Read Account
, el usuario puede leer todas las cuentas de la unidad de negocio local.Si a un usuario se le asigna el privilegio
Basic Read Account
, el usuario solo puede leer las cuentas de las que es propietario o las cuentas que han compartido con él.Un representante del servicio al cliente con el privilegio
Basic Read Account
puede ver las cuentas de las que es propietario y las cuentas que otro usuario ha compartido con este usuario. Esto permite que el representante lea los datos de la cuenta que corresponde a una solicitud de servicio, pero no puede cambiar datos.Un analista de datos con el privilegio
Local Read Account
puede ver los datos de la cuenta y ejecutar informes relacionados con la cuenta para todas las cuentas de su unidad de negocio.Un responsable de finanzas de la compañía con el privilegio
Deep Read Account
puede ver los datos de la cuenta y ejecutar informes relacionados con la cuenta para todas las cuentas de su unidad de negocio y las cuentas de las unidades de negocio secundarias.
Lista de roles de seguridad predefinidos
La siguiente tabla muestra el conjunto predefinido de roles que se incluyen.
Rol | Descripción |
---|---|
Director general | Usuario que administra la organización en el nivel de unidad corporativa. |
Jefe de servicio al cliente | Usuario que administra actividades de servicio al cliente en el nivel local o de equipo. |
Representante del servicio al cliente (CSR) | Representante de servicio al cliente en cualquier nivel. |
Delegar | Un usuario al que se le permite actuar en nombre de otro usuario. |
Jefe marketing | Usuario que administra actividades de marketing en el nivel local o de equipo. |
Profesional de marketing | Usuario dedicado a actividades de marketing en cualquier nivel. |
Jefe de ventas | Usuario que administra actividades de ventas en el nivel local o de equipo. |
Vendedor | Vendedor en cualquier nivel. |
Administrador de programación | Un usuario que programa citas de servicio. |
Programador | Usuario que administra servicios, recursos requeridos y horas de trabajo. |
Usuario de soporte | Un usuario que es un ingeniero de soporte al cliente. |
Administrador del sistema | Usuario que define e implementa el proceso en cualquier nivel. |
Personalizador del sistema | Un usuario que personaliza entidades, atributos, Relaciones y formularios de Dynamics 365 for Customer Engagement. |
Vicepresidente de marketing | Usuario que administra actividades de marketing en el nivel de unidad de negocio. |
Vicepresidente de ventas | Usuario que administra la organización de ventas en el nivel de unidad de negocio. |
Vea también
El modelo de seguridad de Microsoft Dynamics 365 Customer Engagement (on-premises)
Entidades de privilegio y rol
Usar seguridad basada en registros para controlar el acceso a registros
Cómo se puede usar la seguridad de campos para controlar el acceso a los valores de campo en Microsoft Dynamics 365 Customer Engagement (on-premises)