Introducción
Para garantizar que la implementación de Microsoft Dynamics 365 por parte del cliente sea más segura, el arquitecto de soluciones debe planificar e impartir un taller de modelo de seguridad. El objetivo del taller es evaluar el modelo de seguridad propuesto y ofrecer comentarios y recomendaciones que destaquen los riesgos y problemas técnicos, y luego identifiquen las prácticas recomendadas.
El taller de modelo de seguridad debe programarse y completarse durante la fase de implementación del proyecto. Debe ofrecer un resumen de todas las áreas relacionadas con la seguridad que se trataron previamente en otros talleres.
Puede descargar ejemplos de plantillas para cada taller del módulo y usarlas cuando realice estos talleres de soluciones.
Por qué importa la seguridad
Dynamics 365 impulsa los negocios de sus clientes. Los datos empresariales confidenciales relativos a los clientes, la información financiera y los procesos críticos para la empresa del sistema deben resultar seguros para los clientes que adopten el sistema.
La estrategia de seguridad correcta equilibra los requisitos de seguridad legítimos con la necesidad de acceso al sistema y la colaboración entre empresas. Al implementar Dynamics 365, debe equilibrar dos aspectos: el acceso de los usuarios y la seguridad del sistema.
Conforme a un punto de vista, la preocupación por la seguridad de los datos y del sistema es importante. Sus datos impulsan su negocio. Sus clientes, sus pedidos y la información de contacto de sus contactos empresariales clave son elementos que no desea que caigan en manos de un competidor. Con las regulaciones que rodean los datos personales, su empresa podría ser responsable si una infracción de datos afectara a datos personales.
Alternativamente, están los problemas de usabilidad del sistema y de adopción de usuarios. Una razón principal para implementar Dynamics 365 es aumentar la visibilidad y el uso compartido de datos empresariales entre grupos, incluida la eliminación de los silos de datos en su organización. Al dar visibilidad a los contactos y las cuentas en su organización, los equipos pueden colaborar de manera efectiva en lugar de competir, lo que ayuda a disponer de una versión de referencia cuando se trata de información maestra de contactos y cuentas. Si va demasiado lejos en cualquiera de las direcciones, corre el riesgo de que falle su implementación.
Si es demasiado laxo con la seguridad, los usuarios pueden cambiar datos que no deberían poder cambiar, contaminando así la versión única de referencia y creando una percepción de que los datos del sistema no son confiables.
Si es demasiado estricto con la seguridad y lo bloquea todo, para que los usuarios solo puedan ver un pequeño subconjunto de los registros del sistema, disminuirá el valor de Dynamics 365 como herramienta de colaboración. Luego, por diseño, volverá a los antiguos silos de datos, solo que en una ubicación diferente.
Consideraciones sobre el modelo de seguridad
Antes de explorar los detalles del taller, las siguientes secciones revisarán los elementos de seguridad clave que son comunes para la mayoría de las implementaciones de Dynamics 365.
Crear una estrategia de seguridad
Si bien la estrategia de seguridad de todos será ligeramente diferente, las siguientes directrices pueden resultar útiles para su implementación.
Sea más restrictivo con la escritura que con la lectura
Para mantener una buena calidad de los datos, una buena idea es limitar quién puede editar o eliminar registros, como limitar los derechos de edición o eliminación a solo los propietarios de los registros. Frecuentemente, tiene más sentido ser menos restrictivo sobre los registros que pueden leer otros usuarios. Este enfoque conserva la usabilidad de Dynamics 365 y permite a los usuarios mantener el contexto sobre cómo se relacionan sus registros con otros registros, como las cuentas primarias. Sin embargo, el enfoque elimina el riesgo de que los usuarios, por malicia o error, puedan editar o eliminar registros que no posean.
Simplifique
La caja de herramientas de seguridad de Dynamics 365 incluye muchas herramientas; sin embargo, antes de decidir usar todas ellas, considere lo fácil que podría ser administrar el modelo de seguridad a largo plazo. Si el administrador necesita recordar que debe asignar cuatro roles diferentes a un nuevo usuario y luego agregarlos a varios equipos para que funcione el modelo de seguridad, es poco probable que el cliente sea capaz de mantener la estrategia a largo plazo. El arquitecto de la solución debe considerar el impacto del diseño de seguridad en la experiencia del usuario. Además, deben determinar cómo de compleja será la gestión de la estrategia de seguridad para los administradores de sistemas. Las mejores estrategias de seguridad son sencillas, están bien documentadas y son reproducibles. Por esta razón, el uso de características como los grupos de seguridad de Active Directory es una gran idea para las implementaciones más grandes y complejas, ya que la asignación de roles, equipos y unidades de negocios se puede automatizar, minimizándose así la posibilidad de errores humanos.
Asegúrese de que el diseño de la seguridad se base en requisitos empresariales legítimos
Asegúrese de determinar si sus decisiones sobre diseño de seguridad provienen de una posición de miedo o de una preocupación empresarial legítima. Si es por miedo, quizás la decisión provenga de un error que alguien ha cometido en el pasado. El miedo nunca es una buena motivación para el diseño, en especial el miedo a sus empleados. Confía en sus empleados para hacer su trabajo, representar a su empresa y vender sus productos. En ocasiones, un diseño de seguridad demasiado estricto indica problemas fundamentales de confianza entre la dirección y los empleados.
Documente y reevalúe periódicamente su diseño de seguridad
El diseño de seguridad es un concepto que se considera al comienzo de una implementación de Dynamics 365 pero, en ocasiones, se pasa por alto a partir de entonces. Periódicamente, a medida que cambian los patrones de uso del cliente o su base de usuarios, las decisiones iniciales del diseño de seguridad no resultan ser las más adecuadas y deben ajustarse.
Por ejemplo, cuando se tiene una base de usuarios más pequeña, el diseño de una sola unidad de negocio puede funcionar bien. Sin embargo, si su base de usuarios crece y abarca varios departamentos con diversos requisitos, podría necesitar agregar más unidades de negocio para escalar su implementación a una base de usuarios mayor. No existe una regla absoluta, pero la práctica recomendada es revisar periódicamente la estrategia y el diseño de seguridad, evaluar sus fortalezas y debilidades y, finalmente, identificar áreas de mejora. Por esta razón, es importante documentar el modelo de seguridad como parte del marco de Success by Design, ya que crea documentación que el cliente y el consultor pueden revisar intermitentemente y actualizar a medida que cambien los requisitos de seguridad.
La estrategia de seguridad conforma las opciones de configuración
A medida que el cliente o partner diseña la estructura de su tabla, necesita tener en cuenta su estrategia de seguridad. La configuración de la tabla soporta su estrategia de seguridad. Por ejemplo, si las tablas se crean con propiedad en el nivel de organización, el cliente no podrá restringir el acceso a los registros de la tabla por propiedad o unidad de negocio. Incluso si no tiene planes para restringir el acceso a la tabla, es una buena práctica seleccionar siempre la propiedad del usuario o del equipo, a menos que la tabla se use únicamente para datos de referencia entre empresas, como para abastecer una lista de búsqueda. Además, tenga en cuenta cómo debería afectar la seguridad de una tabla a la seguridad de las tablas relacionadas. Si el acceso a un registro primario debe transmitirse en cascada a los registros secundarios, querrá utilizar tipos de relación en cascada configurables o parentales.
La seguridad, en la capa de plataforma y no en la de aplicaciones
Se dispone de numerosas formas de controlar la lectura y la edición de datos. Puede configurar campos como de solo lectura en su formulario basado en modelo, usar JavaScript para enmascarar campos en la experiencia de usuario y ocultar campos de formularios y vistas. Ninguno de estos enfoques se considera como de seguridad porque, si bien guían el comportamiento de los usuarios, no protegen los datos. Los usuarios pueden acceder a los datos de otras formas. Para implantar una seguridad real, necesita utilizar funciones de seguridad como roles, equipos y unidades de negocio.
Componentes del modelo de seguridad
Dynamics 365 ofrece diversas herramientas que se pueden usar colectivamente para cumplir prácticamente con todos los requisitos de seguridad. Esta sección trata brevemente las principales herramientas disponibles para que un arquitecto de soluciones ofrezca un modelo de seguridad integral.
Unidades de negocio
Las unidades de negocio proporcionan un marco para definir la estructura organizativa de los usuarios y registros en Dynamics 365. Las unidades de negocio permiten agrupar a los usuarios y equipos por jerarquía organizativa y pueden funcionar con los roles de seguridad para conceder o restringir el acceso a los datos.
La capacidad de las unidades de negocio proviene de su naturaleza jerárquica. Los usuarios pueden tener acceso a los registros exclusivamente en su unidad de negocio, o en su unidad de negocio y las unidades de negocio situadas por debajo su unidad. Por ejemplo, la naturaleza jerárquica de las unidades de negocio puede permitirle limitar el acceso a los registros en el nivel de sitio, distrito, región y empresa.
Factores que deben conocerse sobre las unidades de negocio:
La unidad de negocio raíz se crea cuando se aprovisiona la base de datos de Microsoft Dataverse.
Un usuario o un equipo solo puede ser miembro de una unidad de negocio.
Los registros se vinculan a una única unidad de negocio a través del usuario o equipo propietario.
Un usuario o equipo pueden trasladarse a una unidad de negocio diferente. Al mover un usuario o un equipo entre unidades de negocio, todos los registros propiedad del usuario o del equipo podrían necesitar asociarse con la nueva unidad de negocio, y las personas con seguridad de lectura en el nivel de unidad de negocio de la unidad de negocio anterior perderán el acceso a esos registros.
Al mover un usuario o equipo a una nueva unidad de negocio, todos los roles de seguridad deberán volver a aplicarse al usuario o equipo.
Las unidades de negocio que no son raíz se pueden eliminar después de deshabilitarlas.
Las unidades de negocio se pueden mover en la jerarquía, pero no se puede asignar un elemento primario a la unidad de negocio raíz.
La estructura de la unidad de negocio generalmente se parece en algo al organigrama de una empresa, pero no debería ser tan detallado como este, a menos que tenga una razón comercial específica para hacerlo. Debería ver las unidades de negocio como bloques de construcción de su modelo de seguridad. En la mayoría de los casos, no es necesario crear una unidad de negocio para cada departamento de la empresa. Por ejemplo, en un sitio, el departamento de ventas y el de marketing pueden compartir la misma unidad de negocio si los registros no necesitan restringirse entre grupos. Tenga en cuenta que los roles de seguridad funcionan con las unidades de negocio, por lo que, aunque las ventas y el marketing estén en la misma unidad de negocio, no necesariamente todos los usuarios podrán ver todos los registros si sus roles de seguridad les limitan en el nivel de usuario.
Roles de seguridad
Los roles de seguridad determinan el nivel de permiso que tienen los usuarios dentro de las entidades de la organización. Los roles de seguridad se pueden asignar a usuarios o a equipos. Los roles de seguridad determinan a qué entidades puede acceder el usuario, los registros de la tabla sobre los que pueden actuar y qué permisos tienen con esos registros.
Cuando se asigna a un usuario o equipo, el rol de seguridad siempre se aplica dentro del ámbito de la unidad de negocio del usuario o equipo. Por consiguiente, si un usuario hereda un rol de seguridad de un equipo, los privilegios concedidos por ese rol de seguridad se aplicarán en el ámbito de la unidad de negocios del equipo y no en el del usuario. Este enfoque puede resultar útil para ampliar el ámbito de los derechos de acceso de un usuario a otras unidades de negocio. Por ejemplo, utilizando el diagrama de unidad de negocio precedente, se puede agregar un usuario de la unidad de negocio Oficina de Chicago a un equipo que está vinculado a la unidad de negocio Oficina de Atlanta y se les pueden conceder derechos de lectura sobre los registros de la unidad de negocio.
Equipos
Los equipos son otra forma de agrupar a los usuarios y pueden desempeñar un papel en su estrategia de seguridad. Existen varios tipos de equipos disponibles en Dynamics 365:
A los equipos propietarios se les pueden asignar roles de seguridad y se pueden usar como propietarios de registros en Dynamics 365. Cuando un usuario se agrega como miembro de un equipo propietario, hereda del rol de seguridad del equipo, pero el rol se aplica en el contexto de la unidad de negocio del equipo. Los equipos propietarios pueden resultar útiles al vincular un registro a una unidad de negocio específica.
Los equipos del grupo de seguridad de Microsoft Entra ID son similares a los equipos propietarios, pero están vinculados con un grupo de seguridad de Microsoft Entra ID. Los usuarios agregados al grupo de seguridad de Microsoft Entra ID con una licencia de Dynamics 365 se habilitan automáticamente en el sistema y se agregan al equipo vinculado de Dynamics 365 cuando se conectan al entorno. Esta característica es útil al administrar los derechos de acceso de los usuarios fuera de Dynamics 365, porque los usuarios pueden heredar los roles de seguridad asignados a los equipos de Dynamics 365.
Los equipos de grupo de oficina de Microsoft Entra ID son similares a los del grupo de seguridad de Microsoft Entra ID, con la diferencia de que usan un grupo de Office 365 en lugar de un grupo de seguridad de Microsoft Entra ID. La principal diferencia es que se pueden crear grupos de Office 365 y que la administración de grupos la pueden realizar personas que no sean administradores de Active Directory.
Los equipos de acceso son un tipo especial de equipo que no puede poseer registros y no puede tener una asociación de roles de seguridad. Sin embargo, al igual que los equipos propietarios, los equipos de acceso pueden compartir registros con ellos. Cuando se habilitan en el nivel de tabla, los equipos de acceso pueden conceder permisos de nivel de registro específicos al miembro del equipo de acceso del registro. Esta opción es una alternativa para compartir manualmente el registro con un usuario o un equipo. Para las entidades configuradas para equipos de acceso, la creación de estos equipos está automatizada mediante plantillas de equipos de acceso.
Al asignar un rol de seguridad a un equipo propietario (incluidos los equipos de grupo de seguridad de Azure AD o de grupo de oficina de Microsoft Entra ID), debe comprobarse la configuración de herencia de privilegios del miembro, para asegurarse de que esté configurada correctamente. Esta configuración puede permitir que los usuarios que son miembros del equipo hereden privilegios en el nivel de usuario, como si el rol de seguridad se les hubiera asignado directamente. Esta característica es útil al permitir que los usuarios posean registros a su nombre, aunque no tengan un rol de seguridad asignado directamente. Por ejemplo, con esta opción, los usuarios pueden poseer vistas personales. Con los equipos propietarios, no es necesario conceder roles de seguridad directamente a usuarios individuales, lo que ayuda a reducir el esfuerzo de administración.
Seguridad de jerarquía
La seguridad de jerarquía se puede utilizar para conceder visibilidad de los registros de propiedad de usuarios a la administración de esos usuarios y a los niveles superiores de la jerarquía. Por ejemplo, si un jefe de ventas con un equipo de cinco personas necesita ver los registros propiedad de alguien de su equipo, la seguridad de jerarquía puede proporcionarle ese acceso. La seguridad de jerarquía admite dos modelos de jerarquía diferentes:
Jerarquía del administrador: concede acceso según la relación del administrador. Con el modelo de seguridad de jerarquía del administrador, un administrador tiene acceso a los registros propiedad del usuario o del equipo del que es miembro un usuario, y a los registros que se comparten directamente con el usuario o el equipo del que es miembro.
Jerarquía de posición: concede acceso en función de niveles de posición definibles. Este modelo es útil cuando es necesario proporcionar acceso de seguridad en función de estructuras de subordinados indirectos. Con el modelo de seguridad de jerarquía de posición, un usuario con una posición superior tiene acceso a los registros que posee un usuario de posición inferior o el equipo del que es miembro un usuario, y a los registros que se comparten directamente con el usuario o el equipo del que es miembro un usuario.
Seguridad de campo
La seguridad de campo le permite proteger los datos en el nivel de campo, como en el caso de que ciertos usuarios necesiten ver o editar un registro pero no deberían ver detalles específicos. Esta característica es importante en situaciones en las que los datos deben estar realmente seguros, porque están protegidos en la capa de plataforma. En esencial, si un usuario inicia sesión en una aplicación basada en modelo o en una aplicación de lienzo, exporta datos a Microsoft Excel o genera un informe, los perfiles de seguridad de campo protegerán los datos.
Una vez que a un usuario se le concede acceso (por ejemplo, de lectura) a un conjunto de campos protegidos a través de un perfil de seguridad de campo, se le concede acceso a esos campos en todos los registros a los que tiene acceso con su configuración de seguridad o mediante el uso compartido.
Uso compartido
El uso compartido permite conceder acceso de nivel de registro específico a usuarios y equipos específicos. El uso compartido debe limitarse al manejo de excepciones, cuando sea posible. Anteriormente, era habitual usar y automatizar el uso compartido de registros para escenarios complejos de acceso a registros. El uso compartido puede ser una característica beneficiosa, ya que ofrece a los administradores y usuarios con los permisos adecuados la capacidad de conceder permisos específicos a registros específicos, y es útil para manejar las excepciones a la regla. Por ejemplo, si necesita que el comercial A controle las cuentas del comercial B mientras está fuera durante un mes, el uso compartido puede ayudar en esta tarea. El uso compartido también se puede automatizar, lo que significa que, si necesita una condición específica para compartir registros automáticamente con un usuario o equipo, se pueden usar complementos simples, ensamblajes de flujo de trabajo o herramientas ETL para hacerlo. Esta característica ha sido la respuesta a los requisitos de seguridad que presentaban muchos clientes de Dynamics 365 en el pasado.
Si bien el uso compartido es una característica útil, también crea múltiples problemas potenciales, entre los que se encuentran los siguientes:
Rendimiento: la tabla de acceso a objetos principales (POA) facilita el uso compartido. Cuando comparte un registro con un usuario o equipo, se crea un registro en la tabla de POA, que contiene el id. de usuario, el id. de registro y el permiso que debería tener. La naturaleza en cascada del uso compartido implica que, si existe una relación parental o configurable en cascada que está habilitada para el uso compartido, los registros secundarios de esas relaciones también se compartirán con el usuario o el equipo (y se agregarán más registros a la tabla de POA). Los escenarios complejos de reparentación o uso compartido heredados también pueden crear registros, lo que puede hacer que la tabla de POA crezca rápidamente. Este escenario se convierte en un problema de rendimiento cuando la tabla se amplía (entre 20 millones y dos mil millones de registros). Cuando se consulta Dynamics 365, como al abrir una vista, realizar una búsqueda avanzada o ver un gráfico, la tabla de POA filtra los resultados. Si la tabla es grande o los índices no están optimizados, esto puede provocar un rendimiento lento del sistema.
Problemas de administración: no puede identificar fácilmente qué registros se comparten con un usuario. Si bien puede seleccionar un registro y mostrar con quién se comparte directamente, no existe ningún método que pueda ayudarle a realizar esa tarea para todos los registros. Además, los recursos compartidos en cascada o heredados no se muestran en el cuadro de diálogo de uso compartido en el registro. Sin abrir cada registro en el contexto de ese usuario, es casi imposible saber si su estrategia de uso compartido está funcionando correctamente.
Elementos compartidos olvidados: anteriormente, se explicó un escenario en el que compartía los registros del comercial B con el comercial A, quien manejaba las cuentas de sus compañeros de trabajo mientras estaban fuera durante un mes. Lo más probable es que el administrador se olvide de dejar de compartir esos registros, lo que podría crear problemas si el comercial B necesita volver a conectarse con las personas de su flujo de trabajo.
No funciona bien: después de que el cliente usa el sistema durante uno o dos años, podría descubrir que se ha vuelto impreciso o anticuado. También podría decidir hacer un cambio completo en su estrategia de uso compartido; según esto, desea ejecutar un trabajo por lotes para configurar y actualizar todos los registros con el permiso de uso compartido adecuado. No existe un método simple para completar esta tarea con el uso compartido.
Alternativas al uso compartido
Entre los pasos que pueden darse para evitar problemas con el uso compartido se encuentran los siguientes:
Utilizar la propiedad de equipo: con la propiedad del equipo, puede asignar registros a equipos de usuarios en varias unidades de negocio.
Compartir con equipos, no con usuarios: si comparte un registro con 10 usuarios, se crearán 10 registros de POA, multiplicados por 10 registros de POA por cada registro secundario compartido en cascada. Si comparte el registro con un equipo de 10 usuarios, solo se crea un registro de POA (junto con un registro de POA para cada recurso compartido en cascada). Este enfoque ayudará a reducir drásticamente el tamaño de la tabla de POA. Si desea quitarle los permisos a un usuario, puede quitarlo del equipo.
Utilizar equipos de acceso para uso compartido controlado: utilice este enfoque si no puede crear equipos propietarios, pero sigue deseando poder conceder acceso especial a registros específicos para usuarios específicos. En este escenario, desea conceder acceso a ciertos usuarios para que solo lean el registro, mientras que desea que otros usuarios puedan leer o escribir en el registro. Los equipos de acceso pueden manejar esta situación, y pueden tenerse varias plantillas de equipos de acceso, una para lectura y otra para lectura/escritura. Los equipos de acceso están diseñados teniendo en cuenta el rendimiento, por lo que en realidad no crean el equipo y comparten el registro hasta que no se agrega el primer miembro del equipo. Cuando se comparte un registro con un equipo de acceso, también se crea un registro en la tabla de POA.
Ejemplo de escenario de seguridad
El siguiente escenario explica cómo se pueden combinar estas herramientas para proporcionar un modelo de seguridad integral. En este ejemplo Contoso LTD es una empresa de productos de consumo que quiere asegurarse de que los usuarios tengan acceso a la información que necesitan para hacer su trabajo, mientras se protegen los datos confidenciales. Al combinar las herramientas de seguridad de Dynamics 365, la empresa puede enfrentarse a todos los escenarios siguientes.
Bob
La seguridad en el nivel de campo evita que Bob vea información confidencial de un registro, y la seguridad del equipo o de la unidad de negocio limita su visibilidad a solo los asuntos de la empresa.
Ingeniero de fabricación
Necesita poder ver los problemas de calidad que notifican los clientes
No debería poder ver el correo electrónico ni el teléfono móvil del cliente
No debería poder ver los asuntos de otras empresas
Amy
La seguridad de la unidad de negocio implica que Amy puede ver los registros que posee otra persona de la división, pero no puede ver ni editar registros de otras divisiones.
Representante de servicio al cliente
Crea casos de servicio al cliente a partir de reclamaciones de uso
Debería poder ver la información del cliente y el historial de casos de los clientes que utilizan los productos de su división
No debería poder ver los datos de clientes de otras divisiones
Roy
La seguridad jerárquica permite a Roy ver los registros que son propiedad de sus subordinados directos o indirectos, pero no los de otros usuarios.
Director de ventas
Necesita ver los registros de sus subordinados directos
No debería poder ver datos de otros directores de ventas
Linda
El rol de seguridad de Linda ofrece visibilidad en toda la organización para los datos en Dynamics 365.
Director general
Necesita visibilidad para todos los datos de los clientes y los asuntos relacionados
Taller de modelo de seguridad
El taller de modelo de seguridad debe limitarse a aproximadamente una hora y, a menudo, se lleva a cabo como parte de una reunión de Microsoft Teams cuando no todos se encuentran en el mismo lugar. Entre los asistentes deben encontrarse las partes interesadas clave de los equipos del cliente y del partner. Deben participar los arquitectos de soluciones y los responsables técnicos y funcionales.
Se debe hacer referencia a los detalles de seguridad de la plantilla del taller de planos técnicos de soluciones para preparar el taller de modelo de seguridad.