Converting to Transparent Data Encryption with Oracle Data

Converting To Transparent Data Encryption With Oracle Data-Free PDF

  • Date:19 Nov 2020
  • Views:0
  • Downloads:0
  • Pages:18
  • Size:427.96 KB

Share Pdf : Converting To Transparent Data Encryption With Oracle Data

Download and Preview : Converting To Transparent Data Encryption With Oracle Data


Report CopyRight/DMCA Form For : Converting To Transparent Data Encryption With Oracle Data


Transcription:

Table of Contents,Table of Contents 0,Introduction 1. Prerequisites 1,High Level Steps 1,Transparent Data Encryption Overview 2. TDE Offline Data File Encryption Restrictions 2,Conversion Overview 3. Prerequisites 3,Conversion Example 3, Enabling Transparent Data Encryption for Oracle 11 2 4. Enabling Transparent Data Encryption for Oracle 12 1 and 12 2 6. Convert Data Files 8,Asymmetrical Configurations 12.
Hardware Keystore 13,Logical Standby Considerations 13. Decrypt 13,Conclusion 13, Appendix A Alternative Methods to Convert to TDE 15. CONVERTING TO TRANSPARENT DATA ENCRYPTION USING DATA GUARD PHYSICAL STANDBY. Introduction, With an increasing number of applications requiring 24 7 availability both unplanned outages and planned downtime. become a significant concern The Oracle Cloud also requires that production databases be encrypted using Oracle. Advanced Security Transparent Data Encryption TDE To minimize downtime required to encrypt an unencrypted. database either for migration to the cloud or to provide additional security for on premises databases Oracle. Database 12c and Oracle Database 11 2 0 4 now enable offline in place conversion of data files to TDE Combining. this capability with Data Guard physical standby enables production workloads to run unaffected on an unencrypted. primary database while its standby is converted to TDE Regardless of the size of the database total downtime is. limited to a brief brownout while application connections are switched to the new encrypted copy of production a. Data Guard switchover after the process is complete This new functionality is enabled by a patch for 12 1 0 2 and. 11 2 0 4 that must be requested from Oracle Support See My Oracle Support Note 2148746 1 for instructions on. how to access the patch, Once installed the patch enables offline in place TDE conversion of data files at a Data Guard standby with a DDL. command instead of having to reload data which can be time consuming tedious and in some cases complex The. patch must be applied to all Oracle Homes in the Data Guard configuration This process is the recommended. Oracle Maximum Availability Architecture best practice for converting to TDE with minimal downtime and least. complexity This supersedes previous methods for converting to TDE described in Appendix A Alternative Methods. Whether you have an existing physical standby database or are using a new physical standby database deployed. solely for facilitating conversion to TDE the process of conversion includes the following. NOTE As of Oracle Database 12 2 Online encryption can be performed against a primary database which in turn. encrypts the standby See Encryption Conversions for Existing Online Tablespaces in the 12 2 documentation for. more details,Prerequisites, See MOS 2148746 1 for the most recent information on the patch to the database home for the primary and.
standby databases required by this process,Take or ensure there is a viable backup available. Understand TDE implications and restrictions and develop a process for maintaining wallets and keys Refer to. the Oracle Database Advanced Security Administrator s Guide 11 2 12 1 12 2 and MOS 1228046 1 for further. High Level Steps, 1 Verify that the Data Guard configuration is healthy and contains no gaps. 2 Create the encryption wallet and set the master key. 3 Copy the wallet files to the standby database environment. 4 Place the standby in a mounted state with recovery stopped. 5 On the standby Encrypt data files in place and in parallel. 6 On the standby Restart redo apply and catch up, 7 Execute a Data Guard switchover making the encrypted standby the new primary and the unencrypted primary. the new standby, 8 On the NEW standby Place the new standby database in a mounted state with recovery stopped. 1 CONVERTING TO TRANSPARENT DATA ENCRYPTION USING DATA GUARD PHYSICAL STANDBY. 9 On the NEW standby Encrypt data files in place and in parallel. 10 On the NEW standby Restart redo apply and catch up. 11 Optionally execute a Data Guard switchover to reestablish the original configuration. This Oracle Maximum Availability Architecture Oracle MAA best practices white paper is intended for database. administrators who wish to convert a non encrypted Oracle Database to TDE with minimal downtime This paper. assumes the reader has a technical understanding of Data Guard and TDE. As always be sure to execute and verify this process in a test environment before executing in production. Transparent Data Encryption Overview, Transparent Data Encryption TDE provides encryption of data at rest in an Oracle database At rest implies that.
the data is encrypted at the operating system and storage level where data is stored TDE decrypts data. transparently when it hits the buffer cache where it is subject to normal database authentication and authorization. There are two forms of TDE encryption TDE column encryption encrypts specific columns of data while TDE. tablespace encryption encrypts all data within a TDE encrypted tablespace Tablespace encryption takes advantage. of bulk encryption to enhance performance while relieving the administrator of the task of analyzing each column to. determine which should be encrypted Additionally there are fewer restrictions with tablespace encryption compared. to column encryption This paper describes how to convert to TDE tablespace encryption TDE tablespace. encryption is available in Oracle Database 11g Release 1 11 1 and higher. Refer to the Oracle Database Advanced Security Administrator s Guide and MOS 2359020 1 for full details. regarding TDE encryption1,TDE Offline Data File Encryption Restrictions. There are few restrictions with TDE tablespace encryption because encrypt decrypt takes place during read write as. opposed to the SQL layer with column encryption TDE tablespace encryption restrictions are. External Large Objects BFILEs cannot be encrypted using TDE tablespace encryption because these files. reside outside the database, To perform import and export operations on TDE encrypted tablespaces you must use Oracle Data Pump. The offline encryption process described in this paper will use the AES128 encryption algorithm with the key. identifier listed in V DATABASE KEY INFO, This process is only for application tablespace data files SYSTEM SYSAUX and TEMP tablespaces cannot be. encrypted with TDE prior to Oracle Database version 12 2 0 1 While SYSTEM and SYSAUX can be encrypted. for 12 2 it is not yet recommended, Oracle does not recommend encrypting offline the UNDO tablespace in these releases Doing so prevents the. keystore from being closed and this prevents the database from functioning In addition encrypting the UNDO. tablespace while the database is offline is not necessary because all undo records that are associated with any. encrypted tablespaces are automatically encrypted in the UNDO tablespace. 1 https docs oracle com database 121 ASOAG asotrans htm ASOAG10117. 2 CONVERTING TO TRANSPARENT DATA ENCRYPTION USING DATA GUARD PHYSICAL STANDBY. The UNDO and TEMP metadata that is generated from sensitive data in an encrypted tablespace is already. automatically encrypted Therefore encrypting UNDO and TEMP is optional. Conversion Overview, There are many configuration options for TDE tablespace encryption including but not limited to the type of keystore.
and storage used This document describes the most common options Refer to the Database Advance Security. Guide for your specific version for full details 11 2 12 1 12 2. Prerequisites, This process requires the following prerequisites to ensure a successful execution. There is an existing physical standby database, A current backup has been taken of the database prior to converting data files. The patch described in MOS 2148746 1 has been applied to both primary and standby RDBMS installation. COMPATIBLE is set to 12 2 0 1 12 1 0 2 or 11 2 0 4 respectively. Oracle MAA Best practices require the primary database to have forced logging enabled This is required for. replication and will protect against unrecoverable objects during role transition To ensure there are no. unrecoverable blocks the following query at the primary database should return no rows See MOS 290161 1 for. additional details on nologging operations and handling. SQL select NAME from V DATAFILE where UNRECOVERABLE CHANGE 0. no rows selected, Note If UNRECOVERABLE CHANGE is 0 for any datafile compare the value on the primary to the value on the. standby If they are the same the datafile was copied after the unrecoverable change and no action is necessary. A log archive destination LAD must be set for each database to transport redo when it is a primary database If. the broker is configured and utilized as per MAA best practices the LAD will be set automatically after the role. transition,Conversion Example, TDE utilizes wallets and keystores to store the master encryption key While the default database wallet can be. used Oracle recommends using a separate wallet for TDE by using the ENCRYPTION WALLET LOCATION. parameter in sqlnet ora Additionally using an auto login wallet relieves the administrator from opening the wallet. manually each time the database is started, The wallet will be created on the primary database and must be manually copied to the standby environment In.
RAC configurations the MAA best practice is to create the wallet in a shared location such as an ASM disk group If. no shared storage is available the wallet must be copied to all nodes of the primary and standby clusters. If the database is already using an encryption wallet or keystore the same may be reused but Oracle recommends. a new master key be set, 3 CONVERTING TO TRANSPARENT DATA ENCRYPTION USING DATA GUARD PHYSICAL STANDBY. Enabling Transparent Data Encryption for Oracle 11 2. NOTE The new wallet should not be used for encryption on the primary database until the end of this process A. database bounce is required for all database processes to pick up the wallet location from the sqlnet ora which is. being deferred at the initial primary until the switchover. 1 Set the encryption wallet location, NOTE ASM storage of the encryption wallet is not supported until RDBMS version 12 1 0 1. Set the wallet location in the sqlnet ora on all nodes of primary and standby. ENCRYPTION WALLET LOCATION,SOURCE METHOD FILE,METHOD DATA. DIRECTORY u01 app oracle admin TDE ORACLE UNQNAME, NOTE Using an environment variable like ORACLE UNQNAME in the directory path ensures that all databases on a. shared system use their own wallet Using this environment variable requires that the variable be set in CRS where. applicable and the OS user s environment, 2 Create the corresponding directory on all nodes or shared storage with the proper ORACLE UNQNAME.
mkdir p u01 app oracle admin TDE ORACLE UNQNAME, 3 Set the environment variable in CRS if applicable and for the OS session. srvctl setenv database d ORACLE UNQNAME T ORACLE UNQNAME ORACLE UNQNAME. export ORACLE UNQNAME ORACLE UNQNAME, NOTE Set the ORACLE UNQNAME variable in login scripts or environment scripts as well Any session that may. start the database or instance must have the variable set in order to find the wallet. 4 CONVERTING TO TRANSPARENT DATA ENCRYPTION USING DATA GUARD PHYSICAL STANDBY. 4 Initiate a new SQL Plus session This causes the changes to sqlnet ora and the environment variable to be. picked up by the new session,5 Set the Master Encryption Key. SQL ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY AbCdEfGh. This step may cause redo apply to stop on the standby It can be restarted once the wallet is copied to the standby. in the step 8, NOTE Ensure that the password string is contained in double quotation marks. 6 Open the wallet, SQL ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY AbCdEfGh.
System altered,7 Create auto login wallet, An auto login wallet removes the requirement of manually opening the wallet when the database is started. orapki wallet create wallet u01 app oracle admin TDE ORACLE UNQNAME auto login. 8 Copy the files generated in the keystore directory to all nodes of the primary and standby. Copy files to each node,scp u01 app oracle admin TDE ORACLE UNQNAME. oracle host u01 app oracle admin TDE ORACLE UNQNAME. 9 Restart the standby database to mounted mode,Ensure ORACLE UNQNAME is set properly and. SQL shutdown immediate,SQL startup mount, 5 CONVERTING TO TRANSPARENT DATA ENCRYPTION USING DATA GUARD PHYSICAL STANDBY. srvctl stop database d standby DB,srvctl start database d standby DB o mount.
10 Ensure the wallet is open on all nodes,SQL select from gv encryption wallet. INST ID WRL TYPE WRL PARAMETER STATUS, 1 file u01 app oracle admin TDE ORACLE UNQNAME OPEN. Enabling Transparent Data Encryption for Oracle 12 1 and 12 2. TDE utilizes keystores to store the master encryption key Oracle recommends using a specific wallet for TDE by. using the ENCRYPTION WALLET LOCATION parameter in sqlnet ora Additionally using an auto login keystore. relieves the administrator from opening the keystore manually each time the database is started. The keystore will be created on one primary instance and must be manually copied to the standby database. environment,1 Create encryption keystore, Set the keystore location in the sqlnet ora on all nodes of primary and standby. ENCRYPTION WALLET LOCATION,SOURCE METHOD FILE,METHOD DATA. Converting to Transparent Data Encryption with Oracle Data Guard using Fast Offline Conversion Oracle Database 12c and Oracle Database 11 2 OR ACL E WH IT E P AP E R AU GU ST 2018 CONVERTING TO TRANSPARENT DATA ENCRYPTION USING DATA GUARD PHYSICAL STANDBY Table of Contents Table of Contents 0 Introduction 1 Prerequisites 1 High Level Steps 1 Transparent Data Encryption Overview 2 TDE

Related Books