What are the options for securing data projects

In a previous blog, I have provided an example how you can use eXtensible Data Security in combination with data entities. At the end of that post, I had one issue left to ensure people are not using each others data projects and in that way see data which is not permitted to see. In this blog post, I will tell about the options for securing data projects in the data management features.

Preconditions

Before users are able to use data management features, they need at least have permissions to execute data entities. Data entities were introduced as new technology in the development environment of Microsoft Dynamics 365 for Finance and Operations. On the privileges, there is now a node where you can specify access for data entities. You can also control the data entity access from within the Security configuration.

Out of the box there are privileges for both view and maintain access control. However, if the data entity is created as read-only, you can’t overwrite it using the security. When a user expects to have an entity available for Open in Excel and it is not available, then probably some security objects are missing in his/her role assignments.

A second (not mandatory) pre step for a user would be granting access to the data management workspace. An out of the box security role called Data management operations user. If a person has been assigned to this role, it can use the data management workspace and use import and export projects. Without this role, an user can only use the Excel add-in.

When a user has the data management operations user role, all import and export data projects are visible. For example, Mia is a Payroll administrator and as part of her role, she needs to import salary details into a general journal monthly. Without additional settings, she will see all data projects, but also other users can see it.

What is the exact risk?

When users will open a data project, the entities which are not part of the security role will not be visible. So, is there actually a risk or not? My answer on this is: “Yes!”. A user is able to open the Job history for these projects. Still, the person is not able to see entity details, but for export projects, the data package can be downloaded. So, without additional settings, there is a risk that an unauthorized person can see data which is not part of his/her role.

Also, when users do have record security enabled, they can have access to the same entity, and so, can download files created by other users.

Securing data projects

The correct mitigation for the risk is using the option Setup roles for data projects. This form can be started from the data management workspace if you are a System administrator or Data management administrator. On this form, you can do the setup which data projects (aka processing group) can be used by which user or role.

For the example above, the next setup like the screenshot below can be done. Once there is at least one record in this table, it will have impact on all users; except the system administrators. If a setup is done for e.g. the Products – import, Mia is not able to see any data project in her workspace. So, once you have defined one constraint, you have to complete it for all other users/data projects.

The most convenient way would be setting up the constraints per security role. However, if you remember correctly, one and the same role has been assigned to the Retail operations managers. To overcome this challenge, there would be an option to setup data projects per user. Be aware that depending on your requirements the list with settings might be a larger one.

The fields Apply processing group to and Grant access to do both also have an option All. This can be used to make a rule which is valid for all data projects and/or users. The Disable field can be used to (temporary) disable access to a certain data project/user combination. You can also make exclusions to prevent access. E.g. Disable rule for the Salary journal and the Retail operations managers. If you start using this approach, you must be aware that you might need to repeat this for all other roles which has access to the data management workspace.

Data Management Administrator

Guess what is the technique used by Microsoft to deliver this option for securing data projects… Yes, it is a security policy created with the eXtensible Data Security framework. This means that also the users part of the Data management administrator role will be affected by the policies. Out of the box, the Data management administrator is not able to specify which users/roles should get what individual data projects. But there is some oddness here.

The data management administrator can remove individual rules related to data projects which are not part of his role. However adding new rules with specific data projects not assigned to the data management administrator is not possible. Ironically, the data management administrator can add a rule for all processing groups. This can be added to another role/user but also to himself. To know what would be the risk if a user has access to the wrong data projects, you have to reread the paragraph above: What is the exact risk?

So, with the current security policy and option a data management administrator has, I would not suggest to implement this feature and also have the data management administrator role assigned to a user…

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!