Unable to render embedded object: File (Emp18Notice.png) not found.

Skip to end of banner
Go to start of banner

creatingsodpolicies

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

---title: Creating Separation of Duties Policies---

Creating Separation of Duties Policies

EmpowerID Separation of Duties (SoD) Policies are policies that you can author to raise flags known as SoD Violations when unacceptable combinations of group or role assignments to any one person, such as being assigned to a Management Role that allows the person to write RBAC policy while being in a Management Role that allows that same person to approve any violations occurring to those policies. With a SoD policy, you can rectify these situations by adding those roles to the policy. Then when the policy is compiled, it looks for any person having both of those roles.

To create a Separation of Duties Policy

From the Navigation Sidebar, navigate to the Audit Configuration page by expanding For Recertification Managers and clicking Audit Configuration. From the Audit Configuration page, click the Actions tab and then click Create SoD Policy. In the SoD Policy Details form that appears, do the following: Select the appropriate policy type from the Policy Type drop-down. When selecting policy types, you have the following options:
  • Group Membership Policy - This policy type allows you to combine two collections or sets of Groups to define a Separation of Duties violation for people being members of groups contained in both collections at the same time. An example of this could be a SoD policy that denies any person who is a member of a contractor's group from being a member of a domain admin group at the same time.
  • Management Role Policy - This policy type allows you to combine two collections or sets of Management Role Assignments to define a Separation of Duties violation for people being members of Management Roles contained in both collections at the same time. An example of this could be a SoD policy that denies a person with a Management Role assignment that allows them to author security policies from being assigned to a Management Role that gives them audit privileges for those policies.
  • Query-Based Collections Policy - This policy type allows you to combine two collections of objects or query-based sets to define a Separation of Duties violation for people being in both Query-Based Collections at the same time. Query-Based Collections (also known as "Set Groups") are comprised of Sets, which are SQL, LDAP or code-based queries. These Sets are re-evaluated by the EmpowerID engine on a scheduled basis and can group collections of people or resources based upon queries written against the EmpowerID Identity Warehouse or other external systems in your environment.
  • Resource Role Policy - This policy type allows you to combine two collections or sets of Access Levels to define a Separation of Duties violation for people having Access Levels in both collections at the same time. An example of this could be a SoD policy that denies an individual person from holding the Modify Access Level for shared folders in Switzerland and the Modify Access Level for shared folders in the United States at the same time.
Type the appropriate information for the SoD policy in the Name, Display Name and Description fields. Optionally, select a workflow to process the SoD violations from the Custom Workflow drop-down. In our example, we have selected the SOD Violation with Email Notification workflow. This workflow sends out email notifications to everyone assigned the Reviewers Access Level for the policy.
EmpowerID ships with one workflow configured for SoD violations, the SOD Violation with Email Notifications workflow mentioned above. You can expand this library, adding your own workflows for handling SoD violations as needed. If you do create your workflows, you must tag them with the "SoD" tag before they will appear in the Custom Workflow drop-down.
Tick Enabled to enable the policy. The policy must be enabled before it can be run.

The below image shows what the form looks like at this point for a SoD policy we are creating in our environment. We want this policy to raise a flag if someone is given a Management Role that allows them to perform author policies while being an auditor. We also want an email to be sent to each person assigned the Reviewer Access Level for the policy.

Underneath Schedule, select the desired start and end dates for the Separation of Duties policy from the Start and End calendars. The default start date is the date you create the policy and the default end date is 10 years from the creation date. Underneath Schedule, select the desired interval and iterations for running the policy. Iterations can set to run indefinitely or to a specified count. When setting the interval, you have the following options:
  • Once - Runs the policy once at the specified time.
  • Minute - Runs the policy every "X" minutes according to the specified interval. For example, if you set the interval to "12" and have selected "Run Indefinitely," the policy will run once every 12 minutes during the specified start and end dates.
  • Weekly - Runs the policy every "X" weeks according to the specified interval. For example, if you set the interval to "12" and have selected "Run Indefinitely," the policy will run once every 12 weeks during the specified start and end dates.
  • Monthly - Runs the policy every "X" months according to the specified interval. For example, if you set the interval to "6" and have selected "Run Indefinitely," the policy will run once every 6 months during the specified start and end dates.
  • Hour - Runs the policy every "X" hours according to the specified interval. For example, if you set the interval to "12" and have selected "Run Indefinitely," the policy will run once every 12 hours during the specified start and end dates.
  • Daily - Runs the policy every "X" days according to the specified interval. For example, if you set the interval to "3" and have selected "Run Indefinitely," the policy will run once every 3 days during the specified start and end dates.

The following image shows what the schedule looks like for a policy that has been configured to run once weekly every Monday at 7:00 am during the specified dates.

Click Save to save your policy.
  • No labels