Tablespace Encryption in Oracle 11g R1(原创)

Overview

In Oracle Database 10g, Oracle introduced the new Transparent Data Encryption (TDE) feature, which let you easily encrypt a column’s data in a table. The encryption is called transparent because the Oracle database takes care of all the encryption and decryption details, with no need for you to manage any tables or triggers to decrypt data. Now, in Oracle Database 11g, you can encrypt an entire tablespace by simply using a pair of special clauses during tablespace creation. The tablespace creation statement for an encrypted tablespace has the following syntax:

create tablespace <tbsp_name>
encryption [ using<encrypt_code> ]
default storage(encrypt)
The encryption clause in line 2 doesn’t actually encrypt the tablespace. You provide the encryption properties by setting values for the keyword encryption. You may additionally specify the using clause along with the encryption clause (encryption using    . . .) to specify the name of the encryption algorithm you want to use, such as 3DES168, AES128, AES192, and AES256. If you want to use the default algorithm of AES128, you can omit the using clause altogether. It is the encrypt keyword passed to the storage clause in line 3 that encrypts the tablespace.

Creating the Oracle Wallet

An Oracle Wallet is a container to store authentication and signing credentials. The tablespace encryption feature uses the wallet to protect the master key used in the encryption. There are two kinds of Oracle wallets—encryption wallets and auto-open wallets. You must manually open an encryption wallet after database startup, whereas the auto-open wallet automatically opens upon database startup. The encryption wallet is commonly recommended for tablespace encryption, unless you’re dealing with unattended Data Guard environments, in which case the automatic opening of the wallet comes in handy.
TDE tablespace encryption uses the two-tiered, key-based architecture to transparently encrypt (and decrypt) tablespaces. The TDE master key is stored in an external security module (Oracle Wallet or HSM). This TDE master key is used to encrypt the TDE tablespace encryption key, which in turn is used to encrypt and decrypt data in the tablespace.

 

 

TDE tablespace encryption also allows index range scans on data in encrypted tablespaces. This is not possible with TDE column encryption.
Oracle Database 11g Release 2 (11.2) implements the following enhancements to TDE tablespace encryption:

• A unified master encryption key is used for both TDE column encryption and TDE tablespace encryption.
• You can reset the unified master encryption key. This provides enhanced security and helps meet security and compliance requirements.

In order to use Oracle Wallet, you must create the wallet itself and then add a master key to it.Oracle stores the encryption keys outside the database, in a file called an Oracle Wallet. By default, this file is named ewallet.p12 under both Windows and UNIX/Linux-based systems.

You can create a wallet in a couple of ways. You can create the Oracle Wallet by:

• Using the mkstore command from the operating system command line
• Invoking the Oracle Wallet Manager either through a GUI interface or by issuing the command owm at the command line
• Executing the alter system statement from SQL*Plus

Here is the syntax to create a wallet from the OS:
$ mkstore -wrl $ORACLE_BASE/admin/$ORACLE_SID/wallet -create
Enter password:
Enter password again:
However, the simplest way to create the wallet is to simply use the following command in SQL*Plus:
SQL> alter system set encryption key identified by "password";
This command both creates the wallet if it doesn’t already exist and adds a master key to it.

If you already have an Oracle Wallet, it opens that wallet and creates (or re-creates) the master encryption key.
If you don’t have an Oracle Wallet already, it creates a new wallet, opens the wallet, and creates a new master encryption key.

Strongly recommending.
The search order for finding the wallet is as follows:

1. If present, the location specified by the ENCRYPTION_WALLET_LOCATION parameter in the sqlnet.ora file.
2. If present, the location specified by the WALLET_LOCATION parameter in the sqlnet.ora file.
3. The default location for the wallet ($ORACLE_BASE/admin/$ORACLE_SID/wallet).

Although encrypted tablespaces can share the default database wallet, Oracle recommend you use a separate wallet for transparent data encryption functionality by specifying the ENCRYPTION_WALLET_LOCATION parameter in the sqlnet.ora file. To accomplish this we add the following entry into the sqlnet.ora file on the server and make sure the specified directory has been created.
ENCRYPTION_WALLET_LOCATION=
  (SOURCE=(METHOD=FILE)(METHOD_DATA=
    (DIRECTORY=/u01/app/oracle/admin/DB11G/encryption_wallet/)))

Wallets must be reopened after an instance restart and can be closed to prevent access to encrypted data.

ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "myPassword"; 

ALTER SYSTEM SET ENCRYPTION WALLET CLOSE;

Note:

