Security Guide for Oracle Exadata Database Service on Dedicated Infrastructure

This guide describes security for an Exadata Cloud Infrastructure. It includes information about the best practices for securing the Exadata Cloud Infrastructure.

Part 1: Security Configurations and Default Enabled Features

Responsibilities

Exadata Cloud Infrastructure is jointly managed by the customer and Oracle.

The Exadata Cloud Infrastructure deployment is divided into two areas of responsibility:

Customer accessible services: components that the customer can access as part of their subscription to Exadata Cloud Infrastructure

  • Customer accessible virtual machines (VM)
  • Customer accessible database services

Oracle Managed Infrastructure: components that are owned and operated by Oracle to run customer accessible services

  • Power Distribution Units (PDUs)
  • Out of band (OOB) management switches » InfiniBand switches
  • Exadata Storage Servers
  • Physical Exadata database servers
  • Datacenter security which hosts Exadata Servers with customer information

Customers control and monitor access to customer services, including network access to their VMs (through OCI Virtual Cloud Networks and OCI Security Lists), authentication to access the VM, and authentication to access databases running in the VMs. Oracle controls and monitors access to Oracle Managed Infrastructure components and physical server security. Oracle staff are not authorized to access customer services, including customer VMs and databases except where customers are unable to access the customer VM. See the Exadata Cloud Service Security Controls document, https://www.oracle.com/a/ocom/docs/engineered-systems/exadata/exadata-cloud-service-security.pdf, Exception Workflows .

Customers access Oracle databases (DB) running on Exadata Cloud Infrastructure via client and backup VCNs to the databases running in the customer VM using standard Oracle database connection methods, such as Oracle Net on port 1521. Customer’s access the VM running the Oracle databases via standard Oracle Linux methods, such as token based ssh on port 22.

Infrastructure Security

Secutrity features offered by Exadata Cloud Infrastructure.

  • Oracle Cloud Physical Security

    Oracle Cloud data centers align with Uptime Institute and Telecommunications Industry Association (TIA) ANSI/TIA-942-A Tier 3 (99.982% Availability) or Tier 4 (99.995% Availability) standards and follow a N2 ('N' stands for Need) redundancy methodology for critical equipment operation. Data centers housing Oracle Cloud Infrastructure services use redundant power sources and maintain generator backups in case of widespread electrical outage. Server rooms are closely monitored for air temperature and humidity, and fire-suppression systems are in place. Data center staff are trained in incident response and escalation procedures to address security and availability events that may arise. For more information see Oracle Cloud Infrastructure Security Guide. For further details on Oracle Cloud Infrastructure Data Center compliance, and see Oracle Cloud Compliance.

  • Operator access to customer systems

    Oracle access protocols include:

    • Physical access to facilities is limited to certain Oracle employees, contractors, and authorized visitors.
    • Oracle employees, subcontractors, and authorized visitors are issued identification cards that must be worn while on Oracle premises.
    • Visitors are required to sign a visitor’s register, be escorted and/or observed when they are on Oracle premises, and/or be bound by the terms of a confidentiality agreement with Oracle.
    • Security monitors the possession of keys/access cards and the ability to access facilities. Staff leaving Oracle’s employment must return keys/cards and key/cards are deactivated upon termination.
    • Security authorizes all repairs and modifications to the physical security barriers or entry controls at service locations.
    • Oracle use a mixture of 24/7 onsite security officers or patrol officers, depending on the risk/protection level of the facility. In all cases officers are responsible for patrols, alarm response, and recording of security incidents.
    • Oracle has implemented centrally managed electronic access control systems with integrated intruder alarm capability. The access logs are kept for a minimum of six months. Furthermore, the retention period for CCTV monitoring and recording ranges from 30-90 days minimum, depending on the facility’s functions and risk level.
  • Hypervisor Customer Isolation

    The hypervisor is the software that manages virtual devices in a cloud environment, handling server and network virtualization. In traditional virtualization environments, the hypervisor manages network traffic, enabling it to flow between VM instances and between VM instances and physical hosts. This adds considerable complexity and computational overhead in the hypervisor. Proof-of concept computer security attacks, such as virtual machine escape attacks, have highlighted the substantial risk that can come with this design. These attacks exploit hypervisor complexity by enabling an attacker to “breakout” of a VMinstance, access the underlying operating system, and gain control of the hypervisor. The attacker can then access other hosts, sometimes undetected. Oracle Cloud Infrastructure reduces this risk by decoupling network virtualization from the hypervisor. We’ve implemented network virtualization as a highly customized hardware and software layer that moves cloud control away from the hypervisor and host, and puts it on its own network. This hardened and monitored layer of control is what enables isolated network virtualization. Isolated network virtualization reduces risk by limiting the attack surface. Even if a malicious actor succeeds with a VM escape attack on a single host, it’s designed so they can’t reach other hosts in the cloud infrastructure. The attack is effectively contained to the one host. Isolated network virtualization is implemented in every data center in every region, which means that all Oracle Cloud Infrastructure tenants benefit from this reduced risk.

    Figure 6-1 Isolated Network Virualization Reduces Risk in Oracle Generation 2 Cloud

    Description of Figure 6-1 follows
  • Multitenant Security

    Consistent with our security philosophy of Defense in Depth, Multitenant has a comprehensive isolation architecture.

    There are four major categories to this, with several important features in each category.

    1. Access Control Mechanism
    2. Prevent Unauthorized Admin Access
    3. Protect from direct access to Data Files
    4. Resource Isolation

    Figure 6-2 Multitenant’s Comprehensive Isolation Architecture

    Description of Figure 6-2 follows

