Oracle Cloud Infrastructure Documentation

Security Best Practices

This guide provides actionable guidance and recommendations to Oracle Cloud Infrastructure customers for securely configuring Oracle Cloud Infrastructure services and resources. Understanding Oracle Cloud Infrastructure services and their security features is an essential prerequisite before reading. As a prerequisite, Oracle recommends that you become familiar with security of services. For more information, see Oracle Cloud Infrastructure Security Guide.

Security of an Oracle Cloud Infrastructure tenancy is based on a combination of factors, all of which must be thought through and securely configured. From a practical perspective, take a hierarchical view of Oracle Cloud Infrastructure tenancy security configuration, where we start with addressing the foundational security issues. The following steps provide a roadmap of high-level guidelines to follow when configuring security of a tenancy, where we provide a link to a section enumerating detailed security guidance related to each step.

  • User authentication and authorization: The initial step in securely configuring a The root compartment that contains all of your organization's compartments and other Oracle Cloud Infrastructure cloud resources. is to create mechanisms for authenticating users and authorizing users to access tenancy resources in a least-privilege manner. This step comprises creating Oracle Cloud Infrastructure Identity and Access Management (IAM) users, creating IAM groups, formulating authentication mechanisms (for example, Console access using password, API access using API keys, and auth token for object store) for the IAM users created, grouping customer tenancy resources into logical groups using compartments, and formulating IAM security policies authorizing access of IAM groups to tenancy or compartment resources. For enterprises, federating their on-premises users and groups to their tenancy is an important consideration. IAM allows you to create users, groups, security polices, and federation mechanisms. Security recommendations for configuring IAM are provided in the IAM section.
  • Network security architecture: After formulating IAM user authentication and authorization, a next step is creating a network security architecture for securely running the customer applications and storing their data in a tenancy. All the customer's compute and storage resources are enclosed in a virtual cloud network (VCN) created for the customer. VCN is a software-defined network, resembling the on-premises physical network used by customers to run their workloads. Formulating a VCN security architecture includes tasks such as:
    • Creating VCN subnets for network segmentation
    • Formulating VCN and load balancer firewalls using VCN security lists
    • Using load balancing for high-availability and TLS
    • Determining type of VCN external connectivity whether internet, on-premises network, peered VCN, or combination of these
    • Using virtual network security appliances (for example, next-generation firewalls, IDs)
    • Creating DNS zones and mappings. An important security consideration in load balancers is using customer Transport Layer Security (TLS) certificates to configure TLS connections to customer's VCN. Security recommendations for VCN are provided in the Networking section.
  • Compute instances security configuration: Within a customer VCN, the customer applications run on compute instances including Bare Metal (BM) instances, Virtual Machine (VM) instances and GPUs. Compute instances are the basic compute building blocks. Bare metal instances have no Oracle-managed software running on them, with the result that the instances and data stored (in memory and local drives) are completely controlled by the customer. VM instances are architected with least privilege mechanisms, and with corporate industry-leading hypervisor security best-practices. Depending on their security and performance requirements, customers have a choice of using BM and VM instances, to run their application workloads in their tenancy. It is imperative to securely configure compute instances, to maintain security of customer applications running on them. Recommendations related to instance security configuration with respect to instance firewalls, instance credential management, entropy, security patching, and security logging and monitoring are provided in the Compute section.
  • Data storage security configuration: Depending on the type of data and access required, customers can store data in local drives (attached to compute instances), remote block volumes, object store buckets, databases, or file storage in their tenancy. To handle these data storage requirements, Oracle Cloud Infrastructure offers multiple data storage services such as Block Volume, Object Storage, Database, and File Storage. In order to meet their data security requirements, customers need to formulate a tenancy data storage architecture for storing their data in their tenancy, and securely configure the storage services used. Compliance and regulatory requirements are an important factor in determining an appropriate data storage security architecture. Recommendations related to storage services security configuration are available in Block Volume, Object Storage, Database, and File Storage sections. In addition to these services, customers need to consider security of data stored ephemerally in compute instance memory (DRAM) and local NVMe storage.

API Audit logs record calls to APIs (for example, through the Console, SDKs, CLIs, and custom clients using the APIs) as log events. The API Audit logs are always on by default and can't be turned off. These logs are available to customers for 90 days, with retention period configurable up to 365 days. Information in the API Audit logs show what time API activity occurred, the source of the activity, the target of the activity, what the action was, and what the response was. Oracle recommends that customers periodically review the OCI API Audit logs to ensure they are in accordance with actions they took on their tenancy resources.

For service-specific best practices, see the following topics: