What is the customers responsibility on the Oracle Cloud infrastructure database system?

This guide describes security for an Oracle Exadata Cloud@Customer System. It includes information about the best practices for securing the Oracle Exadata Cloud@Customer System.

• Security Configurations and Default Enabled Features
  
• Additional Procedures for Updating Security Posture
  

Security Configurations and Default Enabled Features

• Responsibilities
  
• Guiding Principles Followed for Security Configuration Defaults
  
• Security Features
  
• Guest VM Default Fixed Users
  
• Guest VM Default Security Settings
  
• Guest VM Default Processes
  
• Guest VM Network Security
  

Responsibilities

Exadata Cloud@Customer is jointly managed by the customer and Oracle. The Exadata Cloud@Customer deployment is divided into two major areas of responsibilities:

• Customer accessible services:

  Components that the customer can access as part of their subscription to Exadata Cloud@Customer:

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

• Oracle-managed infrastructure:
  • Power Distribution Units (PDUs)
  • Out-of-band (OOB) management switches » InfiniBand switches
  • Exadata Storage Servers
  • Physical Exadata database servers

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

Customers access Oracle Databases running on Exadata Cloud@Customer through a layer 2 (tagged VLAN) connection from customer equipment to the databases running in the customer VM using standard Oracle Database connection methods, such as Oracle Net on port 1521. Customers access the VM running the Oracle Databases through standard Oracle Linux methods, such as token based SSH on port 22.

Guiding Principles Followed for Security Configuration Defaults

• Defense in Depth

  Exadata Cloud@Customer offers a number of controls to ensure confidentiality, integrity, and accountability throughout the service.

  First, Exadata Cloud@Customer is built from the hardened operating system image provided by Exadata Database Machine. For more information, see Overview of Oracle Exadata Database Machine Security. 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@Customer 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@Customer 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

  To ensure that processes only have access to the privileges they require, Oracle Secure Coding Standards require the paradigm of least privilege.

  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 Oracle Exadata Cloud@Customer 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.

  This ensures that both Oracle and customers know what was done on the system and when that occurred. These facts not only ensure we remain compliant with reporting needs for external audits, but also can help match up some change with a change in perceived behavior in the application.

  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 and a secure configuration is ensured.

  The service is designed to be secure and by automating all provisioning, configuration, and most other operational tasks, it is possible to avoid missed configurations and ensure all necessary paths into the system are closed tightly.

Security Features

• Hardened Operating System 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 by disabling services.

• Additional Security Features Enabled (grub passwords, secure boot)
  • Leveraging Exadata image capabilities, Exadata Cloud@Customer 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 detailed later in this chapter.
• Secure Access Methods
  • Accessing database servers through 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 through 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.

• Deployment-Time Considerations
  • Wallet file download contents and sensitivity: The wallet file download that is obtained by a customer to enable the deployment to occur contains sensitive information and should be handled appropriately to ensure the contents are protected. The content of the wallet file download is not needed after deployment is completed, so it should be destroyed to ensure no information leakage occurs.
  • Control Plane Server (CPS):
    • Deployment requirements for the CPS include permitting outbound HTTPS access so the CPS can connect to Oracle and enable remote administration, monitoring, and maintenance. Find more details in the Deployment Guide.
    • Customer responsibilities include providing physical security to the Exadata Cloud@Customer equipment in their data center. While Exadata Cloud@Customer employs many software security features, physical server compromise must be addressed by customer physical security to ensure the safety of the servers' contents.

Guest VM Default Fixed Users

Several user accounts regularly manage the components of Oracle Exadata Cloud@Customer. In all Exadata Cloud@Customer machines, Oracle uses and recommends SSH based login only. No Oracle user or processes use password based authentication system.

Below described are the different kind of users created by default.

• 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 /bin/false.

  • 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:/bin/false
  daemon:x:2:2:daemon:/sbin:/bin/false
  adm:x:3:4:adm:/dev/null:/bin/false
  mail:x:8:12:mail:/var/spool/mail:/bin/false
  nobody:x:99:99:Nobody:/:/bin/false
  systemd-network:x:192:192:systemd Network Management:/:/bin/false
  dbus:x:81:81:System message bus:/:/bin/false
  rpm:x:37:37::/var/lib/rpm:/bin/false
  sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/bin/false
  rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/bin/false
  nscd:x:28:28:NSCD Daemon:/:/bin/false
  saslauth:x:999:76:Saslauthd user:/run/saslauthd:/bin/false
  mailnull:x:47:47::/var/spool/mqueue:/bin/false
  smmsp:x:51:51::/var/spool/mqueue:/bin/false
  chrony:x:998:997::/var/lib/chrony:/bin/false
  rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/bin/false
  uucp:x:10:14:Uucp user:/var/spool/uucp:/bin/false
  nslcd:x:65:55:LDAP Client User:/:/bin/false
  tcpdump:x:72:72::/:/bin/false
  exawatch:x:1010:510::/:/bin/false
  sssd:x:997:508:User for sssd:/:/bin/false
  tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/bin/false
  dbmsvc:x:12137:11137::/home/dbmsvc:/bin/false

