Foundational Security in Oracle Cloud Infrastructure
Oracle is pushing its motto for a while now, that is, to put customers and security first. In accordance with the endeavor, Oracle Cloud Infrastructure (OCI) customers today do not only get the industry-leading, automatized, architected-in, and always-on security across their databases, data, applications, networks, and systems, however, they also get it in the most simplified, prescriptive, and easy-to-use form.
The Difference Between 1st and 2nd Generation Cloud
Security on 1st Generation Cloud - Others
Built to offer virtual machines (VMs), with the ability to be networked inside a software-defined Layer 3 (L3).
Hypervisor plays critical role, however, receives no protection.
Highly vulnerable hardware due to lack of foundational security.
Extremely easy for rogue users to get in and infect the hardware to access new customers’ workloads.
Lacking security innovations like Root-of-Trust, storage and network virtualization, and cloud control computer.
Too many responsibilities on the customers, yet too much to lose.
Security on 2nd Generation Cloud - OCI
Bare metal engineered instances built for affording security against the modern-day threats.
Strict isolation; storage/network virtualization
Secured hardware, right from the BIOS and baseboard management controller (BMC) tier.
Eclypsium issue eliminated – i.e., no more threats of malware implants in the firmware.
Jampacked with security innovations such as Root-of-Trust, cloud control computer, security zones, Oracle Cloud Guard, Oracle Data Safe, etc.
Off box virtualization; complements to hardware reuse best practices; only the prescribed measures to be taken by customers.
1st generation cloud leveraged by most cloud service providers:
The 1st generation clouds are built to extend virtual machines (VMs) via a software-defined Layer 3 (L3) network. A hypervisor plays the leading role in enforcing the multi-tenancy security isolation, on top of implementing the privileged cloud operations by communicating with the cloud control plane. These privileged operations comprise packet encapsulation/decapsulation, block storage processing, etc.
The cloud control plane, on the other hand, is responsible for operations orchestration for customer commands implementation.
Despite the cardinality of the hypervisor and the control plane, they share the processor, server, and storage resources with non-trusted customer VMs. And the security disadvantage of the 1st generation cloud significantly lies there, i.e., in the faulty configurations that jeopardize the hypervisor’s security, and thereby inviting a potentially massive blast radius abused by malicious/infected entities to break into customer resources.
Oracle Cloud Infrastructure’s 2nd generation cloud:
The 2nd generation cloud on which the Oracle Cloud Infrastructure (OCI) is built, is designed to neutralize most security vulnerabilities attributable to the 1st generation clouds.
OCI enables customers to easily provision bare metal instances—featuring purely customer-controlled and single-tenant accessibility to the physical server—via the console and APIs. And, unlike the 1st generation cloud services, no codes/components other than the customer-controlled ones can run on the OCI’s bare metal instances. Not even those managed by Oracle.
It is simply because Oracle is the original device manufacturer (ODM) of their purpose-built, OCI server motherboards along with the firmware running on them. And they understand that the first step in building truly robust cloud security is to successfully restrict their own access. Plus, Oracle also has massive, dedicated teams for embedding security innovations into their hardware, such as the Root-of-Trust (RoT), and off-box virtualization.
Root-of-Trust in Oracle Cloud Infrastructure Security
This part deserves elaboration. The Root-of-Trust security feature in Oracle cloud means full access to the physical server for customers to reconfigure/modify the firmware and optimize support for their workloads. However, this security capability also comes with a risk of rogue customers leaving behind persistent firmware malware, i.e., UEFI BIOS malware, or NVMe drive malware. Oracle Cloud Infrastructure’s RoT feature contains this security threat by installing last-known-good images of all firmware on the server during provisioning to new customers.
Besides, the multiple storage chips on OCI—such as fused ROMs, SPI for BMC and BIOS firmware, DRAM, and EPROM PCIe peripheral like NVMe flash memory; all chips categorized under Guaranteed Immutable, Persistent and Mutable, and Guaranteed Ephemeral—also preserve the secured condition across OCI’s Intel and Arm servers.
Cloud Control Computer in Oracle Cloud Security
Another foundational security feature in Oracle Cloud Infrastructure is the cloud control computer that involves bespoke hardware directly attached to Oracle cloud servers running customer applications. All the traffic originating from the applications is sent/received via the server’s network interface card (NIC), streaming through the cloud control computer executing the OCI control plane code. However, please note that the cloud control computer is inaccessible from customer applications because of the configurations, and hence customers do not notice the additional leap in their network circuit.
The cloud control computer in OCI offers a virtualized network interface card (VNIC) connected to customer bare metal and VMs. The VNICs are categorized into subnets inside customers’ software-defined network (a.k.a. the OCI virtual cloud network [VCN]). Cloud control computer preserves the condition of all VNICs inside a customer’s VCN, along with the network rules prerequisite for routing packets across VNICs.
Even after taking part in these many crucial operations, the cloud control computer further extends the following security advantages:
- It speculates every packet from instances in public and private VCNs and only lets the legitimate traffic to go to each VCN. By any chance, if the public customer attempts to trick the source of an IP address to get into the instances in private VCN, the cloud control computer quickly identifies the intent and tosses the packets.
- It enforces inbound/outbound network security ACLs from the customers for the VCNs. Irrespective of any security issue in customer instances, the ACLs implementation by the cloud control computer remains intact.
- It offers robust isolation amongst customer VCNs and OCI by permitting only the white-listed traffic to reach the control-plane network.
Oracle Cloud’s Foundational Security in Action
Upon OCI hardware’s arrival at one of the Oracle’s data centers, a deep wiping process is initiated for it. The process confirms that the server is in pristine condition, with all the mutable storage discarded and reinitialized. After it is confirmed that the hardware has achieved that stage, Oracle systems begin allocating the capacity either for the customers or for production use. Most significantly, the series of procedures involve reinitializing the cloud control computer that offers the network virtualization for Oracle cloud. The system is thereafter locked down and made ready for customer use.
When a customer asks for a host from Oracle’s Console, OCI automatedly chooses and allocates the host to the customer. Information pertaining to resources is accessible to the host, e.g., storage or network virtualization, and is relayed to the cloud control computer. Upon the successful configuration and provisioning of the bare metal hardware and the cloud control computer for matching customer’s specifications, the OCI control plane orders the host to boot and start running the customer workload.
While the customer has all the controls on the system, the cloud control computer extends the resources the customer needs and simultaneously secures the customer and OCI from threats or rogue users. After the customer is finished with using a system, Oracle instantly repeats the wiping process along with firmware initialization via the RoT hardware. This assists in ensuring that the customer data is completely discarded from the system and is inaccessible even to OCI. In the following step, the system is made ready for the new deployment.
Also, when the hardware turns obsolete or affected, it is simply decommissioned. As a segment of the decommissioning, the hardware holding customer data, such as the storage devices, are mechanically destroyed inside the OCI data center, followed by ticketing the destroyed hardware for tracking, and the final review of the process is initiated.
