Oracle Database Encryption

 

Many companies are struggling to address both existing and emerging privacy and compliance requirements around the world. These include industry specific requirements such as Payment Card Industry-Data Security Standard (PCI-DSS), government regulations like the Health Insurance Portability and Accountability Act of 1996 (HIPAA Privacy Rule) and Health Information Technology for Economic and Clinical Health (HITECH) Act, and numerous security breach notification laws.

One of the most difficult aspects of complying with such laws and regulation is restricting access to personally identifiable information (PII), like credit card numbers, social security numbers, and so on. One of the most effective — and challenging — means of doing this is encryption. Fortunately for Oracle customers, there are many options for accomplishing this goal.

Encryption capabilities within Oracle databases have progressively improved with each version. Oracle 9i introduced row level encryption, and Oracle 10g introduced row and column encryption.

  • To ensure that all client connections to the database are encrypted (e.g., protect the confidentiality of the password), the parameter ORA_ENCRYPT_LOGIN should be set to TRUE on the client machine.

  • One or more columns of data can be encrypted as necessary.

    • Oracle 10g Release 1 and earlier use the DBMS_CRYPTO and DBMS_OBFUSCATION_TOOLKIT toolkits. Some programming skill is required to use these.

    • Oracle 10g Release 2 and later use Transparent Data Encryption (TDE). This allows admins to implement encryption right out of the box without having to write code. TDE supports standard encryption algorithms including AES (up to 256-bit keys) and Triple DES. In addition, encryption of entire tablespaces can be performed.

Be advised that this only addresses the protection of data at rest (on the hard disk). Data encrypted with TDE is decrypted when it is read back from database file. This means that once data is sent over the network it will be in clear-text (unencrypted). However, data in transit can be encrypted using Oracle’s network encryption solution, which is included along with TDE in the Oracle Advanced Security option.

In addition to data encryption, data masking can also be performed. Data masking is different from encryption in that sensitive data (e.g. social security numbers, salary information) is “scrubbed” in order to share that data with development/test, analysis groups, business partners, etc.

The OEM (Oracle Enterprise Manager) Data Masking Pack is a separate product that uses an irreversible process to replace sensitive data with realistic looking, but scrubbed, data based on masking rules. This ensures that original data cannot be retrieved, recovered or restored. OEM version 10.2.0.4. is required to use it.

In this example, the last name and SSN data is masked, but the salary data is preserved.

LAST_NAME

SSN

SALARY

Johnson

203-40-2324

80,000

Adams

323-33-9793

87,000

Williams

324-56-2067

67,000

Kawalski

204-66-6935

76,000

LAST_NAME

SSN

SALARY

Kghkehh

111-11-4959

80,000

Ihwoiherkjeo

111-22-6843

87,000

Oiwenrhiowo

111-56-3985

67,000

Bhihwewni

111-55-5683

76,000

Hopefully this short article helps explain some of the options available for safeguarding sensitive data. Be sure to consult Oracle’s extensive documentation on the subject at their web site, including the FAQs. Finally, as with any major IT endeavor, thorough testing should be performed before making any changes to the pro duction environment.