Hoy vamos a hablar de un tema que suele dejarnos un poco desprevenidos en cada implementación, es odiado y amado en igual proporción. La seguridad en F&O es una parte muy robusta del sistema que con una buena cuota de optimización puede lograr maravillas. Vamos a verlo!
¿Qué hablamos cuando hablamos de Seguridad en D365 F&O? Cuando mencionamos el tema muchos de los más viejitos recordamos dar de alta cuentas en Active Directory y luego en Ax2012 y asignar roles de seguridad, etc. Toda una historia que solo unos pocos sabían hacer.
Bueno hoy en día no mucho de ello ha cambiado aunque las formas y los conceptos son un poco diferentes.
Para hablar de seguridad en F&O tenemos que comenzar hablando de la arquitectura de seguridad, que es la siguiente:
Aquí podemos ver que la Seguridad en Dynamics consta de tres segmentos.
En primera instancia tenemos la Autenticación que nos habla de cómo podemos acceder al sistema. Es la primer llave de acceso y reside en AAD (Azure Active Directory). Debemos tener un usuario creado en el AAD, dentro del Tenant (o inquilino) correspondiente para poder acceder a F&O.
Para explicar un poco mas esto, el tenant es una instancia o un lugar, que crea nuestra empresa donde se asocian todos los servicios que vamos a utilizar. Para acceder a él es necesario tener una cuenta de correo (un usuario) que permita ingresar al tenant.
Una vez tengamos nuestro usuario dado de alta en el AAD de nuestro tenant, ¿entonces podremos acceder a F&O? Aún no. Antes debemos pasar a la segunda instancia de seguridad, la Autorización, que controla el acceso de los usuarios a las funcionalidades de la aplicación.
En particular la Autorización controla el acceso de cada usuario a los menúes, ítems de menúes, acciones, botones, controles, reportes, etc... de nuestro cliente de F&O. En particular, funciona con un esquema de seguridad basado en Roles que vamos a explicar mas adelante.
Una vez Autorizados, tenemos un nivel más de seguridad, la Seguridad de datos, en este caso en lugar de autorizar acceso, restringimos accesos a los datos, tablas y registros dentro de la base de datos. A través de una funcionalidad llamada "Extensible data security policies"(XDS) podemos extender la seguridad de los roles, restringiendo el acceso a ciertos objetos y registros de la base de datos. En algún otro Post, podremos hablar un poco mas sobre XDS, pero por el momento vamos a continuar con la Seguridad basada en roles.
Seguridad basada en roles.
Como parte de la "Autorización" que vimos antes nace este concepto. Aquí la seguridad no se asigna directamente a los usuarios, sino que se asigna directamente a los roles. ¿Qué quiere decir esto? Que los privilegios de seguridad a menúes, formularios y campos se asignan a roles dentro de la organización, como por ejemplo un empleado contable, y luego se asignan usuarios al rol del empleado contable. En caso de no tener ese rol dentro de nuestro usuario, no tendremos esos privilegios de seguridad. Esto nos permite tener una administración muy dinámica de la seguridad. Si las políticas de seguridad cambian, se modifican o cambian los roles sin tener que ir usuario a usuario cambiando los accesos. En el caso que necesitemos realizar un cambio masivo, simplemente generamos una regla de asignación automática a roles y reasignamos a todos los usuarios.
Si observamos bien el gráfico anterior en la sección de Autorización vamos a ver los siguientes conceptos
Roles: Son el corazón de la asignación de seguridad. Normalmente describen una posición o un puesto dentro de la organización, el cual realiza múltiples actividades, como por ejemplo, "Funcionario contable", "Agente de compras" o "Gerente de Ventas". Los roles son los que se asignan a los usuarios. Puede asignarse un único rol o más de uno, la combinación de roles es positiva siempre dando acceso en lugar de restringirlo. Los roles pueden asociarse a jerarquías organizacionales y ayudarnos a dar seguridad o incluso a trabajar con flujos de aprobación por jerarquías de roles. Por defecto F&O, trae roles de seguridad que contienen toda la funcionalidad del sistema
Deberes/Aranceles: Los deberes (ahora también conocidos como Aranceles) describen los accesos de un procesos de negocios. Por ejemplo "Mantener ordenes de compra". Al asociar un deber a un rol de seguridad estamos dando asociando una posición a un proceso de negocios. Es decir que si queremos que nuestro Rol "Funcionario de compras" pueda "Mantener ordenes de compra", simplemente agregamos el deber al rol y listo. Los deberes tienen múltiples privilegios, correspondiendo al proceso de negocio al que hacen mención. Dentro de su nombre podemos distingir si son de ABM, porque normalmente comienzan con la palabra Mantener o si son solo de consulta, porque comienzan con la palabra "Ver".
En cumplimiento con normas internacionales (por ejemplo SOX o IFRS) existe una funcionalidad de segregación de controles que nos permite cargar restricciones de seguridad, para que por ejemplo, no se asigne a un usuario que realice facturas de venta, a también poder pagarlas.
Privilegios: Los privilegios de seguridad son los que manejan la seguridad a nivel de cada control del sistema. Es cada trabajo, acción y pueden asociarse tanto a los roles como a los deberes. Lo mas recomendable es asociarlo a deberes para poder tener un mantenimiento más sencillo, pero nada nos impide que los asociemos a los roles.
Permisos: Los permisos son cada acción de cada control que tiene el privilegio. A través de los permisos podemos controlar si un privilegio puede leer un registro o modificarlo.
Finalmente tenemos un apartado de Auditoria, el cual nos permite revisar y controlar los accesos al sistema a través de logs, y sumado a una serie de reportes de seguridad nos dejaran visualizar la información de accesos rápidamente y detectar cualquier anomalía.
Hasta aquí dejamos esta primer parte. En el próximo post veremos cómo manejamos toda la seguridad basada en roles, dentro de F&O.
Nos vemos en otro Consejo Dynamics!!
Comments