February 5, 2017 Leave a comment
With the expansion of Self-Service BI, BI Teams need to be more vigilant about protecting sensitive data.
This is a summary of options available for protecting data in Oracle databases.
The information in this post was found here and summarized for a quick read: https://docs.oracle.com/database/121/ASOAG/toc.htm
The 3 features available are (1) Transparent Data Encryption, (2) Data Redaction, and (3) Data Masking and Subsetting Pack.
Here is a quick summary.
(1) Transparent Data Encryption (TDE)
- Encrypt data so only authorized people can see it
- Use it to protect sensitive data that maybe in an unprotected environment, such backup data sent to a storage facility
- You can encrypt an individual column or an entire tablespace
- Applications using encrypted data can function just the same
(2) Data Redaction
- Enable the redaction (masking) of column data in tables
- Redaction can be full, partial, based on regular expressions, or random
- Full redaction: replaces strings with a single blank space ‘ ‘; numbers with zero (0); dates with 01-JAN-01
- Partial redaction: replaces a portion of the column data; for example SSN: ***-**-1234
- Regular expressions: can be used to perform partial or full redactions
- Random: generates random values for display when accessed
- The redaction takes place at runtime; not in the permanent data stored
(3) Oracle Enterprise Manager Data Masking and Subsetting Pack
- enables you to create a “safe” development or test copy of the production database
Let’s look into some more details …
(1) Transparent Data Encryption (TDE)
- TDE uses a two-tiered key-based architecture
- TDE column encryption uses the two-tiered key-based architecture to transparently encrypt and decrypt sensitive table columns. The TDE master encryption key is stored in an external security module, which can be an Oracle software keystore or hardware keystore. This TDE master encryption key encrypts and decrypts the TDE table key, which in turn encrypts and decrypts data in the table column.
- A Key Management Framework is used for TDE to store and manage keys and credentials.
- Includes the keystore to store the TDE master encryption keys and the management framework to manage keystore and key operations
- The Oracle keystore stores a history of retired TDE master encryption keys, which enables you to change them and still be able to decrypt data that was encrypted under an earlier TDE master encryption key.
- Types of Keystores
- Software keystores
- Hardware, or HSM-based, keystores
- Types of Software Keystores:
- auto-login software keystores that are local to the computer on which they are created.
- cannot be opened on any computer other than the one on which they are created.
- typically used for scenarios where additional security is required while supporting an unattended operation
- Password-based software keystores
- protected by using a password that you create. You must open this type of keystore before the keys can be retrieved or used.
- Auto-login software keystores
- protected by a system-generated password, and do not need to be explicitly opened; automatically opened when accessed.
- can be used across different systems; ideal for unattended scenarios.
- Local auto-login software keystores
- Steps for configuring a Software Keystore
- Step 1: Set the Software Keystore Location in the sqlnet.ora File
- Step 2: Create the Software Keystore
- Step 3: Open the Software Keystore
- Step 4: Set the Software TDE Master Encryption Key
- Step 5: Encrypt Your Data
- Oracle Database checks the sqlnet.ora file for the directory location of the keystore, whether it is a software keystore or a hardware module security (HSM) keystore.
- You cannot change an existing tablespace to make it encrypted
- You can create or modify columns to be encrypted
(2) Data Redaction
- Define data redaction policies to specify what data needs to be redacted
- Use policy expressions to set whether a user sees the redacted data or the full data
- Policy Procedures
- Sample scrip
object_schema => ‘hr’,
object_name => ’employees’,
column_name => ‘commission_pct’,
policy_name => ‘redact_com_pct’,
function_type => DBMS_REDACT.PARTIAL, –partial; use DBMS_REDACT.FULL for full
function_parameters => DBMS_REDACT.REDACT_US_SSN_F5, — many standard params, but it can also be custom
expression => ‘SYS_CONTEXT(”SYS_SESSION_ROLES”,”MGR”) = ”FALSE”’); –allows MGR role to see data
policy_description => ‘Partially redacts 1st 5 digits in SS numbers’,
column_description => ‘ssn contains Social Security numbers’);
- Use DBMS_REDACT.ALTER_POLICY and action => DBMS_REDACT.ADD_COLUMN to redact multiple columns
- Redaction takes place on select lists and not on where clauses
- Be aware of the scenarios when using redacted tables to build other tables or views
(3) Oracle Enterprise Manager Data Masking and Subsetting Pack (DMSP)
- DMSP enables you to create a development or test copy of the production database, by taking the data in the production database, masking this data in bulk, and/or creating a subset of the data, and then putting the resulting masked data and/or subset of data in the development or test copy.
- You can still apply Data Redaction policies to the non-production database, in order to redact columns
- Used to mask data sets when you want to move the data to development and test environments.
- Data Redaction is mainly designed for redacting at runtime for production applications
I hope you found this helpful to get you started on taking the steps to protect your data internally and externally.
You can visit the link I provided above to find more details.