Investing in the Cloud: Securing Your Oracle Cloud Applications
In the previous blog post, I discussed how organizations should prepare to transition smoothly to Oracle Cloud Applications. In this post, we’ll delve into the internal workings of Fusion Applications and how your TIS (Technology and Infrastructure Support) team needs to be ready to secure your environment while bearing in mind that you are no longer responsible for hardware maintenance or patching.
Flying at High Altitude (& Secured) with Oracle Cloud Applications
#1 Securing access through Authentication and Passwords
One of the most challenging aspects of security is having users secure their passwords. In a recent survey by Bitwarden, almost 90% of respondents were somewhat or very familiar with password security best practices but not putting them into practice. Most global respondents (84%) reuse their passwords across more than one site. Users of a Cloud Application follow the same pattern, so managing it through a strong password policy is vital.
A straightforward and effective method to secure the access of users is “Location-Based Access.” You can control user access to tasks and data based on their roles and computer IP addresses.
Also, many organizations are leveraging a single sign-on with 3rd party solutions that add an extra layer of security to Cloud Applications by enabling a policy across all the corporate applications. This includes two-factor authentication (2FA), which can avoid a common breach: “password sharing.”
#2 Who is access to what?
Cloud Applications have evolved dramatically from unlimited applications, giving users a wide breadth of flexibility based on multiple ways to secure access to the designated business functions. These “Job Roles” are part of a hierarchy within Cloud Applications, as shown below:
Oracle Cloud Applications seeds most of the relevant roles, which is what is typically used at the time of the implementation. But in many cases, it might become pertinent to create custom roles or what we call some hybrid, which is a tailored seeded role.
This needs to be treated very carefully because we’ve seen -and corrected- cases where some end-user roles had access to configurations or grotesque conflicts on segregation of Duties. Another aspect to consider when choosing the right approach on roles is that some roles are updated automatically during quarterly updates, which creates an additional element to test as part of the release upgrade. While reading this article, you are wondering what your status is; here’s some help. The User and Role Access Audit Report and User Role Membership Report provide details of the function and data security privileges granted to specified users or roles. This information is equivalent to the information you can see for a user or role on the Security Console.
Finally, the other way to access data is through reports. For standard BI Publisher reports, the “Role Mapping Security” can restrict the information you’re retrieving to a certain extent. Still, there are other ways to secure the data for custom reports. The first is by code based on the user’s role, which is more complex but is the most sustainable solution. The other option, which is what is typically used, is through catalog permissions.
The security levels for Oracle Cloud reports and analytics are:
- Object-level security: The visibility of business logical objects is controlled at the object level, based on a user’s role. Object-level security can be configured for Oracle BI Repository items like business models and subject areas and Web objects like dashboards and dashboard pages defined in the Presentation Catalog.
- Data-level security: The access of the user associated with data-level security controls (dashboard, subject areas, reports, and other BI objects).
Since Release 13 19A, Oracle Cloud Applications has turned an Audit and Performance Monitoring on by default. This is another extra layer of security to monitor who runs what in your applications. You can follow the steps on how to configure and use audit in the Doc ID 2059102.1
The following six reports are available as sample Reports built using Audit Data:
1. Audit Reports
a. Audit Data for Report Execution
b. Audit Data for Catalog Object Updates
2. Usage Reports
a. Hourly Concurrency
b. Report Execution-Time Metrics
c. Report Performance by Report Type
d. Runtime Statistics
Important note: The Audit Retention Period is three months for Fusion SaaS customers.
#3 Are you extending Fusion Applications? Is it secured?
Let’s start with a definition of an extension. Extensions are what you use to deliver new capabilities into Oracle Cloud Applications. Those capabilities may take the form of customizations you make to the App’s user interface, or your extension may include things like App UIs, to deliver new pages or resources to your Oracle Cloud Applications instance. For instance, in the Oracle Cloud Application, standard Globalization for Argentina, a new application built by Oracle, includes a user interface component to fulfill the local tax requirements.
When choosing a platform to extend your Oracle Cloud Applications, you’re ahead of any other SaaS product because of the maturity of Oracle Visual Builder Studio and Oracle APEX as part of the technology stack.
Suppose you already have Oracle Cloud Applications and Oracle Integration Cloud, which we recommend as the foundation for your journey to SaaS. In that case, you have an Oracle Visual Builder Studio for free. It might require extra cost if you are interested in CI/CD automation.
Starting on Release 13 22C, Oracle Visual Builder Studio has been added to the Oracle Cloud Applications navigation.
If you check the Settings and Actions menu while in a “Redwood”-style Oracle Cloud Application and see an option for “Edit Pages in Visual Builder,” that’s your signal that you need to use VB Studio to make your changes to the App’s user interface:
Regarding security, the changes made to Oracle Cloud Applications in VB Studio are stored in an artifact called an extension. Physically, the source files associated with the extension are stored in a Git repository. When working on an extension, the best practice is to have only one extension for the base app (the Oracle Cloud Application you’re extending) in the project and store the source files for the extension in the same Git repository.
Regarding how VB Studio and Cloud Applications are paired, there is only one instance of VB Studio per customer\tenancy, and it is paired to your TEST pod. You can make necessary changes in TEST and deploy it to other instances.
