Security Guide for Base Database Service
This article describes security for Base Database Service.
Security Overview
This topic provides an overview of the security in the Base Database Service. Oracle manages security for most components, while users are responsible for the security of some components.
The cloud service components are classified into user-accessible services and Oracle-managed infrastructure. User-accessible service refers to the components that users can access as part of their subscription to the Base Database Service. These are virtual machines and database services commonly called as DB systems and databases respectively. Oracle-managed infrastructure refers to the hardware that Oracle owns and operates to support user-accessible services. It consists of AMD or Intel-based database computing shapes.
Oracle will manage the security and access to the Oracle-managed infrastructure components. Users will manage the security and access to the user-accessible services that include access to DB system and database services, network access to the DB system, authentication to access the DB system, and authentication to access databases running on the DB systems. Oracle staff are not authorized to access user-accessible services.
Users access Oracle Databases running on DB systems via a layer 2 (tagged VLAN) connection from user equipment using standard Oracle Database connection methods, such as Oracle Net on port 1521. Users can use the standard Oracle Linux methods to connect to the DB system running the Oracle Databases, such as token-based SSH on port 22.
The Base Database Service employs multiple, independent, and mutually-reinforcing security controls to help organizations create a secure operating environment for their workloads and data. The Base Database Service provides the following security controls:
- Defense in Depth to Secure the Operating Environment
- Least Privilege for Services and Users
- Audit and Accountability of Events and Actions
- Automating Cloud Operations
Defense in Depth to Secure the Operating Environment
The Base Database Service provides several controls to maintain confidentiality, integrity, and accountability across the service. The Base Database Service promotes the principle of defense-in-depth as follows:
- The virtual machines for DB systems are built from the hardened operating system image based on Oracle Linux 7. It 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.
- Additional secure default configuration choices are implemented in the service instances in addition to inheriting all the strengths of the mature Oracle Linux platform. 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.
- The Base Database Service also constitutes a complete deployment and service and is subject 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 vulnerability scans for all Oracle-managed infrastructure systems in the fleet.
Least Privilege for Services and Users
Oracle secure coding standards require the paradigm of least privilege. Ensuring that applications, services, and users have access to the capabilities that they need to perform their tasks is only one side of the least-privilege principle. It is equally important to ensure that access to unnecessary capabilities, services, and interfaces are limited. Base Database Service promotes the principle of least-privilege as follows:
- 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 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.
Audit and Accountability of Events and Actions
A system must be able to recognize and notify incidents as they occur. Similarly, when an incident cannot be averted, an organization must be able to identify its occurrence in order to take the appropriate actions. Base Database Service encourages audit and accountability in the following ways:
- Auditing and accountability ensure that both Oracle and users are aware of the activity done on the system and its time. These details not only ensure that we remain compliant with reporting requirements for external audits, but they can also assist in identifying the activity that led to unexpected behavior.
- Auditing capabilities are provided for all infrastructure components to ensure all actions are captured. Users can also configure auditing for their database and user domain (domU) configuration and may choose to integrate those with other enterprise auditing systems.
- Oracle does not access the user domU.
Automating Cloud Operations
By eliminating manual operations required to provision, patch, maintain, troubleshoot, and configure systems, the possibility for error is reduced and a secure configuration is ensured.
The Base Database Service is designed to be secure by automating all provisioning, configuration, and the majority of other operational tasks. By automating, it is possible to avoid missed configurations and ensure all necessary paths into the system are properly configured.
Security Features
This topic describes the security features available in the Base Database Service.
The Base Database Service provides the following security features:
- Hardened OS Image
- Minimized Attack Surface
- Additional Security Features Enabled
- Secure Access Methods
- Auditing and Logging
Hardened OS Image
- Minimal package installation: Only the necessary packages required to run an efficient system are installed. By installing a smaller set of packages, the attack surface of the operating system is reduced and the system remains more secure.
- Secure configuration: Many non-default configuration parameters are set during installation to enhance the security posture of the system and its content. For example, SSH is configured to only listen on certain network interfaces, sendmail is configured to only accept local host connections, and many other similar restrictions are implemented during installation.
- Run only necessary services: Any services that may be installed on the system but are not required for normal operation are disabled by default. For example, while NFS is a service often configured by users for various application purposes, it is disabled by default as it is not required for normal database operations. Users may choose to optionally configure services as per their requirements.
Minimized Attack Surface
As part of the hardened image, the attack surface is reduced by installing and running only the software required to deliver the service.
Additional Security Features Enabled
- Base Database Service is designed to be secure by default and provides a complete security stack, from network firewall control to access control security policies.
- FIPS, SE Linux, and STIG can be enabled additionally to improve security on systems using the
dbcli secure-dbsystemCLI. - The STIG tool is provided to increase compliance with DISA’s Oracle Linux 7 STIG on each system node in provisioned systems.
Secure Access Methods
- Access database servers via SSH using strong cryptographic ciphers. Weak ciphers are disabled by default.
- Access 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.
Auditing and Logging
By default, auditing and logging do not add any additional configuration for commercial deployments from what the operating system provides, but it can be improved by adding additional security settings by enabling STIG.
For more information, see:
- Enable FIPS, SE Linux, and STIG on the DB System Components
- Security Technical Implementation Guide (STIG) Tool for the DB System
User Security
This topic describes the user security available in the Base Database Service. The Base Database Service components are regularly managed by several user accounts. Oracle uses and recommends token-based SSH login only. Oracle users or processes do not use password-based authentication.
The following kinds of users are created by default:
Default Users: No Logon Privileges
This user list consists of default operating system users. These users should not be altered. These users cannot login to the system.
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
polkitd:x:999:996:User for polkitd:/:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
tss:x:59:59:Account used by the trousers package to sandbox the
tcsd daemon:/dev/null:/sbin/nologin
sssd:x:998:994:User for sssd:/:/sbin/nologin
named:x:25:25:Named:/var/named:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
dhcpd:x:177:177:DHCP server:/:/sbin/nologin
saslauth:x:997:76:Saslauthd user:/run/saslauthd:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologinDefault Users: With Login Privileges
These privileged users are responsible for accomplishing most of the tasks in the system. These users should never be altered or deleted as it would have a significant impact on the running system. SSH keys are used for logging in.
The following is the list of default users with login privileges.
rootis a Linux requirement. It is used sparingly to run local privileged commands. The root is also used for some processes like TFA Agent. It runs the local agent (aka “DCS Agent”) that performs lifecycle operations for RDBMS software (patching, create database, etc.)oracleowns the Oracle Database software installation and runs RDBMS processes.gridowns the Oracle Grid Infrastructure software installation and runs GI processes.opcis used by Oracle Cloud Automation for automation tasks. User has the ability to run certain privileged commands without further authentication (to support automation functions).mysqlis a critical user, and it needs to be up and running for successful operation of DCS Agent as it owns the metastore of DCS Agent.
root:x:0:0:root:/root:/bin/bash
opc:x:54322:54323::/home/opc:/bin/bash
mysql:x:54323:54331::/home/mysql:/bin/bash
grid:x:102:1001::/home/grid:/bin/bash
oracle:x:101:1001::/home/oracle:/bin/bashSecurity Settings
This topic describes the security settings available in the Base Database Service. The following are the default security settings provided in the system.
| Security Settings | Default Values |
|---|---|
| Password complexity | Password minimum length: 15 Password to maximum of consecutive repeating characters from the same character class: 4 Password maximum consecutive repeating characters: 3 Password strength minimum digit characters: 1 Password strength minimum different categories: 4 Password strength minimum different characters: 8 Password strength minimum special characters: 1 Password strength minimum lowercase characters: 1 Password strength minimum uppercase characters: 1 |
| User account configuration | Maximum number of days a password may be used: 60 Minimum number of days allowed between password changes: 1 Encryption hash algorithm: SHA512 Logon failure delay: 4 seconds |
| Disabled options | Disabled Ctrl-Alt-Del Reboot DCCP support is disabled USB storage device is disabled X Windows Package Group is removed |
| SSH Configurations | Only SSH Protocol 2 is allowed Enabled use of privilege separation SSH idle timeout interval: 600 seconds GSSAPI Authentication disabled Compression set to delayed Non-certificate trusted allowed to SSH logon to the system SSH daemon does not allow authentication using known hosts authentication |
| Packages | Remove all software components after updated versions have been installed The system prevents the installation of local packages for unverified software, patches, service packs, device drivers, or operating system components |
| Logging | System and Kernel messages are sent to remote host (rsyslog) Cron configured to log to rsyslog Configure AIDE for periodic execution |
| Others | Authentication required upon booting into single-user and maintenance modes Interactive session timeout: 600 seconds Configured PAM in SSSD devices PAM system service configured to store only encrypted representations of passwords Configured SSSD LDAP backend client CA certificate location Configured SSSD LDAP backend to use TLS for all transactions Disable account after password expires Group account administration utilities are configured to store only encrypted representations of passwords |
Additionally, by default, ONSR regions enable FIPS, SE Linux, and STIG to comply with the requirements standards. You can improve the system security by enabling additional configurations. The configuration standard (STIG) can be set to follow the most restrictive standards and increase security compliance with DISA’s Oracle Linux 7 STIG. A tool is provided as a part of the image to enable FIPS, SE Linux, and STIG.
For more information, see:
- Enable FIPS, SE Linux, and STIG on the DB System Components
- Security Technical Implementation Guide (STIG) Tool for the DB System
Security Processes
This topic describes the default security processes available in the Base Database Service. The following are the list of processes that are run by default on the user virtual machine (DB system) also called the domU.
| Processes | Description |
|---|---|
| domU agent | It is a cloud agent for handling database lifecycle operations. Runs as root userprocess table shows it running as a java process with the following jar names: dcs-agent-VersionNumber-SNAPSHOT.jardcs-admin-VersionNumber-SNAPSHOT.jar |
| TFA Agent | The Oracle Trace File Analyzer (TFA) provides several diagnostic tools in a single bundle, making it easy to gather diagnostic information about the Oracle Database and Clusterware, which in turn helps with problem resolution when dealing with Oracle Support. Runs as root userruns as initd demon (/etc/init.d/init.tfa)process tables show a java application ( oracle.rat.tfa.TFAMain) |
| Database and GI (clusterware) | Runs as oracle and grid userssome of CRS/clusterware daemon process runs as root userprocess table shows following applications: ora_*, apx_*, ams_*, and oracle+ASM*mysqld and zookeepersome of other process from /u01/<version>/grid/* |
Network Security
This topic describes the network security in the Base Database Service. The following are the list of default ports, processes, and iptables rules that are run by default on the user virtual machine (DB system), also called the domU.
Ports for domU Service
The following table provides a list of default ports for domU services.
| Type of interface | Name of interface | Port | Process running |
|---|---|---|---|
| Listen on all interfaces | 0.0.0.0 | 22 | SSH |
| Listen on all interfaces | 0.0.0.0 | 1522 | RDBMS: TNS listener |
| Listen on all interfaces | 0.0.0.0 | 7060 | DCS Admin |
| Listen on all interfaces | 0.0.0.0 | 7070 | DCS Agent |
| Listen on all interfaces | 0.0.0.0 | 2181 | Zookeeper |
| Listen on all interfaces | 0.0.0.0 | 8888, 8895 | RAC: Quality of Management Service (QOMS) Server |
| Listen on all interfaces | 0.0.0.0 | 9000 | RAC: Oracle Clusterware |
| Listen on all interfaces | 0.0.0.0 | 68 | DHCP |
| Listen on all interfaces | 0.0.0.0 | 123 | NTP |
| Listen on all interfaces | 0.0.0.0 | 5353 | Multicast DNS |
| Client Interface | ens3 | 1521 | RDBMS: TNS listener |
| Client Interface | ens3 | 5000 | RDBMS: Autonomous Health Framework (AHF) (includes TFA) |
| Client Interface | ens3:1 | 1521 | RDBMS: TNS listener |
| Client Interface | ens3:2 | 1521 | RDBMS: TNS listener |
| Client Interface | ens3:3 | 1521 | RDBMS: TNS listener |
| Cluster Interconnect | ens4 | 1525 | RDBMS: TNS listener |
| Cluster Interconnect | ens4 | 2888 | Zookeeper |
| Cluster Interconnect | ens4 | 3888 | Zookeeper |
| Cluster Interconnect | ens4 | 6000 | RAC: Grid inter-process communication |
| Cluster Interconnect | ens4 | 7000 | RAC: High availability service |
iptables Rules for domU
The default iptables is set up to ACCEPT connections on input, forward, and output chains.
The following are the default iptables rules for domU services:
CHAIN INPUTCHAIN FORWARDCHAIN OUTPUT
Example - iptables rules
The following example provides the default iptables rules for domU services.
iptables -L -n -vOutput:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
43M 110G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2664 224K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
40793 2441K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- ens4 * 0.0.0.0/0 0.0.0.0/0
3 192 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
40 2400 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:1521 /* Required for access to Database Listener, Do not remove or modify. */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:5000 /* Required for TFA traffic. */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:6200 /* This rule is recommended and enables the Oracle Notification Services (ONS) to communicate about Fast Application Notification (FAN) events. */
343 20580 ACCEPT tcp -- * * 169.254.0.0/16 0.0.0.0/0 state NEW tcp dpt:7070 /* Required for instance management by the Database Service, Do not remove or modify. */
132 7920 ACCEPT tcp -- * * 169.254.0.0/16 0.0.0.0/0 state NEW tcp dpt:7060 /* Required for instance management by the Database Service, Do not remove or modify. */
0 0 ACCEPT tcp -- * * 169.254.0.0/16 0.0.0.0/0 state NEW tcp dpt:22 /* Required for instance management by the Database Service, Do not remove or modify. */
3 424 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 51078 packets, 3218K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * ens4 0.0.0.0/0 0.0.0.0/0
52M 170G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
8003 548K InstanceServices all -- * * 0.0.0.0/0 169.254.0.0/16
Chain InstanceServices (1 references)
pkts bytes target prot opt in out source destination
11 660 ACCEPT tcp -- * * 0.0.0.0/0 169.254.2.0/24 owner UID match 0 tcp dpt:3260 /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */
1 60 ACCEPT tcp -- * * 0.0.0.0/0 169.254.0.2 owner UID match 0 tcp dpt:3260 /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.0.2 tcp dpt:80 /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */
678 63323 ACCEPT udp -- * * 0.0.0.0/0 169.254.169.254 udp dpt:53 /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.169.254 tcp dpt:53 /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.0.3 owner UID match 0 tcp dpt:80 /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.0.4 tcp dpt:80 /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */
2569 195K ACCEPT udp -- * * 0.0.0.0/0 169.254.169.254 udp dpt:123 /* Allow access to OCI local NTP service */
4727 284K ACCEPT tcp -- * * 0.0.0.0/0 169.254.169.254 tcp dpt:80 /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */
15 4920 ACCEPT udp -- * * 0.0.0.0/0 169.254.169.254 udp dpt:67 /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */
0 0 ACCEPT udp -- * * 0.0.0.0/0 169.254.169.254 udp dpt:69 /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */
0 0 REJECT tcp -- * * 0.0.0.0/0 169.254.0.0/16 tcp /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */ reject-with tcp-reset
0 0 REJECT udp -- * * 0.0.0.0/0 169.254.0.0/16 udp /* See the Oracle-Provided Images section in the Oracle documentation for security impact of modifying or removing this rule */ reject-with icmp-port-unreachableUser Responsibilities for Security Settings
This topic describes the Oracle Cloud Operations responsibilities and user responsibilities for security settings in the Base Database Service. The following table provides a list of security settings that the Oracle Cloud Operations and user need to perform.
| Operation | Oracle Cloud Platform: Oracle Cloud Responsibility | Oracle Cloud Platform: User Responsibility | User / Tenant Instances: Oracle Cloud Responsibility | User / Tenant Instances: User Responsibility |
|---|---|---|---|---|
| DATABASE DEPLOYMENT | Software infrastructure and guidance for Base Database Service deployment | Network Admin: Configure cloud network infrastructure (VCN and subnets, gateway, etc). Database Admin: Setup database requirements (memory, storage, computation, database version, database type, etc). |
Install operating system, database and Grid Infrastructure system if selected | Database Admin: Update Oracle Database software version, shape of virtual machine requirements (CPU / memory), data storage and recovery storage configuration size resources based on workloads if required (upgrade/downgrade resources). |
| MONITORING | Physical security, infrastructure, control plane, hardware faults, availability, capacity | Nothing required | Infrastructure availability to support user monitoring of user services. | Database Admin: Monitoring of user operating system, databases, apps and Grid Infrastructure |
| INCIDENT MANAGEMENT AND RESOLUTION | Incident management and remediationspare parts and field dispatch | Nothing required | Support for any incidents related to the underlying platform | Database Admin: Incident Management and resolution for user apps |
| PATCH MANAGEMENT | Proactive patching of hardware, IaaS/PaaS control stack | Nothing required | Staging of available patches, for example, Oracle Database patch set | Database Admin: Patching of tenant instances, testing OS Admin: OS patching |
| BACKUP AND RESTORATION | Infrastructure and control plane backup and recovery, recreate user virtual machines | Nothing required | Provide running and user accessible virtual machines | Database Admin: Snapshots / backup and recovery of user IaaS and PaaS data using Oracle native or third-party capability |
Enable Additional Security Capabilities
The Base Database Service provides the following additional security capabilities:
dbcli NetSecurity
The dbcli NetSecurity deals with the encryption of data as it travels through the network. When the data moves from Oracle Database to a third party or from a server to client, it has to be encrypted at the sender’s end and decrypted at the receiver’s end. In NetSecurity, rules are configured with default values for both client and server during provisioning and database home creation operations. The dcs-agent CLI interface provides commands to update these NetSecurity rules and enhance security for encryption algorithms, integrity algorithms, and connection types.
By default, dcs-agent configures the following default rules for the database home:
SQLNET.ENCRYPTION_SERVER=REQUIREDSQLNET.CRYPTO_CHECKSUM_SERVER=REQUIREDSQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192,AES128)SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA1)SQLNET.ENCRYPTION_CLIENT=REQUIREDSQLNET.CRYPTO_CHECKSUM_CLIENT=REQUIREDSQLNET.ENCRYPTION_TYPES_CLIENT=(AES256,AES192,AES128)SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA1)
For more information on updating the settings, see Oracle Database CLI Reference.
OCI Vault Integration
The Base Database Service now has integration with the OCI Vault service in all OCI commercial regions. You can now create and manage TDE master keys within the OCI Vault that protect your databases. With this feature, you have the option to start using the OCI Vault service to store and manage the master encryption keys. The OCI Vault keys used for protecting databases are stored in a highly available, durable, and managed service.
Note: The OCI Vault integration is only available for Oracle Database versions 19.13 and later.
With OCI Vault integration with Base Database Service, you can:
- Centrally control and manage TDE master keys by enabling OCI Vault-based key encryption while provisioning Oracle Databases on the Base Database Service.
- Have your TDE master keys stored in a highly available, durable, and managed service wherein the keys are protected by hardware security modules (HSM) that meet Federal Information Processing Standards (FIPS) 140-2 Security Level 3 security certification.
- Rotate your encryption keys periodically to maintain security compliance and, in cases of personnel changes, disable access to a database.
- Migrate from Oracle-managed keys to user-managed keys for your existing databases.
- Bring in your own keys—that’s BYOK (Bring Your Own Key)—and use them while creating databases with user-managed encryption.
Note:
- BYOK is applicable to the container database (CDB) only. The pluggable database (PDB) will be assigned an automatically generated new key version.
- Oracle Databases that use user-managed encryption support DB system cloning, in-place restore, out-of-place restore, intra-region Data Guard configuration, and PDB-specific operations like PDB creation and local cloning.
CLI to Enable FIPS
Oracle provides a tool for commercial users to improve security by default. This tool is used to enable FIPS, SE Linux, and STIG to follow the most rigorous standards.
For more information, see Enable FIPS, SE Linux, and STIG on the DB System Components.