1 Introduction to Oracle Private Cloud Appliance Security

The Oracle Private Cloud Appliance is an engineered system that combines customer-premise-based hardware and preloaded software with a cloud component that runs entirely within the customer data center and on-premises network. Although there is no Oracle Cloud Infrastructure account involved, Oracle Private Cloud Appliance offers core Oracle Cloud Infrastructure services, and is fully compatible with Oracle Cloud Infrastructure services such as Compute, Network, Block Volume Storage, Object Storage, File System Storage, Identity and Access Management, and some other smaller or less visible elements. Because Oracle Private Cloud Appliance is disconnected, it also has its own control plane implementation, known as the Service Enclave.

This engineered system is installed by Oracle, which provides a level of security independent of local practices. However, this also requires the system administrators to understand exactly what is provided as a security baseline. Then the administrators can adjust security practices and configurations to achieve the desired level of security needed for their specific circumstances.

Product Security Overview

Product Security Overview

The core security components of the Oracle Private Cloud Appliance are layered. The three layers of the Oracle Private Cloud Appliance are:

• Infrastructure - This is the physical rack hardware installed on the customers premises. Some security-related tasks are performed at this basic level when the system is installed.

• Service Enclave - This is the part of the system where the appliance infrastructure is controlled. Access to this enclave is closely monitored and restricted to privileged administrators. The Service Enclave runs on a cluster of three management nodes, and many security-related tasks are performed at this level.

• Compute Enclave - The Compute Enclave, designed for compatibility with Oracle Cloud Infrastructure, is where workloads are created, configured and hosted by users or groups and where cloud resources such as compute instances, networks, and storage are controlled.

The Oracle Private Cloud Appliance follows the same basic security principles as other OracleOracle products. These principles are:

• Authentication: Authentication is how a user is identified, typically through confidential information such as user name and password, or shared keys. All components use authentication to ensure that users are who they say they are. By default, local user names and passwords are used for authentication. Shared key-based authentication is also available.

• Authorization: Administrators configure user or group privileges to resources along with the level of access allowed to the resources. Personnel can only access the resources with the level of access that has been given to them. Users with administrative privileges can authorize users and groups with one or more types of access (inspect, read, use, manage) to resources (all-resources, instance-family, and so on).

• Auditing: Auditing maintains a record of user activity at the various layers of the Oracle Private Cloud Appliance. Audit records exist for the Service Enclave, Compute Enclave, and for the infrastructure. Using audit records, an administrator is able to associate a particular user with a change that occurred in one or more components in the system. Monitor audit records to ensure users in the layers are properly accessing and using components and monitoring for excessive or insufficient resource privileges for users. Audit records can also identify unexpected system usage patterns that could identify denial of service attempts, attempts to access services through probing attacks of the boundaries or misuse of resources that resulted in data loss or unexpected resource modifications.

• Accounting: Accounting lets administrators track inventories of hardware and cloud resources. Hardware assets are tracked through serial numbers whereas cloud resources are tracked through Oracle Cloud IDs (OCIDs). For hardware components, Oracle part numbers are electronically recorded on all cards, modules and mother boards. These can be used for inventory or for association with issues reported to Oracle. Cloud resources tracked by OCIDs can be monitored by administrators to track usage and resource consumption.

When applied properly, the above security principles allow:

• Survivability of Mission-Critical Workloads - Oracle Private Cloud Appliance prevents or minimizes the damage caused from accidental and malicious actions taken by internal users or external parties. This is accomplished by security testing of components, checking protocols for vulnerabilities, and verifying software continuity even during security breaches.

• Defense in Depth to Secure the Operating Environment - Oracle Private Cloud Appliance employs multiple, independent, and mutually-reinforcing security controls to help organizations create a secure operating environment for their workloads and data. All levels of the system are protected by an array of security capabilities.