Guiding Principles Followed for Security Configuration Defaults

  • Defense in Depth Exadata Cloud Infrastructure offers a number of controls to ensure confidentiality, integrity, and availability throughout the service.

    First, Exadata Cloud Infrastructure is built from the hardened operating system image provided by Exadata Database Machine (https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/exadata-security-overview.html). This secures the core operating environment by restricting the installation image to only the required software packages, disabling unnecessary services, and implementing secure configuration parameters throughout the system.

    In addition to inheriting all the strength of Exadata Database Machine's mature platform, because Exadata Cloud Infrastructure provisions systems for customers, additional secure default configuration choices are implemented in the service instances. For example, all database tablespaces require transparent data encryption (TDE), strong password enforcement for initial database users and superusers, and enhanced audit and event rules.

    Exadata Cloud Infrastructure also constitutes a complete deployment and service, so it is subjected to industry-standard external audits such as PCI, HIPPA and ISO27001. These external audit requirements impose additional value-added service features such as antivirus scanning, automated alerting for unexpected changes to the system, and daily vulnerability scans for all Oracle-managed infrastructure systems in the fleet.

  • Least privilege

    Oracle Secure Coding Standards require software processes run at the minimum privilege level to implement their functionality.

    Each process and daemon, must run as a normal, unprivileged user unless it can prove a requirement for a higher level of privilege. This helps contain any unforeseen issues or vulnerabilities to unprivileged user space and not compromise an entire system.

    This principle also applies to Oracle operations team members who use individual named accounts to access the Exadata Cloud Infrastructure for maintenance or troubleshooting. Only when necessary will they use the audited access to higher levels of privilege to solve or resolve an issue. Most issues are resolved through automation, so we also employ least privilege by not permitting human operators to access a system unless the automation is unable to resolve the issue.

  • Auditing and accountability

    When required, access to the system is allowed, but all access and actions are logged and tracked for accountability.

    Exadata Cloud Infrastructure audit logs are controlled by Oracle and used for security monitoring and compliance purposes. Oracle can share relevant audit logs with customers per Oracle Incident Response Practices and the Oracle Data Processing Agreement.

    Auditing capabilities are provided at all infrastructure components to ensure all actions are captured. Customers also have ability to configure auditing for their database and guest VM configuration and may choose to integrate those with other enterprise auditing systems.

  • Automating cloud operations

    By eliminating manual operations required to provision, patch, maintain, troubleshoot, and configure systems, the opportunity for error is reduced.

