Oracle Security in the Cloud

Introduction

Over the past few years, Oracle has been firmly shifting its software solutions portfolio model to the cloud, allowing organizations to focus more on business operations and less on back-end management of the supporting applications and infrastructure. As a result, organizations are rapidly transitioning off the standard on-premise, internally managed technologies in favor of a model that integrates key financial applications onto Oracle’s cloud infrastructure stack, which requires only a browser and an internet connection to access.

The idea of the cloud has existed since the 1960s but has become more popular in recent years as computer processing power and bandwidth have made cloud-based services more accessible. Cloud computing leverages shared, elastic resources that can be delivered to users through self-service web technologies. This allows companies to use only what they need instead of purchasing resources and creating redundancies within their own data center.

Company board members and chief executives are becoming better educated in cloud capabilities and the potential cost savings, and chief information officers (CIOs) are increasingly asked to have a strategy for moving resources to the cloud. This strategy may include data center services, email, VOIP and phone services, Microsoft Office products, customer relationship management (CRM), and enterprise resource planning (ERP) solutions.

As more organizations begin developing their ERP cloud strategy, a number of considerations will drive executive decision-making, including compliance requirements and the impact that a cloud solution will have on the organization’s internal control structure. Most notably, management will have to be proactive in planning for application-specific security to support strong segregation-of-duties (SoD) and appropriate sensitive access levels. Leading practices indicate that access should be granted based on a user’s job duties as well as management’s risk tolerance for performing conflicting functions (e.g., “Create a Supplier” and “Issue Payment to a Supplier”).

A well thoughtout and implemented ERP security design is the foundation for how the company’s employees will interact with the application for years to come, allowing them to appropriately enter business transactions and interpret information used to manage the business. An effective design also scales with the growth of the organization without creating unexpected security gaps.

Companies that do not maintain consistency with a well-designed security model may face challenges during upgrades, acquisitions, employee hiring or termination, and other changes to the business. Consequences of a poorly executed security design include, but are not limited to:

• Errors stemming from entries by unauthorized personnel
• Unauthorized visibility into corporate information
• Fraudulent manipulation of financial information
• Theft of assets
• Inefficient access provisioning
• Regulatory and compliance issues

In the full paper, we explain key concepts and provide recommendations to achieve a robust security model and avoid these problems.

The Oracle ERP Cloud Security Model

The security model within Oracle ERP Cloud is very different from that of the traditional Oracle E-Business Suite (EBS) versions. Oracle has replaced the “responsibility” and “menu” containers with a role-based model that allows for a more robust and scalable approach to user administration.

The security models for Oracle ERP Cloud (Financials) and Oracle’s other cloud applications (HCM, CX, SCM, EPM, etc.) are slightly different, and as such, our focus for this paper will be on Oracle ERP Cloud. However, the concepts for building and evaluating security can be applied toward the other applications.

Although the security design of the Oracle ERP Cloud applications can vary slightly for different offerings such as Financials and Human Capital Management, generally, the application security architecture can be separated into two considerations — functional access and data access. The different components of the Oracle ERP Cloud security model are discussed in detail below:

• Privileges
• Duty Role
• Job Role
• Abstract Role
• Data Access Policies
• Data Security Policies
• Provisioning Rules

Functional Access

1. Privileges are the basic building blocks of functional access. Privileges determine what functionality a user is able to access and execute on his or her screen all the available buttons, tabs, editable fields and reports able to be generated by a particular user. Privileges are the old “Function” concept within Oracle EBS and are very specific to the capabilities within a page. Examples of privileges include Create Payables Invoice, Validate Payables Invoice and Initiate Payables Invoice Approval Task Flow.
2. Duty Roles are made up of different privileges within Oracle ERP Cloud to perform specific actions with specific data; typically, they are very specific task-based activities within the business process. An example of a duty role is “Payables Invoice Creation Duty.” The collection of privileges within this duty role would enable one to create and update an invoice, either through mass updates, updates through uploads or direct modifications within the invoice form. The duty roles are assigned directly to job roles. They are not assigned directly to a user. (Note: While duty roles can be assigned to other duty roles, it is not recommended to take this approach except when strictly copying an out-of-the- box role provided by Oracle.)
3. Job Roles, which should represent the specific jobs or positions within an organization, are a collection of duty roles that allow a person to perform specific job functions. For example, the job role “AP Clerk” would allow the user to perform those functions an accounts payable clerk should be able to complete as part of his or her job requirements. (Note: While job roles can be assigned directly to other job roles, it is not recommended to take this approach except when strictly copying an out-of-the-box role provided by Oracle.)
4. Abstract Roles are similar to job roles but define required tasks based on level of employment rather than job title. A simple example of this would be a role assigned to all employees for the intention of timecard entry, selecting benefits and reporting expenses. This role would be defined as the abstract role “Employee.” Another example of an abstract role is “Line Manager,” which, when assigned to managers, provides them the ability to perform certain tasks they would be expected to perform, such as approving time entries, managing goals for the team, etc.

Key point: The key to taking a proactive security approach is establishing strong policies governing security design and a solid foundation of job roles that are conflict-free.

Data Access

Prior to Release 12, data access was managed by data roles and data security policies. A security model introduced by Oracle for new users of Release 11 and all users of Release 12 eliminated the need for data roles. Data access is now managed by a combination of data security policies and data access policies. This new access functionality exists within ERP Cloud and Supply Chain Management (SCM) Cloud.

In EBS Financials, data security was managed through “Profile Options” and access was granted based on “Ledgers,” “Operating Units” and “Inventory Orgs.” This data model still applies, but instead of assigning data access to a responsibility, the data access is restricted through data security policies and data access assigned to users in Oracle ERP Cloud.

1. Data Access Policies are specific values of database resources. These resource values need to be assigned to each user and to each role that is provisioned to it. For example, the job role “U.S. AP Clerk” would allow the user to perform all the functions of a payables clerk, but only within the U.S. business unit. The privileges inherited by the job role will allow the user to view and transact within all the appropriate business objects such as invoice and payment terms. The data security policy will restrict the access to only the specific business units assigned through the data access policies, in this case, the U.S. operating unit. This becomes very useful when larger companies have several employees with the same job title, but with each employee needing to work within a different set of data.
2. Data Security Policies define the permissible level of data access allowed in reference to a specific database resource, such as business unit, ledger and asset book, and are assigned to a job role. They act as the WHERE clauses to limit what data can be accessed by those database resources. Due to this, in order for a job role to reach the desired level of access, it may take several data security policies.
3. Provisioning Rules are the rules that define how access will be granted to users. They ensure that the integrity of the Oracle security model is maintained by laying down specific rules for maintaining user access requests. We discuss provisioning rules in more detail in Steps 4 and 5 in the next section.