Oracle Data Redaction and Other Oracle Products

Why do I need Oracle Data Redaction if I already use Transparent Data Encryption?

Oracle Transparent Data Encryption transparently encrypts the data in data files, RMAN backups, and Data Pump exports. The data is transparently decrypted when a user or application queries the data. Oracle Data Redaction limits exposure of sensitive data by redacting the column value according to the Data Redaction policy before the result of the query is returned to the user or application.

How does Oracle Data Redaction differ from traditional data masking?

Traditional data masking typically involves altering the data stored in the database, while Oracle Data Redaction masks data dynamically at runtime without changing the actual data stored in the database. Oracle Data Redaction is typically used on production databases, where real customer or corporate data resides. Oracle Data Masking and Subsetting is used on non-production databases because it physically changes the data to "production-like" data. Oracle Data Redaction is included, along with Transparent Data Encryption, in the Advanced Security Option. Data masking is included in the Oracle Enterprise Manager Pack, Data Masking and Subsetting, or in the cloud-option Oracle Data Safe.

What is the difference between Oracle Data Redaction and tokenization?

Tokenization is a data security technique that replaces sensitive data with a unique, non-sensitive identifier called a token. The token is used instead of the original data, which is stored securely in a separate system. Tokenization usually requires changes to the application code and the application architecture to accommodate the original data being stored in a separate system. This can add complexity and latency to the architecture.

Oracle Data Redaction dynamically redacts sensitive data in real-time at the point of display without altering the actual stored data, using policies to control who can see actual data or only a redacted result. It is non-intrusive and ensures data protection without affecting data integrity. Oracle Data Redaction is built into the kernel of the Oracle AI Database and requires no application changes and no external software or hardware. Typically, customers will use Data Redaction for read only application screens or web pages, business intelligence or analytic reports, or any application that should redact the result displayed in the report, but will not write the results back to the Oracle AI Database.

How does Oracle Data Redaction compare to other similar Oracle offerings?

Oracle Data Redaction - Selectively remove sensitive information before they are returned in the SQL query results. Enforces redaction at runtime, with low overhead, and according to conditions set in policies. Allows you to use full, partial, random, and regular expressions to redact data in your columns, but does not restrict the number of rows returned by a query.
Oracle Data Masking and Subsetting - Create masked and subsetted copies of production data for use in non-production environments such as testing and development databases.
Oracle Data Safe (Data Discovery and Data Masking) - Discover and mask sensitive data with a cloud service that supports Oracle AI Databases everywhere: in the Oracle Cloud, on-premises, and third-party clouds.
Oracle Label Security - Implements Multi-Level Security (MLS), enabling rows with differing sensitivity to reside in the same table. Explicitly labels rows with group, compartment, and sensitivity levels, then matches them with user labels. Does not redact column data but restricts the rows returned to a user.
Oracle Virtual Private Database (VPD) and Real Application Security (RAS) - Can limit the column data returned or the rows returned, but can only return null column data. Oracle VPD and RAS do not allow partial or regular expression redaction on the column data.

How does Data Redaction interact with VPD/RLS, OLS, and Database Vault? Any order-of-evaluation nuances?

Oracle Data Redaction works in conjunction with other Oracle security features.

Evaluation order:

Database Vault (DV): Enforces command and realm based restrictions first, potentially blocking the operation before data access.
Virtual Private Database (VPD)/Row-Level Security (RLS): Applies row filters to control which rows are visible to the user.
Oracle Label Security (OLS): Enforces label based access controls on the remaining rows.
Data Redaction: Lastly, redacts sensitive column values in the result set before they are returned to the user.

This means redaction does not override access controls - it only modifies data returned by queries that already pass row-level and label checks.

Best practice: Use VPD/OLS/Database Vault to control who can access data and Data Redaction to control what they can see.

If I also use Data Safe masking on non-production copies, how should I sequence masking and redaction policies to avoid conflicts?

Use Data Safe masking first, then configure Data Redaction on the masked environment if needed.

Masking is a data-at-rest transformation — it permanently replaces sensitive data before non-production use.

Redaction is data-in-use protection — it dynamically hides data at query time.

Recommended sequence:

Apply Data Safe masking to create a sanitized non-prod copy.
Enable Data Redaction on that copy only if additional runtime protection is needed (for example, restricting visibility by role).

Running redaction before data masking generally does not change the masking outcome, because masking is performed on the base table data using privileged accounts that are typically exempt from redaction. However, if a masking job reads data through redaction-protected queries, for example, CTAS or SELECT used by a non-exempt account, the masked values could be based on redacted rather than original data, which is not recommended.

What happens to Data Redaction policies during clones, refreshable clones, Data Guard switchover/failover, or GoldenGate?

Clones and refreshable clones: Data Redaction policies are copied along with the database metadata. Policies remain intact and active in the cloned environment unless explicitly modified.

Data Guard switchover/failover: Redaction policies are replicated to standby databases and remain enforced automatically after role transition.

GoldenGate replication: Redaction policies are not applied to data being replicated - they affect only query results in the source or target database. Policies must be created manually on the target if runtime redaction is required there.

Best practice: Always review redaction policy state post-clone or replication to ensure intended enforcement settings remain valid in the new environment.

Can I use Oracle Data Redaction with Oracle EBS, PeopleSoft, Siebel, or other packaged applications?

Yes. Oracle Data Redaction is enforced in the database and applies to any application that queries protected columns, including packaged applications, as long as those applications do not rely on seeing the original (unredacted) values for their core functionality. Most packaged applications offer some type of built-in redaction feature. Please see your packaged application documentation for more information on redacting data within the application.

Can Oracle Data Redaction be managed through Oracle Enterprise Manager?

Yes. Oracle Enterprise Manger Cloud Control provides a management interface for most Oracle Data Redaction features including creating, modifying, or disabling policies and applying or removing policies from columns of table or views.

7.4 Oracle Data Redaction and Other Oracle Products