Oracle Operator Access Control (OpCtl) is a cross-tenancy, access control Oracle Cloud Infrastructure (OCI) service for enterprises to better govern Oracle authorized personnel’s necessary access to their Exadata Cloud@Customer (ExaCC) on-premises public cloud, and effortlessly address the general security and privacy requirements in regulated industries. Explore here.
OpCtl is precisely designed to help institutions—such as banks, energy utilities, defense, or any other enterprise operating in a high-risk management and regulatory framework—extract operational and monetary value of their cloud implementation, and monitor the chartered maintenance of the resources by Oracle while also meet the legal, policy, and regulatory needs for the specific mission-critical applications – all via the OpCtl software interfaces.
Security Features of Oracle Operator Access Control
To begin with the cardinal fragment in the Oracle Operator Access Control, following is the list of preventive, detective, and responsive security features that enterprises get with Exadata Cloud@Customer out of the box. These are largely for determining the scope of work to be performed by Oracle staff and detect and dismiss unauthorized access.
- For every Oracle work request, an Oracle personnel (a.k.a. Oracle Cloud Ops) would require authorization from the enterprise to access the Oracle managed Exadata Cloud-at-Customer
- The authorization would only open the relevant components to the Oracle work request
- Automatic revocation of the Oracle personnel access upon the completion of authorized task
- Enterprises control the window for Oracle personnel’s access to their on-premises public cloud
- Software control over Oracle personnel’s privilege escalation
- Notifications upon the enterprise approved Oracle personnel’s need for Exadata Cloud@Customer access
- Separate audit logs for every command/keystroke run by Oracle personnel
- Oracle personnel’s identity is furnished by Oracle to enterprises for any command executed
- Oracle’s in-house security team monitors all Oracle Cloud Ops activities
- Both enterprises and Oracle’s security team are vested with the power to terminate authorized Oracle personnel’s access, and restore all the processes initiated by them at any time
Note: Although enterprises have the authority to revoke or ignore Oracle’s maintenance task permissions, they should know that these tasks are mostly critical to ExaCC’s health and availability. Hence, to assist enterprises with the dilemma, Oracle mark these requests for severity between 1 – 5, where 1 is of the highest priority.
Oracle’s Access to Enterprise Exadata Cloud@Customer - in Action
- Upon enterprise authorization to Oracle Cloud Ops to access the Exadata Cloud-at-Customer infrastructure, a REST API command is transmitted via the persistent secure tunnel to the agents in the respective infrastructure, and a temporary, secure, outbound operator tunnel is established to a Secure Tunnel Service in Oracle cloud.
- The authorized Oracle personnel use this tunnel to establish a ssh connection, followed by allowing OpCtl to authenticate them as a named user via their Oracle managed device with the help of hardware multi-factor authentication before passing into the enterprise authorized ExaCC resource component.
- The Cloud Ops personnel use their Oracle-issued laptop and Yubikey (hardware, and the credentials to it) to verify the ssh connection between their laptop and the enterprise on-premises public cloud, and pass into the temporary account to begin the component maintenance work.
- Past this stage, Oracle Linux chroot jail controls entry into the infrastructure. A chroot jail modifies the visible root directory for executing processes and enables enterprises to run programs with a root directory different than ‘/’. Please note that the program is not capable of reading or accessing files beyond the designated directory tree. And, an artificial root directory as such is called a chroot jail, whose aim is to constrain a possible attacker from gaining access.
- The chroot jail laches the authorized process and the user ID utilizing it, so that only the directory inside which the process is executed remains visible. This enforcement undertaken by chroot jail is also called the Oracle Operator Access Control – OpCtl Actions. It determines the operations an operator can carry out on Exadata Cloud@Customer including ‘Dom0’, the Exadata cell server, and control plane server.
- Oracle Linux permissions are also categorized by OpCtl Actions into Full System Access, System Maintenance with Restart Privileges, System Diagnostics, and System Maintenance with Hypervisor/VM Access. All these permissions categories play a critical role in ensuring secured management of the enterprise Exadata Cloud@Customer resources by the authorized Oracle Cloud Ops personnel. For detailed information on the entire process, please refer to Oracle Operator Access Control documentation page.
Operations Concept in OpCtl for Exadata Cloud@Customer
The idea of Oracle Operator Access Control is to create a jointly responsible security model that involves both the enterprise and Oracle to collaboratively work towards securing request, authorization, and monitoring access to Cloud@Customer resources. OpCtl technology makes it extremely easy to provide and approve chartered personnel with process planning and technology updates for the management of ExaCC while simultaneously ensuring compliance.
OpCtl Interfaces: OpCtl can be configured/managed through the classic, intuitive, easy-to-use OCI Console or APIs. It is the most seamless way to interact with the Operator Control service for configuring and enforcing policies to Exadata Cloud-at-Customer, while also granting, monitoring, and suspending access.
OpCtl Notifications: Oracle Operator Access Control’s access requests are relayed to enterprises inside OpCtl interfaces. They may access the interfaces through the Oracle Cloud Infrastructure Console and API interfaces at any point of time to discover any pending access requests seeking grant. Enterprises may also sign up for push notifications through the OCI Events and Notifications services.
Exadata Software Updates: Updates for Exadata Cloud@Customer infrastructure are orchestrated processes schedulable by the enterprise. It is available via the Oracle Cloud Infrastructure interfaces and is applied via enterprise-managed IAM credentials. To guarantee service quality amid ExaCC update, enterprises utilizing the OpCtl are needed to pre-approve every system access profiles such as hypervisor, diagnostics, maintenance update, etc., to allow Oracle Cloud Ops personnel instant access for responding to any failures detected while the software update is in progress.
Exception Workflows: Oracle Operator Access Control service offers the option for technical/process controls to allow running exception workflows on several occasions such as access for a different Oracle Ops for completion of a task, or the original personnel’s access to enterprise VM during recovery, etc.
Oracle’s Access to Enterprise VMs
The Oracle Exadata Cloud@Customer service does not permit Oracle personnel to access the enterprise VMs under the standard operating scenarios. However, there may be exceptions during a time of failure in the enterprise VM, demanding Oracle Cloud Ops personnel’s access to address the issue. The processes/technical controls managing Oracle personnel’s access to enterprise VMs depend on whether or not the VMs is retrievable by the enterprise.
OpCtl Failure Recovery and Incident Reporting
The Oracle Operator Access Control service is enforced within a highly available delivery model that safeguards against any single/multiple hardware component failure. To guarantee enterprises’ absolute control over every remote access, the OpCtl does not extend Oracle a substitute human remote access technique to alleviate against failure of the Operator Control software such as chroot jail deployment, or the access request processing. In case the OpCtl software fails and demands human shell access for resolution, the procedure for the enterprise to offer access to Oracle for recovering are as follows:
- Oracle reaches out to the enterprise on their default bridge and elaborates the problem to them
- Oracle personnel visit the enterprise and the physical location of the hardware
- Enterprise affiliated personnel accompany Oracle Ops staff to the infrastructure
- Oracle personnel would execute the analysis and recovery processes after gaining access, therefter
Once the underlying issue is addressed, the rest of the remediation is undertaken via the restored OpCtl service.
In the event of an unfortunate security incident with Exadata Cloud@Customer and Operator Access Control, Oracle would fully comply with applicable state and federal laws, and the Oracle Global Security policies relevant to incident response and damage containment.