• Least-Privilege Access for Services and Users - Oracle Private Cloud Appliance promotes the use of security policies that ensure that applications, services, and users have access to the capabilities that they need to perform their tasks. However, it is equally important to ensure that access to unnecessary capabilities, services, and interfaces are limited. Users and administrators are confined to their particular areas of concern.

• Accountability of Events and Actions - Oracle Private Cloud Appliance offers detailed audit trails at each layer as well as controls to help account for resources. This helps an administrator detect and report incidents as they are occurring (such as a denial of service attack) or after they occurred if it was not preventable (through traceability through audit logs to resulting changes to resources).

• Understanding of Operating System Security - The operating system requires stringent security during patches and updates to ensure the integrity of the operating system at all times. This is possible by enforcing security policies, limiting network access, and monitoring all operating-system-level activities.

Security Planning

Security cannot be added onto a product like a new software feature or parameter adjustment.

Some categories and examples of the kinds of things to consider during this initial product installation planning are:

• Networking: Virtual and physical interfaces, bridged and routed

• User Access: Users and groups, what their role is, and what resources they will access to inspect, read, use or manage

• Password rules: length and character requirements, other characteristics

• Cryptographic algorithms: allowed or mandated, usage guidelines

• Patch or update process security: limitations, roles allowed to execute procedures

This is not an exhaustive list. The more things that can be planned ahead of time, the better.

Basic Security Considerations

These principles are fundamental for securing the product:

• Keep software up-to-date. This includes the latest product release and any patches that apply to it. For more information, see Oracle Private Cloud Appliance Installation Guide and Oracle Private Cloud Appliance Patching Guide.

• Limit privileges wherever possible. Give users only the access necessary to perform their work. Review user privileges periodically to determine relevance to current work requirements. For more information, see Oracle Private Cloud Appliance Concepts Guide.

• Monitor system activity. Establish who has access to which system components, and how often, and monitor those components.

• Learn about and use Oracle security features.

• Use best practices for security.

Customer Security Responsibilities

The customer is always responsible for securing aspects of the system that are under the customer's direct control. These responsibilities include:

• Information and Data: The customer always retains control over information and data. The customer controls how and when this data is used. The Cloud provider (Oracle) has zero visibility into customer data, and all data access is under the customer's control by design.

• Application Logic and Code: Regardless of how Cloud resources are spun up, the customer secures and controls the customer's proprietary applications during the entire application life cycle. This includes securing code repositories from malicious misuse or intrusion, application build testing during the development and integration process, ensuring secure production access, and maintaining the security of any connected systems.

• Identity and Access: The customer is always responsible for all aspects of identity and access management (IAM). This includes authentication and authorization mechanisms, any single sign-on (SSO) access, multi-factor authentication (MFA), access keys, certificates, the user creation processes, and password management.

• Platform and Resource Configuration: When cloud environments spin up, the customer controls the operating environment. How control is maintained over those environments varies, based on whether instances are server-based or serverless (PaaS). A server-based instance requires more hands-on control over security, including OS and application hardening, maintaining OS and application patches, and so on. Server-based instances in the cloud behave like physical servers, and function as an extension of the customer's data center. For serverless resources, the provider’s control plane gives the customer access to the setup of the configuration. In all cases, the customer is responsible for knowing how to configure customer instances in a secure manner.

  Additionally, the customer maintains responsibility for securing everything in the customer organization that connects with the cloud. This includes:

  • The on-premises infrastructure stack and user devices.

  • Customer-owned networks and applications.

  • The communication layers that connect your users, both internal and external, to the cloud and to each other.

  The customer also needs to set up monitoring and alerting for security threats, incidents, and responses for domains that remain under customer control.

A Note on Auditing

Good auditing practices require a firm separation of duties. This separation makes it easier, if issues with changes are causing problems, to determine the following:

• Who made the change? (More than information that "root" made the alteration.)

• When was the change made? (An adequate log retention period is important.)

• What was the purpose of the change? (If not malicious, the change was made for a reason.)

The main point of the audit process is to allow personnel to move forward in a better way to implement the changes needed.