• 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 altered as the defined task will fail in case these users are altered or deleted.

  dbmmonitor: The dbmmonitor user is used for DBMCLI Utility. For more information, see Using the DBMCLI Utility.

  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.

  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.

Guest VM Default Security Settings

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

• 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 yes.
  • It is recommended to disable allowance of SSH root login PermitRootLogin to no.
• 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

Guest VM Default Processes

• Exadata Cloud@Customer Guest 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 Oracle 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.

• ExaWatcher:

  • 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.

• Oracle Database and Oracle Grid Infrastructure (Oracle 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 and weblogic.Server as oracle user.
• Management Server (MS): Part of Exadata image software for managing and monitoring the image functions.
  • Runs as dbmadmin user.
  • Process table shows it running as a Java process.

Guest VM Network Security

Table 35-1 Default Port Matrix for Guest VM Services

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

Additional Procedures for Updating Security Posture

• Customer Responsibilities
  
• Enabling Additional Security Capabilities
  

Customer Responsibilities

Table 35-2 Resposibilities

Enabling Additional Security Capabilities

Migrating TDE Keys to HSM

For more information, see Managing the Keystore and the Master Encryption Key.

Migrating from a Password-Protected Software Keystore to a Hardware Keystore

You can migrate from a password-protected software keystore to a hardware keystore.

• Step 1: Convert the Software Keystore to Open with the Hardware Keystore

  Some Oracle tools require access to the old software keystore to encrypt or decrypt data that was exported or backed up using the software keystore.

• Step 2: Configure the Hardware Security Module Keystore Type

  You can use the ALTER SYSTEM statement to configure the HSM keystore type.

• Step 3: Perform the Hardware Keystore Migration

  You can use the ADMINISTER KEY MANAGEMENT SQL statement to perform a hardware keystore migration.

1. Convert the Software Keystore to Open with the Hardware Keystore

   Some Oracle tools require access to the old software keystore to encrypt or decrypt data that was exported or backed up using the software keystore.

   Examples of these tools are Oracle Data Pump and Oracle Recovery Manager.

   Use the ADMINISTER KEY MANAGEMENT SQL statement to convert a software keystore to a open with a hardware keystore.

   • To set the software keystore password as that of the hardware keystore, use the following syntax:

     ADMINISTER KEY MANAGEMENT ALTER KEYSTORE PASSWORD
     
     FORCE KEYSTORE
     
     IDENTIFIED BY software_keystore_password
     
     SET "hardware_keystore_credentials" WITH BACKUP
     
     [USING 'backup_identifier'];

     In this specification,

     • software_keystore_password is the same password that you used when creating the software keystore.
     • hardware_keystore_credentials is the new software keystore password which is the same as the password of the hardware keystore.
     • WITH BACKUP creates a backup of the software keystore. Optionally, you can use the USING clause to add a brief description of the backup. Enclose this description in single quotation marks (' '). This identifier is appended to the named keystore file, for example, ewallet_time-stamp_emp_key_backup.p12, with emp_key_backup being the backup identifier. Follow the file naming conventions that your operating system uses.

   • To create an auto-login keystore for a software keystore, use the following syntax:

     ADMINISTER KEY MANAGEMENT CREATE [LOCAL] AUTO_LOGIN KEYSTORE
     
     FROM KEYSTORE 'keystore_location'
     
     IDENTIFIED BY software_keystore_password;

     In this specification,

     • LOCAL enables you to create a local auto-login software keystore. Otherwise, omit this clause if you want the keystore to be accessible by other computers.

     • keystore_location is the path to the keystore directory location of the keystore that is configured in the sqlnet.ora file.

     • software_keystore_password is the existing password of the configured software keystore.

2. Configure the Hardware Security Module Keystore Type

   You can use the ALTER SYSTEM statement to configure the HSM keystore type.

   For the software keystore to open with the hardware keystore, either the software keystore must have the same password as the hardware keystore, or alternatively, you can create an auto-login keystore for the software keystore.

   1. Log in to the database instance as a user who has been granted the SYSDBA administrative privilege.

      For example:

      sqlplus sec_admin as sysdba
      Enter password: password

   2. Set the TDE_CONFIGURATION dynamic initialization parameter.

      The following example migrates from a TDE keystore to a hardware keystore:

      ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=HSM|FILE";

      The next example migrates from a TDE keystore to an Oracle Key Vault keystore:

      ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=OKV|FILE";

   3. Restart the database.

      SHUTDOWN IMMEDIATE
      STARTUP

3. Perform the Hardware Keystore migration.

   You can use the ADMINISTER KEY MANAGEMENT SQL statement to perform a hardware keystore migration.

   To migrate from the software keystore to hardware keystore, you must use the MIGRATE USING keystore_password clause in the ADMINISTER KEY MANAGEMENT SET KEY SQL statement to decrypt the existing TDE table keys and the tablespace encryption keys with the TDE master encryption key in the software keystore and then reencrypt them with the newly created TDE master encryption key in the hardware keystore.

   After you complete the migration, you do not need to restart the database, nor do you need to manually re-open the hardware keystore. The migration process automatically reloads the keystore keys in memory.

   • Migrate the hardware keystores by using the following syntax:

     ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY 
     IDENTIFIED BY "user_name:password" 
     MIGRATE USING software_keystore_password 
     [WITH BACKUP [USING 'backup_identifier']];

     In this specification,

     • user_name:password is the user ID and password that was created in Step 2 under Step 2: Configure the Hardware Security Module (in Configuring Transparent Data Encryption). Enclose this setting in double quotation marks (" ") and separate user_name and password with a colon (:).

     • software_keystore_password is the same password that you used when creating the software keystore or that you have changed to in Step 1: Convert the Software Keystore to Open with the Hardware Keystore.

     • USING enables you to add a brief description of the backup. Enclose this description in single quotation marks (' '). This identifier is appended to the named keystore file (for example, ewallet_time-stamp_emp_key_backup.p12, with emp_key_backup being the backup identifier). Follow the file naming conventions that your operating system uses.

     Note

     If the database contains columns encrypted with a public key, then the columns are decrypted and reencrypted with an AES symmetric key generated by HSM-based Transparent Data Encryption.

Modifying Password Complexity Requirements Using host_access_control

Table 35-3 host_access_control password-aging

Table 35-4 host_access_control pam-auth

Implementing or Updating the iptables firewall Configuration in Guest VM

iptables configuration and firewall rules are stored in /etc/sysconfig/iptables.

man iptables : To get iptables help. Various websites online have many tutorials as well.

iptables --list : To get current iptables rules.

Refer to earlier section "Guest VM Network Security" for details on what ports may be required on Guest VM. To configure the firewall manually, create commands like the following example. Note that it is possible to lock yourself out of the system by blocking the ports over which you connect, so it's recommended to consult a test system and engage an experienced iptables administrator if possible.

1. At the command prompt, enter the appropriate command for each port to be opened, for example:

   # iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 7002 -j ACCEPT
   
   # iptables -A INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT

2. Save the iptables configuration.

   # service iptables save

Changing passwords and Updating Authorized Keys

To change a user password the password command is used. Passwords must be changed 7 days prior expiration date. Password policies are described above in the default security settings section.

Default Oracle Exadata Users and Passwords - See My Oracle Support note https://support.oracle.com/epmos/faces/DocContentDisplay?id=1291766.1. Other accounts not included in that note are listed below.

Table 35-5 User Accounts

Pay Attention to What Actions May Impact Service-Related Logins for Cloud Automation

For example, procedures will include ensuring that authorized keys used for cloud automation actions remain intact.

For more information about Physical Network access controls including guidelines for Oracle Cloud Automation, see Oracle Gen2 Exadata Cloud@Customer Security Controls.

Oracle Cloud Automation access to the customer VM is controlled through token based SSH. Public keys for Oracle Cloud Automation access are stored in the authorized keys files of the oracle, opc, and root users of the customer VM. The private keys used by the automation are stored and protected by the Oracle Cloud Automation software running in the Exadata Cloud@Customer hardware in the customer’s data center. The customer’s OCI Identity and Access Management (IAM) controls govern if and how a customer can execute Oracle Cloud Automation functionality against the customer VM and databases. The customer may further control access through the management network and Oracle Cloud Automation keys by blocking network access (firewall rules, disabling network interface), and by revoking the credentials used by the Oracle Cloud Automation (remove the public keys from the authorized keys files). Oracle Cloud Automation Access may be temporarily restored by the customer to permit the subset of functionality required to access the customer VM and customer databases, such as customer VM operating system patching. Oracle Cloud Automation does not need network access the customer VM to perform OCPU scaling, and OCPU scaling functionality will function normally when customers block Oracle Cloud Automation network access to the customer VM.

Configure Encrypted Channels for Database Listener (Oracle Net) Connectivity

For more information, see Configuring Oracle Database Native Network Encryption and Data Integrity.

Related Topics

• Managing the Keystore and the Master Encryption Key
• https://support.oracle.com/epmos/faces/DocContentDisplay?id=1291766.1
• Oracle Gen2 Exadata Cloud@Customer Security Controls
• Configuring Oracle Database Native Network Encryption and Data Integrity

Which of the following OCI security tasks are customer's responsibilities?

Which three are customer's responsibilities in the shared responsibilities model for security?

Which three are Oracle's responsibilities in the shared security model in Oracle cloud infrastructure?

What is Oracle cloud customer?