Oracle Database Tablespace Encryption Behavior in Oracle Cloud (Doc ID 2359020.1)

is Document Purpose Scope Details ENCRYPT_NEW_TABLESPACES Parameter Database releases 11.2.0.4 and 12.1.0.2 Database release 12.2.0.1 (with April'17 PSU - 17.3.1 / July 7th) and all future versions. Database release 12.2.0.1 (pre-April '17 PSU) Summary: Database Releases Encryption in the cloud Hybrid DR Deployment Considerations Unencrypted On-Premises and Unencrypted Cloud Primary: Unencrypted On-Premises | Standby: Encrytped Cloud Primary: Encrypted Cloud | Standby: Unencrypted On-Premises General Considerations Table: On-Premises Unencrypted Primary | Cloud Encrypted Standby Table: Cloud Encrypted Primary | On-Premises Unencrypted Standby Additional Encryption Notes References APPLIES TO: Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) Gen 2 Exadata Cloud at Customer Oracle Cloud Infrastructure - Exadata Cloud Service Linux x86-64 on Oracle Public Cloud PURPOSE The purpose of this document is to describe the behavior of Transparent Data Encryption in an Oracle Cloud environment. Oracle Database Cloud Services, including Exadata Cloud Service and Cloud@Customer, require TDE Encryption be enabled for all tablespaces by policy. SCOPE This document describes how Oracle Database Tablespace Encryption works for the following use cases: New tablespaces created in a Database deployed in Cloud Tablespaces that have been migrated to Cloud from an on-premises Database Tablespaces in a standby database in Cloud with its corresponding primary database located on-premises (i.e. a Hybrid DR configuration) This document is related to Database Releases: 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c and 19c (and beyond) Applies to Oracle Database Cloud Service (PaaS) including Exadata Cloud Service, Exadata Cloud at Customer. DETAILS ENCRYPT_NEW_TABLESPACES Parameter By default, all new tablespaces created in the cloud are encrypted for all database releases. However, you can change that behavior for 11.2 and 12.1 databases. The behavior of tablespace encryption in Cloud is controlled by the initialization parameter ENCRYPT_NEW_TABLESPACES. This parameter has the following attributes: ENCRYPT_NEW_TABLESPACES=CLOUD_ONLY is the default setting. Any new tablespaces created will be transparently encrypted with the AES128 algorithm unless a different algorithm is specified on the ENCRYPTION clause in the CREATE TABLESPACE statement. For on-premises databases, tablespaces will only be encrypted if the CREATE TABLESPACE ENCRYPTION clause is specified. This is the same behavior for all database releases.(11.2, 12.1, and 12.2) ENCRYPT_NEW_TABLESPACES=ALWAYS. Any new tablespace created on-premises or in the cloud will be transparently encrypted with the AES128 algorithm unless a different encryption algorithm is specified on the CREATE TABLESPACE ENCRYPTION clause. This is the same behavior for all releases (11.2, 12.1, and 12.2). ENCRYPT_NEW_TABLESPACES=DDL. This option allows users to create tablespaces with or without encryption following the CREATE TABLESPACE command, and also users can change the encryption algorithm. Database releases 11.2.0.4 and 12.1.0.2 For both these database releases, new tablespaces created in the cloud are encrypted using AES128 algorithm. By changing the ENCRYPT_NEW_TABLESPACES parameter value to "DDL", users can create unencrypted tablespaces using CREATE TABLESPACE command. Users can also change to other encryption algorithms. So, for database releases 11.2.0.4 and 12.1.0.2, for all the 3 use cases, users can deploy, create and open unencrypted tablespaces in the cloud.  Database release 12.2.0.1 (with April'17 PSU - 17.3.1 / July 7th) and all future versions. All new 12.2 deployments in the cloud are using this 12.2 image. (Fix for Bug 25410877) Use case: New tablespace creation in cloud: Any new tablespace created in the cloud is encrypted using AES128 algorithm. Unencrypted tablespace creation is not allowed. The operation errors out. However, customers can change the encryption algorithm. Use case: Migration to cloud: Users can back up an unencrypted 12.2 CDB database to cloud (object storage) and restore it to a cloud database. They can also use RMAN RESTORE AS ENCRYPT command to restore the database as an encrypted database. Unencrypted data can also be moved to the cloud using other migration techniques including Data Guard (with TDE conversion, upgrades etc.) and GoldenGate. Note that migration to Oracle cloud using backup & restore must be a CDB for 12.1 and above. Use case: Hybrid DR: In a Hybrid DR case, customers may have an unencrypted primary database on-premises and the corresponding standby database in cloud. Users can instantiate the unencrypted standby database from on-premises to cloud using RMAN DUPLICATE, or RESTORE from the object storage. When new unencrypted tablespaces are created on the on-premises primary database, the standby database creates corresponding unencrypted tablespace via redo. However, following any failover/switchover to the cloud standby, which now becomes the new primary, if any new tablespace is created on this new primary, that will be encrypted. This poses challenges while synching back with the on-premises unencrypted standby, or after a failback. For example, if the on-premises database is not licensed for ASO, they cannot access the encrypted tablespace. Thus, for a Hybrid DR use-case, users are strongly advised to license ASO for their on-premises deployments, which allows them to use tablespace encryption, or they should not create any new tablespaces in the cloud after a role transition event. Database release 12.2.0.1 (pre-April '17 PSU) Following is the behavior for any deployments prior to pre-April PSU, or an image without patch for Bug 25410877. Use case: New tablespace creation in cloud: The creation of unencrypted tablespace completes without an error. However, after the instance is restarted, opening of those encrypted tablespaces errors out. Use case: Migration to cloud: Users can migrate unencrypted database to the cloud, but they cannot open the database. Use case: Hybrid DR: Users can deploy a hybrid DR configuration with unencrypted tablespaces. However, when they try to open the database (e.g. after a role transition or open as a Read Only standby with Active Data Guard), the operation fails. Bug 25410877 was created to address the above behavior. Summary: Database Releases Encryption in the cloud Oracle Database 11.2.0.4 and 12.1.0.2: Unencrypted databases can be deployed in cloud using migration or hybrid DR techniques, and new unencrypted tablespaces can be created. Oracle Database 12.2.0.1, pre- April'17 PSU: Unencrypted databases can be deployed using migration or hybrid DR techniques, but these cannot be opened subsequently in the cloud. Any new tablespace created in the cloud can be created as unencrypted, but subsequent reopen of the database will error out. Oracle Database 12.2.0.1, post-April'17 PSU or higher: Unencrypted databases can be deployed in cloud using migration or hybrid DR techniques. Any new tablespace created in the cloud will be encrypted. A one-off patch for Bug 25410877 is available for Oracle Database 12.2.0.1. Patch 25875415: applied on Wed Apr 26 17:47:00 UTC 2017 Unique Patch ID: 21186339 Created on 24 Apr 2017, 01:10:30 hrs PST8PDT Bugs fixed: 25410877, 25662088 The table below summarizes current behavior for Unencrypted Tablespace Support: Database Releases New Unencrypted Tablespace Creation Allowed? Open Unencrypted Tablespace? Migrated Unencrypted Tablespaces can be Opened? Hybrid DR with Unencrypted Tablespaces can be Opened? 11.2 Yes Yes Yes Yes 12.1 Yes Yes Yes Yes 12.2 (Pre-April'17 PSU) Yes No No No 12.2 (Post-April '17 PSU) and higher No Yes Yes Yes Hybrid DR Deployment Considerations Oracle strongly recommends deploying encrypted databases in both on-premises and cloud. But for many reasons, customers may choose not to encrypt their on-premises database (primary or standby). This section provides additional details and cosiderations. Unencrypted On-Premises and Unencrypted Cloud Customers can choose to deploy unencrypted databases on both on-premises and cloud. It doesn't matter which site is primary and which is standby. In this model, With Database releases 11.2 and 12.1, no data is encrypted on both sites irrespective of whether the cloud is primary or standby. However, when deployed with Database 12.2 and above, when the cloud becomes the primary, any new tablespace created WILL BE ENCRYPTED. The corresponding on-premises standby requires the same wallet used in the cloud primary to decrypt the data. Hence customers have to get ASO license. If customers do not prefer to get ASO license, then they should not create any new tablespace in the cloud. Primary: Unencrypted On-Premises | Standby: Encrytped Cloud Customers can choose to deploy unencrypted on-premises primary and encrypted standby in the cloud. In this model, All new tablespaces created on-premises will be created as unencrypted tablespaces in the cloud standby. Requires manual offline encryption of new files in the cloud. New and changed blocks are NOT encrypted on-premises (Primary). Blocks applied via recovery to the encrypted data files on the cloud standby ARE encrypted. Redo logs and archived redo logs are not encrypted on both sites. Scenario: After a role change of database release 11.2 or 12.1, the unencrypted on-premises becomes the primary site. The database is upgraded to 12.2. In this condition, before the database key is re-keyed, it is strongly recommended to decrypt tablespaces using the existing key. Otherwise, the previous key that was used to encrypt blocks is lost and hence renders already encrypted blocks to be non-decryptable and shows up as corrupted blocks. Primary: Encrypted Cloud | Standby: Unencrypted On-Premises When the cloud becomes a primary after a role switch (or) when the cloud database is deployed as a primary site and on-premises as a standby, following are to be considered: New tablespaces created in the cloud ARE encrypted on both sites. With Database 12.2, tablespaces can be manually decrypted. New and changed blocks ARE encrypted in the cloud (Primary). All redo logs and archived logs ARE encrypted in all sites. Blocks applied to on-premises standby are decrypted and stored as unencrypted data (12.2). For 11.2 or 12.1, on-premises data is stored as encrypted data. Hence ASO licensing is required to decrypt and read the data into the buffer cache. Unencrypted on-premises tablespace could contain encrypted data. ASO is required for on-premises. General Considerations Oracle strongly recommends encrypting both on-premises and cloud. Oracle supports unencrypted on-premises and encrypted cloud with Data Guard. ASO is required to encrypt/decrypt data when using database after a role transition. This configuration may lead to have unencrypted data in the cloud and encrypted data on-premises. Table: On-Premises Unencrypted Primary | Cloud Encrypted Standby This may be a typical case when doing a database cloud migration using Data Guard. Operation On-Prem Primary 11.2 Cloud Standby 11.2 On-Prem Primary 12.1 Cloud Standby 12.1 On-Prem Primary 12.2 (and higher) Cloud Standby 12.2 (and higher) Remarks DG initial Setup for on-prem Primary & cloud Standby Unencrypted Encrypted Unencrypted Encrypted Unencrypted Encrypted Standby is manually encrypted after instantiation New Tablespace Creation on-prem primary Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted Requires manual TDE conversion for Standby DB Redo generated in on-prem primary Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted Archived logs Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted New and changed blocks Unencrypted Encrypted* Unencrypted Encrypted* Unencrypted Encrypted* * Redo shipped from the on-prem primary to the cloud is not encrypted Recovery in the cloud standby N/A Encrypted* N/A Encrypted* N/A Encrypted* *Redo shipped from the on-prem primary to the cloud is not encrypted Table: Cloud Encrypted Primary | On-Premises Unencrypted Standby You may get into this state in a hybrid Data Guard or in a cloud migration scenario. Operation Cloud 11.2 Primary On-Premises 11.2 Standby Cloud 12.1 Primary On-Premises 12.1 Standby Cloud 12.2 Primary (and higher) On-Premises 12.2 Standby (and higher) Remarks New Tablespace Creation in cloud primary Encrypted Encrypted Encrypted Encrypted Encrypted Encrypted ASO required for on-prem to decrypt Redo generated in cloud primary Encrypted Encrypted Encrypted Encrypted Encrypted Encrypted ASO required for on-prem to decrypt Archived logs Encrypted Encrypted Encrypted Encrypted Encrypted Encrypted ASO required for on-prem to decrypt New and changed blocks for existing unencrypted Tablespace on standby Encrypted Encrypted* Encrypted Encrypted* Encrypted Unencrypted ASO required for on-prem to decrypt and encrypt. * For 11.2 & 12.1 blocks are encrypted if redo is encrypted Recovery in the on-prem standby N/A Encrypted N/A Encrypted N/A Unencrypted data depends on whether the datafile is encrypted ASO required for on-prem Additional Encryption Notes Oracle does not support encrypting SYSTEM/SYSAUX prior to database release 19.1. The main reason is, once the SYSTEM/SYSAUX is encrypted, wallet can never be closed. Similar restriction is applicable to UNDO/TEMP tablespaces. If customers really want to encrypt SYSTEM/SYSAUX before it is officially supported, they should use SSO wallet. Starting 11gR1 onwards, even though TEMP and UNDO tablespaces were created as UNENCRYPTED tablespaces, the blocks that are part of encrypted tablespaces are stored in TEMP/UNDO are automatically encrypted. For example, if an undo block is used to store undo generated for data for an encrypted tablespace, or if a query involves data from encrypted tablespaces requires a temp block, Oracle will automatically encrypt the corresponding undo and temp blocks.