Cómo se puede usar la seguridad basada en registros para controlar el acceso a registros de Microsoft Dynamics CRM 2015

Publicado: noviembre de 2016

Se aplica a: Dynamics CRM 2015

La seguridad basada en el registro de Microsoft Dynamics CRM 2015 y Microsoft Dynamics CRM Online se aplica a los registros individuales. Se proporciona por el uso de los derechos de acceso.

La relación entre un derecho de acceso y un privilegio es que los derechos de acceso se aplican solo después de que los privilegios hayan entrado en vigor. Por ejemplo, si un usuario no tiene el privilegio de lectura de cuentas, no podrá leer ninguna cuenta, independientemente de los derechos de acceso que otro usuario pueda concederle sobre una cuenta específica a través del uso compartido.

En este tema

Derechos de acceso

Uso compartido de registros

Asignando registros...

Recuperar los derechos de acceso a un registro

Dependencias entre los derechos de acceso

Derechos de acceso

Un derecho de acceso se concede a un usuario para un registro en particular. En la siguiente tabla se enumeran las descripciones de estos derechos de acceso.

Crear accesos

El derecho para crear un registro de un tipo de entidad no se incluye en la tabla anterior porque este derecho no se aplica a un registro individual, sino a una clase de entidades. El derecho para crear se controla como un privilegio en vez de como un acceso secundario. El usuario que crea un registro tiene todos los derechos sobre ese registro, a menos que sus otros privilegios prohíban un derecho específico.

El privilegio Crear controla si puede crear un registro. Si tiene el privilegio Crear con acceso Local, Profundo u Organización, puede crear registros para otros usuarios. Si tiene los privilegios Crear y Leer con acceso Básico, puede crear registros para usted mismo.

Para obtener más información sobre las dependencias que se relacionan para crear privilegios, consulte Dependencias entre los derechos de acceso.

Uso compartido de registros

Al compartir se permite que los usuarios conceder a otros usuarios o equipos acceso a la información específica del cliente. Esto resulta útil para compartir información con usuarios en los roles que solo tienen el nivel de acceso Básico. Por ejemplo, en una organización que proporciona al personal de ventas acceso Básico de lectura y escritura a las cuentas, un comercial puede compartir una oportunidad con otro comercial de forma que los dos pueden realizar el seguimiento del progreso de una venta importante.

Por razones de seguridad, únicamente se deben compartir los registros necesarios con el menor número de usuarios posible. Conceda solo el mínimo acceso necesario para que los usuarios puedan realizar su trabajo.

Microsoft Dynamics 365 ofrece las siguientes funciones de uso compartido:

• Compartir. Cualquier usuario con privilegios compartidos en un tipo de entidad determinado puede compartir registros de ese tipo con cualquier otro usuario o equipo en Microsoft Dynamics 365. Para compartir un registro, use GrantAccessRequest.

  Al compartir un registro con otro usuario, indique los derechos de acceso (Leer, Escribir, Eliminar, Anexar, Asignar y Compartir) que desee conceder a otro usuario. Los derechos de acceso de un registro compartido pueden ser diferentes para cada usuario con el que se comparte el registro. Sin embargo, no puede otorgar a un usuario un derecho que ese usuario no tendría para ese tipo de entidad, en función del rol asignado a dicho usuario. Por ejemplo, si un usuario no tiene privilegios de lectura para las cuentas y usted comparte una cuenta con ese usuario, el usuario no podrá ver esa cuenta.

• Modificar el uso compartido. Puede modificar los derechos otorgados a un registro compartido después de que ha sido compartido. Para modificar el uso compartido de un registro, use ModifyAccessRequest.

• Quitar el uso compartido. Si comparte un registro con otro usuario o equipo, puede cancelar el uso compartido del registro. Después de quitar el uso compartido de un registro, el otro usuario o equipo pierde los derechos de acceso al registro. Para quitar el uso compartido de un registro, use RevokeAccessRequest.

Un usuario podría tener acceso al mismo registro en más de un contexto. Por ejemplo, un usuario podría compartir directamente un registro con los derechos de acceso específicos, y ese usuario también podría estar en un equipo en el que se comparte el mismo registro con diferentes derechos de acceso. En este caso, los derechos de acceso que el usuario tiene en el registro son una combinación de todos los derechos.

