In Oracle Database Cloud Service databases, data security is provided for data in transit and data at rest.
Security of data in transit is achieved through network encryption. Data at rest security is achieved through encryption of data stored in
database data files and backups.Data in Oracle Database files, including backups, is secured by the use of encryption implemented through a key management framework. Security of data across the network is provided by native Oracle Net encryption and integrity capabilities.
Oracle Transparent Data Encryption (TDE) includes a keystore (referred to as a wallet in Oracle Database 11g and previous releases) to securely store master encryption keys, and a management framework to securely and efficiently manage the keystore and perform key maintenance operations.
TDE is the underlying mechanism used for default tablespace encryption and encrypted backups. It uses a two-tiered, key-based architecture to transparently encrypt and decrypt data. The master encryption key is stored in the software keystore. For tablespace encryption, this master encryption key is used to encrypt the tablespace encryption key, which in turn is used to encrypt and decrypt data in the tablespace. By default in Oracle Database Cloud Service When a database deployment is created on Oracle Database Cloud Service, a local auto-login software keystore is created. The keystore is local to the compute node and is protected by a system-generated password. The auto-login software keystore is automatically opened when accessed.
The keystore location is specified in the ENCRYPTION_WALLET_LOCATION parameter in
the $ORACLE_HOME/network/admin/sqlnet.ora file.
The Oracle keystore stores a history of retired TDE master encryption keys, which enables you to change them and still be able to decrypt data that was encrypted under an earlier TDE master encryption key.
By default, backups to Cloud Storage for Enterprise Edition databases are encrypted. Recovery Manager (RMAN) performs transparent encryption using the auto-login software keystore.
Please refer below note for more examples:-
By default, all new tablespaces that you create in a Database Cloud Service database are encrypted.
However, not all of the tablespaces created when you create a database deployment are encrypted:
you create a database deployment.
User-created tablespaces are encrypted by default.
By default, any new tablespaces created by using the SQL CREATE TABLESPACE command are encrypted with the AES128 encryption algorithm. You do not need to include the USING ‘encrypt_algorithm’ clause to use the default encryption.
You can specify another supported algorithm by including the USING ‘encrypt_algorithm’ clause in the CREATE TABLESPACE command. Supported algorithms for Oracle Database 11g and later are AES256, AES192, AES128, and 3DES168.
You can manage the software keystore (known as an Oracle wallet in Oracle Database 11g), the master encryption key, and control whether encryption is enabled by default.
Managing the Software Keystore and Master Encryption Key Tablespace encryption uses a two-tiered, key-based architecture to transparently encrypt (and decrypt) tablespaces. The master encryption key is stored in an external security module (software keystore). This master encryption key is used to encrypt the tablespace encryption key, which in turn is used to encrypt and decrypt data in the tablespace.
When the database deployment is created on Database Cloud Service, a local autologin software keystore is created. The keystore is local to the compute node and is protected by a system-generated password. The auto-login software keystore is automatically opened when accessed.
You can change (rotate) the master encryption key by using the tde rotate masterkey subcommand of the dbaascli utility. When you execute this subcommand you will be prompted for the keystore password. Enter the password specified during the database deployment creation process. For example:
DBAAS>tde rotate masterkey
The ENCRYPT_NEW_TABLESPACES initialization parameter controls default encryption of new tablespaces. In Database Cloud Service databases, this parameter is set to CLOUD_ONLY by default. See Viewing and Modifying Initialization Parameters for additional information.With Oracle Database 12c Release 2 (12.2) or later releases on Database Cloud Service, you can no longer create a new unencrypted tablespace. An error message is returned if you set ENCRYPT_NEW_TABLESPACES to DDL and issue a CREATE TABLESPACE command without specifying an ENCRYPTION clause.
|During creation, tablespaces are transparently encrypted with the AES128 algorithm unless a different algorithm is specified in the ENCRYPTION clause.
|Tablespaces created in a Database Cloud Service database are transparently encrypted with the AES128 algorithm unless a different algorithm is specified in the ENCRYPTION clause. For noncloud databases, tablespaces are only encrypted if the ENCRYPTION clause is specified. This is the default value.
|During creation, tablespaces are not transparently encrypted by default, and are only encrypted if the ENCRYPTION clause is specified.
To secure connections to your Oracle Database Cloud Service databases, you can use native Oracle Net encryption and integrity capabilities.Encryption of network data provides data privacy so that unauthorized parties are not able to view data as it passes over the network. In addition, integrity algorithms protect against data modification and illegitimate replay.
Oracle Database provides the Advanced Encryption Standard (AES), DES, 3DES, and RC4 symmetric cryptosystems for protecting the confidentiality of Oracle Net traffic. It also provides a keyed, sequenced implementation of the Message Digest 5 (MD5) algorithm or the Secure Hash Algorithm (SHA-1 and SHA-2) to protect against integrity attacks.
By default, database deployments on Database Cloud Service are configured to enable native Oracle Net encryption and integrity. Also, by default, Oracle Net clients are configured to enable native encryption and integrity when they connect to an appropriately configured server. If your Oracle Net client is configured to explicitly reject the use of native encryption and integrity then connection attempts will fail.
The following procedure outlines the basic steps required to confirm that native Oracle Net encryption and integrity are enabled in your Database Cloud Service environment.
$ cd $ORACLE_HOME/network/admin
$ ls sqlnet.ora
SQLNET.ENCRYPTION_SERVER = required
SQLNET.CRYPTO_CHECKSUM_SERVER = required
The required setting enables the encryption or integrity service and disallows the connection if the client side is not enabled for the security service. This is the default setting for database deployments on Database Cloud Service.
The following procedure outlines the basic steps required to confirm that native encryption and integrity are enabled in your Oracle Net client configuration.
tnsnames.ora and sqlnet.ora, for example:
$ cd $ORACLE_HOME/network/admin
SQLNET.ENCRYPTION_CLIENT = rejected
SQLNET.CRYPTO_CHECKSUM_CLIENT = rejected
The rejected setting explicitly disables the encryption or integrity service, even if the server requires it. When a client with an encryption or integrity service setting of rejected connects to a server with the required setting, the connection fails with the following error: ORA-12660: Encryption or crypto-checksumming parameters incompatible.
Because native Oracle Net encryption and integrity are enabled in your Database Cloud Service environment by default, any parameter setting other than rejected,or no setting at all, would result in the use of native encryption and integrity.
You can verify the use of native Oracle Net encryption and integrity by connecting to your Oracle database and examining the network service banner entries associated with each connection. This information is contained in the NETWORK_SERVICE_BANNER column of the V$SESSION_CONNECT_INFO view. The following example shows the SQL command used to display the network service banner entries associated with current connection:
SQL> select network_service_banner from v$session_connect_info where sid in (select distinct sid from v$mystat);
The following example output shows banner information for the available encryption service and the crypto-checksumming (integrity) service, including the algorithms in use:
If native Oracle Net encryption and integrity was not in use, the banner entries would still include entries for the available security services; that is, the services linked into the Oracle Database software. However, there would be no entries indicating the specific algorithms in use for the connection. The following output shows an example: