crmtipoftheday: Tip #1079: Security Design Principles

[Blog bot]

Источник: https://crmtipoftheday.com/1079/secu...gn-principles/
==============

We have a lot of flexibility when it comes to security in Dynamics 365; field-level, record-level, hierarchy, ad hoc sharing and so on. Sometimes, depending on the requirements, there are a few ways to skin the cat (such a violent expression). Whenever you are presented with a range of options to solve a problem, it is good to fall back on some guiding principles to work out the right path. Here is my MASCOT model for security design.

Maintainability: If the design cannot be maintained by a power user/non-coding developer, rethink. Having a base security role helps in this regard

Always Think of the User: If the Users hate it, the system will not be used. There is a balance to be found between governance and practicality

Simplicity: Keep the design as simple as possible. Minimise Security Roles and Business Unit complexity. Documentation gets lost and exception rules are often forgotten. Do not share security roles between Users and Teams though

Configuration First: Mixing development and security can lead to scalability issues, especially if automated sharing and un-sharing is involved. Keep the system running smoothly by avoiding ad hoc sharing of records via code

Only Use Security When Necessary: If there is not a valid business reason to protect information, don’t. A lack of trust is not a valid business reason

True Security, Not Security By Obfuscation: It is sometimes much easier to remove a field from all forms and views and think it is secure. If the data can be found via Advanced Find, it is not secure

I remember one security model which broke all of these rules. Accounts came in from a third party system via integration. Based on the Account’s office location, code automatically allocated it to a Territory and then ad hoc shared the Account to all Users with permission to access that Territory. To keep up with the growing scaling issues and minimise User complaints, the administrator was upgrading the RAM of the SQL Servers literally every month. Field security was implemented by simply adding and taking away fields from forms and having Users use the right form. It was a mess.

I reviewed their system and proposed a security model using both record and field level security and no code. The only difference was one field, previously read only, would be editable. A vastly simpler security model and no more RAM blow out. The CTO refused to change because he was the architect of the original model and, despite having auditing enabled, did not trust his employees not to edit that one field.

Six months later he was sacked, his team replaced, and a rival CRM system implemented (yes, THAT one!). They could have upgraded Dynamics for a fraction of the cost but the system was so despised it was politically easier to ditch it.

Learn from the mistakes of others and embrace the MASCOT.



Источник: https://crmtipoftheday.com/1079/secu...gn-principles/