June 3, 2022

Keeping your Oracle Cloud Infrastructure Secure (Part 1): Compute Instances

In recent years, migration to the cloud has been a priority for organizations, especially for those looking to drive digital transformation. In this sense, it is common to find a lot of content on how to keep the security of your account and services on Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform (GCP), but unfortunately the same is not true for other public cloud providers like an Oracle Cloud Infrastructure (OCI).

To help alleviate this shortage, we will publish a series of blog posts, using practical and didactic examples, about the minimum precautions that should be taken when configuring resources and services on OCI.

Hardening Compute Instances

Most companies that migrate to the cloud do so in Lift and Shift model, also known as rehosting. In essence reallocating of the on-premises infrastructure to instances in the cloud, without significantly modifying the architecture.

It is important to note that this Infrastructure as a Service (IaaS) model is a shared responsibility between the customer and the cloud service provider (Figure 1: Shared Responsibility Security Model). Operating system update routines, backups and encryption, access management, identity, application vulnerabilities, for example, are customer responsibilities.

An important part of this migration is the Oracle Instances setup process, a resource that “allows you provision and manage computing hosts, known as instances. You can create instances as needed to meet your compute and application requirements. Once you’ve created an instance, you can safely access it from your computer, restart it, attach and detach volumes, and terminate it when you’re done.”

During the creation of your computational instance, some points related to your security will be suggested by the Oracle console itself. Make sure you select enable the following options:

Secure Boot:
- It is a Unified Extensible Firmware Interface (UEFI) feature that prevents unauthorized bootloaders and operating systems from booting. Secure Boot uses checksums and cryptographic signatures to prevent malicious code from being loaded and executed early in the boot process, before the operating system is actually loaded.
- Each program loaded by firmware includes a signature and a checksum that is validated by the firmware before the program runs. When enabled, Secure Boot stops all attempts to run an untrusted program, effectively preventing any unexpected or unauthorized code from running in the UEFI-based environment.
Measured Boot:
- It is complementary to Secure Boot. Improves boot security by taking and storing measurements of boot components such as boot loaders, drivers, and operating systems. Bare metal instances do not support Measured Boot.
Trusted Platform Module (TPM):
- It is used to securely store boot measurements. It is a hardware-based security chip that provides attestation and authentication of data and security through the use of secure, shielded locations.

Networking

After the setup step, it is necessary to define a Security Group. It is intended to control the ingress and egress network traffic of the instance, where you can configure specific ports and resources to be allowed.

Ideally, you create or use a specific Security Group to meet your needs. For example, if you have a specific group of instances that run the RDP (Remote Desktop Protocol) service, you should create a Security Group and limit the connections to this service to a narrow set of allowed source IP address.

The Networking Service has numerous other configurations and because of that we will dedicate another publication exclusively to this subject.

Authentication.

It’s also critical to correctly configure your instance’s authentication mechanism. You must use SSH (Secure Shell) key pairs, generated specifically for the instance in question. Authentication by login and password, though allowed by OCI, should be avoided to prevent attacks such as password spraying.

Management

In the Management step, we need to pay attention to the following points:

The Instance Metadata (IMDS) feature in version 1 does not support any authentication features, so it is recommended to use version 2;
Oracle has resources for the execution of vulnerability scanning, which can be configured through the Oracle Cloud Agent. It is an interesting feature to have enabled, since the Shared Responsibility Security Model, states that the management of vulnerabilities in the responsibility of the customer.

Boot volume

We will dedicate a specific blog post to talk about features in the Block Storage section. For now, we would like to point out that it is essential that the “Use in-transit encryption” feature is enabled, to ensure data in transit between the instance, boot volume, and block volumes is encrypted.

Zanshin

It’s not reasonable to expect your employees, or those from your third parties, to know and remember every single security-relevant best practice or configuration option in OCI or any other cloud provider. That is we created Zanshin, a SaaS platform that allows companies to easily share information and cooperate with their internal teams and business units and third parties to manage security risk. Zanshin connects companies and their value chains, promoting transparency and responsible handling of risks associated with cybersecurity and privacy.

Written by Heitor Gouvea