Security Guide for Oracle Exadata Database Service on Cloud@Customer Systems

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

Security Configurations and Default Enabled Features

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

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

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 7-29 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

Additional Procedures for Updating Security Posture

Customer Responsibilities

Table 7-30 Resposibilities

  Oracle Cloud Platform Customer/Tenant Instances

Monitoring

Oracle Cloud Ops

Customer

Oracle Cloud Ops

Customer

Infrastructure, Control Plane, hardware faults, availability, capacity

Provide network access to support Oracle infrastructure log collection and monitoring

Infrastructure availability to support customer monitoring of customer services

Monitoring of customer operating system, databases, apps

Incident Management and Resolution

Incident Management and Remediation

Spare parts and field dispatch

Onsite diagnostic assistance, for example, network troubleshooting

Support for any incidents related to the underlying platform

Incident Management and resolution for Customer’s apps

Patch Management

Proactive patching of hardware, IaaS/PaaS control stack

Provide network access to support patch delivery

Staging of available patches, for example, Oracle Database patch set

Patching of tenant instances

Testing

Backup and Restoration

Infrastructure and Control Plane backup and recovery, receate customer VMs

Provide network access to support cloud automation delivery

Provide running and customer accessible VM

Snapshots / backup and recovey of customer's IaaS and PaaS data using Oracle native or third-party capability

Cloud Support

Response and resolution of SR related to infrastructure or subscription issues

Submit SR through MOS Response and resolution of SR Submit SR through Suppot portal

Enabling Additional Security Capabilities

Using Oracle Key Vault as an External TDE Key Store for Databases on Exadata Cloud@Customer

Oracle supports customers using Oracle Key Vault (OKV) as an external key store for databases running on Exadata Cloud@Customer. Instructions for migrating TDE Master Keys to OKV are published in My Oracle Support Document 2823650.1 (Migration of File based TDE to OKV for Exadata Database Service on Cloud at Customer Gen2). Oracle does not support third-party hardware security modules (HSM) with Exadata Cloud@Customer.

Modifying Password Complexity Requirements Using host_access_control

Table 7-31 host_access_control password-aging

Option Description

-s, --status

Displays current user password aging.

-u USER, --user=USER

A valid interactive user's username.

--defaults

Sets all password-aging values to *Exadata factory defaults for all interactive users.

--secdefaults

Sets all password-aging values to **Exadata secure defaults for all interactive users.

--policy

Sets all password-aging values to the aging policy as defind by the password-policy command (or /etc/login.defs) for all interactive users.

-M int, --maxdays=int

Maximum number of days a password may be used. Input limited to from 1 to 99999.

-m int, --mindays=int

Minimum number of days allowed between password changes. Input limited to from 0 to 99999, 0 for anytime.

-W int, --warndays=int

Number of days warning given before a password expires. Input limited to from 0 to 99999.

host_access_control password-policy

--PASS_MAX_DAYS integer (60)*

--PASS_MIN_DAYS integer ( 1)*

--PASS_MIN_LEN integer ( 8)*

--PASS_WARN_AGE integer ( 7)*

--defaults

--status

Table 7-32 host_access_control pam-auth

Options Description

-h, --help

Shows this help message and exits.

-d DENY, --deny=DENY

Number of failed login attempts before an account will be locked. Input is limited to from 1 to 10. (*Exadata factory default is 5)

-l LOCK_TIME, --lock=LOCK_TIME

Number of seconds (integer) an account will be locked due to a single failed login attempt. Input is limited to from 0 to 31557600 (one year) (*Exadata factory default is 600 (10m))

-p list, --passwdqc=list

FOR SYSTEMS RUNNING ON LESS THAN OL7

Comma-separated set of 5 values: N0,N1,N2,N3,N4 defining the minimum allowed length for different types of password/passphrases. Each subsequent number is required to be no larger than the preceding one. The keyword "disabled" can be used to disallow passwords of a given kind regardless of their length. (Refer to the pam_passwdqc manpage for an explanation).

Passwords must use three character classes. Character classes for passwords are digits, lowercase letters, uppercase letters, and other characters. Minimum password length is 12 characters when using three character classes.

Minimum password length is 8 characters when using four character classes. ( *Exadata factory default is 5,5,5,5,5) (**Exadata secure default is disabled,disabled,16,12,8)

-q PWQUALITY, --pwquality=PWQUALITY

FOR SYSTEMS RUNNING ON OL7 AND GREATER

Integer, ranging from 6 to 40, defining the minimum allowed password length. defined by the Exadata secure defaults. All classes will be required for password changes as well as other checks enforced for lengths >7. For lengths <8, class requirements are not used.

(*Exadata factory default is: minlen=8 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 difok=8 maxrepeat=3 maxclassrepeat=4)

(**Exadata secure default is: minlen=15 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 difok=8 maxrepeat=3 maxclassrepeat=4)

(Refer to the pam_pwquality manpage for details)

-r REMEMBER, --remember=REMEMBER

The last n passwords to remember for password change history. Valid range is an integer from 0 to 1000.

(*Exadata factory default is 10)

--defaults

Sets all pam-auth values to *Exadata factory defaults.

--secdefaults

Sets all pam-auth values to **Exadata secure defaults.

-s, --status

Displays current PAM authentication settings.

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 7-33 User Accounts

User Name and Password User Type Component

opc - key-based login only

Operating system user Oracle Exadata Database Servers
exawatch (release 19.1.0 and later) - no logon privileges Operating system user

Oracle Exadata Database Servers

Oracle Exadata Storage Servers

SYS/We1come$ Oracle Database user Oracle Exadata Database Servers
SYSTEM/We1come$ Oracle Database user Oracle Exadata Database Servers

MSUser

Management Server (MS) uses this account to manage ILOM and reset it if it detects a hang.

The MSUser password is not persisted anywhere. Each time MS starts up, it deletes the previous MSUser account and re-creates the account with a randomly generated password.

Do not modify this account. This account is to be used by MS only.

ILOM user

Database server ILOMs

Oracle Exadata Storage Server ILOMs

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.