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> ]
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 WalletAn 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 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:
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:
Here is the syntax to create a wallet from the OS:
$ mkstore -wrl $ORACLE_BASE/admin/$ORACLE_SID/wallet -create
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.
The search order for finding the wallet is as follows:
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.
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;
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
encryption using 'AES256'
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;
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
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:
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29653765/viewspace-1821330/，如需转载，请注明出处，否则将追究法律责任。