Transparent Data Encryption enables you to disguise data in table columns and in an entire tablespace.
Topics:
Oracle Database Advanced Security Guide for detailed information about using tablespace encryption
Encrypted data is data that has been disguised so that only an authorized recipient can read it.
You use encryption to protect data in a potentially unprotected environment, such as data you have placed on backup media that is sent to an offsite storage location.
Encrypting data includes the following components:
An algorithm to encrypt the data. Oracle Databases use the encryption algorithm to encrypt and decrypt data. Oracle Database supports several industry-standard encryption and hashing algorithms, including the Advanced Encryption Standard (AES) encryption algorithm, which has been approved by the National Institute of Standards and Technology (NIST).
A key to encrypt and decrypt data. When you encrypt data, Oracle Database uses the key and plain text data as input into the encryption algorithm. Conversely, when you decrypt data, the key is used as input into the algorithm to reverse the process and retrieve the clear text data. Oracle Database uses a symmetric encryption key to perform this task, in which the same key is used to both encrypt and decrypt the data. The encryption key is stored in the data dictionary, but encrypted with another master key.
You can encrypt individual table columns or an entire tablespace. Be careful that you do not mix the two. For example, suppose you encrypt a table column and then encrypt its surrounding tablespace. This double encryption can cause performance problems. In addition, column encryption has limitations in data type support, and only supports B-tree indexes for equality searches. To check the current encrypted settings, you can query the V$ENCRYPTED_TABLESPACES
data dictionary view for tablespaces and the DBA_ENCRYPTED_COLUMNS
view for encrypted columns.
In most cases, you must encrypt sensitive data on your site to meet a regulatory compliance. For example, sensitive data such as credit card numbers, Social Security numbers, or patient health information must be encrypted.
Historically, users have wanted to encrypt data to restrict data access from their database administrators. However, this problem is more of an access control problem, not an encryption problem. You can address this problem by using Oracle Database Vault to control the access to your application data from database administrators.
In most cases, you encrypt sensitive data, such as credit cards and Social Security numbers, to prevent access when backup tapes or disk drives are lost or stolen. In recent years, industry regulations such as the Payment Card Industry (PCI) Data Security Standard and the Healthcare Insurance Portability and Accountability Act (HIPAA) have become a driving factor behind increased usage of encryption for protecting credit card and health care information, respectively.
Transparent Data Encryption enables you to encrypt individual table columns or an entire tablespace.
When a user inserts data into an encrypted column, Transparent Data Encryption automatically encrypts the data. When authorized users select the column, then the data is automatically decrypted.
To encrypt data by using Transparent Data Encryption, you create the following components:
A keystore to store the master encryption key. The keystore is an operating system file that is located outside the database. The database uses the keystore to store the master encryption key. To create the keystore, you can use the ADMINISTER KEY MANAGEMENT
SQL statement. The keystore is encrypted using a password as the encryption key. You create the password when you create the keystore. Access to the contents (or master key) of the keystore is then restricted to only those who know the password. After the keystore is created, you must open the keystore using the password so that the database can access the master encryption key.
You can use either software keystores or hardware keystores. A software keystore is defined in a file that you create in a directory location. The software keystore can be one of the following types:
Password-based keystores: Password-based keystores are protected by using a password that you create. You must open the keystore before the keys can be retrieved or used.
Auto-login keystores: Auto-login keystores are protected by a system-generated password, and do not need to be explicitly opened by a security administrator. Auto-login keystores are automatically opened when accessed. Auto-login keystores can be used across different systems. If your environment does not require the extra security provided by a keystore that must be explicitly opened for use, then you can use an auto-login keystore.
Auto-login local keystores: Auto-login local keystores are auto-login keystores that are local to the system on which they are created. Auto-login local keystores cannot be opened on any computer other than the one on which they are created.
A hardware keystore is used with a hardware security module, which is a physical device that is designed to provide secure storage for encryption keys. This guide explains how to configure software keystores only. For detailed information about hardware keystores, see Oracle Database Advanced Security Guide.
A location for the keystore. You must specify the keystore location in the sqlnet.ora
file.
Afterward, when a user enters data, Oracle Database performs the following steps:
Retrieves the master key from the keystore.
Decrypts the encryption key using the master key.
Uses the encryption key to encrypt the data the user entered.
Stores the data in encrypted format in the database.
If the user is selecting data, the process is similar: Oracle Database decrypts the data and then displays it in plain text format.
Transparent Data Encryption has the following benefits:
As a security administrator, you can be sure that sensitive data is safe if the storage media or data file is stolen or lost.
Implementing Transparent Data Encryption helps you address security-related regulatory compliance issues.
Data from tables is transparently decrypted for the database user. You do not need to create triggers or views to decrypt data.
Database users do not need to be aware that the data they are accessing is stored in encrypted form. Data is transparently decrypted for the database users and does not require any action on their part.
Applications need not be modified to handle encrypted data. Data encryption and decryption is managed by the database.
Transparent Data Encryption has a minimal impact on performance. Transparent Data Encryption column encryption affects performance only when data is retrieved from or inserted into an encrypted column. There is no impact on performance for operations involving unencrypted columns, even if these columns are in a table containing encrypted columns. However, be aware that encrypted data must have more storage space than plain text data. On average, encrypting a single column requires between 32 and 48 bytes of additional storage for each row. Transparent tablespace encryption provides even better performance because Oracle Database performs the encryption and decryption at the I/O block layer. Once blocks are decrypted, they are cached in Oracle Database memory for optimal performance.
Oracle Database Advanced Security Guide for detailed information about using Transparent Data Encryption
To start using Transparent Data Encryption, you must create a keystore and set a master key.
The keystore should be a separate keystore specifically used by Transparent Data Encryption. This keystore will be used for all data that is being encrypted through Transparent Data Encryption. .
Topics:
Oracle Database Advanced Security Guide for detailed information about using tablespace encryption
When you create a software password-based keystore, you must designate the directory location for the keystore in the sqlnet.ora
file. You perform this step once.
To configure the keystore location:
Create a directory in the $ORACLE_HOME
directory to store the keystore.
For example, on Microsoft Windows, you could create a directory called ORA_KEYSTORES
in the C:\oracle\product\12.1.0\db_1
directory.
Create a backup copy of the sqlnet.ora
file, which by default is located in the $ORACLE_HOME/network/admin
directory.
At the end of the sqlnet.ora
file, add code similar to the following, where ORA_KEYSTORES
is the name of the directory where you plan to store the keystore:
ENCRYPTION_WALLET_LOCATION= (SOURCE= (METHOD=file) (METHOD_DATA= (DIRECTORY=C:\oracle\product\12.1.0\db_1\ORA_KEYSTORES)))
Save and close the sqlnet.ora
file.
If you want to configure the full set of tablespace encryption features, then you must set the COMPATIBLE
initialization parameter for the database to 11.2.0.0
or later.
Otherwise, ensure that it is at least 11.0.0.0
. Be aware that once you set this parameter, you cannot change it.
To set the COMPATIBLE initialization parameter:
Log into the database instance.
For example:
sqlplus sec_admin
Enter password: password
Connected.
Check the current setting of the COMPATIBLE
parameter.
For example:
SHOW PARAMETER COMPATIBLE NAME TYPE VALUE ------------------------------------ ----------- ------------- compatible string 11.0.0.0
If you must change the COMPATIBLE
parameter, then complete the remaining steps in this procedure.
The value should be 11.2.0.0
or higher.
Locate the initialization parameter file for the database instance.
UNIX systems: This file is in the ORACLE_HOME
/dbs
directory and is named init
ORACLE_SID
.ora
(for example, initmydb.ora
).
Windows systems: This file is in the ORACLE_HOME
\database
directory and is named init
ORACLE_SID
.ora
(for example, initmydb.ora
).
Edit the initialization parameter file to use the correct COMPATIBLE
setting.
For example:
COMPATIBLE = 12.0.0.0
In SQL*Plus, log in as a user who has the SYSDBA
administrative privilege.
sqlplus sys as sysdba
Enter password: password
Restart the Oracle Database instance.
For example:
SHUTDOWN IMMEDIATE STARTUP
Do not log out of SQL*Plus.
To create the keystore, use the ADMINISTER KEY MANAGEMENT
SQL statement.
By default, the Oracle keystore stores a history of retired master keys, which enables you to change them and still be able to decrypt data that was encrypted under an old master key. A case-sensitive keystore password unknown to the database administrator provides separation of duty: a database administrator can restart the database, but the keystore is closed and must be manually opened by a security administrator before the database can encrypt or decrypt the data.
To create the keystore:
In SQL*Plus, connect as a user who has been granted the SYSKM
administrative privilege.
For example:
CONNECT psmith / AS SYSKM
Enter password: password
Run the following ADMINISTER KEY MANAGEMENT
SQL statement:
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 'keystore_location' IDENTIFIED BY software_keystore_password;
In this specification:
keystore_location
is the path to the keystore location that you defined in the sqlnet.ora
file (for example, oracle\product\12.1.0\db_1\ORA_KEYSTORES
). Enclose the keystore_location
setting in single quotation marks. To find this location, query the WRL_PARAMETER
column of the V$ENCRYPTION_WALLET
view.
software_keystore_password
is a new password that you, the security administrator, creates.
For example, to create the keystore in the c:\oracle\product\12.1.0\db_1\ORA_KEYSTORES
directory:
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 'c:\oracle\product\12.1.0\db_1\ORA_KEYSTORES' IDENTIFIED BY password;
keystore altered.
After you run this statement, the ewallet.p12
file, which contains the keystore, appears in the keystore location.
You can manually open and close keystores. Auto-login keystores open automatically when they are accessed.
Topics:
Immediately after you create a software password-based keystore, you must manually open it before you can use Transparent Data Encryption.
You do not need to open the auto-login or hardware keystores because they open automatically. You can check the status of whether a keystore is open or closed by querying the STATUS
column of the V$ENCRYPTION_WALLET
view.
To open a keystore:
Ensure that you are logged into SQL*Plus as a user who has been granted the SYSKM
system privilege.
Enter the following ADMINISTER KEY MANAGEMENT
SQL statement:
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY software_keystore_password;
keystore altered.
Replace software_keystore_password
with the password that you created in "Step 3: Create the Software Password-Based Keystore".
You can close a keystore to disable access to the master key and prevent access to the encrypted columns.
In most cases, leave the keystore open unless you have a reason for closing it. The keystore must be open for Transparent Data Encryption to work. To reopen the keystore, use the ADMINISTER KEY MANAGEMENT
statement.
To close a keystore:
Ensure that you are logged into SQL*Plus as a user who has been granted the SYSKM
system privilege.
Enter the following SQL statement:
ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY software_keystore_password;
The master encryption key is stored in a keystore. It protects the table keys and tablespace encryption keys.
By default, the master encryption key is a random key generated by Transparent Data Encryption (TDE).
To create the master encryption key:
Ensure that you are logged into SQL*Plus as a user who has been granted the SYSKM
system privilege.
Run the following ADMINISTER KEY MANAGEMENT
SQL statement:
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY software_keystore_password [WITH BACKUP [USING 'backup_identifier']]; keystore altered.
In this specification:
software_keystore_password
is the password that you created in "Step 3: Create the Software Password-Based Keystore".
WITH BACKUP
creates a backup of the keystore. You must use this option for password-based keystores. You do not need to use it for auto-login or auto-login local keystores. Optionally, you can use the USING
clause to add a brief description of the backup. Enclose this description in double quotation marks. This identifier is appended to the named keystore file (for example, ewallet_
timestamp
_emp_key_backup.p12
).
For example:
ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY software_keystore_password WITH BACKUP USING 'password key backup';
After you have created a directory location for the keystore in the sqlnet.ora
file and created the keystore and master encryption key, you are ready to encrypt either individual table columns or an entire tablespace.
Topics:
Oracle provides a set of guidelines that you should follow before you select columns to encrypt.
The decisions that you make when you identify columns to encrypt are determined by governmental security regulations, such as California Senate Bill 1386, or by industry standards such as the Payment Card Industry (PCI) Data Security Standard. Credit card numbers, Social Security numbers, and other personally identifiable information (PII) fall under this category. Your own internal security policies — trade secrets, research results, or employee salaries and bonuses — determine your needs for encryption. See "When Should You Encrypt Data? " for guidelines about when and when not to encrypt data.
Follow these guidelines when you select columns to encrypt:
Check the data types of the columns you plan to encrypt. Transparent Data Encryption supports the following data types:
|
|
|
|
|
|
|
|
|
|
Large object types (LOBs) such as |
Ensure that the columns you select are not part of a foreign key. With Transparent Data Encryption, each table has its own encryption key, which is stored in the database data dictionary and encrypted with the external master key. Encrypted columns cannot be used as foreign keys.
To encrypt a column in a table:
Ensure that you have created and opened the keystore and created a master encryption key.
See the following sections, if necessary:
"Step 3: Create the Software Password-Based Keystore" to learn how to create a keystore key
"Step 4: Open (or Close) the Keystore" to learn how to open or a keystore
"Step 5: Create the Master Encryption Key" to create the master encryption key
In Enterprise Manager, access the Database home page.
See Oracle Database 2 Day DBA for more information.
From the Schema menu, select Database Objects, then Tables.
If the Database Login page appears, then log in as SYS
with the SYSDBA
administrative privilege.
In the Tables page, do one of the following:
To create a new table, click Create, and then answer the questions in the subsequent page to start creating the table.
To modify an existing table, search for the table name by entering its schema name into the Schema field and the table name in the Object Name field. (You can use the percent sign (%) wildcard character to search for a group of tables, for example O%
to find all tables beginning with the letter O.) When the table is listed in the Tables page, select the table, and then click Edit.
In the Create Table or Edit Table page, you can set the encryption options.
For example, to encrypt columns in the OE.ORDERS
table, the Edit Table page appears as follows:
In the Create Table (or Edit Table) page, do the following:
Select the column that you want to encrypt.
Do not select columns that are part of a foreign key constraint (primary or unique key columns). You cannot encrypt these columns. These columns are indicated with a key or check mark icon to the left of their names.
Click Encryption Options to display the Encryption Options for the Table page.
From the Encryption Algorithm list, select from the following options:
AES192: Sets the key length to 192 bits. AES is the abbreviation for Advanced Encryption Standard.
3DES168: Sets the key length to 168 bits. 3DES is the abbreviation for Triple Data Encryption Standard.
AES128: Sets the key length to 128 bits. This option is the default.
AES256: Sets the key length to 256 bits.
Under Key Generation, select either Generate Key Randomly or Specify Key. If you select Specify Key, enter characters for the seed values in the Enter Key and Confirm Key fields.
The Generate Key Randomly setting enables salt. Salt is a way to strengthen the security of encrypted data. It is a random string added to the data before it is encrypted, causing the same text to appear different when encrypted. Salt removes one method attackers use to steal data, namely, matching patterns of encrypted text.
Click Continue to return to the Create Table (or Edit Table) page.
Enable encryption for the column by selecting its box under Encrypted.
Click Apply, and then click Return.
The Tables page appears.
While a table is being updated, read access is still possible. Afterward, existing and future data in the column is encrypted when it is written to the database file, and it is decrypted when an authorized user selects it. If data manipulation language (DML) statements are needed, you can use online redefinition statements.
You can encrypt a new tablespace while you are creating it, but you cannot encrypt an existing tablespace.
As a workaround, you can use the CREATE TABLE AS SELECT
, ALTER TABLE MOVE
, or use Oracle Data Pump import to get data from an existing tablespace into an encrypted tablespace. For details about creating a tablespace, see Oracle Database 2 Day DBA.
To encrypt a tablespace:
Ensure that you have created and opened the keystore, as described in the preceding steps of this section.
In Enterprise Manager, access the Database home page.
See Oracle Database 2 Day DBA for more information.
From the Administration menu, select Storage, then Tablespaces.
If the Database Login page appears, then log in as an administrative user, such as SYS
. User SYS
must log in with the SYSDBA role selected.
The Tablespaces page appears.
Click Create, and then answer the questions in the subsequent page to start creating the tablespace and its required data file.
In the Create Tablespace page, do the following:
Under Type, in the Permanent list, select the Encryption box.
Under Datafiles, select Add to add a data file. (Linux and Windows systems only)
Select Encryption options to display the Encryption Options page.
From the Encryption Algorithm list, select from the following options:
AES192: Sets the key length to 192 bits. AES is the abbreviation for Advanced Encryption Standard.
3DES168: Sets the key length to 168 bits. 3DES is the abbreviation for Triple Data Encryption Standard.
AES128: Sets the key length to 128 bits. This option is the default.
AES256: Sets the key length to 256 bits.
See "Available Methods" under Step 5 in "Configuring Network Encryption" for more information about these encryption algorithms.
Click Continue.
In the Create Tablespace page, click OK.
The new tablespace appears in the list of existing tablespaces. Remember that you cannot encrypt an existing tablespace.
"Data Dictionary Views for Checking Encrypted Tablespaces in the Current Database Instance" to query the database for existing encrypted tablespaces
Oracle Database Advanced Security Guide for detailed information about tablespace encryption
Oracle Database SQL Language Reference for more information about the CREATE TABLESPACE
statement
You can query the database for the data that you have encrypted. You can check for individually encrypted columns, all tables in the current database instance that have encrypted columns, or all tablespaces that are encrypted.
Topics:
To find the type of keystore that was created, query the V$ENCRYPTION_KEYS
view.
To find the type of keystore that was created:
In SQL*Plus, query the V$ENCRYPTION_KEYS
view as follows:
SELECT KEYSTORE_TYPE FROM V$ENCRYPTION_KEYS;
The keystore location appears, similar to the following:
KEYSTORE_TYPE ----------------------------- SOFTWARE KEYSTORE
You can find the location of a keystore by querying the V$ENCRYPTION_WALLET
view.
To find the keystore location:
In SQL*Plus, query the V$ENCRYPTION_WALLET
view as follows:
SELECT WRL_PARAMETER FROM V$ENCRYPTION_WALLET;
The keystore location appears, similar to the following:
WRL_PARAMETER ----------------------------- C:\oracle\product\12.1.0\db_1
You can find out if a keystore is open or closed by querying the V$ENCRYPTION_WALLET
view.
To check whether a keystore is open or closed:
In SQL*Plus, query the V$ENCRYPTION_WALLET
view as follows:
SELECT STATUS FROM V$ENCRYPTION_WALLET;
The keystore status appears, similar to the following:
STATUS ------- OPEN
You can use the DESC
(for DESCRIBE
) statement in SQL*Plus to check the encrypted columns in a database table.
To check the encrypted columns of an individual table:
In SQL*Plus, run the DESC
statement using the following syntax.
DESC tablename;
For example:
DESC OE.ORDER_ITEMS;
A description of the table schema appears. The following output shows that the QUANTITY
column is encrypted:
Name Null? Type
---------------------------------------- -------- --------------------------
ORDER_ID NOT NULL NUMBER(12)
LINE_ITEM_ID NOT NULL NUMBER(3)
PRODUCT_ID NOT NULL NUMBER(6)
UNIT_PRICE NUMBER(8,2)
QUANTITY NUMBER(8) ENCRYPT
To check all encrypted table columns, you can query the DBA_ENCRYPTED_COLUMNS
view.
To check all encrypted table columns in the current database instance:
In SQL*Plus, select from the DBA_ENCRYPTED_COLUMNS
view:
For example:
SELECT * FROM DBA_ENCRYPTED_COLUMNS;
This SELECT
statement lists all tables and column in the database that contain columns encrypted using Oracle Transparent Data Encryption. For example:
OWNER TABLE_NAME COLUMN_NAME ENCRYPTION_ALG SALT INTEGRITY_ALG ------- ---------- ----------- ---------------- ---- ------------- OE CUSTOMERS INCOME_LEVEL AES 128 bits key YES SHA-1 OE UNIT_PRICE ORADER_ITEMS AES 128 bits key YES SHA-1 HR EMPLOYEES SALARY AES 192 bits key YES SHA-1
Oracle Database Reference for more information about the DBA_ENCRYPTED_COLUMNS
view
Oracle Database provides a set of data dictionary views that you can query to check encrypted tablespaces.
Table 4-1 lists data dictionary views that you can use to check encrypted tablespaces.
Table 4-1 Data Dictionary Views for Encrypted Tablespaces
Data Dictionary View | Description |
---|---|
Describes all tablespaces in the database. For example, to determine if the tablespace has been encrypted, enter the following: SELECT TABLESPACE_NAME, ENCRYPTED FROM DBA_TABLESPACES; TABLESPACE_NAME ENC ---------------------------- ---- SYSTEM NO SYSAUX NO UNCOTBS1 NO TEMP NO USERS NO EXAMPLE NO SECURESPACE YES |
|
Describes the tablespaces accessible to the current user. It has the same columns as |
|
Displays information about the tablespaces that are encrypted. For example: SELECT * FROM V$ENCRYPTED_TABLESPACES; TS# ENCRYPTIONALG ENCRYPTEDTS ----------- ------------- ----------- 6 AES128 YES The list includes the tablespace number, its encryption algorithm, and whether its encryption is enabled or disabled. If you want to find the name of the tablespace, use the following join operation: SELECT NAME, ENCRYPTIONALG ENCRYPTEDTS FROM V$ENCRYPTED_TABLESPACES, V$TABLESPACE WHERE V$ENCRYPTED_TABLESPACES.TS# = V$TABLESPACE.TS#; |
Oracle Database Reference for more information about data dictionary views
You cannot encrypt external LOBs (BFILE
).