Uso Excesivo y Sistemático de “compartir” en Microsoft Dynamics CRM

Antecedentes

El modelo de autorización en Microsoft Dynamics CRM es sofisticado y dinámico. Los patrones tradicionales de las listas de Control de acceso (ACL) ofrecen también seguridad basada en funciones con una granularidad incluso de campos y registros individuales. Microsoft Dynamics CRM 2011 y Microsoft Dynamics CRM Online también ofrecen esta capacidad, pero una diferencia clave es que Microsoft Dynamics CRM se basa en la propiedad del registro y la jerarquía de la unidad de negocio. Como resultado, los niveles de acceso se basan en el propietario de un registro individual y la unidad de negocio al que pertenezca el propietario.

La acción de compartir permisos a nivel registro está disponible para otorgar privilegios a registros específicos, así como a los registros hijo registros (los cuales son aplicados con reglas en cascada configurables).

Microsoft Dynamics CRM 2011 presenta también propiedad del equipo para registros así como la seguridad de nivel de campo (FLS), que puede utilizarse para restringir el acceso a los campos individuales basados en roles.

 

Necesidad:

Algunos clientes requieren modelos de seguridad complejo para cubrir algunas necesidades como:

• Manejo de una “matriz compleja de seguridad”
• Manejo de un estricta "segregación de funciones" o "necesidad de conocer" el modelo usado.
• Excepciones relacionadas con normas de cumplimiento regulatorio u otros estándares.

 

Idea:

La idea de utilizar el mecanismo de compartir registros para implementar mediante programación cualquier modelo o "matriz", puede ser la idea más fácil. Después de todo, el cliente tiene el control.

Sin embargo el diseño debería aprovechar la configuración de seguridad de Microsoft Dynamics CRM e incluir una jerarquía organizacional bastante simple, depender de código personalizado para plug-ins y aplicar la opción de compartir registros necesarios para implementar el modelo de seguridad deseado. Por supuesto, los
registros deben ser explícitamente compartidos entre usuarios individuales por el contrario, las reglas en cascada nativas asegurarían el correcto “share” de los registros secundarios para los queues (colas).

 

Impacto

Cuando se comparte un registro a un usuario o a un team (equipo), se agrega una entrada a la tabla PrincipalObjectAccess (POA) en la base de datos, por cada una de las acciones compartidas. Además, conforme a las reglas en cascada en las relaciones de la entidad, se agrega una entrada para cada parte de cada registro hijo compartido. Por ejemplo, al compartir la entidad cuenta de un cliente con una relación 1:n a diversas entidades hijas (correo electrónico, llamada telefónica, tarea, cita, carta, contacto, caso, etc.) resultará en una entrada para cada regla hija que está siendo compartida específicamente. Es por ello que para implementaciones de Microsoft Dynamics CRM a gran escala que utilizan la acción de compartir, la tabla de POA puede crecer hasta varios millones se registros en poco tiempo.

 

Pregunta

¿En pocas palabras, la pregunta es "¿Qué es compartir a escala?”

 

Buenas Noticias

Utilizando técnicas de optimización y evitando la redundancia es posible reducir el número de registro de la tabla POA. Y el reducido tamaño de la bases de datos proporciona un rendimiento aceptable en el servidor.

 

"Peros"

El mecanismo de “compartir” no ha sido diseñado para uso general en general escala en un modelo de seguridad ya que:

• El producto y la interfaz de usuario no proporcionan nativamente la función para mostrar, informar y monitorear la acción “compartir” a través de varios registros
• Las reglas en cascada para registros secundarios pueden tomar una cantidad excesiva de tiempo de procesamiento si millones de registros son afectados.
• La realización de pruebas y la experiencia indican que la acción de “compartir” puede presentar problemas cuando el contenido de la tabla POA excede el 1 millón de registros – dependiendo del hardware y el tuning de la base de datos.
• La automatización de la acción “share” se basa en la lógica y el código de implementaciones personalizadas, por lo tanto podrían ser volátil y presentar errores en caso de un mal diseño o implantación.
• Reportes de integridad masivos requieren el desarrollo de código personalizado.

 

La Alternativa

Se sugieren investigar modelos alternativos. A menudo puede implementarse un modelo de seguridad complejo con teams (equipos) personalizados sin compartir, por ejemplo, la creación de un team (equipo) que posea un conjunto de registros, y por el hecho de poseer dichos registros obtener los privilegios correctos. Es importante tomar en cuenta que mientras que un usuario puede ser miembro de muchos equipos, sólo un equipo puede poseer un registro.

También se deben considerar factores evaluados y especificados:

• Planear una estructura personalizada para un team (equipo) evitando combinaciones irrelevantes.
• La combinación de 15 team (equipos) personalizados (A, B, C, A + B, B + C, A + C, A + B + C,...) generaría 215-1 = 32,767 teams (equipos) personalizados
• Planificar y diseño la automatización asegundando la integridad con código personalizado, también teniendo en cuenta la necesidad de ver, informar e interactuar con cualquier registro de un team (equipo) actual personalizado.
• Ejecutar pruebas de rendimiento y duración, así como cambios en los roles de seguridad para miles de teams (equipos) personalizados.

 

 Saludos,

 

 Claudia Cisneros

Dynamics CRM Support Escalation Engineer