Security Features

  • Hardened OS image
    • Minimal package installation:

      Only the necessary packages required to run an efficient system are installed. By installing a smaller set of packages, the attack surface of the operating system is reduced and the system remains more secure.

    • Secure configuration:

      Many non-default configuration parameters are set during installation to enhance the security posture of the system and its content. For example, SSH is configured to only listen on certain network interfaces, sendmail is configured to only accept localhost connections, and many other similar restrictions are implemented during installation.

    • Run only necessary services:

      Any services that may be installed on the system, but not required for normal operation, are disabled by default. For example, while NFS is a service often configured by customers for various application purposes, it is disabled by default as it is not required for normal database operations. Customers may choose to optionally configure services per their requirements.

  • Minimized attack surface

    As part of the hardened image, attack surface is reduced installing and running only the software required to deliver the service.

  • Additional security features enabled (grub passwords, secure boot)

    • Leveraging Exadata image capabilities, ExaDB-D enjoys the features integrated into the base image such as grub passwords and secure boot in addition to many others.
    • Through customization, customers may wish to further enhance their security posture with additional configurations.
  • Secure access methods
    • Accessing database servers via SSH using strong cryptographic ciphers. Weak ciphers are disabled by default.
    • Accessing databases via encrypted Oracle Net connections. By default, our services are available using encrypted channels and a default configured Oracle Net client will use encrypted sessions.
    • Accessing diagnostics via Exadata MS web interface (https).
  • Auditing and logging
    • By default, auditing is enabled for administrative operations and those audit records are communicated to OCI internal systems for automated review and alerting when required.

Guest VM Default Fixed Users

Several user accounts regularly manage the components of Exadata Cloud Infrastructure. These users are required and may not be modified.

In all ExaDB-D machines, Oracle uses and recommends token-based SSH login.

There are three classes of users:

Default Users: No Logon Privileges

This user list consists of default operating system users along with some specialized users like exawatch and dbmsvc. These users should not be altered. These users cannot login to the system as all are set to /sbin/nologin.

In the list of users below, most are either standard Linux OS users or related to standard Linux packages except for the exawatch and dbmsvc users.
  • exawatch: The exawatch user is responsible for collecting and archiving system statistics on both the database servers and the storage servers
  • dbmsvc: User is used for Management Server on the database node service in Oracle Exadata System

NOLOGIN Users

bin:x:1:1:bin:/bin:/sbin/nologin
Daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/dev/null:/sbin/nologin
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
rpm:x:37:37::/var/lib/rpm:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
unbound:x:999:997:Unbound DNS resolver:/etc/unbound:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin
saslauth:x:998:76:Saslauthd user:/run/saslauthd:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin
smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin
chrony:x:997:996::/var/lib/chrony:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nslcd:x:65:55:LDAP Client User:/:/sbin/nologin
uucp:x:10:14:Uucp user:/var/spool/uucp:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
exawatch:x:1010:510::/opt/oracle.ExaWatcher:/sbin/nologin
sssd:x:996:508:User forsssd:/:/sbin/nologin
dbmsvc:x:2001:2001::/:/sbin/nologin
clamupdate:x:995:504:Clamav database update user:/var/lib/clamav:/sbin/nologin
Default Users WITH RESTRICTED SHELL Access

These users are used for accomplishing a defined task with a restricted shell login. These users should not be removed as the defined task will fail in case these users are deleted.

dbmmonitor password is set to a random string during deployment, which must change on first use.

Restricted Shell Users
dbmmonitor:x:2003:2003::/home/dbmmonitor:/bin/rbash
Default Users with Login Permissions

These privileged users are used for accomplishing most of the tasks in the system. These users should never be altered or deleted as it would have significant impact on the running system.

SSH keys are used for login by customer staff and cloud automation software.

Customer-added SSH keys may be added by the UpdateVmCluster method, or by customers directly accessing the customer VM and managing SSH keys inside of the customer VM. Customers are responsible for adding comments to keys to make them identifiable. When a customer adds the SSH key by the UpdateVmCluster method, the key is only added to the authorized_keys file of the opc user.

Cloud automation keys are temporary, specific to a given cloud automation task, for example, VM Cluster Memory resize, and unique. Cloud automation access keys can be identified by the following comments: OEDA_PUB, EXACLOUD_KEY, ControlPlane. Cloud automation keys are removed after the cloud automation task completes so the authorized_keys files of the root, opc, oracle, and grid accounts should only contain cloud automation keys while the cloud automation actions are running.

Privileged Users

