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
- 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.
Parent topic: Security Configurations and Default Enabled Features
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.
Related Topics
Parent topic: Security Configurations and Default Enabled Features
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.
- Minimal package installation:
- 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.
Parent topic: Security Configurations and Default Enabled Features
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
anddbmsvc
. 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 Usersbin: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
: Thedbmmonitor
user is used for DBMCLI Utility. For more information, see Using the DBMCLI Utility.Restricted Shell Usersdbmmonitor: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 theUpdateVmCluster
method, the key is only added to theauthorized_keys
file of theopc
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 theauthorized_keys
files of theroot
,opc
,oracle
, andgrid
accounts should only contain cloud automation keys while the cloud automation actions are running.Privileged Usersroot: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 andExaWatcher
.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
Related Topics
Parent topic: Security Configurations and Default Enabled Features
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 thePermitRootLogin
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
tono
will disable this subset of cloud automation functionality.
- By default,
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 withuid=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
Related Topics
Parent topic: Security Configurations and Default Enabled Features
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
anddbcs-admin-VersionNumver-SNAPSHOT.jar
.
- Runs as
- 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
.
- Runs as
-
ExaWatcher
:- Runs as
root
andexawatch
users. - Runs as backgroud script,
ExaWatcher.sh
and all its child process run as a Perl process. - Process table shows as multiple Perl applications.
- Runs as
- Oracle Database and Oracle Grid Infrastructure (Oracle Clusterware):
- Runs as
dbmsvc
andgrid
users. - Process table shows following applications:
oraagent.bin
,apx_*
, andams_*
asgrid
user.dbrsMain
, and Java applications,derbyclient.jar
andweblogic.Server
asoracle
user.
- Runs as
- 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.
- Runs as
Parent topic: Security Configurations and Default Enabled Features
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 |
|
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 |
||
|
1521 Optionally, customers can assign a SCAN listener port (TCP/IP) in the range between 1024 and 8999. Default is 1521. |
Oracle TNS listener |
|
|
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 |
|
7879 |
Jetty Management Server |
Oracle Clusterware running on each cluster node communicates through these interfaces. |
|
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) |
||
|
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. |
|
7060 |
dbcs-admin |
7070 |
dbcs-agent |
||
|
7060 |
dbcs-admin |
|
7070 |
dbcs-agent |
||
Control Plane server to domU |
|
22 |
sshd |
Loopback |
|
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 |
TNS listener opens dynamic ports after initial contact to well known ports (1521, 1525).
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
Parent topic: Security Configurations and Default Enabled Features
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 |
Parent topic: Additional Procedures for Updating Security Posture
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 |
---|---|
|
Displays current user password aging. |
|
A valid interactive user's username. |
|
Sets all password-aging values to *Exadata factory defaults for all interactive users. |
|
Sets all password-aging values to **Exadata secure defaults for all interactive users. |
|
Sets all password-aging values to the aging policy as defind by
the password-policy command (or
|
|
Maximum number of days a password may be used. Input limited to from 1 to 99999. |
|
Minimum number of days allowed between password changes. Input limited to from 0 to 99999, 0 for anytime. |
|
Number of days warning given before a password expires. Input limited to from 0 to 99999. |
|
|
Table 7-32 host_access_control pam-auth
Options | Description |
---|---|
|
Shows this help message and exits. |
|
Number of failed login attempts before an account will be locked. Input is limited to from 1 to 10. (*Exadata factory default is 5) |
|
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)) |
|
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) |
|
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) |
|
The last n passwords to remember for password change history. Valid range is an integer from 0 to 1000. (*Exadata factory default is 10) |
|
Sets all pam-auth values to *Exadata factory defaults. |
|
Sets all pam-auth values to **Exadata secure defaults. |
|
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.
- 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
- 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 |
---|---|---|
|
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 |
Management Server (MS) uses this account to manage ILOM and reset it if it detects a hang. The 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.
Related Topics
Parent topic: Additional Procedures for Updating Security Posture