For tablespace encryption, Oracle not add salt before encrypting it. Salt is specified at the column level. That is to say, for encrypted column TDE adds salt to cleartext before encrypting it. This means that an encrypted column in a table can choose not to use salt irrespective of whether other encrypted columns in the table use salt or not. If there are multiple encrypted columns in a table, then all of these columns must use the same pair of encryption and integrity algorithms. This makes it harder for attackers to steal data through a brute force attack. TDE also adds a Message Authentication Code (MAC) to the data for integrity checking. The SHA-1 integrity algorithm is used by default.

Creating an Encrypted Tablespace
SQL> create tablespace encrypted_ts
datafile '/home/oracle/encrypted_ts01.dbf' size 10M
autoextend on
encryption using 'AES256'
DEFauLT storage(ENCRYPT)

The ENCRYPTED column of the DBA_TABLESPACES and USER_TABLESPACES views indicates if the tablespace is encrypted or not.
SQL> SELECT tablespace_name, encrypted FROM dba_tablespaces;
TABLESPACE_NAME                ENC
------------------------------ ---
SYSTEM                         NO
SYSAUX                         NO
UNDOTBS1                       NO
TEMP                           NO
USERS                          NO
ENCRYPTED_TS                   YES
6 rows selected.

Oracle encrypts the data in the tablespace upon writing it and decrypts it upon reading the data. There is no additional memory requirement because the tablespace encryption and decryption aren’t performed in memory, the data has been decrypted before going to memroy, but there is an encryption overhead on I/O. The encrypted data will remain encrypted in both the undo segments as well as the redo logs, in addition to being encrypted in temporary tablespaces during typical operations such as sort and join operations that make use of a temporary tablespace.

If you want to change the key for an encrypted tablespace, the only method in the present release is to create a new tablespace and move all the objects in the encrypted tablespace to the new tablespace. You can then encrypt the new tablespace.

Restrictions on Tablespace Encryption

When you encrypt a column(s) for a table, there are limitations on certain queries. By encrypting the entire tablespace, some of these restrictions are removed. For example, in Oracle Database 10g, if the column is part of a foreign key or used in another Database Constraint, it cannot be encrypted. By encrypting the entire tablespace instead of just a table or tables, this restriction is lifted. Note the following restrictions on tablespace encryption. You

• Can transport an encrypted tablespace only if the two operating system platforms have the same endianness and the same wallet.
• Can’t change the key for an encrypted tablespace.
• Can’t encrypt temporary and undo tablespaces.
• Can’t encrypt bfiles and external tables.
  

Security Considerations
Security considerations for Transparent Data Encryption (TDE) operate within the broader arena of total system security. As a security administrator, you must identify the levels of risk to be addressed and the degrees of sensitivity of data maintained by the site. Costs and benefits must be evaluated for the alternative methods of achieving acceptable protections. In many cases, it makes sense to have separate security administrators, a separate wallet for TDE, and protected backup procedures for encrypted data. Having a separate wallet for TDE permits auto-login for other Oracle components but preserves password protection for the TDE wallet.

Additional security considerations apply to normal database and network operations when using TDE. Encrypted column data stays encrypted in the data files, undo logs, redo logs, and the buffer cache of the system global area (SGA). However, data is decrypted during expression evaluation, making it possible for decrypted data to appear in the swap file on the disk. Privileged operating system users can potentially view this data.
Column values encrypted using TDE are stored in the data files in encrypted form. However, these data files may still contain some clear-text fragments, called ghost copies, left over by past data operations on the table. This is similar to finding data on the disk after a file has been deleted by the operating system.
Old clear-text fragments may be present for some time until the database overwrites the blocks containing such values. If privileged operating system users bypass the access controls of the database, they might be able to directly access these values in the data file holding the tablespace. You can use the following procedure to minimize this risk:

1. Create a new tablespace in a new data file. You can use the CREATE TABLESPACE statement.
2. Move the table containing encrypted columns to the new tablespace. You can use the ALTER TABLE.....MOVE statement. Repeat this step for all objects in the original tablespace.
3. Drop the original tablespace. You can use the DROP TABLESPACE tablespace INCLUDING CONTENTS KEEP DATAFILES statement. Oracle recommends that you securely delete data files using platform specific utilities.
4. Use platform and file system specific utilities to securely delete the old data file. Examples of such utilities include shred (on Linux) and sdelete (on Windows).

参考至:《McGraw.Hill.OCP.Oracle.Database.11g.New.Features.for.Administrators.Exam.Guide.Apr.2008》

              http://www.oracle-base.com/articles/11g/tablespace-encryption-11gr1.php
              http://docs.oracle.com/cd/E11882_01/network.112/e40393/asotrans.htm#ASOAG9552

本文原创，转载请注明出处、作者

如有错误，欢迎指正

邮箱:[e-mail]