root:x:0:0:root:/root:/bin/bash 
oracle:x:1001:1001::/home/oracle:/bin/bash 
grid:x:1000:1001::/home/grid:/bin/bash 
opc:x:2000:2000::/home/opc:/bin/bash 
dbmadmin:x:2002:2002::/home/dbmadmin:/bin/bash
  • root: Linux requirement, used sparingly to run local privileged commands. root is also used for some processes like Oracle Trace File Analyzer Agent and ExaWatcher.
  • grid: Owns Oracle Grid Infrastructure software installation and runs Grid Infastructure processes.
  • oracle: Owns Oracle database software installation and runs Oracle Database processes.
  • opc:
    • Used by Oracle Cloud automation for automation tasks.
    • Has the ability to run certain privileged commands without further authentication (to support automation functions).
    • Runs the local agent, also known as “DCS Agent” that performs lifecycle operations for Oracle Database and Oracle Grid Infastructure software (patching, create database, and so on).
  • dbmadmin:
    • The dbmadmin user is used for Oracle Exadata Database Machine Command-Line Interface (DBMCLI) utility.
    • The dbmadmin user should be used to run all services on the database server. For more information, see Using the DBMCLI Utility.

Default Security Settings: Customer VM

In addition to all of the Exadata features explained in Security Features of Oracle Exadata Database Machine, the following security settings are also applicable, to Exadata Cloud Infrastructureinstances.

  • Custom database deployment with non-default parameters.
    The command host_access_control is to configure Exadata security settings:
    • Implementing password aging and complexity policies.
    • Defining account lockout and session timeout policies.
    • Restricting remote root access.
    • Restricting network access to certain accounts.
    • Implementing login warning banner.
  • account-disable: Disables a user account when certain configured conditions are met.
  • pam-auth: Various PAM settings for password changes and password authentication.
  • rootssh: Adjusts the PermitRootLogin value in /etc/ssh/sshd_config, which permits or denies the root user to login through SSH.
    • By default, PermitRootLogin is set to no.
    • PermitRootLogin=without-password is required for the cloud automation to perform some lifecycle management operations, disabling root login will cause that service functionality to fail.
  • session-limit: Sets the * hard maxlogins parameter in /etc/security/limits.conf, which is the maximum number of logins for all users. This limit does not apply to a user with uid=0.

    Defaults to * hard maxlogins 10 and it is the recommended secure value.

  • ssh-macs: Specifies the available Message Authentication Code (MAC) algorithms.
    • The MAC algorithm is used in protocol version 2 for data integrity protection.
    • Defaults to hmac-sha1, hmac-sha2-256, hmac-sha2-512 for both server and client.
    • Secure recommended values: hmac-sha2-256, hmac-sha2-512 for both server and client.
  • password-aging: Sets or displays the current password aging for interactive user accounts.
    • -M: Maximum number of days a password may be used.
    • -m: Minimum number of days allowed between password changes.
    • -W: Number of days warning given before a password expires.
    • Defaults to -M 99999, -m 0, -W 7
    • --strict_compliance_only-M 60, -m 1, -W 7
    • Secure recommended values: -M 60, -m 1, -W 7

Default Processes on Customer VM

A list of the processes that run by default on the customer VM, also called DOMU, or Guest VM and Guest OS

  • Exadata Cloud Infrastructure VM agent:

    Cloud agent for handling database lifecycle operations.

    • Runs as opc user
    • Process table shows it running as a Java process with jar names - dbcs-agent-VersionNumber-SNAPSHOT.jar and dbcs-admin-VersionNumver-SNAPSHOT.jar.
  • Oracle Trace File Analyzer agent:

    Oracle Trace File Analyzer (TFA) provides a number of diagnostic tools in a single bundle, making it easy to gather diagnostic information about the Oracle database and clusterware, which in turn helps with problem resolution when dealing with Oracle Support

    • Runs as root user
    • Runs as initd demon (/etc/init.d/init.tfa)
    • Process tables show a Java application (oracle.rat.tfa.TFAMain)
    • Runs as root and exawatch users.
    • Runs as backgroud script, ExaWatcher.sh and all its child process run as a Perl process.
    • Process table shows as multiple Perl applications.ExaWatcher:
  • Database and GI (clusterware):
    • Runs as dbmsvc and grid users
    • Process table shows following applications:
      • oraagent.bin, apx_* and ams_* as grid user
      • dbrsMain, and Java applications - derbyclient.jar, weblogic.Server as oracle user.
  • Management Server (MS):

    Part of Exadata image software for managing and monitoring the image functions.

    • Runs as dbmadmin.
    • Process table shows it running as a Java process.
Guest VM Network Security

Table 6-28 Default Port Matrix for Guest VM Services

Type of interface Name of interface Port Process running

Bridge on client VLAN

bondeth0

22

sshd

