An Oracle White Paper March Oracle Transparent Data Encryption for SAP

Transcription

1 An Oracle White Paper March 2010 Oracle Transparent Data Encryption for SAP

2 Introduction Securing sensitive customer data has become more and more important in the last years. One possible threat is confidential data lost either by data theft internal or external or by gaining unauthorized access to a physical storage media containing the data accidently or not. Storage media can be a hard disk (or a laptop) with the original data or e.g. a CD, DVD, USB device, tape, or something similar where a backup of the data(base) could be stored. While Oracle provides for data theft several database options like Oracle Database Vault, the data located in the datafiles can be secured by Oracle Transparent Data Encryption (hereinafter: TDE). With TDE the (sensitive) customer data is encrypted using common standardized ciphering methods: 3DES168, AES128, AES192, or AES256 The key focus of TDE is that, even if the data is ciphered, there are no modifications necessary to the application. Or in other words the encryption is transparent for the application. With TDE for Oracle Database 10.2 some restrictions apply. With this version of TDE it was only possible to cipher single columns. Also the data in all indexes referring to these encrypted columns are ciphered. Nevertheless it already added a big value to the customers. With TDE for Oracle Database 11.2 it is now additionally possible to encrypt whole tablespaces with all data inside. So now with Oracle 11.2 there are available: 1. TDE column encryption 2. TDE tablespace encryption 2

3 The principle of Transparent Data Encryption The idea behind TDE is to encrypt the sensitive data when it is physically stored in database files. This means if unauthorized access of one or more datafiles was achived the sensitive data is still not compromised. The method to encrypt and decrypt the data is a two-tired, key-based architecture: 1. The so-called TDE Master Key is stored ciphered in an external Oracle Wallet (file), secured by a password. This should only known by the Security Administrator or the Database Administrator, if a Security Administrator was not yet constituted. 2. This master key is then used to unlock the a. table encryption key (TDE column encryption) b. tablespace encryption key (TDE tablespace encryption) which is then used to encrypt/decrypt the data stored either in the column(s) of the table or in the whole tablespace. Each table or tablespace respectively has its own encryption key. These keys are all stored in the database dictionary. So it is mandatory not to store the Oracle Wallet password in no way together with the database (backup). In the redolog files the confidential data, when encrypted in the datafiles, is encrypted also. Licensing of TDE TDE is part of the Advanced Security Option (ASO), which is contained in the Oracle database license offered by SAP. If the database license is bought directly from Oracle it has to be in the license scope prior using TDE. Installing TDE Requirements There are no requirements for TDE. Software installation for TDE 3

4 TDE is part of the Oracle Advanced Security Option (ASO). As ASO is installed by default in the Oracle Database installation for a SAP system, there is no separate software stack to be installed for TDE. TDE just needs to be configured: Configuration of TDE TDE configuration is done in 2 steps: 1. The external, password secured, Oracle Wallet file is created in a defined location on the database server. This Wallet is containing the TDE master key. 2. Then in this 2nd step the encryption on table column level and/or tablespace level can be set up: a. by creating a new table where one or more columns are encrypted. b. by altering an existing table so that one or more columns got encrypted. c. by creating a new encrypted tablespace Remark: An existing tablespace cannot be encrypted later on, but the with the Oracle Online Redefinition feature all tables of an existing tablespace can be moved to a newly created encrypted tablespace. TDE and BR*Tools Working with TDE is implemented in the SAP BR*Tools. Changes resulting from TDE As previously mentioned, the encryption and decryption process is transparent to the application. So there are no modifications in the application necessary. 4

5 Besides this the only exception is that after starting the database the Oracle Wallet must be opened using the password prior accessing the ciphered data. Performance The handling of the ciphered data has a slight performance impact in the following areas depending whether TDE column encryption or TDE tablespace encryption is used: CPU (TDE column encryption) Consider the entire application, on average the additional CPU utilization for encryption and decryption in common less than five percent (5%). There is no performance impact for SQL statements accessing non-ciphered data only. Nevertheless in case of a single SQL statement handling ciphered data, it could be significantly higher. CPU (TDE tablespace encryption) Accessing non-ciphered tablespaces also does not require additional resources. In fact for the entire application, on average the additional CPU utilization for encryption and decryption is around five percent (5%). Memory (TDE column encryption) Encrypting an individual column requires between 33 and 40 bytes of extra memory for each entry. For a table with k TDE encrypted columns and n lines, you would need a maximum of n * k * 48 bytes of extra memory in the database for TDE column encryption. Using the NOMAC and the NO SALT option some space can be regained. Due to the additional memory required, encrypting with 'ALTER TABLE... ENCRYPT' may create a very large number of chained rows. Memory (TDE tablespace encryption) 5

6 In contrast to TDE tablespace encryption a table in an encrypted tablespace does not need more space. Changing access plans (TDE column encryption) If you want to encrypt columns that are part of an index, this index can then only be used in an equality ( = ) search. For other access types like <, <=, >=, >, like on a ciphered column the index cannot be used. This leads to a different access like Full Table Scan which then causes significant longer response times. On columns encrypted with SALT option, no indexes can be created. Changing access plans (TDE tablespace encryption) If case of TDE tablespace encryption these restrictions are no longer in place. General restrictions TDE column encryption With TDE column encryption there are some restrictions in place as e.g. the data types CLOB, BLOB, LONG, LONG RAW and Oracle Dictionary tables belonging to the SYS user cannot be encrypted. Not working are also indexes sorted in descending order, range-scan search through an index, other index types other than standard-b tree and export/import with exp and imp. TDE tablespace encryption The following list includes the restrictions that apply to TDE tablespace encryption: External Large Objects (BFILEs) cannot be encrypted using TDE tablespace encryption. This is because these files reside outside the database. Original import/export utilities are not supported. Use the Oracle Data Pump utility instead. 6

7 General recommendations Based on the restriction with TDE column encryption there is a great advantage when using TDE tablespace encryption. TDE and other Oracle database option Implementing TDE does include using encryption for other database options also. Secure files Secure files the successor of the old LOB files can be ciphered, in contrast to the LOBs which can t be encrypted using TDE column encryption. Data Guard TDE supports Oracle DataGuard in a physical standby configuration. There is no modification necessary. Only each time the master key is changed, the modified encryption wallet must be transferred to all attached standby databases. For automatic switch to the standby side without manual intervention, it is possible to use a so called auto-open wallet on the standby side. RAC In SAP systems all Oracle instances share one single Oracle Home on the cluster file system. Thus TDE is active for all RAC instances equally. RMAN Using TDE provides the additional advantage to use encrypted RMAN savesets. This means that in the savesets (=backupsets) can be encrypted without human intervention when using an Oracle Wallet. This feature is supported by the BR*Tools. More information about TDE The Oracle 11g documentation contains more details about TDE. 7

8 TDE current status TDE can be used for Oracle/SAP systems without any further restrictions. 8

9 Oracle Database SAP September 2009 Author: Marc Ströhle Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Worldwide Inquiries: Phone: Fax: oracle.com Copyright 2009, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. 0209