During Quest Forum Digital Event: Cloud Week, ATCO (Alberta Trailer Company) Group’s Ella Kulyk gave a presentation on Oracle Cloud Security from the customer perspective.
About ATCO
ATCO was originally founded in 1947 in Alberta when a father and son began providing housing accommodations to workers in Canada during the nation’s first oil boom. Now, ATCO’s capabilities have expanded to a number of innovative solutions in several sectors. The company has invested its 6,000 people and $24 billion in four main areas:
- Structures and logistics
- Energy infrastructure
- Port and transportation
- Commercial real estate
The image below shows a summarized view of ATCO investments. The organization’s endeavors are both complex and diverse, and ATCO has provided services in over 100 countries around the world.
ATCO was initially on E-Business Suite (EBS). Then, nine ATCO companies converted from EBS to Oracle Cloud. They implemented a single CoA with standardized processes. It was a no customization approach with go-live taking place in October of 2018.
ATCO’s Cloud Security Challenges
Kulyk explained that Oracle Cloud Security is still challenging for ATCO, even a year and a half after implementation. The first challenge regarded finding Oracle Cloud security expertise. The options for finding this expertise are as follows:
- Hire an expert or a consulting firm
- As a word of warning, Kulyk mentioned that consulting firms may not have all of the answers for which you are looking. Take references before hiring.
- Complete Oracle University training
- Developing expertise in-house may be the best investment of your time and resources. Kulyk said she wishes her team had taken Oracle University training even before beginning the project launch. They currently require certain employees to take security-specific training from Oracle University.
- Figure it out on your own
- Ultimately, you will have to do this to some extent. It is not recommended to begin with this approach.
Oracle Cloud Security in a Nutshell
Below is a glossary for Oracle Cloud security. Underneath each job role is a list of privileges. These privileges are logically grouped in duty roles. To determine which privileges are assigned to each Oracle role, refer to the Oracle Help Center online for the most up to date information.
- Abstract Roles – not specific to a particular job
- Job Roles – specific to a particular job
- Privileges, logically grouped into Duty Roles
- Data Security Policies – Roles are bundled with data security policies, which define the conditions in which access to data is granted to a role
- (For example, an Accounts Payable Manager can view the supplier qualification response, but not alter it.)
- Security Context (ERP roles)
- Business Unit
- Asset Books
- Inventor Orgs
- Ledger, etc.
- Data Roles (Human Capital Management)
- Inherit job roles, abstract roles, or duty roles (There is no security context for HCM roles; the user’s data access is limited by the inherited job role to a dimension of data as defined by a data security policy.)
As an example, Kathy is an employee who has been given two abstract roles and a job role. The image below shows Kathy’s roles and access.
The image below shows the security setup menu for Kathy’s view in the system.
Oracle Cloud Security Deep Dive
In addition to the explanation above, Oracle Cloud security also houses a Procurement Agent (SCM) and a Contract Administrator Resource (Finance).
The Procurement Agent is not a role. It is a task that must be assigned manually for every procurement user in Oracle. The Procurement Agent task allows the implementation of document security for individual document types such as purchase orders, purchase agreements, and requisitions. All Procurement users must be set up as procurement agents in order to manage Procurement documents and perform other Procurement actions.
Similarly, in Finance, the Contract Administrator Resource access is an additional piece of security that must be assigned to the Enterprise Contract Administrator role.
Segregation of Duties
Oracle has taken care of some, but not all, Segregation of Duties (SoD) within roles. You need to pay special attention to SoD vulnerabilities in your organization.
Oracle ERP Cloud includes roles that have been defined with a knowledge of a set of SoD policies that are included in the Oracle Cloud’s Access Controls Governor product. For example, the privilege, Create Payments, is incompatible with the privilege, Approve Invoice. The predefined Accounts Payable Manager role has the privileges of Force Approve Invoices and Create Payments. When you assess and balance the cost of duty segregation against the reduction of risk, you may determine that the Accounts Payable Manager role is not allowed to perform force approve invoices and remove this privilege.
Seeded Roles
There are multiple seeded roles in the Oracle system for the same job. One version of the security role begins with the letters ORA. This version is the most up-to-date role for that job, and it continues to receive Oracle updates. The other version is an old role that is still being used by some Oracle customers. Because of this, Oracle did not want to eliminate this role. They recommend you utilize the security roles with the prefix ORA-.
The second challenge faced by ATCO was the decision to either seed or customize roles. They wanted to allow read-only access to users who experienced this in EBS. Oracle Fusion did not offer this option. They reached out to Oracle:
ATCO: Should we avoid building custom roles?
Oracle: We designed the system to be flexible so that you can build whatever you would like. However, custom roles won’t receive updates.
The answer from Oracle was not extremely helpful. Ultimately, ATCO determined they could not avoid the path of creating custom roles if they wanted to allow Read-Only access. If you are in the same situation but have not implemented Oracle Cloud Security, it is good to note that Oracle will probably offer Read-Only in the future.
Tips for Creating Custom Roles
Kulyk shared a few tips for creating custom roles:
- To make minor changes to a role, copying and editing the predefined role is the most efficient approach.
- Creating roles from scratch is most successful when the role has very few privileges and is easily identifiable.
- The predefined duty roles represent logical groupings of privileges that you may want to manage as a group.
- For example, the Asset Accountant role has a Fixed Asset Inquiry duty role which ATCO copied to build an inquiry-only, or read-only, role.
- Use Aggregate Roles as building blocks for custom roles.
- Prefix your custom role names to make them easily identifiable.
- For example, ATCO added the prefix ATCO- to custom roles.
- Want to get rid of a custom role? Too bad— you can’t delete them!
Copying Roles
There are two ways to copy a role in order to create a custom role. One approach will allow your copy to receive quarterly updates from Oracle. The other keeps your role untouched by updates. Depending on your intended use, you may choose to use either.
- Initiate a copy or an edit from the Roles tab in the Security Console.
- If you are copying a role, select one of two options in a Copy Option dialog.
- Copy role: You copy only the role you have selected. The source role has links to roles in its hierarchy, and the copy inherits links to the original versions of those roles.
- If you select this option, subsequent changes to the inherited roles affect the source’s highest role AND your copy.
- Copy role and inherited roles: You copy the role you have selected AND all of the roles in its hierarchy. Your copy of the highest role is connected to the new copies of subordinate roles.
- If you select this option, you insulate the copied role from changes to the original versions of the inherited roles.
- If you create a copy of the inherited duty roles (i.e. a deep copy), your duty roles will not be updated with upgrades. When inherited duty roles are copied, custom duty roles are created. Therefore, you can edit them without affecting other roles. Similarly, changes made subsequently to the source duty roles don’t appear in the copies of those roles.
- For example, if those duty roles are predefined and are updated during an upgrade, then you may have to update your copies manually after the upgrade. This option is referred to as a deep copy.
- Copy role: You copy only the role you have selected. The source role has links to roles in its hierarchy, and the copy inherits links to the original versions of those roles.
Aggregate Privileges
Aggregate privileges are a type of role that combines a single function security privilege with related data security policies. They are all predefined and cannot be altered, created, or copied. Aggregate privileges are the combination of a job role and a data security policy. The job and abstract roles directly inherit aggregate privileges. Duty roles may also inherit them. You can include aggregate privileges in the role hierarchy of a custom role. Use them as building blocks for custom roles, as pictured below.
Customization of Roles
The third challenge for ATCO was that of customizing roles. Customization of roles is not a simple endeavor. For ATCO’s purposes, the seeded roles had too much access. The organization had to decide which privileges to take away from each role. From a list of 100+ privileges per role, the only way to discover the specifics of each privilege was to test it out. This was time-consuming and tedious.
ATCO also realized that assigning read-only roles to users took away their update access. In Fusion, read-only roles appear to supersede the right access.
Finally, ATCO realized that they had exposed personal employee information with some custom roles.
Security Setup and Licensing
A fourth challenge occurred with security setup licensing impacts. ATCO went live, designing their security without any concept of how licensing would be impacted. They were $9 million over their licensing threshold and received a note from Oracle referencing the issue. They sought help:
ATCO: Can you tell us which roles are driving up our licensing costs?
Oracle: Licensing is a bit like a forensic investigation. You have to get a whole bunch of data and do some triangulation.
This response was not the level of assistance ATCO had hoped for. It took a while for them to discover the main issue. After searching for Oracle support forums, they found a user in the UK who had posted a report, which ATCO further modified:
From this report, the ATCO team created a list of license-triggering roles. Through this exercise, they discovered many seeded roles that trigger multiple licenses. Some users were triggering up to ten licenses. They also discovered that the read-only custom roles were all triggering licenses. The ultimate solution was to create more custom roles. They would do this to remove license-triggering privileges wherever possible.
Additionally, ATCO worked with a second company on Oracle Cloud. They mentioned OTBI licenses that are report-only at $20 per person. There is a bit of mystery revolving around these licenses, but they may be worth an inquiry to your Oracle rep.
Automation at ATCO
The challenge currently facing ATCO is that of automation. To date, ATCO’s service provider does auto-provisioning and de-provisioning on their behalf. It is difficult for this provider to know how to do this appropriately and effectively. The example below shows the complexity of security approvals at ATCO.
After doing some research and reaching out to Oracle, ATCO discovered that the best practice for all is to create roles with embedded security context. Unfortunately, they had applied the job role, then manually applied the security context for the designated person.
You should create a custom role to embed security access within the role. More specifically, if you have five business units, then every role that requires business unit as security context will have five different versions of that role—one for each business unit. ATCO has just started to correct this issue and the team is working through the process to find the right balance. Had they done the Oracle University security training prior to the project, ATCO would have known the solution beforehand and would not be in the current predicament.
Key Takeaway
Oracle Cloud security is a complex system to learn. As a best practice, take Oracle University’s security course before beginning implementation. Kulyk’s hope is that the information provided in this post will better prepare you for success, as you can learn from the mistakes made at ATCO. For some quick tips, take a look below.
Quick Tips & Tricks
During her presentation, Kulyk provided several quick tips and tricks for others to take into account during their own cloud security journey.
- Document EVERYTHING (All of this will be used by your audit team)
- Security setup and how it works in Oracle Cloud
- Custom role privileges
- Approvals matrix
- Build reports to monitor:
- Licensing
- Roles assigned in error
- Assignment of roles with elevated access
- Quarterly updates
- Watch for new privileges — incorporate to roles via customer duty roles
To learn more, check out Kulyk’s Cloud Week presentation and additional resources attached below.