It’s no secret that Oracle Cloud is quickly making its mark on the cloud application landscape. Over the last several years, Oracle’s cloud footprint has expanded tremendously. In doing so, more and more companies are beginning to understand the complexities of Oracle Cloud application security and how it can either help or hinder compliance goals.
For many organizations, risks related to Segregation of Duties (SoD) and excessive sensitive access are ever-present. A common misconception is that out-of-the-box (seeded) roles are designed to be conflict-free; however, the reality is that these roles inherently contain an abundance of Segregation of Duties conflicts. As users are assigned multiple roles, the potential for SoD conflicts can increase tenfold.
Is this possible to mitigate? When is it appropriate to rely on seeded roles vs. custom roles? How intensive would customization be?
There is no perfect answer, but there are questions organizations should consider to help guide their role design approach and ultimately, their processes for maintaining compliant Oracle user security. The below approach assumes organizations have identified Segregation of Duties and Sensitive Access risks.
- Job Role – Identification Approach
Organizations must first gain an understanding of the business roles and responsibilities of their application user base. This will provide insights around the Oracle Job Roles that will ultimately be assigned to end users, as well as potential risks associated with business process areas. It is during this phase that organizations can begin considering the following questions and formulating their approach based on the answers.
| Question / Consideration | Answer: Yes | Answer: No |
| Does the seeded Oracle role provide too much access? | Job Role customization recommended | Seeded role, as is, may be appropriate – pending user testing and confirmation |
| Does the seeded role, or required combination of assigned seeded roles, result in user SoD conflicts? | Job Role customization recommended | Seeded role, as is, may be appropriate – pending SoD analysis for confirmation |
| Is the seeded role missing privileges that a user would need to perform their job function? | Job Role customization recommended | Seeded role, as is, may be appropriate – pending user testing and confirmation |
Utilizing seeded roles may be the most appropriate approach for your organization, depending on which roles are needed for the user base and the organization’s compliance requirements. However, should Job Role customization be needed – whether to increase functionality or limit Segregation of Duties risks and excessive access – there are several methods for building custom Job Roles, each with their own pros and cons.
- Job Role – Customization and Ongoing Maintenance
The security model within Oracle Cloud is significantly different from that of the traditional Oracle E-Business Suite (EBS). Oracle Cloud relies on a role-based security model, with Job Roles and Abstract Roles being the primary security components assigned to end-users. Job Roles are comprised of a collection of privileges – either assigned to the Job Role individually or through Duty Roles, a grouping of privileges – all of which ultimately allows the Job Role functional access to perform specific tasks in Oracle. Abstract Roles provide a user with basic access to the system, such as the ability to enter a time or expense report. Rounding out the security model are Data Security Policies and Data Security.
Context, which defines what data the user can view and transact on
Organizations can achieve similar results through different combinations of privileges, data security policies, and data security context assignments. However, how you choose to develop your Job Roles will present you with different benefits and challenges. A method commonly utilized is a hybrid approach between leveraging seeded roles, with modifications, and configuring custom roles from scratch – this results in a reduction of risk and smaller level of effort as compared to full role customization. As an additional consideration, seeded Duty Roles may unknowingly be impacted through Oracle patch releases that will require intensive IT change management evaluation to ensure the impacted roles are not resulting in unintended access for the end user.
See the table below for a few examples and considerations:
| Example 1: Duplicate & Customize Seeded Roles | Example 2: Configure Custom Roles from Scratch | |
| Description | Copy the seeded role and perform customizations. | Create new role and manually add security components to role. |
| Configuration Speed | Configuration is faster due to reliance on seeded roles | Configuration is more manually intensive |
| Role / Privilege Transparency | Redundant / duplicate roles will likely exist in environment
|
Role privileges can be more transparent. Can choose to have less reliance on “child” Duty Roles |
| Ease of Ongoing Maintenance | Updates to roles will likely require more analysis time to determine if edits will have a cascading impact on other roles | Adding and removing privileges from a role will be intuitive to the end-user |
While the above examples are not the only routes you can take with security design, it is important to consider these factors, especially in regard to role maintenance and transparency. How you dictate your role customization will impact how your Information Technology department ultimately maintains security going forward.
Organizations are constantly evolving, and as such, being able to nimbly adapt access security to meet end user and compliance requirements is critical. With the right strategy, success in Oracle Cloud access security is attainable.