1521

Optionally, customers can assign a SCAN listener port (TCP/IP) in the range between 1024 and 8999. Default is 1521.

Oracle TNS listener

5000

Oracle Trace File Analyzer Collector

7879

Jetty Management Server

bondeth0:1

1521

Optionally, customers can assign a SCAN listener port (TCP/IP) in the range between 1024 and 8999. Default is 1521.

Oracle TNS listener

bondeth0:2

1521

Optionally, customers can assign a SCAN listener port (TCP/IP) in the range between 1024 and 8999. Default is 1521.

Oracle TNS listener

Bridge on backup VLAN

bondeth1

7879

Jetty Management Server

Oracle Clusterware running on each cluster node communicates through these interfaces.

clib0/clre0

1525

Oracle TNS listener

3260

Synology DSM iSCSI

5054

Oracle Grid Interprocess Communication

7879

Jetty Management Server

Dynamic Port: 9000-65500

Ports are controlled by the configured ephemeral range in the operating system and are dynamic.

System Monitor service (osysmond)

Dynamic Port: 9000-65500

Ports are controlled by the configured ephemeral range in the operating system and are dynamic.

Cluster Logger service (ologgerd)

clib1/clre1

5054

Oracle Grid Interprocess communication

7879

Jetty Management Server

Cluster nodes use these interfaces to access storage cells (ASM disks).

However, the IP/ports 7060/7070 attached to the storage interfaces are used to access DBCS agent from the Control Plane server.

stib0/stre0

7060

dbcs-admin

7070

dbcs-agent

stib1/stre1

7060

dbcs-admin

7070

dbcs-agent

Control Plane server to domU

eth0

22

sshd

Loopback

lo

22

sshd

2016

Oracle Grid Infrastructure

6100

Oracle Notification Service (ONS), part of Oracle Grid Infrastructure

7879

Jetty Management Server

Dynamic Port 9000-65500

Oracle Trace File Analyzer

Note

TNS listener opens dynamic ports after initial contact to well known ports (1521, 1525).

Default iptables rules for Guest VM:

The default iptables are setup to ACCEPT connections on input, forward, and output chains.
#iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Compliance Requirements

PII ( Personally Identifiable Information ) This information is considered confidential and sensitive, and must be protected to prevent unauthorized use of personal information for the purposes of legal regulation, financial liability, and personal reputation.

You must configure a set of explicit rules to prevent Personally Identifiable Information (PII) from being displayed in your data.

The default Application Performance Monitoring rules hide PII in URLs by recognizing monetary values, bank-account numbers, and dates. However, the default rules only catch obvious PII and are not exhaustive. You must evaluate the default rules and further configure rules to ensure correct reporting in your environment and ensure that PII is not displayed in your data.

For more information, see Hide Personally Identifiable Information and Security and Personally Identifiable Information

Backup Retention

When you enable the Automatic Backup feature, the service creates daily incremental backups of the database to Object Storage. The first backup created is a level 0 backup. Then, level 1 backups are created every day until the next weekend. Every weekend, the cycle repeats, starting with a new level 0 backup.

If you choose to enable automatic backups, you can choose one of the following preset retention periods: 7 days, 15 days, 30 days, 45 days, or 60 days. The system automatically deletes your incremental backups at the end of your chosen retention period.

For more information, see Manage Database Backup and Recovery on Oracle Exadata Database Service on Dedicated Infrastructure

Audit Log Retention Period

The OCI Audit service provides records of API operations performed against supported services as a list of log events. By default, Audit service records are retained for 365 days.

For more information, see Audit Log Retention Period

Service Log Retention

Oracle Cloud Infrastructure services, such as API Gateway, Events, Functions, Load Balancing, Object Storage, and VCN Flow Logs emit service logs. Each of these supported services has a Logs resource that allows you to enable or disable logging for that service. By default, Log retention is 1 month, but it can be set until 6 months.

Logs groups can be used to limit access to sensitive logs generated by services using IAM policy. You don't have to rely on complex compartment hierarchies to secure your logs. For example, say the default log group in a single compartment is where you store logs for the entire tenancy. You grant access to the compartment for log administrators with IAM policy as you normally would. However, let's say some projects contain personally identifiable information (PII) and those logs can only be viewed by a select group of log administrators. Log groups allow you to put logs that contain PII into a separate log group, and then use IAM policy to restrict access to all but a few log administrators.

