Data security

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.

Security of data at rest

Oracle Database Cloud Service uses Oracle Transparent Data Encryption to encrypt data in the database data files and in backups. Encrypted data is also protected in temporary tablespaces, undo segments, redo logs and during internal database operations such as JOIN and SORT.

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

https://clouddba.co/tde-encryption-setup-for-migrating-on-premise-backup-to-oracle-cloud-using-rman/

Tablespace Encryption

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:

  • In an Oracle Database 11g database, none of the tablespaces created when you create a database deployment are encrypted.
  • In an Oracle Database 12c Release 1 database, none of the tablespaces created when you create a database deployment are encrypted. This includes the tablespaces in the root (CDB$ROOT), the seed (PDB$SEED), and the PDB created when

you create a database deployment.

  • In an Oracle Database 12c Release 2 or later database, only the USERS tablespaces created when you create a database deployment are encrypted. None of the other tablespaces are encrypted. This includes the tablespaces in the root (CDB$ROOT), the seed (PDB$SEED), and the PDB created when 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.

Managing Tablespace Encryption

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

Controlling Default Tablespace Encryption

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.

 

Value

Description
Always During creation, tablespaces are transparently encrypted with the AES128 algorithm unless a different algorithm is specified in the ENCRYPTION clause.
CLOUD_ONLY 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.
DDL During creation, tablespaces are not transparently encrypted by default, and are only encrypted if the ENCRYPTION clause is specified.

 

Security of Data in Transit

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.

Checking your Database Cloud Service environment

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.

  1. In a command shell, connect to the compute node as the oracle user.
  2. Change directories to the location of the sqlnet.ora Oracle Net configuration file. For example:

$ cd $ORACLE_HOME/network/admin

$ ls sqlnet.ora

sqlnet.ora

  1. View the sqlnet.ora file and confirm that it contains the following parameter settings:

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.

Checking your Oracle Net Client Configuration

The following procedure outlines the basic steps required to confirm that native encryption and integrity are enabled in your Oracle Net client configuration.

  1. In a command shell, connect to the Oracle Net client.
  2. Change directories to the location of the Oracle Net configuration files

tnsnames.ora and sqlnet.ora, for example:

$ cd $ORACLE_HOME/network/admin

sqlnet.ora tnsnames.ora

  1. View the sqlnet.ora file and confirm that it does not contain the following

parameter settings:

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.

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

NETWORK_SERVICE_BANNER

————————————————————————————-

TCP/IP NT Protocol Adapter for Linux: Version 12.1.0.2.0 – Production
Encryption service for Linux: Version 12.1.0.2.0 – Production
AES256 Encryption service adapter for Linux: Version 12.1.0.2.0 – Production
Crypto-checksumming service for Linux: Version 12.1.0.2.0 – Production
SHA1 Crypto-checksumming service adapter for Linux: Version 12.1.0.2.0 – Production

Verifying the use of Native Encryption and Integrity

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:

NETWORK_SERVICE_BANNER
————————————————————————————-
TCP/IP NT Protocol Adapter for Linux: Version 12.1.0.2.0 – Production
Encryption service for Linux: Version 12.1.0.2.0 – Production
Crypto-checksumming service for Linux: Version 12.1.0.2.0 – Production

 

Leave a Reply

Your email address will not be published. Required fields are marked *