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.

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

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

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 by customer staff and cloud automation.

  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.

The following groups are created by default on the guest virtual machine.

root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mem:x:8:
kmem:x:9:
wheel:x:10:
cdrom:x:11:
mail:x:12:
man:x:15:
dialout:x:18:
tape:x:33:
video:x:39:
lock:x:54:
audio:x:63:
nobody:x:99:
users:x:100:
utmp:x:22:
utempter:x:35:
input:x:999:
systemd-journal:x:190:
systemd-network:x:192:
dbus:x:81:
ssh_keys:x:998:
sshd:x:74:
rpm:x:37:
rpc:x:32:
unbound:x:997:
nscd:x:28:
tss:x:59:
saslauth:x:76:
mailnull:x:47:
smmsp:x:51:
chrony:x:996:
rpcuser:x:29:
ldap:x:55:
slocate:x:21:
uucp:x:14:
tcpdump:x:72:
exawatch:x:510:
cgred:x:509:
fuse:x:508:
screen:x:84:
sssd:x:507:
printadmin:x:506:
docker:x:505:
dbmsvc:x:2001:
dbmadmin:x:2002:
dbmmonitor:x:2003:
dbmusers:x:2004:
floppy:x:19:
oinstall:x:1001:
asmdba:x:1004:
asmoper:x:1005:
asmadmin:x:1006:
dba:x:1002:
racoper:x:1003:
opc:x:2000:

root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mem:x:8:
kmem:x:9:
wheel:x:10:
cdrom:x:11:
mail:x:12:
man:x:15:
dialout:x:18:
tape:x:33:
video:x:39:
lock:x:54:
audio:x:63:
users:x:100:
nobody:x:2001:
utmp:x:22:
utempter:x:35:
dbus:x:81:
input:x:999:
kvm:x:36:
render:x:998:
systemd-journal:x:190:
systemd-coredump:x:997:
systemd-resolve:x:193:
tss:x:59:
ssh_keys:x:996:
sshd:x:74:
unbound:x:995:
nscd:x:28:
rpc:x:32:
saslauth:x:76:
mailnull:x:47:
smmsp:x:51:
rpcuser:x:29:
ldap:x:55:
slocate:x:21:
chrony:x:994:
tcpdump:x:72:
cgred:x:993:
fapolicyd:x:992:
printadmin:x:991:
polkitd:x:990:
sssd:x:989:
rpm:x:37:
screen:x:84:
dnsmasq:x:988:
exawatch:x:510:
dbmsvc:x:2002:
dbmadmin:x:2003:
dbmmonitor:x:2004:
dbmusers:x:2005:
uucp:x:14:
floppy:x:19:
mausers:x:2006:
secscan:x:1009:
oinstall:x:1001:
asmdba:x:1004:
asmoper:x:1005:
asmadmin:x:1006:
dba:x:1002:
racoper:x:1003:
opc:x:2000:

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 without-password.
  • It is recommended to leave this setting to permit the subset of cloud automation that uses this access path (for example, customer VM OS patching) to function. Setting PermitRootLogin to no will disable this subset of cloud automation functionality.
• 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

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

Default iptables rules for Guest VM:

#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