Temas del taller de seguridad
Esta unidad se centra en los temas recomendados que deberían tratarse en el taller de modelo de seguridad.
Información general del modelo de seguridad
En la sección Descripción general del modelo de seguridad de la plantilla, debe proporcionar una descripción general de alto nivel del modelo de seguridad de los asistentes. Los detalles no necesitan ser extremadamente precisos, porque se tratará cada área específica en detalle más adelante en la plantilla.
A continuación, responda a la pregunta de cómo administra el acceso a los registros. Esta información es útil para saber si existen restricciones específicas en los datos (por ejemplo, a los comerciales solo se les permite ver los datos de sus propios clientes) o si cualquier otra información especial de acceso a datos afectará al modelo de seguridad. Además, esta sección puede incluir detalles técnicos, como el requisito de disponer de autenticación multifactor para poder acceder a los datos del sistema.
Aspectos básicos
Dos diapositivas de la plantilla cubren información básica sobre el modelo de seguridad. En estas diapositivas se incluyen las siguientes preguntas.
¿Cuántos usuarios tiene (destino)? - El número de usuarios tiene un impacto significativo en la escalabilidad del modelo de seguridad. Por ejemplo, si el cliente confía en compartir registros para proporcionar acceso, debe ser consciente del impacto potencial en el rendimiento cuando se comparten muchos registros entre muchos usuarios. Algunos modelos de seguridad que son aceptables para un número reducido de usuarios, se vuelven inadecuados a medida que aumenta el número de usuarios. Por esa razón, es importante tener en cuenta el número actual de usuarios y el crecimiento previsto en el futuro.
¿Cuántos patrones o configuraciones de seguridad distintos tiene en su modelo y cuántos usuarios se encuentran en cada configuración de patrón? - El patrón de seguridad se refiere a las diferentes configuraciones de seguridad que el cliente desea implementar para responder a los requisitos. Por ejemplo, las personas del departamento de ventas se acogerán al uso estándar de los roles de seguridad de usuario, las de servicio al cliente usarán una combinación de roles de usuario y jerarquía de administradores, y las de marketing usarán solo equipos de acceso. Al determinar el número previsto de patrones, podrá identificar si el modelo de seguridad será demasiado complicado o difícil de mantener a largo plazo.
¿Qué porcentaje de usuarios potencialmente tienen requisitos de seguridad más complejos que el resto? - Los clientes a veces complican demasiado sus modelos de seguridad al diseñar pensando en las excepciones específicas del proceso estándar. Cuando identifique la existencia de muchos requisitos no estándar diferentes, debe cuestionarse cada requisito y recomendar estandarizar el proceso principal.
¿Necesita restringir o filtrar el acceso a los datos? - Esta pregunta distingue entre los filtros de conveniencia y los requisitos de seguridad reales. Querer ofrecer a los usuarios una vista simplificada de los datos que más les importan es un buen objetivo; sin embargo, la seguridad no debe utilizarse para lograrlo. Utilice vistas para filtrar datos, mientras deja disponible el acceso a otros registros.
¿Qué número de roles de seguridad necesita? - Mantener el número de roles de seguridad al mínimo facilita la gestión de las tareas administrativas. Dynamics 365 incluye muchos roles de seguridad estándar para tipos de usuarios estándar, como director de ventas, representante de servicio al cliente y administrador del sistema. Estos roles deben usarse como base para los roles de seguridad del cliente.
Si los requisitos difieren de los roles estándar, considere la posibilidad de crear copias de roles estándar e iterarlos.
¿Ha creado nuevos roles de seguridad en lugar de personalizar los existentes? - Una práctica recomendada es guardar una copia de uno de los roles de seguridad estándar en lugar de crear uno nuevo.
Los roles de seguridad incluyen muchos permisos que se necesitan para entrar a la aplicación, y crear un nuevo rol resulta problemático, debido a que el cliente probablemente no dispondrá de todos los permisos básicos necesarios.
Recuerde al cliente que se agregan nuevos permisos frecuentemente a los roles de seguridad estándar mediante actualizaciones regulares de la aplicación, y que estos nuevos permisos no se agregan automáticamente a los roles de seguridad personalizados existentes. Si se utilizan roles de seguridad personalizados, alguien deberá acordarse de identificar los permisos recién agregados y actualizar los roles de seguridad personalizados después de cada actualización, para garantizar la continuidad del acceso al sistema después de las actualizaciones.
¿Ha intentado reducir el número de roles de seguridad tanto como sea posible? - Cuantos más roles de seguridad utilice una implementación de Dynamics 365, más difícil será administrarla a largo plazo. Cuando se agrega una nueva funcionalidad, si hay 25 roles de seguridad diferentes y todos la necesitan, el fabricante deberá actualizar 25 roles de seguridad para ofrecer acceso a la nueva característica.
Una estrategia popular es usar un rol base, que proporciona la referencia de la funcionalidad necesaria para iniciar sesión en la aplicación y todas las tablas que están disponibles para todos los usuarios. A continuación, complemente ese rol con roles adicionales que tengan las características específicas de rol que necesita ese rol.
Por ejemplo, si todos los usuarios necesitan leer cuentas, pero solo los directores de ventas deberían poder crear nuevas cuentas, su rol base contendría el permiso de lectura de cuentas en el nivel de organización y el rol del director de ventas únicamente incluiría el permiso de creación de cuentas. Luego, si agrega una nueva característica que todos los usuarios necesitan, se puede agregar solo al rol base.
¿Cuál es el número de roles de seguridad que necesita una persona individual? - Cuantos más roles de seguridad deban agregarse a un usuario individual, más complicada se volverá la incorporación del usuario y será más probable que alguien cometa errores. Si existen muchos roles necesarios, estos roles deben consolidarse para facilitar la administración en curso y futura.
Otro enfoque que puede ser útil aquí es usar los equipos del grupo de seguridad de Microsoft Entra ID o los equipos de grupo de oficina de Microsoft Entra ID para conceder los roles una sola vez al equipo y que luego los usuarios hereden automáticamente los roles del equipo (es decir, en el contexto de la unidad de negocio del equipo), después de agregarlos al grupo de Microsoft Entra ID correspondiente.
¿Los roles de seguridad se crean en el nivel de la unidad de negocio raíz o en el nivel secundario? - Si bien puede crear roles que sean específicos para una unidad de negocio secundaria, se recomienda crear y editar los roles de seguridad en el nivel de la unidad de negocio raíz.
La creación de roles en el nivel de unidad de negocio raíz hace que el rol esté disponible para todas las unidades de negocio, mientras que los roles de unidad de negocio de nivel secundario solo están disponibles en un nivel de unidad de negocio única. Si tiene un rol específico de la unidad de negocio, cuando mueva un usuario a otra unidad de negocio, ese rol no estará disponible. De lo contrario, tendrá diferentes versiones del mismo rol en una unidad de negocio diferente, lo que dificultará la administración del sistema.
¿Cuál es su estrategia para actualizar los roles de seguridad a medida que implementa nuevas tablas y funcionalidades? - En un entorno que cambia rápidamente con un desarrollo continuo, puede ser fácil olvidarse de actualizar los roles, o solo probar con el acceso del administrador del sistema y no actualizar los roles de seguridad para incluir la nueva funcionalidad. La estrategia del cliente debe incluir un proceso para actualizar los roles de seguridad y realizar pruebas con la combinación de roles de cada persona, siempre que se implemente una nueva versión de la configuración.
Razones de esta información
Las razones por las que debería solicitar la información anterior a sus asistentes son las siguientes:
Es raro que un patrón de seguridad se adapte a todas las necesidades y roles de los usuarios. Se necesita conocer cuántos patrones diferentes necesitará implementar en el proyecto.
Los modelos de seguridad complejos se diseñan frecuentemente para adaptarse a las necesidades de una fracción de los usuarios que no se incluyen en el modelo principal. En ese caso, podría existir una oportunidad de cuestionar si esos usuarios no podrían acceder a los datos deseados de una manera diferente o en otro lugar, como mediante informes.
Unidades de negocio
En esta sección, proporcionará una descripción de la estructura jerárquica de la organización interna del cliente y la estructura de la unidad de negocio en Dynamics 365. Debería existir alguna relación entre la estructura de la unidad de negocio y la estructura de la organización, pero la estructura de la unidad de negocio no debería ser tan detallada como la de la organización. Aunque dos grupos estén en diferentes divisiones de la empresa, eso no significa que necesariamente tenga que restringirse la visibilidad de los registros entre los dos grupos. Con frecuencia, varios departamentos pueden compartir la misma unidad de negocio.
Utilice una herramienta como Microsoft Visio o alguna otra aplicación de diagramas/gráficos visuales para crear una representación visual de la estructura. Si ya tiene un documento que visualiza la jerarquía organizativa de la empresa, puede pegar una captura de pantalla de ese diagrama en el documento.
Tenga en cuenta dos problemas potenciales: demasiadas unidades de negocio o no suficientes unidades de negocio.
Demasiadas unidades de negocio
Si el modelo de seguridad propuesto identifica que habrá disponibles cientos o miles de unidades de negocio, este problema debe marcarse como un riesgo. Las unidades de negocio son como las grandes rocas de granito; están diseñadas para ser permanentes y moverse raramente. Si bien los usuarios pueden moverse entre unidades de negocio, no es un asunto trivial, especialmente si poseen muchos registros.
Cuando se mueve un usuario de la unidad de negocio uno a la unidad de negocio dos, cambiará la asociación de unidades de negocio de cada registro que posee el usuario. Este factor puede causar algunas sorpresas a otros usuarios que sean miembros de la unidad de negocio original del usuario, si tienen permiso de lectura en el nivel de unidad de negocio. Los registros que pertenecen a los usuarios movidos ya no estarán disponibles para ellos, pero, si poseen registros secundarios de esos registros, como actividades, se podrían generar escenarios extraños. Además, si el usuario posee muchos registros, mover usuarios entre unidades de negocio puede llevar mucho tiempo.
Otro impacto potencial de las grandes cantidades de unidades de negocio son las actualizaciones de roles de seguridad extremadamente lentas. Cada rol no es únicamente un registro. Se agrega una copia de cada rol a cada unidad de negocio. Por lo tanto, si crea miles de unidades de negocio, realizar un pequeño cambio en un rol de seguridad podría llevar horas.
Una buena práctica es mantener sus unidades de negocio al mínimo. Utilice solo el número mínimo para facilitar los requisitos de seguridad reales de la unidad de negocio. Para una segmentación de usuarios más detallada, considere el uso de equipos. Los equipos son más flexibles, se pueden usar para controlar el acceso de seguridad a los registros y los usuarios pueden ser miembros de varios equipos.
No hay suficientes unidades de negocio
Si está implementando para un solo grupo, lo habitual es que solo desee usar la unidad de negocio raíz para todos los usuarios.
Si bien el enfoque de "mantenerlo sencillo" es excelente, existe una gran posibilidad de que el cliente pueda, en algún momento, tener algunos datos que desee mantener en secreto de un subconjunto de usuarios.
Supongamos los siguientes escenarios:
Se amplía el uso de Dynamics 365 a otras partes de la empresa.
Una gran empresa multinacional adquiere su empresa.
El CEO decide hacer un seguimiento de los correos electrónicos y no quiere que todos los lean.
El vicepresidente de ventas descubre una serie de contactos en su libreta de direcciones que deben estar en Dynamics 365, pero que sería mejor mantenerlos privados frente al resto de la empresa.
Mover personas entre unidades de negocio es difícil y constituye un proceso que querrá hacer únicamente cuando sea necesario. Si el cliente comienza con todos los usuarios en la unidad de negocio base y se desarrolla un cambio que requiere que un subconjunto de datos esté separado, se verá obligado a reubicar a muchos de los usuarios existentes, o todos ellos, ya que la unidad de negocio raíz no se puede reubicar con otro elemento primario.
Para protegerse contra esta eventualidad, podría ser una buena idea crear inicialmente una unidad de negocio secundaria y después colocar a todos los usuarios en esa unidad de negocio. Si su negocio cambia y requiere una mayor segmentación de datos, este enfoque ayudará a simplificar los cambios, ya que se puede cambiar el elemento primario de la unidad de negocios, con la mayor parte de los usuarios, o se pueden trasladar usuarios seleccionados, como el director ejecutivo, a la unidad de negocio base. Se puede evitar un traslado a gran escala de todos los usuarios en el nivel de unidad de negocio.
Equipos
La sección de equipos de la plantilla de modelo de seguridad captura detalles sobre el uso planificado de los registros de equipo para la seguridad en Dynamics 365.
En esta sección, deberá responder a las siguientes preguntas:
¿Utiliza equipos propietarios para asignar roles a los usuarios? - Los equipos propietarios (incluidos los equipos grupo de seguridad de Microsoft Entra ID y grupo de oficina de Microsoft Entra ID) son una excelente manera de asignar roles de seguridad a los usuarios y reducir el esfuerzo de administración. Cuando se asigna un rol de seguridad a un equipo, lo heredan los usuarios miembros, pero se aplica al ámbito de la unidad de negocio del equipo.
¿Utiliza equipos propietarios para poseer registros? - Se puede considerar que la propiedad de los registros por parte del equipo administra la asociación de un registro con una unidad de negocio, con independencia de la unidad de negocio del usuario propietario estándar. Este enfoque puede resultar útil cuando la asociación funcional de un registro y una unidad de negocio difiere de la asociación del usuario con una unidad de negocio.
Algunas desventajas y riesgos están asociados con la propiedad del equipo de los registros, y debiera conocerlos. En general, requiere automatización para ser coherente y fácil de usar. Algunas características, como los objetivos y la previsión, dependen de la propiedad de los registros por parte del usuario. Además, la capacidad de reasignar los registros de un usuario de forma masiva (por ejemplo, cuando un nuevo comercial reemplaza a otro que se jubila y hereda su cartera de clientes) no está disponible para los equipos propietarios.
La propiedad de equipo de los registros se puede utilizar para simplificar modelos de seguridad complejos y reducir la necesidad de compartir registros en exceso. Los roles del equipo propietario conceden permisos de seguridad especiales en el contexto de los registros que posee el equipo. Por consiguiente, si los miembros de un equipo de ventas deberían tener derecho de edición de las oportunidades para las que están asociados, pero de solo lectura para las oportunidades con las que no están asociados, los equipos de seguridad de propietario pueden habilitar esta excepción sin tener que recurrir a usar uso compartido complejo.
¿Automatiza la asignación de registros? ¿Cómo lo hace? - Cuando se crea una nueva cuenta, debe determinar cómo asignará el registro. Además, debería plantearse si el coordinador de ventas recordará asignar manualmente el registro con precisión. Cuando se trata de tipos de registros importantes, como cuentas, se recomienda disponer de un proceso automatizado que asigne registros automáticamente cuando se crean, para simplificar la administración continua del sistema. Un enfoque podría ser almacenar la asignación de personal de ventas por estado en el registro de territorio de Dynamics 365. Luego, al crear una nueva cuenta, se ejecuta un flujo de Microsoft Power Automate. Compara el estado de la dirección uno con el campo de estado de territorio y asigna la cuenta al territorio y al comercial apropiados. Luego, envía un correo electrónico de notificación al comercial para decirle que se comunique con su nuevo cliente potencial.
¿Utiliza equipos de acceso (administrados por el sistema o manualmente)? - Los equipos de acceso son magníficas soluciones para administrar permisos de registro especiales. Por ejemplo, si un asistente de ventas necesita tener permisos de edición en 25 cuentas diferentes, en lugar de compartir las cuentas manualmente con ellos, puede agregarlos a una subcuadrícula del equipo de acceso en el registro y entonces ellos heredarán los permisos de edición según la plantilla de equipo de acceso que esté asociada con la cuadrícula. Los equipos de acceso son excelentes soluciones porque solo se crea un registro de uso compartido para todo el equipo de acceso en la tabla de POA, en lugar de registros individuales para cada persona, como lo hace el uso compartido de registros (consulte la sección Uso compartido anterior de este módulo). Este enfoque o también permite a los administradores ver quién tiene acceso al registro.
Si el mismo grupo de personas necesita acceder a varios registros, los equipos de acceso también se pueden utilizar para compartir los registros con ese equipo. Sin embargo, tenga en cuenta que un equipo de acceso no puede poseer registros y no se les pueden asignar roles de seguridad.
¿Automatiza la pertenencia a los equipos de acceso? - Es común tener una matriz de personas que necesitan acceso a los registros. Por ejemplo, un proyecto de fabricación necesita un ingeniero, un electricista y un técnico de seguridad. Con frecuencia, estas asignaciones se mantienen en otro sistema.
En este caso, se debe utilizar el equipo de acceso, porque la combinación de personas individuales es diferente para cada registro y se necesita acceso de seguridad para los miembros del equipo. Puede automatizar la pertenencia al equipo de acceso utilizando enfoques como la integración, las acciones o los complementos.
¿Cómo se implementan las plantillas del equipo de acceso en todos los entornos? - Los permisos de registro del equipo de acceso se establecen mediante una plantilla de equipo de acceso. La plantilla determina qué permisos se comparten con los miembros del equipo.
Un problema es que los registros de la plantilla del equipo de acceso no son conscientes de la solución, lo que significa que no se pueden agregar a las soluciones. Cuando las personalizaciones se mueven entre entornos, la plantilla del equipo de acceso deberá moverse o volver a crearse manualmente en el entorno de destino. Si está automatizando una pertenencia al equipo de acceso, las plantillas deben tener GUID idénticos en todos los entornos, ya que se hace referencia a ellos en la lógica.
Tiene a su disposición varios enfoques que puede usar para migrar las plantillas de equipo de acceso, como la utilidad de migración de datos de configuración, herramientas ETL, como Scribe o SSIS, o las utilidades de XrmToolBox.
¿Usa los grupos sincronizados de Microsoft Entra ID para administrar los derechos de acceso? - Los equipos del grupo de seguridad de Microsoft Entra ID o del grupo de oficina de Microsoft Entra ID son magníficos para automatizar la asignación de permisos de roles a los usuarios, y deben tenerse en cuenta para implementaciones mayores o más complejas.
Con Microsoft Entra ID, puede controlar completamente los permisos desde un único origen.
¿Tiene algún requisito que no encaje en el modelo estándar? - Identifique los requisitos de seguridad no estándar. En la sección de conclusiones y recomendaciones, recomiende enfoques para estandarizar los requisitos no estándar.
Mecanismos de seguridad implementados
En esta sección, deberá identificar qué métodos se utilizan para automatizar la seguridad, incluido el uso compartido automatizado, la seguridad en el nivel de campo, la seguridad jerárquica, los complementos y los comportamientos de relación. Consulte la sección de herramientas de seguridad de este módulo si no está familiarizado con alguno de estos enfoques.
Razones para facilitar esta información:
Si se automatiza el uso compartido a escala, pueden aparecer problemas de rendimiento. La tabla PrincipalObjectAccess o tabla de POA se llena con excepciones al modelo de seguridad estándar.
En general, el uso compartido debería seguir siendo un proceso manual para conceder excepciones al modelo de seguridad implementado y debería evitarse a escala.
Si bien es fácil ajustar una unidad de negocio, los equipos y los roles de un usuario, puede resultar complejo realizar una migración de datos sobre reglas de uso compartido personalizadas después de una reorganización.
La seguridad en el nivel de campo no reconoce el usuario o la unidad de negocio.
La seguridad de jerarquía puede causar problemas de rendimiento en configuraciones complejas si hay demasiados niveles de profundidad de la jerarquía.
El comportamiento en cascada en las relaciones es cómodo, pero a veces puede tener consecuencias no deseadas (como la reasignación de actividades cerradas al reasignar una cuenta). La asignación en cascada o el uso compartido se pueden deshabilitar o modificar según la relación, o utilizando una opción de ORG DB DisableImplicitSharingOfCommunicationActivities.
Interfaz de usuario
Muchos componentes de Dynamics 365 tienen roles de seguridad habilitados, lo que significa que el acceso a ese elemento puede limitarse a uno o más roles de seguridad. Esta característica es importante porque diferentes usuarios requieren diferentes experiencias al usar tablas comunes y, al limitar el acceso a los componentes de la aplicación que no necesitan los usuarios, se ofrecerá una experiencia más simple y personalizada al usuario.
Entre los elementos de Dynamics 365 que se pueden habilitar para roles se encuentran los siguientes:
Aplicaciones basadas en modelo
Paneles
Formularios
Flujos de proceso de negocio
Subáreas de mapas de sitio
Botones de la barra de comandos
Plantillas de documento
En esta sección de la plantilla, deberá identificar si se están utilizando roles para simplificar el acceso a estas áreas.
Razones para facilitar esta información:
Se pueden utilizar roles de seguridad y privilegios de tabla para personalizar y limitar la experiencia de los usuarios finales.
Cuantos menos elementos vean los usuarios, más fácil será la experiencia.
Las aplicaciones basadas en modelos se pueden asociar con roles de seguridad, lo que ayuda a simplificar la experiencia de usuario general, ya que limita la lista de vistas, gráficos, paneles, formularios y flujos de procesos de negocio.
Los clientes sin una estrategia en esta área podrían experimentar problemas inesperados. Por ejemplo, las aplicaciones de Microsoft, como Centro de ventas, Centro de servicio al cliente y Aplicación para Outlook controlarán el acceso mediante roles de seguridad de acceso a la aplicación. Si un cliente realiza la prueba con solo un rol de administrador del sistema, podría no advertir el hecho de que los usuarios sin este rol necesitan el rol de acceso a la aplicación para usar la aplicación (o la aplicación debe compartirse con sus roles de seguridad personalizados). Este escenario puede llevar a que los usuarios no tengan acceso a las aplicaciones que necesitan durante la implementación.
Escalabilidad, rendimiento y mantenimiento
En esta sección de la plantilla, examinará preguntas que identificarán si existe algún problema potencial que pueda ocurrir cuando la aplicación se escale a más usuarios y aumente la cantidad de datos.
Preguntas de mantenimiento y por qué son importantes
Responda las siguientes preguntas de mantenimiento en la plantilla.
¿Ha identificado escenarios en los que no es necesario que el registro sea propiedad de un usuario o equipo? - Al crear nuevas tablas que representen datos referenciales entre empresas y que nunca necesitarán detallar para cada unidad de negocio, equipo o usuario, debería plantearse crearlas como tablas propiedad de la organización.
La propiedad de los registros es importante cuando se debe conceder visibilidad variable o permiso de edición a diferentes usuarios. Sin embargo, si existen registros generales que deben ser visibles para todos los usuarios y todos los usuarios comparten el mismo nivel de permisos de edición (como los registros generados mediante una integración), se debe considerar una estrategia, como la asignación de registros al equipo de la unidad de negocio, de modo que estos registros no tengan que reasignarse cuando alguien deje la empresa.
¿Ha identificado algún problema potencial de escalabilidad en su diseño de seguridad con volúmenes mayores? - Las estrategias como el uso compartido de registros pueden funcionar adecuadamente en implementaciones más pequeñas, pero pueden volverse ineficaces rápidamente, cuando se escalan a un gran número de usuarios.
Además, hacer que los usuarios sean miembros de miles de equipos en miles de unidades de negocio puede ser un verdadero desafío en términos de rendimiento y escalabilidad.
¿Ha considerado el impacto de sus modelos de datos y seguridad en la tabla POA? - Con un uso compartido excesivo se crea una tabla POA grande, que puede degradar el rendimiento del sistema.
¿Actualiza periódicamente los registros de usuarios, equipos o unidades de negocio? - Como regla general, deben evitarse las actualizaciones periódicas de las tablas de usuario, equipo o unidad de negocio. Por ejemplo, la actualización de un atributo en una tabla de usuario puede hacer que la caché de seguridad se vacíe y potencialmente afecte al rendimiento.
¿Ha considerado el impacto de una gran reorganización en los usuarios, equipos, unidades de negocio y registros? - Cambio de las estructuras de negocio. Se adquieren nuevas empresas, se venden divisiones, y los empleados se van o se trasladan a otros departamentos. Su estructura debe ser lo suficientemente flexible para que pueda agregar o eliminar fácilmente usuarios, equipos o unidades de negocio sin que sea necesario rediseñar completamente el modelo de seguridad.
Para los usuarios que ya tienen acceso a un gran porcentaje de registros, ¿ha considerado proporcionarles acceso global para conseguir un mejor rendimiento? - Al proporcionar acceso de lectura a los registros en el nivel de organización o global, se puede optimizar el rendimiento para la implementación de una vista, ya que el sistema no tiene que considerar los principios de seguridad que se aplican a un usuario (roles individuales, roles de equipo, registros compartidos, jerarquía) al recuperar registros.
Si bien un usuario podría tener acceso a todos los registros desde el punto de vista de la seguridad, debería personalizar las vistas del sistema que filtrarán el número de registros para presentar solo lo que es pertinente para su trabajo.
¿Reasigna registros de forma masiva cuando un usuario se va? ¿Ha considerado el impacto de una relación en cascada? - La configuración en cascada de relaciones para actividades y otros registros comunes puede causar resultados inesperados al reasignar registros, y este comportamiento debe modificarse si no desea que se reasignen actividades cerradas al reasignar la cuenta del cliente y los registros de contacto.
Pruebas de seguridad
El modelo de seguridad se compone de varias partes que trabajan juntas y tiene varias áreas en las que podría fallar. En esta sección de la plantilla, revisará el enfoque que se utilizará para probar la seguridad, identificará el plan continuo para supervisar el acceso a Dynamics 365 y se asegurará de que el diseño de los roles de seguridad esté bien documentado y sea sencillo de mantener a largo plazo.
Preguntas de seguridad y por qué son importantes
En la sección de pruebas de seguridad de la plantilla del modelo de seguridad, responda las siguientes preguntas.
¿Tiene entornos de prueba para validar los datos en el contexto de sus requisitos de seguridad? - Para probar adecuadamente los roles de seguridad, su cliente requerirá un entorno que no sea de producción con la misma configuración que la de producción y una buena aproximación al conjunto de datos de producción. Si bien no necesita un porcentaje del 100 por cien de los datos de producción, los datos deben ser lo suficientemente similares como para probar con precisión el comportamiento de los roles de seguridad. También es importante tener distintos usuarios de prueba y no reasignar roles a los mismos usuarios de prueba. La razón es que los usuarios que originalmente tienen un permiso más elevado pueden retener el acceso a determinados registros cuando se elimina ese rol mediante el uso de la propiedad de registros o el uso compartido.
¿Tiene la hoja de Excel de la matriz de seguridad con los niveles de acceso y privilegios definidos por su empresa o cliente? Es importante tener alguna documentación del diseño de seguridad fuera del rol de seguridad de Dynamics 365, por si alguien cambia el rol de seguridad en Dynamics 365 y desea recordar cómo se diseñó. El documento puede ser una hoja de cálculo de Excel que indique el nivel de permiso adecuado por tabla.
¿Tiene casos de prueba en torno a la matriz de seguridad para todos los roles de seguridad? - Los requisitos de seguridad del cliente probablemente provienen de los requisitos recopilados durante los talleres anteriores del proyecto, y estos requisitos crean la base de los casos de pruebas de seguridad. Cada restricción de seguridad debería tener un caso de prueba y probarse a fondo antes de su puesta en marcha. Luego, las restricciones deben probarse en el contexto de cada rol de seguridad afectado.
¿Se ha planteado realizar pruebas negativas en el nivel de seguridad de campos y equipos? - Es importante probar si alguien con un rol puede ver los campos protegidos y acceder a los registros asignados a su equipo. Además, debe verificar que los usuarios sin estos roles o asignaciones de equipo no puedan acceder a estos elementos.
¿Realizará pruebas de penetración en la plataforma? - Para entornos de alta seguridad, las pruebas de penetración son una opción. Tenga en cuenta que las pruebas de penetración deben seguir las reglas de involucración de Microsoft Cloud para las pruebas de penetración. Para más información, consulte Reglas de involucración de las pruebas de penetración.
Otras preguntas de seguridad de Dynamics 365
En esta sección de la plantilla de modelo de seguridad, examinará la seguridad en lo relativo a las funciones relacionadas dentro de Dynamics 365.
Preguntas de seguridad de Dynamics 365 y por qué son importantes
Proporcione respuestas a las siguientes preguntas.
¿Ha considerado el privilegio Exportar a Excel? - Exportar a Excel es una magnífica característica de utilidad y generación de informes, pero también puede conllevar un riesgo, ya que se ha dado el caso de que algunos clientes han tenido empleados que se han llevado datos del cliente al abandonar la empresa.
Es importante ser conocedor y precavido, porque aunque el privilegio Exportar a Excel puede impedir que algunos usuarios descarguen fácilmente datos de Dynamics 365 con el botón Exportar a Excel, todo el que tenga acceso de lectura a un registro puede acceder a esos datos a través de las API y, finalmente, exportarlos.
Si procede, ¿cómo tiene previsto controlar la seguridad en el Servicio de exportación de datos, Azure SQL o en Exportar a Data Lake y Power BI? - Cuando los datos salen de Microsoft Dataverse para informes o integración, ya no están protegido por la seguridad de Dynamics 365. Las organizaciones deben ser conscientes de este parámetro y planificar la seguridad cuando los datos abandonen el sistema.
Si es aplicable, ¿cuál es su estrategia de modelo de seguridad para los portales de Power Pages y Unified Service Desk? - Power Pages le ayudan a exponer datos externamente y también permiten que las partes externas actualicen los datos de Dynamics 365. Sin embargo, es importante plantearse las implicaciones de seguridad de esta característica y asegurarse de que los datos seguros y confidenciales no estén expuestos a las personas equivocadas.
En caso de que sus usuarios hereden los roles de seguridad exclusivamente desde los equipos, ¿se ha planteado usar la opción Herencia al usuario directo en los roles de seguridad? Al asignar un rol de seguridad a un equipo propietario (incluidos los equipos de grupo de seguridad de Microsoft Entra ID o grupo de oficina de Azure AD), debe comprobarse la opción Herencia de privilegios del miembro correspondiente para asegurarse de que esté configurada correctamente. Esta configuración puede permitir que los usuarios que sean miembros del equipo hereden privilegios en el nivel de usuario (y no en el nivel de unidad de negocio o superiores), como si el rol de seguridad se les hubiera asignado directamente.
Esta característica es útil para 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.
Si planea utilizar tablas virtuales, ¿se ha planteado crear un modelo de seguridad para ellas? - Las tablas virtuales permiten la creación de tablas que no almacenan datos en Dataverse, sino que señalan a un origen de datos externo. Si bien esta característica es conveniente y, en muchos casos, preferible a sobrecargar Dynamics 365 con datos, debe comprender que la conexión de la tabla virtual usa un único origen de datos, lo que significa que todos los usuarios que tienen acceso a la tabla virtual verán los mismos registros. Si tiene registros confidenciales que no deberían ser visibles para todos los usuarios, se recomienda la integración de datos.
Supervisión de la seguridad
En esta sección de la plantilla, revisará la estrategia del cliente para la supervisión de los derechos de acceso apropiados e identificará el uso indebido de la aplicación. Si las auditorías de actividad están habilitadas en Dynamics 365, muchas actividades de los usuarios se registran en el Centro de administración de Microsoft 365. Mediante el uso de estos registros, puede identificar actividad inusual o potencialmente malintencionada en el sistema, incluidas acciones comunes como:
Quién publicó personalizaciones
A quién se agregó a un equipo
Quién agregó una solución
Quién publicó personalizaciones
Quién exportó a Excel
Quién vio un informe
Quién exportó un informe
Los registros de auditoría estándar supervisan cuando acceden al sistema los usuarios. Herramientas como Microsoft Power Automate pueden alertarle cuando tienen lugar determinadas actividades, y Microsoft Entra ID puede avisarle cuando usuarios que se encuentran fuera de las áreas geográficas normales intenten obtener acceso al sistema.
En esta sección de la plantilla del taller de modelo de seguridad, resumirá la estrategia de supervisión y alerta de comportamientos anómalos y los planes para comprobar periódicamente los permisos de los usuarios en Dynamics 365.
Reglamentos y cumplimiento
En esta sección de la plantilla, identificará si se aplica alguna normativa gubernamental o de cumplimiento que pudiera afectar al modelo de seguridad de Dynamics 365. Entre estos reglamentos se encuentran los de protección de datos del consumidor, como la HIPAA, la SEC y lo concerniente a auditoría, como la segmentación comercial. Complete la información en la diapositiva de regulaciones y cumplimiento.
La seguridad más allá de Dynamics 365
En esta sección de plantillas, mirará más allá de Dynamics, hacia otros sistemas que se integran con Dynamics 365 y la seguridad asociada. Dynamics 365 no es autónomo; otros sistemas interactúan con él o se integran con él. Por lo tanto, debe tener una visión holística de la seguridad, no solo la seguridad de las piezas individuales. Actualice las diapositivas de La seguridad más allá de Dynamics 365 para responder a las siguientes preguntas.
¿Ha asociado sus entornos con un grupo de seguridad para controlar a los usuarios que tienen acceso a él? - La asociación de un entorno de Dynamics 365 con un grupo de seguridad de Microsoft Entra ID limitará el acceso al entorno para los usuarios de fuera del grupo y restringirá los usuarios que se muestran como habilitados en el sistema. También simplifica la experiencia de los usuarios, ya que solo verán aparecer en la lista de entornos aquellos entornos a los que tienen acceso.
¿Utiliza el acceso condicional en Microsoft Entra ID para controlar cómo acceden los usuarios a sus datos de Office 365/Dynamics 365? - El acceso condicional de Microsoft Entra ID se puede usar para limitar desde dónde y desde qué dispositivo se puede usar el entorno, así como qué servicios y conectores se pueden usar.
¿Utiliza la administración de dispositivos móviles para administrar una flota de dispositivos (teléfonos móviles, etc.)? - Mediante el uso de soluciones de administración de dispositivos móviles (MDM) como Microsoft Intune, puede aplicar la seguridad, administrar de forma remota la implementación de aplicaciones móviles de Dynamics 365 y también eliminar datos de forma remota, en caso de pérdida o robo del dispositivo.
¿Tiene una integración con SharePoint? Si es así, ¿cómo aborda la seguridad en SharePoint frente a la seguridad en Dynamics 365? - La integración de documentos de SharePoint automatiza la creación de bibliotecas de documentos en SharePoint a partir de los registros de Dynamics 365 y proporciona un rápido acceso de los usuarios de Dynamics 365 a los documentos almacenados en SharePoint. La seguridad puede ser una preocupación, porque la seguridad de la biblioteca de documentos de SharePoint no refleja la seguridad de Dynamics 365. Si alguien tiene acceso al sitio de SharePoint donde se almacenan los documentos de Dynamics 365, podrá ver los documentos de la biblioteca, aunque no tenga acceso al registro de Dynamics 365 relacionado. Si esta situación resulta preocupante, debería plantearse alternativas cuando los derechos de acceso sean más restrictivos en el lado de SharePoint (por ejemplo con múltiples sitios de SharePoint, integración con OneDrive para la Empresa o integración con Teams).
¿Tiene una integración con Microsoft Power BI? Si es así, ¿cómo aborda la seguridad en Power BI frente a la seguridad en Dynamics 365? - Cuando Power BI genera un informe directamente desde Dataverse, mediante el conector estándar de Microsoft Dataverse, refleja solo los datos a los que el usuario tiene acceso en el sistema. Sin embargo, si se comparte ese informe de Power BI, los demás usuarios con los que se comparte el informe verán los datos del propietario del informe.
Se puede implementar seguridad en el nivel de fila para hacer cumplir la seguridad en el lado de Power BI, pero otra opción es crear un informe de SQL DirectQuery en Power BI, que se representará en el contexto del usuario conectado. A continuación, el uso compartido de un informe solo compartirá la representación de los datos, no los datos reales, y se aplicará por completo el modelo de seguridad de Dynamics 365.
¿Utiliza otros mecanismos de seguridad? - Otros mecanismos de seguridad podrían incluir la autenticación multifactor y proveedores de autenticación externos, como OKTA, y otros.
¿Su modelo de seguridad mantiene dependencias de las soluciones de fabricantes de software independientes (ISV)? Si es así, ¿cuáles son? - Los ISV brindan soluciones valiosas que pueden mejorar la implementación de Dynamics 365, pero también pueden introducir riesgos y dependencias de seguridad. Es importante comprender cómo se implementará esta solución, cómo se actualizará y qué tipo de acceso de seguridad requerirán los ISV.
¿Cuáles son sus requisitos para los patrones de seguridad de integración de datos? - Cuando los datos fluyen entre sistemas, es importante comprender cuándo será necesario controlar la seguridad en el nivel de flujo. Asegúrese de determinar qué acceso de seguridad necesitará la integración para el sistema de origen, qué acceso de seguridad requerirá la integración en Dynamics 365 y con qué cuenta se ejecutará el proceso de integración. Se recomienda usar los usuarios de aplicación (no interactivos) para controlar el acceso a las cuentas de integración.
En caso de que esté usando otras funcionalidades de Microsoft Power Platform, como Power Automate y Power Apps, ¿cuáles son sus requisitos de seguridad y diseño? - Power Apps y Power Automate usan conectores para integrarse con cientos de sistemas diferentes y estas herramientas forman parte de la misma plataforma que Dynamics 365. Las aplicaciones de lienzo de Power Apps y Power Automate usan Dataverse, como Dynamics 365, y las aplicaciones y los flujos pueden administrarse en soluciones, junto con otros componentes de Dynamics 365 en soluciones. La introducción de otros conectores en el proceso introduce una serie de consideraciones de seguridad adicionales, incluidos el acceso a los datos y la seguridad de esos sistemas, así como la estrategia de entorno para la que se están creando las aplicaciones y los flujos que tocan Dynamics 365 de producción. Entre el resto de consideraciones de seguridad se encuentran el acceso para los fabricantes que se conectan a su entorno de producción de Dataverse y las directivas de prevención de pérdida de datos (DLP) que determinan qué conectores se pueden utilizar juntos. El arquitecto de la solución debe hacer preguntas aclaratorias sobre la estrategia del entorno de Microsoft Power Platform y la estrategia DLP, y entonces identificar qué permisos tendrán los usuarios finales para crear aplicaciones y flujos.
¿Tiene requisitos de seguridad de infraestructura específicos (cifrado, etc.)? - Dynamics 365 ofrece opciones de cifrado avanzadas, incluidas claves administradas por el cliente para escenarios idóneos. Identifique si se utilizan estas opciones y si el cliente ha establecido una estrategia para mantener estos métodos a largo plazo.