As more organizations move to the cloud to gain operational and financial value there also is a concern meeting policy, legal, and regulatory requirements with crucial applications and highly regulated industries. There are many ways to protect data which can include a third-party vendor add-on, or in this case Oracle’s built-in security features. In the first blog of this series, Exadata Cloud@Customer Takes Security to the Next Level, Jeffrey Wright, Product Manager at Oracle, explains how Oracle Operator Access Control can help customers control access to Exadata Cloud@Customer and Autonomous Database Dedicated infrastructure.
Jeff explains, “When dealing with security and access controls, Operator Access Control provides enhanced Preventive, Detective, and Responsive security controls.” This second blog of the series will take a deep dive into Preventive controls.
Jeff adds, “The Preventive controls in Operator Access Control are not just the passwords to the front door, but a set of locks on all the doors in the system that can be selectively opened by the customer to enable Oracle staff to perform authorized maintenance while preventing them from performing actions beyond the scope of a predefined minimal privilege set.” The technical enforcement of these controls is a unique aspect of Operator Access Control. Compared to general privileged access management (PAM) products and services that control access to infrastructure, Operator Access Control is a PAM service engineered end-to-end and implemented into the core of the Oracle Linux operating system in the ExaCloud@Customer service. Jeff explains, “For a customer that needs to realize the financial and operational benefits of the cloud while meeting strict security and compliance goals, Operator Access Control is a compelling solution.”
Image 1 below illustrates how Operator Access Control works. After the customer permits access to the Exadata Cloud@Customer infrastructure, the Operator Access Control software deploys a temporary credential in an Oracle Linux chroot jail that is engineered into the Exadata Cloud@Customer service. The temporary credential is accessible through FIPS 140-2 level 3 multi-factor authentication by a single Oracle operator associated with the temporary credential. The Oracle operator tunnels through a series of gates (Oracle Cloud Network Attach VPN, Bastion Servers, Management Servers) to finally log into a chroot jail that permits work within the scope of the defined privileges and prevents escalation beyond those defined privileges. Jeff adds, “An important benefit of Operator Access Control is that the Oracle Linux chroot jail isolates the Oracle operator to a specific and limited set of resources.”
Image 1 – Operator Access Control
Operator Access Control provides 4 levels of access privileges for Exadata Cloud@Customer infrastructure. These privilege levels are based on how customers evaluate risk and how Oracle people work to support the Oracle cloud:
These access levels are designed, implemented, tested and validated based on Oracle’s real-world operational experience running enterprise clouds, and in close collaboration with leading Oracle customers to mazimize operational efficiency and minimize risk.
The privilges natually follow well-known troubleshooting processes. The first action an operator often needs to do is system diagnostics. The Operator Access Control system diagnostics chroot jail provides access to important system accounting and log data and prevents access to change the software that can affect customer services or reboot servers that would cause service disruptions. Jeff adds, “The benefit of diagnotics access is that Oracle can quickly formulate an effective action plan to resolve the issue, and we can do that work while the Oracle Linux operating system prevents actions that would disrupt customer services, expose data in memory, modify audit configuration, or become root.”
The second level of privileges, service update/restart, permits Oracle staff to update the infrastructure software on the service and reboot servers, and it prevents access to the hypervisor. This type of access gives an advantage making it easy for Oracle to perform continuous integration and continuous delivery (CI/CD) of software updates and cloud automation functionality while helping to protect customer services from disruptions and unauthorized access.
The third level of privileges permits hypervisor access, which can be necessary to solve exception conditions like configuration errors that disrupt customer services. Jeff further explains, “Sometimes we need to fix things in the customer VMs, and when we do that, we need to be able to access the hypervisor and customer VM. The important part about our hypervisor access profile is that is doesn’t permit our operator to become root or modify the audit service. This means you can still have confidence that the audit logging, your Detective control, is working, and you still can know that the chroot jail prevents the Oracle operator from becoming root.”
Jeff says, “In come cases, Oracle needs full access (root) to fix the problem. With Operator Access Control, Oracle requests full access with a detailed description of why this is needed and what Oracle plans to do, and then the customers have control to permit that access when they are ready.” Once the customer grants full access, there is a clear path as to what was performed through the Detective controls, and Responsive controls for the customer should the customer see anything suspect. Because the access is temporary and time-bound, the customer can take compensating measures so that it is done safely and securely within established maintenance windows.
Operator Access Controll provides customers important advantages when they need to gain the operational and financial benefits of the cloud in regulated environments. An important advantage is better Preventive control because of the integration of security into the Exadata. Jeff concludes, “It not only provides authentication and isolation control, it also uses the Exadata Engineered system architecture to fence off the operator’s lateral motion within the Exadata infrastructure to mitigate the risks of things like, reboots to servers, access to hypervisors, customer networks, and finally access to the root account.” In summary, Preventive controls limit the scope of actions an Oracle Cloud Ops staff can take, such as if, and when, they can log into the infrastructure, how long they can access the infrastructure, the command they can run, and the files and devices they can access.
To learn more: Oracle Exadata Cloud@Customer Operator Access Control Tech Brief