Para obtener una lista de las entidades que admiten el uso compartido, consulte GrantAccessRequest.

Uso compartido y herencia

Si se crea un registro y el registro primario tiene determinadas propiedades de uso compartido, el nuevo registro hereda esas propiedades. Por ejemplo, Juan y Miguel trabajan con un cliente potencial de prioridad alta. Juan crear un nuevo cliente potencial y dos actividades, comparte el cliente potencial con Miguel y selecciona el uso compartido en cascada. Miguel realiza una llamada de teléfono y envía un correo electrónico sobre el nuevo cliente potencial. Juan comprueba que Miguel se ha puesto en contacto con la compañía dos veces, de modo que él no realiza otra llamada.

El uso compartido se mantiene en registros individuales. Un registro hereda las propiedades del uso compartido de su primario y también mantiene sus propias propiedades de uso compartido. Por lo tanto, un registro puede tener dos conjuntos de propiedades de uso compartido, uno propio y otro que hereda del primario.

Al quitar el uso compartido de un registro primario, se quitan las propiedades del uso compartido de los objetos (registros) que se heredaron del primario. Es decir, todos los usuarios que anteriormente tenían visibilidad en este registro ya no la tienen. Los objetos secundarios todavía se podrían compartir con algunos de estos usuarios si se compartieran de forma individual, no desde el registro primario.

Asignando registros...

Un usuario con privilegios para asignar un registro puede asignar dicho registro a otro usuario. Cuando se asigna un registro, el nuevo usuario o equipo pasa a ser el propietario del registro y de sus registros relacionados. El usuario o equipo original pierde la propiedad de los registros, pero automáticamente la comparte con el nuevo propietario.

En Microsoft Dynamics 365, el administrador del sistema puede decidir para una organización si los registros se deben compartir con los propietarios anteriores o no después de la operación de asignación. Si se selecciona Compartir con propietario anterior, el anterior propietario comparte el registro con todos los derechos de acceso después de la operación de asignación. De lo contrario, el propietario anterior no comparte el registro y no puede tener acceso al registro, en función de sus privilegios. El atributo Organization.ShareRoPreviousOwnerOnAssign controla este valor.

Para obtener una lista de las entidades que admiten Asignar, consulte AssignRequest.

Recuperar los derechos de acceso a un registro

Use el mensaje RetrievePrincipalAccessRequest para recupera los derechos de acceso que tiene la entidad de seguridad especificada (usuario o equipo) sobre un registro.

Use el mensaje RetrieveSharedPrincipalsAndAccessRequest para recupera todas las entidades de seguridad (usuarios o equipos) que tienen acceso a un registro, conjuntamente con los derechos de acceso al registro.

Dependencias entre los derechos de acceso

A veces, las dependencias de seguridad existen porque es necesario tener más de un derecho de acceso para realizar una acción determinada. Por ejemplo, si tiene el derecho de acceso para crear para las cuentas, puede crear un registro del tipo de entidad de cuenta. Sin embargo, a menos que también tenga acceso para leer para las cuentas, no puede crear un registro de cuenta y ser el propietario del registro nuevo.

En la siguiente tabla se enumeran las dependencias de derechos de acceso de acciones especificadas.

Existe otro tipo de dependencia cuando los objetos son subordinados a otro objeto. Por ejemplo, el objeto de oportunidad no puede existir por sí solo. Cada objeto de oportunidad siempre está asociado a una cuenta o contacto. Para crear una oportunidad, debe tener los derechos de acceso para anexar a en las cuentas y los derechos de acceso para anexar en las oportunidades.

Ver también

AccessRights
RetrievePrincipalAccessRequest
El modelo de seguridad de Microsoft Dynamics CRM 2015
Cómo se puede usar la seguridad basada en roles para controlar el acceso a las entidades de Microsoft Dynamics CRM 2015
Cómo se puede usar la seguridad de campos para controlar el acceso a los valores de campo en Microsoft Dynamics CRM 2015
Introducción a entidades en Microsoft Dynamics CRM 2015
Comportamiento de relación de entidades

© 2017 Microsoft. Todos los derechos reservados. Copyright