Please read my related LinkedIn article #TOTTreasures Of Talent and Risk Management and HR Digital transformation!
Overview of Microsoft Dynamics 365 security architecture
Role Based Access Control is the approach used to define which user gets access to what functional areas of the application and what data. Every user is assigned with a set of Roles each of which is made of a set of Duties and each Duty is made of a set of Privileges.In simple terms the security hierarchy levels are defines as below:
- A Role defines what functional areas of the application are accessible by the user. Each role assigned to a user can have data access rule attached to it.
- A Duty defines the next lower level of access to specific forms within the functional areas
- A Privilege is the smallest level of access which defines what a user can do (edit/view) of the data elements on the forms
Note: Authentication of access to Microsoft Dynamics 365 for Talent happens via Azure Active Directory
Using Segregation Of Duties on Microsoft Dynamics 365 for Talent
I am considering the above scenario to explain how Segregation Of Duties work on Microsoft Dynamics 365 for Talent.
- Michael is a Security admin who has access to Talent to administer adding new users and assigning roles to the users.
- Operationally he is not supposed to have access to any employee data and compensation data.
- But there is a risk that he will be able to assign “Compensation and Benefits Manager” role his own account to gain access and be able to view or update compensation information.
Although Michael is a trusted employee of the organization and an internal IT policy states that such transactions are to be approved by the IT manager and HR manager before making a change on Talent Security administration. There are 2 risk scenarios identified with Michael being a Security admin:
- Risk Scenario 1: Michael being a technical wizard can try to edit the Security administrator role and add the duty to gain accesss to employee compensation.
- Risk Scenario 2: Michael can assign the Compensation and benefits manager role to his user account to gain access
Define Segregation of Duties rules:
Identify the critical duties related to Security and Compensation and define segregation of duties rules so that they don’t coexist with one user. After defining the rules Validate duties and roles to check if there are any conflicts of the existing role definitions. If there are any conflicts, they will be logged as Segregation of Duties conflicts.
Impact 1:
If Michael tries to edit the Security admin role that is already assigned to him to include duties related to Compensation, then the system would block it:
Impact 2
If Michael tries to allocate the Compensation and benefits manager role to his user account, the system will log a conflict of Segregation of duties.
In a valid scenario when Michael is trying to get access with needed approval from his boss, the conflict can be resolved by granting access. Fool proofing rule: If we have to fool proof this scenario, then the conflict can be logged and denied so that the future attempts from Michael will not be possible as long the Segregation of duty rule is not deleted.
Impact 3:
Check the existing user role assignments for Segregation Of Duties conflicts and resolve (allow/deny) them.Run the process from the navigation: System administration>Segregation of duties>Verify compliance of user role assignment process. System will validate all the user role assignments and log the Segregation Of Duties conflicts that needs to be resolved (allow/deny).
For the conflicts logged one of the mutually exclusive roles can be chosen while resolving the conflict by denying assignment. “I trust no one, not even myself.” – Joseph StalinNow! When we look back at the Fool proofing rule I mentioned: There is one loop hole how Michael can still beat the system. Michael can delete the Segregation of duties rule and assign the Compensation and benefits manager role to himself to be able to access employees data and make a changes in compensation, but not without leaving a audit trail.
The record info can be used to identify who and when a particular record on Dynamics 365 for Talent was modified:
Food for thought:
- Does this cover the risks of IT Admin accessing data on CDS?
- What do you think of data access risk via Power BI reporting and aggregate data entities?
- What other scenarios have you come across so far that can be resolved using Segregation Of Duties?
- Do you think this can help is supporting any of the GDPR requirements?
Inbox me about it for a chat or if you want me to update this article with more details.
Want to know more about Dynamics 365 Human Resources… Stay tuned and subscribe to my blog😀:
Do you think my blog helped you? Then please share it with your network on LinkedIn!