Separation of duty policies
A separation of duty policy is a logical container of separation rules that define mutually exclusive relationships among roles. Policies for separation of duty are defined by one or more business rules. The rules exclude users from membership in multiple roles that might present a business conflict.
A separation of duty policy uses business rules to define the relationships among roles. The separation of duty policy groups the business rules for ease of administration. For example, you can assign a set of administrators to a policy, making the administrators responsible for tracking the violations of a set of rules.
Policy owners
- Exempt users or revoke exemptions from any policy violations that occur
- Be used as principals in system access control items (ACIs)
Exemption approval and revocation
Policy owners can approve and revoke exemptions by default, but they do not necessarily require this ability. You can configure roles or users to have access control capabilities over separation of duty policies though ACIs. The ACIs allow policy owners to do tasks such as editing or tracking violations. You can also configure the approval workflow to use participants other than the policy owner.
Separation of duty rules
A separation of duty policy can include multiple rules. For each rule, two or more roles must be listed. The number of roles to which a user can belong depends on how many roles you allow in the rule. The number of roles that you allow to coexist must be one fewer than the total number of roles in the list. For example, you might create a rule that excludes procurement and order approval. The allowed number of roles in the rule must be one, meaning that a user can have only one role. If you add more roles, such as invoicing and financing, you can allow up to three roles. Each user can have three different roles and the system capabilities defined by that role.
Allowed roles set to greater than one are typically used to prevent one person from having complete control over a process. The process is described by a set of roles. For example, a rule named "A user cannot have full control over the procurement process" might be defined by three roles named purchaser, approver, and orderer. In this example, the rule has two allowed roles. A user can be a member of two of these roles, but the user cannot a member of all three roles.
Enabled and disabled policies
An enabled policy creates exemption approvals and warns users before they submit a role membership change that breaks a separation of duty rule.
A disabled policy can still track violations, but it does not generate approvals or warn users. Violations from disabled policies are not displayed in audit reports. Using a disabled policy is a good way for a security administrator to track violations that occur before a policy is active in the system.
Role hierarchy and rules
Two roles in a rule cannot be direct ascendants or descendants of each other in the role hierarchy. For example, you cannot have a rule with both HR organization and HR department x if HR department x is a child role of HR organization.