Following on from my post last week (https://thecrm.ninja/2019/07/05/environments-for-projects/) where I talked about the different environments for projects, I thought it would be good to talk about security relating to it as well.
What I’ll be discussing below is best practise for projects that relate to (external) clients.
However, there are usually some small differences when it’s an internal project for a company – security is can be slightly more relaxed (after all, the dev teams are usually the ones responsible for rolling the project out, providing on-going support, new features, etc). It’s also the case that internal developers (usually) won’t be prevented from seeing what the actual company data is.
The essential principle is as follows: Users should be restricted to only using environments that they are needing to access
This follows Best Practise for system security, as well as some common sense (it’s surprising how many times this can seem to be lacking!)
Access to the environment/s will depend on roles/s of the person, along with infrastructure that is in place. Users should not be granted access to any environment that they have no need to access at all .
| Dev | Integration | UAT | Staging | Training | Production | Support | |
| Team | |||||||
| Developers | ✔ | ✔ | |||||
| Consultants | ✔ | ✔ | ✔ | ✔ | |||
| Clients | ✔ | ✔ | ✔ | ✔ |
Note: There may be exceptional cases people are required to access the Production instance for a client. In such a circumstance, it is vital and absolutely necessary to have a complete audit trail to cover this, setting out the reason/s for it, along with all actions that are taken within the system. This should be ideally be via email, or any other system that may be present to allow a definitive time-stamped communication of request and sign-off
There is an extensive security model within Dynamics365 that can be used to enable and control this, if needed (eg for users to have access to one part of the system, but not another – this could be due to the system holding restricted access data, for example).
Have you come across any cases where this wasn’t followed, and caused issues? Feel free to comment – I’d love to hear about what happened!
