Oracle® Fusion
Applications Materials Management and Logistics Implementation Guide 11g Release 1 (11.1.2) Part Number E20385-02 |
Contents |
Previous |
Next |
This chapter contains the following:
Segregation of Duties: Explained
Defining Segregation of Duties Policies: Points To Consider
Managing Segregation of Duties Risks and Violations: Critical Choices
Role Provisioning and Segregation of Duties: How They Work Together
Segregation of duties (SOD) separates activities such as approving, recording, processing, and reconciling results so an enterprise can more easily prevent or detect unintentional errors and willful fraud. SOD policies, called access control policies in Application Access Controls Governor (AACG), exert both preventive and detective effects.
SOD policies constrain duties across roles so that unethical, illegal, or damaging activities are less likely. SOD policies express constraints among roles. Duty role definitions respect segregation of duties policies.
You manage, remediate, and enforce access controls to ensure effective SOD using the Application Access Controls Governor (AACG) product in the Oracle Governance, Risk and Compliance Controls (GRCC) suite.
AACG applies the SOD policies of the Oracle Fusion Applications security reference implementation using the AACG Oracle Fusion Adapter.
AACG is integrated with Oracle Identity Management (OIM) in Oracle Fusion Applications to prevent SOD control violations before they occur by ensuring SOD compliant user access provisioning. SOD constraints respect provisioning workflows. For example, when provisioning a Payables role to a user, the SOD policy that ensures no user is entitled to create both an invoice and a payment prevents the conflicting roles from being provisioned. AACG validates the request to provision a user with roles against SOD policies and provides a remediating response such as approval or rejections if a violation is raised.
Use AACG to for the following.
Define SOD controls at any level of access such as in the definition of an entitlement or role.
Simulate what-if SOD scenarios to understand the effect of proposed SOD control changes.
Use the library of built-in SOD controls provided as a security guideline.
SOD policies express incompatible entitlement or incompatible access points into an application. In GRCC, an access point is the lowest level access for a particular application. In GRCC, entitlement is a grouping of access points. As a security guideline, group the lowest level access points or define the SOD policy at the access level causing the least amount of change. Business activities are enabled at access points. In Oracle Fusion Applications, the hierarchy of access points in descending levels is users, roles, and entitlement.
Note
AACG entitlements are logical groupings of security objects that represent Oracle Fusion Application access points such as roles or entitlement.
Note
In AACG, segregation of duties policies are called access controls.
Oracle Fusion Applications does not predefine business logic for dealing with SOD conflicts. Oracle Fusion Applications does define a set of states where role requests are suspended pending resolution of SOD violations the role request introduces. In most cases, Oracle Fusion Applications invokes OIM to handle role requests. Enterprises define SOD resolution rules when defining SOD policy.
The risk tolerance of your enterprise determines what duties must be segregated and how to address violations.
AACG assists in remediation of violations with a guided simulation that identifies corrective action. You determine the exact effects of role and entitlement changes prior to putting them into production, and adjust controls as needed.
For information on managing segregation of duties, see the Oracle Application Access Controls Governor Implementation Guide and Oracle Application Access Controls Governor User's Guide.
Segregation of duties (SOD) policies express incompatibilities enforced to control access in defined contexts.
In Oracle Fusion Applications, SOD policies protect against the following incompatibilities.
Privilege X is incompatible with privilege Y
Role A is incompatible with role B
Any privileges in role A are incompatible with any privileges in role B.
Privilege X is incompatible with any privileges in role B.
The following examples of SOD policies illustrate incompatible entitlement.
No user should have access to Bank Account Management and Supplier Payments duties.
No user should have access to Update Supplier Bank Account and Approve Supplier Invoice entitlement.
You can extend SOD policies to control access to specific data contexts.
For example, no single individual must be able to source a supplier in a business unit and approve a supplier invoice in the same business unit.
SOD policies may include exclusion conditions to narrow the SOD scope and reduce false positive violations, or inclusion conditions to broaden the scope.
Conditions apply to access points globally, to policies, or to access paths defined by policies. Access path conditions can exclude a user from a role, an Oracle Fusion Applications entitlement from a role, or a permission from an Oracle Fusion Applications entitlement.
The following global exclusion conditions are predefine in Oracle Fusion Applications and available when creating SOD policies.
User Status
User Name
Enterprise Role
Action
Business Unit
Within Same Business Unit
Oracle Fusion Applications enforces SOD policies under the following circumstances.
When granting entitlement to a role
When provisioning a role to a user
For information on managing segregation of duties, see Oracle Application Access Controls Governor Implementation Guide and Oracle Application Access Controls Governor User's Guide.
Note
SOD policies are not enforced at the time of role definition.
A single SOD policy can include entitlement from multiple instances of a single enterprise resource planning environment. For example, one SOD policy is enforced in implementation, test, and production instances of Oracle Fusion Applications.
You assess and balance the cost of duty segregation against reduction of risk based on the requirements of your enterprise.
The types of people who resolve SOD conflicts include the following.
Administrator of an external program such as the Procurement Administrator for the supplier portal or the Partner Manager for the PRM Program
Senior executive spanning multiple organizations in an enterprise with opposing interests
Risk management professional implementing a Oracle Governance, Risk and Compliance Controls (GRCC) initiative
Predefines a set of conditions and informs access provisioning staff to approve requests and prove the exception based on certain conditions
Allows defining rules to route SOD violations for approval
You view and respond to risks and violations in the Application Access Controls Governor (AACG).
You may wish to override an SOD violation. For example, the Accounts Payable Supervisor includes incompatible duties to create both invoices and payments when you provision this job role to a user, you may waive the violation in the AACG. You may waive the violation for the currently provisioned user, for the SOD policy that raised the violation, or for the SOD policy within a particular data set, such as a business unit.
The risk tolerance of your enterprise guides how you respond to conflicts. For example, a user may be provisioned with both the role of Order Manager and Shipping Agent. The Order Manger role entitles the user to enter orders, which could result in exploitation when filling shipping quotas. You can remove the entitlement to enter orders that the Order Manger job role inherits from the Orchestration Order Scheduling Duty role. Or you could segregate the shipping and order entry duties by defining an SOD policy that allows a user to have either job role but not both.
False positives can be SOD policy violations that aren't actually violations or violations that are within your risk tolerance and therefore do not require corrective action.
You can reduce false positives by the following methods.
Define exclusion conditions that can be applied to individual or groups of policies.
Define logically complex SOD policies that enforce more exacting specifications.
Determine whether conflicts should be prevented, monitored, or made subject to approval during provisioning.
Conflict analysis detects a user's multiple paths to one or more conflicting access points.
For example, a user may be able to reach a single access point through one or more roles, or by one entitlement leading to another through submenus to a function that represents a risk. The resulting conflict path shows if the conflict is generated by inappropriate role provisioning or configuration of applications. The audit shows the paths from any number of users to any number of access points involved in conflicts, which lets you visualize the root cause and remediate effectively.
AACG assigns one or more users to review all paths involved in a given conflict so that the entire conflict can be addressed in a coherent way.
AACG lets you accept or waive a violation. Your reasons may include that you accept the risk or will define compensating controls.
A waiver may apply to the current user, constraint, or constraint within a dimension such as the business unit.
The risk tolerance of the enterprise determines whether a segregation of duties conflict must be removed from the security reference implementation.
The following approaches resolve conflicts.
Change the segregation of duties policy.
Ensure a job role does not contain incompatible duties.
Define data security policies that restrict authorized access by incompatible duties
Changing a segregation of duties policy may not be possible in most cases. For example, a policy that segregates creation of payables invoice from making payables payments should be preserved, even if the Accounts Payables Manager job role includes a duty role for each activity. To prevent an accounts payables manager from being authorized to perform both duties, or from being authorized to make payables payments to self and direct reports, the Accounts Payables Manager job role must be changed. The security implementation can be changed to include two job roles that segregate the incompatible duties. Added data security policy grants can restrict the access to at risk data.
For information on managing segregation of duties, see the Oracle Application Access Controls Governor Implementation Guide and Oracle Application Access Controls Governor User's Guide.
Segregation of duties (SOD) checks occur when roles are assigned to users. The checks are based on Oracle Application Access Controls Governor (AACG) policies. The Oracle Identity Management (OIM) integration includes predefined routing rules for remediation in the Manage IT Security business process.
External users such as suppliers or partners need to be provisioned with roles to facilitate access to parent company interfaces and data. The process by which such provisioning requests are approved in Oracle Fusion Applications helps explain the request flows and possible outcomes.
Note
In Oracle Identity Management (OIM), external users means users who are not specific to applications, such as enterprise roles or the absence of entitlement to access an application.
The figure shows the role provisioning request flow. OIM uses AACG to check segregation of duties violations.
A supplier or partner requests admission to a program using an implementation of the Supplier Portal Submission. The submission is captured in one or both of the following tables in advance of approving or rejecting the supplier or partner.
Oracle Fusion Trading Community Model
Interface Staging
Oracle Fusion Applications collects the employee names for the supplier or partner company at the time the company submits its request to join the program so that all employees accessing Oracle Fusion Applications on behalf of the supplier or partner are provisioned.
AACG in the Oracle Governance, Risk and Compliance Controls (GRCC) suite is certified to synchronize with the policy and identity stores for all pillars or partitions of Oracle Fusion Applications and integrated with the Oracle Fusion Applications security approach to roll up entitlements (by means of duty roles) to the roles that are provisioned to internal users. SOD policies can be defined and enforced at any level of authorization. For external users, SOD policies use attribute information stored in the Trading Community Model tables.
Enterprise business logic may qualify the requester and initiate a role provisioning request by invoking the Services Provisioning Markup Language (SPML) client module, as may occur during onboarding of internal users with Human Capital Management (HCM), in which case the SPML client submits an asynchronous SPML call to OIM. Or OIM handles the role request by presenting roles for selection based on associated policies.
OIM recognizes the role provisioning request and initiates a call to AACG.
OIM apprises the SPML client of the current state of the role provisioning request as SOD_CHECK_IN_PROGRESS.
OIM stores the SOD check result as part of OIM audit data.
OIM apprises SPML client of the current state of the SPML request. The provisioning is either still in progress with segregation of duties being checked, or conflicts were found. If conflicts exist, AACG rejects the request and notifies the application.
Status |
Conflicts |
Current State |
---|---|---|
SOD_CHECK_IN_PROGRESS |
Unknown |
Request sent to AACG and waiting for response |
SOD_REMEDIATION_IN_PROGRESS |
Conflict found |
AACG detected violations and remediation is in progress |
SOD_CHECK_APPROVED |
No conflict found |
No SOD violations found |
SOD_CHECK_REJECTED |
Conflict found |
AACG detected violations that cannot be remediated |
SOD_REMEDIATION_APPROVED |
Conflict found |
AACG detected violations that are approved |
SOD_REMEDIATION_REJECTED |
Conflict found |
AACG detected violations that are rejected by approver |
In the absence of an SOD exception, OIM provisions all relevant users.
Note
When a partner user is provisioned, all employees of the partner enterprise are provisioned. SOD checks occur when an external user requests to join a program, because SOD policies operate across Oracle Fusion Applications, not at the individual level. Supplier or partner company user requests are not approved if there is an SOD conflict against the supplier company.
OIM provides AACG with the details of SOD exception approval workflow. AACG audits the outcome for use in future detective controls and audit processes.
AACG may respond with the following.
Roles may be provisioned to the external user or its employees because no SOD conflict is found
SOD conflict is found and request is denied because the relevant SOD policy is to be strictly enforced and no exception approval should be allowed
SOD conflict is found and the exception to the policy is allowed, so the request goes through additional processing, such as an approval process.
Supplier or Partner Relationship Management responds to an SOD exception by updating Trading Community Model tables with the current state. An enterprise may elect to implement a landing pad that offers external users a means of addressing the SOD problem by providing more information or withdrawing the request.
SOD violation checking occurs during role implementation and provisioning, and can be turned on or off if AACG is provisioned and enabled as part of the Oracle Fusion Applications deployment.
Depending upon status, OIM kicks off an auditable SOD exception resolution workflow. Resolution can be conditional based on approval or requirements such as contracts being met.
If one of the paths for exception resolution is to get an approval, then the SOD exception resolution drives the approval using AMX. Standard AMX rules, not business rules, resolve the approval for the SOD exception, including the following.
Organizational hierarchies
Multiple mandatory and optional approvers
Rerouting and approval delegation
The approver resolution uses AMX Rules Designer to access various user attributes and organizational hierarchies managed in Oracle Fusion Applications repositories. This information is typically not available in OIM or the LDAP identity store repository. Enterprises can define additional approval rules using AMX Thin Client.
The SOD Exception Approver gets a notification through supported channels that a new request is awaiting approval. The approver signs in to the global SOA federated worklist application that aggregates all pending worklist items for the user from all Oracle Fusion applications and logical partitions or pillars of applications. The SOD exception approval tasks show up in the same list.
The SOD exception approval task shows the details of the SPML request and SOD Provisioning results in a page rendered by OIM. The approver may take one of the following actions.
Approve the request as it is
Reject the request
If the approver approves the request, OIM sends an SOD_REMEDIATION_APPROVED status to the SPML client.
If the approver rejects the request, OIM sends an SOD_REMEDIATION_REJECTED status to the SPML client. The provisioning request is considered completed with a failure outcome and the external users is notified. Oracle Fusion Applications updates the Trading Community Model tables with the rejected status
The SOD remediation tasks are assigned based on the role being requested.
If the role requested is Chief Financial Officer, the SOD remediation task is assigned to the IT Security Manager role.
If the SOD violation results from a policy where the SOD control tag is the Information Technology Management business process and the control priority is 1, the SOD remediation task is assigned to Application Administrator role.
In all other scenarios, the SOD remediation task is assigned to the Controller role.
For more information about configuring audit policies, see the Oracle Fusion Applications Administrator's Guide.
For information on managing segregation of duties, see the Oracle Application Access Controls Governor Implementation Guide and Oracle Application Access Controls Governor User's Guide.