With security threats knocking on the door every second, data is the new gold. So more than ever, data is a primary enterprise concern. In a recent publication, State of the CIO, 2022, the focus on security management has increased from 44% to 51% in 2021, regarding how CIOs spend time and attention on it in their current role.
Another survey shows the realities of the CISOs; 69% of the respondents stated that more of the cloud services they use are business-critical compared with the prior year, and 40% of CISOs are challenged with detecting and reacting to security incidents in the cloud.
When planning your architecture, how will you deploy your Cloud ERP, extend the functionality, and integrate with third-party systems? The strategy must involve a security layer and have a thoughtful plan. This article will share some critical aspects of your deployment and long-term strategy.
Some essential realities about Cloud ERP
Suppose your organization has begun the journey to a Cloud SaaS product from an on-premises world, such as Oracle E-Business Suite or any ERP that runs on a server you own (or rent). In that case, you'll start to phase in some significant differences right from the planning phase.
The first and most important is that you won't have control over the hardware. That means any aspect around data residency will have to be planned in time with your cloud vendor. SaaS Applications are provisioned in the geo-region that you will specify in the service order with Oracle. For SaaS applications, the home region isn't the provisioning location. For example, the North American geo-region includes three regions (Ashburn, Phoenix, and Toronto).
Another change is the "inability" to manage your environments, which in your service order by default is just two (PROD & TEST). You can order as many extra environments as your budget allows you to. In other words, you can manage the different environments or Point of Delivery (PODs), but it must be performed through Service Requests (SRs).
Deploying your business onto the Oracle Cloud Applications involves many activities, milestones, and tight coordination between multidisciplinary teams. Therefore, an environment plan is critical for your long-term SaaS strategy, which should include an active calendar highlighting key events for each POD, such as:
- Milestone testing events
- Configuration tasks
- Data Conversion tasks
- Custom Object Installations
- Maintenance blackout periods
- Schedule refreshes (T2T, P2T)
It is recommended to use a template provided by Oracle (Doc ID 2848566.1) that has a sample of the best practice for your Oracle Cloud Environment Management Plan.
Figure 1: Sample of Environment Management Best Practices Template (Doc ID 2848566.1)
The extensibility of Oracle Cloud Applications is very common among Customer Experience (CX) applications. Recently there has been a better adoption across other modules of Cloud Applications such as ERP, SCM, and WMS of design, develop and deploy extensions for Fusion SaaS applications by leveraging Oracle's cutting-edge OCI technologies, focusing on serverless and/or cloud-native technologies. Some of them are Oracle Visual Builder Studio (VBS), the preferred tooling for the extension of Oracle Cloud Applications, and Oracle Application Express (APEX). Some Oracle Partners and System Integrators have built solutions that run on top of Oracle Cloud Applications, seamlessly integrated into the ERP or SCM modules.
Figure 2: Sample of an extension built by Oracle Partner that works seamlessly with Cloud Applications
Three key aspects to consider about your SaaS security
#1 Easy Passwords and Authentication
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.
Figure 3: Password Policy under user category in Cloud Applications
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 accessing what and performing which tasks
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:
Figure 4: source SaaS Service Usage Metrics
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.
Figure 5: Report assignment to roles and/or users and set 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
Figure 6: Audit reports provided in Doc ID 2059102.1
The following six reports are available as sample Reports built using Audit Data:
- Audit Reports
- Audit Data for Report Execution
- Audit Data for Catalog Object Updates
- Usage Reports
- Hourly Concurrency
- Report Execution-Time Metrics
- Report Performance by Report Type
- Runtime Statistics
Important note: The Audit Retention Period is three months for Fusion SaaS customers.
#3 Extensions 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.
Figure 7: App UIs within a Project's extension. Source: Oracle Docs VBCS.
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:
Figure 8: The menu contains the Edit Pages in Visual Builder link that opens the application extension in Visual Builder Studio
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.
Figure 9: how application extension projects fit into the VB Studio ecosystem
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.
Figure 10: VB Studio & Cloud Apps Pairing
Takeaways
It is inevitable to say that Oracle Cloud Applications allow companies to adopt the best standards for security, taking it to the next level with Oracle's infrastructure.
Oracle's cloud solutions have industry-standard third-party audit reports in formats such as SSAE 18: SOC 1 and SOC 2.
Oracle's global network operation center comprises state-of-the-art physical data center protection, logical data security, and privacy protection policies. Among other advanced security options, I'd like to highlight Oracle Transparent Data Encryption to prevent unauthorized use of sensitive data; and Oracle Breakglass with Database Vault to provide additional controls over data and administrator access to prevent unauthorized use, views, or sharing of employee information.
With Oracle Cloud Applications, each customer has their own database instance in the cloud, including their own virtual network and isolated storage. Because of this architecture, there is no concern about noisy neighbors.
As Cloud Applications become, in many cases, not in an IT matter, the responsibility for securing data can get overlooked, so the data and access as described in this article must be taken seriously with internal resources or a vendor that can guide to ensure the compliance and minimize the risk.
With the correct level of access, you must ensure access controls, role-based access control (RBAC) ideally with a federated single sign-on and a Multi-Factor Authentication (MFA).
After the successful go-live of Oracle Cloud Applications, the organization must have a Standard Operational Procedure (SOP) for any activity performed in setups, such as changes in the configuration, profile options, or any action taken into the security console.
The goal is to mature to a state where data security is the responsibility of everyone in the organization, not just IT. This path must be taken in collaboration with executives and employees to establish security standards and a data governance framework.
Oracle Cloud Applications offer a complete set of capabilities for tailoring and integrations into a single, unified suite. Restricting access to your application's data is not the solution that will help your organization drive growth and innovation. Better security and governance are.