For more information, see Service Logs and Managing Logs and Log Groups

Default Database Security Configuration

Default database security features enabled and used:

  • Transparent Database Encryption (TDE) is used for database tablespaces created by Oracle Database Cloud tools.
    • CDB$ROOT: users tablespace is encrypted
    • PDBs: all tablespaces encrypted
    • Wallet password is provided during initial DB creation. Wallet passwords may be changed using dbaascli. Customers should change this password periodically.
  • Users in the database
    • No additional users are created in the database.
    • After DB creation, all DB users are locked except for SYS, SYSTEM and DBSNMP.
    • Auditing is enabled for the following operations:
      • DATABASE LINK
      • PUBLIC DATABASE LINK
      • PUBLIC SYNONYM
      • DROP ANY PROCEDURE
      • PROCEDURE
      • ALTER SYSTEM
      • TRIGGER
      • CREATE DATABASE LINK
      • ALTER DATABASE LINK
      • CREATE PROCEDURE
      • ALTER SYSTEM
      • CREATE TRIGGER
      • CREATE ANY TRIGGER
      • SELECT ANY DICTIONARY
      • DB VERSION_11_2: EXEMPT REDACTION POLICY
      • DB VERSION_12_1 or DB VERSION_12_2: BECOME USER
      • DB VERSION_12_1: SESSION
      • DBAASSECURE profile is created and it is set as default profile for database user account.
  • Native SQL*Net encryption for all network connections - Relevant sqlnet.ora parameters set in Exadata Cloud Infrastructure by default are:
    • SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)
    • SQLNET.ENCRYPTION_SERVER = requested
    • SQLNET.CRYPTO_CHECKSUM_SERVER = accepted
    • SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)
  • TCPS protocol offered for network connection to the database on port 2484 (wallet configured at /var/opt/oracle/dbaas_acfs/grid/tcps_wallets). Relevant sqlnet.ora parameters set in Exadata Cloud Infrastructure by default are:
    • SSL_CIPHER_SUITES = (SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
      SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
      SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 
      SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
    • WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))
    • SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS = TRUE
    • SSL_VERSION = 1.2
  • Remote listener registration - listeners run from GI home. Exadata Cloud Infrastructure deployments the Grid Infrastructure vresion speified in Oracle Support Document 2333222.1 (Exadata Cloud Service Software Versions). Exadata Cloud Infrastructure default configuration includes listener.ora parameter VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET combined with REMOTE_REGISTRATION_ADDRESS_<SCANLISTENER>=<value> to restrict remote listener registrations for security purposes.
  • OCI Vault integration - TDE encryption key may be stored in OCI Vault (a Key Management System). For more information and instructions to configure principals, vaults, etc. see Customer-Managed Keys in Exadata Cloud Infrastructure. Both private vs shared vault types are supported for Exadata Cloud Infrastructure OCI Vault integration. DB user authentication is not integrated with OCI Vault.

Default Backup Security Configuration

OS/VM backups:

Oracle does a full backup of guest VM weekly and maintains one or more backup copies. These backups are full disk snapshots of the guest VM (local OS filesystems, not ASM disk groups which reside on Exadata storage). This backup is triggered at a preset time every week. The backups are stored locally in the dom0. Customers can request Oracle to restore the guest VM image from the most recent backup by filing a My Oracle Support (MOS) Service Request (SR). Oracle cannot restore specific files from the image backup. Customers should perform file level backups in the guest VM if they require the ability to perform single-file restore.

Managed DB backups:

  • Weekly full backup (level 0)
  • Daily rolling incremental backup (level 1) on seven day cycle
  • Automatic backups daily at a specific time set during the database deployment creation process

Retention period for backups vary from 30 days (on Object Storage) to 7 days (on local storage)

Encryption:

  • Both Object Storage and local storage: All backups to cloud storage are encrypted.
  • Object Storage only: All backups to cloud storage are encrypted.

All backups can be configured via CP UI or CP API.

All backups are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption.

Operator Access to Customer System and Customer Data

Only automated tooling is permitted to access guest VM for purposes of lifecycle automation.

One specific use case is when guest VM is unable to boot. In this case, customers must provide permission to access the guest VM for recovery purposes. Details to handle this scenario are described in section "Exception Workflows" of Exadata Cloud Service Security Controls.

