Security implementation for any ERP system can be a daunting task. However, understanding a few crucial points in advance can decrease the complexity level, cost, and the time taken to implement security.
When we implement security for the customers, we often think it is just the development of security roles for the users and then deploying it to the live environment. However, that is not the complete security implementation—there’s a lot more.
We, at STAEDEAN, ensure our customers are properly implementing the security, using our Security & Compliance Studio (SCS), by considering and working on a few important steps.
In the clouds’ world, maintaining optimal licensing costs for the users and adopting security changes quickly after the go-live are just as important as security development.
Now let’s have a look at how to implement security in D365FO using the standard feature provided by Microsoft, and where it stands in terms of the 10 points as mentioned above.
|
Sl. No. |
Checklist of things to consider |
Ease of implementation in D365FO |
|
1 |
Define permissions for the user
|
Gathered and mentioned all the permissions on form for a user in a document. Difficult to manage a hefty document. |
|
2 |
Gather all the permissions for a user and develop a role for the user |
It can be developed using AOT or security configuration, but it is difficult to find the correct privilege or duty for the specific form level permission for the user. |
|
3 |
Ensure segregation of permissions are set up correctly
|
It can be defined using standard Segregation of Duties (SoD), but there is a huge gap in standard SoD. Duty contains many privileges and entry points; you can even create another duty from the existing privilege, and SoD will fail to recognize it as a violation. |
|
4 |
Verify/test security roles defined for the users |
Assign the security roles to a user and verify all the permissions. |
|
5 |
Optimize the license cost for the user |
No clear insight into licensing at the entry point level. |
|
6 |
Keep track of security changes after go-live |
D365FO does not keep track of security changes. |
|
7 |
Maintain security changes requested by the users after go-live
|
Cannot be managed within D365FO. It must be developed or some other third-party product can be used. |
|
8 |
Change the security role as per user request |
Security changes are not linked to the security request. |
|
9 |
Deploy security changes requested by the user after going live as early as possible
|
Has to be deployed through AOT or move all the roles; no functionality of moving a security role individually. |
|
10 |
Provide a report on security setup and changes to the security auditor
|
Standard reports are there but do not provide much insight into the changes. |
The drawbacks of using standard D365 F&O
If we use standard D365FO features for implementing the security, we might have to let go of some of the points mentioned above. Yet, even after that, it is quite a complex and time-consuming process to implement security.
Imagine if you are implementing security for a customer with more than 500 end users. You can group the users based on their level of permission. For example, if 10 users are operators, then you create an operator security role for all these 10 users. That way, you might end up with around 50+ profiles with different levels of permissions.
Now, gathering all the requirements and maintaining them for all permissions (50+ profiles) is a tedious task itself. If we consider the testing of those roles, it would be further hectic. It might impact the go-live date for your customer, or they might end up in go-live without the proper security roles defined.
How can Security & Compliance Studio help?
Let’s see how our solution Security and Compliance Studio can help you in implementing security and how our solution stands in the 10 security implementation checklist points mentioned earlier in this blog.
|
Sl. No. |
Points to consider |
Ease of implementation in SCS |
|
1 |
Define permissions for the user
|
Use standard task recorder to record the business process for the user and save it as a scenario. |
|
2 |
Gather all the permission for a user and develop a role for the user |
Use Match roles functionality to quickly check existing security roles in the system against the user recording and create a new role or use the existing role for the user. |
|
3 |
Ensure segregation of permissions are set up correctly
|
Define segregation of permissions at the entry point level. SCS will capture all the permission violation. |
|
4 |
Verify/test security roles defined for the users |
Assign the security roles to a user and verify all the permissions. |
|
5 |
Optimize the license cost for the user |
See the licensing against each point while creating the security role itself, even after the security role is created, we can analyze the license at the entry point level. A separate license optimization workspace.
|
|
6 |
Keep track of security changes after going-live |
Use a Security audit log to keep track of all the changes. |
|
7 |
Maintain security changes requested by the users after going -live
|
Security request feature so that users can raise security changes. |
|
8 |
Change the security role as per request by the user |
Link the security scenario to a security request. |
|
9 |
Deploy security changes requested by the user after going -live as early as possible
|
Ability to export and import individual security roles. |
|
10 |
Provide security setup and changes report to the security auditor
|
Security audit report designed to, especially, meet the requirement of an auditor. |
As we can see, SCS can help you reduce the security implementation time to a great extent. Moreover, it also helps in enabling more robust segregation of permission, easier adoption of security changes even after go-live, keeping track of security changes, and optimizing the license cost.