DEV Community

Cover image for Obfuscation IS NOT Security
Riccardo Gregori
Riccardo Gregori

Posted on

Obfuscation IS NOT Security

Many times, I've seen tech leads (me included) working around Dataverse / Dynamics 365 security model.

πŸ˜• Quite often this is due to client security requirements not fitting the standard Dataverse / Dynamics "rules":

"All my users should be able to access all accounts, but I don't want them to be able to freely search in the account base."
"Users should be able to access audit records only on entity A and B. On the other entities audit should be on, but available only to System Administrators"

🀯 Sometimes is just to avoid the complexity of a requirement:

"For the opportunities I would like to have a hierarchical security model, but the hierarchy is different from the one of the business units. And also I need approvers (that are outside the hierarchy) to be able to see only the opportunities that need their approval, and the opportunities they have approved in the past. Ah, and also, customer service reps should be able to see only opportunities on clients in their own territory"

🀐 In some cases is just hard to explain to a customer why a specific security requirement requires so much effort (and maybe a structural change of the data model) to be put in place:

"Role A should be able to see all the info on the Case records belonging to his team, and only a subset of info on the Case records that don't belong to his team"

For all the above reasons (and probably many more), often the proposed solution is "don't touch the roles/teams/whatever, let's simply obfuscate the stuff they don't need to see"😎.

Basic obfuscation techniques

There are many examples of basic obfuscations techniques that, on the surface, seems to address the customer needs without requiring so much effort...

  • Don't put a table on the navbar
  • Leave all the default views empty (or with only meaningless information)
  • Hide by default all the fields on the form, then let's show them via JS only if {the user has a specific role | other custom criteria are met}
  • Customize the application standard command bars to manually hide the buttons we don't want to show
  • Use hidden feature flags to hide standard capabilities (such as the advanced find button)

They all have flaws πŸ€”

You should always remember that there are a lot of ways to access a list of records of a given table, some more easy to use than others, but all available to the common user:

  • The plain, old, legacy advanced find. It's still available via βš™οΈ > Advanced Settings > Advanced Find
  • The Lookup window
  • XrmToolbox tools such has FetchXml Builder or SQL4CDS
  • On Excel, Data > Get Data > From Power Platform > From Dataverse
  • Connect PowerBI to your favorite Dataverse instance and fetch whatever you want
  • Browser extensions such as Dynamics 365 Power Pane or Level Up for Dynamics 365/Power Apps or Audit Engine for Microsoft Dynamics 365 that can be installed locally without control
  • Using the classic WebApis that are freely usable by authenticated users

The general rule is

If you have read privilege on it, you can see it, and you can also export it.

πŸ’¬ My suggestion is: avoid shortcuts βœ‚οΈ; there is no other viable solution that a proper security model configuration. Sometimes this can lead to a lot of customizations (plugins, Power Automate Flows, or whatever to automatically manage record assignments); sometimes this can lead to difficult conversations with our clients; and sometimes it maybe require saying "no" to a specific requirement. But it's the only viable options if you really want to secure your data.

Top comments (0)