Customers control and monitor access to customer services, including network access to their guest VMs (through layer 2 VLANs and firewalls implemented in the guest VM), authentication to access the guest VM, and authentication to access databases running in the guest VMs. Oracle controls and monitors access to Oracle-managed infrastructure components. Oracle staff are not authorized to access customer services, including guest VMs and databases.

Compliance Requirements

PII ( Personally Identifiable Information ) This information is considered confidential and sensitive, and must be protected to prevent unauthorized use of personal information for the purposes of legal regulation, financial liability, and personal reputation.

You must configure a set of explicit rules to prevent Personally Identifiable Information (PII) from being displayed in your data.

The default Application Performance Monitoring rules hide PII in URLs by recognizing monetary values, bank-account numbers, and dates. However, the default rules only catch obvious PII and are not exhaustive. You must evaluate the default rules and further configure rules to ensure correct reporting in your environment and ensure that PII is not displayed in your data.

For more information, see Hide Personally Identifiable Information and Security and Personally Identifiable Information

Backup Retention

When you enable the Automatic Backup feature, the service creates daily incremental backups of the database to Object Storage. The first backup created is a level 0 backup. Then, level 1 backups are created every day until the next weekend. Every weekend, the cycle repeats, starting with a new level 0 backup.

If you choose to enable automatic backups, you can choose one of the following preset retention periods: 7 days, 15 days, 30 days, 45 days, or 60 days. The system automatically deletes your incremental backups at the end of your chosen retention period.

For more information, see Manage Database Backup and Recovery on Oracle Exadata Database Service on Dedicated Infrastructure

Audit Log Retention Period

The OCI Audit service provides records of API operations performed against supported services as a list of log events. By default, Audit service records are retained for 365 days.

For more information, see Audit Log Retention Period

Service Log Retention

Oracle Cloud Infrastructure services, such as API Gateway, Events, Functions, Load Balancing, Object Storage, and VCN Flow Logs emit service logs. Each of these supported services has a Logs resource that allows you to enable or disable logging for that service. By default, Log retention is 1 month, but it can be set until 6 months.

Logs groups can be used to limit access to sensitive logs generated by services using IAM policy. You don't have to rely on complex compartment hierarchies to secure your logs. For example, say the default log group in a single compartment is where you store logs for the entire tenancy. You grant access to the compartment for log administrators with IAM policy as you normally would. However, let's say some projects contain personally identifiable information (PII) and those logs can only be viewed by a select group of log administrators. Log groups allow you to put logs that contain PII into a separate log group, and then use IAM policy to restrict access to all but a few log administrators.

For more information, see Service Logs and Managing Logs and Log Groups

Break Glass Procedure for Accessing Customer's Guest VM

There are situations where some problems can only be resolved by Oracle logging into the customer guest VM.

Below are situations where customer's guest VM access is require and recommended procedures for accessing guest VM:

  1. Situations where the starter database is not yet created and customer do not have ssh access to their guest VM yet. An example would be SR opened by customer to troubleshoot why customer is unable to create a starter database. In this situation, customer never had access to guest VM and no database have yet been created and hence no customer data exists in guest VM.

    As per the security policy associated with ExaDB-D service, Oracle personnel are prohibited to access customer guest VM without customer’s explicit permission. To comply with this policy, Oracle requires to get Customer permission to access guest VM by asking the following question.

    “In order for Oracle to resolve the issue described in this SR, we need customer’s explicit permission allowing us to login to customer guest VM. By giving us explicit permission to access guest VM, you are confirming that there is no confidential data that is stored in customer guest VM or associated databases and customer security team is authorizing Oracle to have access to customer guest VM in order for Oracle to help fix this issue. Do I have your explicit permission to access guest VM?"

    After affirmative response by customer, Oracle support staff can login to customer guest VM to resolve the issue.

  2. Situations where a number of databases exist in customer system and customer have access to guest VM but now support needs to login to guest VM to resolve one of the many situations

    We have encountered ( Nodes doesn’t start because of changes on guest VM, eg. Non-existing mounts in fstab, need to run fsck, Hugepage / sysctl conf modification or lvm backup not completed successfully, fstab has wrong entries for non-existing mounts, customer changed the sshd configurations or permissions in /etc/ssh/sshd_config file, etc.) or simply because customer wants Oracle to help resolve the issue they are facing.

    This case is more serious than the first one as there could be some sensitive data in customer guest VM file system or database. In this case, our support staff will be required to ask the customer to open a new explicit SR specifically to get this permission with the following SR title and content.

    As per the security policy associated with ExaDB-D service, Oracle personnel are prohibited to access customer guest VM without customer’s explicit permission. For Oracle to comply with this policy, We are required to ask you to open a new SR with exact language as shown below granting Oracle an explicit permission to access guest VM.Please note any modification to the language below may delay resolution of your SR.

    New SR Title: SR granting Oracle explicit permission to access DomU of ExaDB-C@C with AK serial number AK99999999

    New SR Content: We are opening this SR to grant explicit permission to Oracle to access our DomU in order for support to help resolve issue described in SR# 1-xxxxxxxx.

    We acknowledge that by providing this permission, we understand that Oracle will have access to ALL FILES in DomU and agree that there are no confidential

    files stored in any of the file systems in DomU. In addition, we also agree that customer security team has authorized Oracle to have access to customer DomU

    in order to resolve the issue described in the above SR.

    After affirmative response by customer in the above SR, Oracle support staff can login to customer guest VM to resolve the issue.

