Consideraciones en la implementación de la seguridad en Microsoft Dynamics CRM

Microsoft Dynamics CRM es una herramienta de Customer Relationship Management (CRM) y forma parte de la familia de productos de Microsoft Dynamics. En su distribución básica se enfoca en ventas, marketing y Service desk, pero es en realidad una plataforma extensible utilizando el framework .Net para cubrir múltiples demandas.

Esta solución tiene un modelo de seguridad que es ampliamente flexible y personalizable, teniendo un alto grado de granularidad que permite administrar de forma muy fina el nivel de acceso de los diferentes usuarios y roles. Esto, por otro lado, también conlleva un punto clave y de gran dimensión que es generalmente minimizado en los proyectos de implementación de estas soluciones y se evidencia el mismo sobre la recta final al momento de la implementación.

Para comprender el modelo de seguridad, debemos ver las partes que lo componen, que son: Business Units (o Security Units), Security Roles y la cuenta del usuario.

Microsoft Dynamics CRM tiene una estructura de árbol para representar las Business Units. Este árbol funciona a modo de organigrama de la organización comercial y permite la administración granular de acceso a los datos de la empresa, permitiendo por ejemplo la visualización de un cliente por un grupo de usuarios y no de otros.

Al definir este árbol también se debe definir la necesidad o no de restringir este tipo de accesos. Eventualmente habrán registros que podrán ser públicos a toda la organización, como por ejemplo una tabla maestra de países, pero los productos estarán limitados a las áreas de negocio que vendan dichos productos. Esta definición debe realizarse en las etapas más tempranas del diseño para que el desarrollo de los casos de uso los tome en consideración.

Luego se deberán definir los roles de seguridad de usuarios que definirán que nivel de acceso tendrán sus miembros a nivel de cada una de las entidades definidas. Una entidad en Microsoft Dynamics CRM es similar a una tabla de registros, que a su vez tiene N cantidad de campos. El rol entonces permitirá definir qué nivel de acceso se tendrá en cada una de ellas y la granularidad permite definir el acceso en:

  • Creación (create): Permite crear un registro nuevo en esa entidad
  • Lectura (read): Permite acceder a visualizar el contenido de la tabla o entidad
  • Actualización (write): Permite modificar los contenidos de la tabla
  • Borrar (delete): Permite el borrado de registros de la entidad
  • Adjuntar (append): Permite vincular registros de esta entidad en otra
  • Adjunta A (append to): Permite que se le vinculen registros de otra entidad
  • Asingar (assign): Permite modificar el dueño del registro de este dato
  • Compartir (share): Permite compartir un registro con otro usuario que no tenga acceso

Adicionalmente a este conjunto de acciones, los permisos deben ser definidos a nivel de alcance de datos, siendo posibles los siguientes niveles de acceso para cada una de las actividades de la lista anterior:

  • Sin acceso (none): No permite acceso alguno
  • Usuario (user): Permite la acción sobre aquellos registros que haya creado el usuario
  • Unidad (business unit): Permite la acción sobre aquellos registros que pertenezcan a los usuarios ubicados en la misma unidad
  • Padre-hijo (parent-Child): Al igual que en la anterior, pero también permite accionar sobre los registros creados en unidades que dependan jerárquicamente de la unidad donde se encuentra ubicado el usuario
  • Organización (organization): Permite ejecutar la acción sobre cualquier registro independientemente de su ubicación en la organización

Una vez definido el rol, dependerá entonces de la ubicación del usuario en la estructura de organizacional sumado a la asignación del rol para efectivamente calcular el nivel de acceso que tendrá el usuario finalmente. El mismo rol asignado a distintos usuarios puede efectivamente arrojar resultados distintos, ya que si estos usuarios están en estructuras diferentes tendrán acceso a datos específicos a esa estructura acorde a lo definido en el rol.

Esta definición debe ser acompañada desde un principio en el proyecto por personal dedicado a la gestión de la seguridad de los datos y que pueda hacer un modelado correcto de los mismos, que respete los requerimientos del usuario final y que aproveche en su extensión al módulo de seguridad de esta herramienta.

 

Read More