Part 2: Additional Procedures for Updating Security Posture

Customer Responsibilities

A list of Oracle Cloud Operations responsibilities and customer responsibilities for various operations by components

Table 6-29 Oracle Cloud Ops and Customer Responsibilities for various operations

Operations Oracle Cloud Ops responsibilities for ORACLE CLOUD PLAFTORM Customer responsibilities for ORACLE CLOUD PLAFTORM Oracle Cloud Ops responsibilities for CUSTOMER / TENANT INSTANCES Customer responsibilities for CUSTOMER / TENANT INSTANCES
DATABASE DEPLOYMENT Software instrastructure and guidance for ExaCS deployment Network Admin: Configure cloud network infraestructure (VCN, Backup/Client subnet, Gateway, etc)Database Admin: Setup database requirements (Memory, Storage, Computation, Database version, Database type, etc) Install Operating System, Database and Grid Infraestructure Database Admin: Mantain customer hardware requirements based on workloads
MONITORING Physical Security, Infraestructure, Control Plane, Hardware Faults, Availability, Capacity Nothing required Infrastructure availability to support customer monitoring of customer services Database Admin: Monitoring of Customer Operating System, Databases, Apps and Grid Infraestructure
INCIDENT MANAGEMENT & RESOLUTION Incident Managment and RemediationSpare parts and field dispatch Nothing required Support for any incidents related to the underlying platform Database Admin: Incident Management and resolution for Customer’s apps
PATCH MANAGEMENT Proactive patching of hardware, IaaS/PaaS control stack Nothing required Staging of available patches, for example, Oracle Database patch set Database Admin: Patching of tenant instancesTesting
BACKUP & RESTORATION Infrastructure and Control Plane backup and recovery, recreate customer VMs Nothing required Provide running and customer accessible VM Database Admin: Snapshots / backup and recovery of customer’s IaaS and PaaS data using Oracle native or third-party capabiltiy

Enabling additional security capabilities

KMS Integration (HSM keys)

Oracle Exadata Cloud Service (ExaCS) has integration with the OCI Vault service to protect data at rest for its databases. Users now have the control to create and manage TDE master keys within the OCI Vault that protect your Exadata databases.

With this feature, users have the option to start using the OCI vault service to store and manage the master encryption keys. The OCI Vault keys used for protecting databases are stored in a highly available,

durable, and managed service. OCI vault integration for ExaCS is only available after Oracle Database 11g release 2 (11.2.0.4).

With OCI Vault integration with ExaDB-D, customers can now:
  • Centrally control and manage your TDE master keys
  • Have their TDE master keys stored in a highly available, durable and managed service wherein the keys are protected by hardware security modules (HSM) that meet Federal Information Processing Standards (FIPS) 140-2 Security Level 3 security certification.
  • Rotate their encryption keys periodically to maintain security compliance and regulatory needs.
  • Migrate from Oracle-managed keys to customer-managed keys for their existing databases.
  • The Key version will only be assigned to the container database (CDB), and not to its pluggable database (PDB). PDB will be assigned an automatically generated new key version.
Using non-default encryption algorithms for TDE tablespace encryption

In the published Oracle Advanced Security Guide (section Encrypting Columns in Tables the methodology to create a table to encrypt columns using a non-default encryption algorithm ids described.