Skip Headers
Oracle® Database Security Guide
12c Release 1 (12.1)

E17607-26
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

11 Using Transparent Sensitive Data Protection

This chapter contains:

About Transparent Sensitive Data Protection

Transparent sensitive data protection (TSDP) enables you to quickly find all table columns in a database that hold sensitive data (such as credit card or Social Security numbers), classify this data, and then create a policy that protects this data as a whole for a given class. The TSDP policy then protects the sensitive data in these table columns by using either Oracle Data Redaction or Oracle Virtual Private Database settings. The TSDP policy applies at the column level of the table that you want to protect, targeting a specific column data type, such as all NUMBER data types of columns that contain credit card information. You can create a uniform TSDP policy for all of the data that you classify, and then modify this policy as necessary, as compliance regulations change. Optionally, you can export the TSDP policies for use in other databases.

The benefits of TSDP policies are enormous: You easily can create and apply TSDP policies throughout a large organization with numerous databases. This helps auditors greatly by enabling them to estimate the protection for the data that the TSDP policies target.

General Steps for Using Transparent Sensitive Data Protection

To use TSDP with Oracle Data Redaction, you must follow these general steps:

  1. Create a sensitive type to classify the types of columns that you want to protect.

    For example, you can create a sensitive type for classify all Social Security numbers or credit card numbers. To create the sensitive type, either use the DBMS_TSDP_MANAGE.ADD_SENSITIVE_TYPE PL/SQL procedure or use an Enterprise Manager Cloud Control Application Data Model. To add multiple sensitive types in one operation from an Application Data Model, you can use the DBMS_TSDP_MANAGE.IMPORT_SENSITIVE_TYPES procedure.

  2. Identify a list of sensitive columns that are associated with the sensitive types.

    To determine and generate this list, you can use either of the following methods:

    • The DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMN procedure individually identifies sensitive columns.

    • An Oracle Enterprise Manager Cloud Control Application Data Model enables you to identify a group of sensitive columns. It then prepares this list of sensitive columns in XML format, which you then import into your database.

  3. If you used an Application Data Model for Step 2, then import the list of sensitive columns from the Application Data Model into your database by using the DBMS_TSDP_MANAGE.IMPORT_DISCOVERY_RESULT procedure.

  4. Create the TSDP policy by using the DBMS_TSDP_PROTECT.ADD_POLICY procedure within an anonymous block that defines the Data Redaction or Virtual Private Database settings that you want to use.

  5. Associate the TSDP policy with one or more sensitive types by using the DBMS_TSDP_PROTECT.ASSOCIATE_POLICY procedure.

  6. Enable the TSDP policy protections by using the DBMS_TSDP_PROTECT.ENABLE_PROTECTION_SOURCE, DBMS_TSDP_PROTECT.ENABLE_PROTECTION_COLUMN, or the DBMS_TSDP_PROTECT.ENABLE_PROTECTION_TYPE procedure.

  7. Optionally, export the TSDP policy to other databases by using Oracle Data Pump to perform a full database export. (You cannot individually export TSDP policies.)

Use Cases for Transparent Sensitive Data Protection Policies

Transparent sensitive data protection has the following benefits:

  • You configure the sensitive data protection once, and then deploy this protection as necessary. You can configure transparent sensitive data protection policies to designate how a class of data (for example, credit card columns) must be protected without actually having to specify the target data. In other words, when you create the transparent sensitive data protection policy, you do not need to include references to the actual target columns that you want to protect. The transparent sensitive data protection policy finds these target columns based on a list of sensitive columns in the database and the policy's associations with the specified sensitive types. This can be useful when you add more sensitive data to your databases after you have created the transparent sensitive data protection policies. After you create the policy, you can enable protection for the sensitive data in a single step (for example, enable protection based on the entire source database). The sensitive type of the new data and the sensitive type and policy associations determine how the sensitive data is protected. In this way, as new sensitive data is added, you do not need to configure its protection, as long as it meets the current transparent sensitive data protection policy's requirements.

  • You can manage protection of multiple sensitive columns. You can enable or disable protection for multiple sensitive columns based on a suitable attribute (such as the source database of the identification, the sensitive type itself, or a specific schema, table, or column). This granularity provides a high level of control over data security. The design of this feature enables you to manage data security based on specific compliance needs for large data sets that fall under the purview of these compliance regulations. You can configure data security based on a specific category rather than for each individual column. For example, you can configure protection for credit card numbers or Social Security numbers, but you do not need to configure protection for each and every column in the database that contains this data.

  • You can protect the sensitive columns identified using the Oracle Enterprise Manager Cloud Control Application Data Modeling (ADM) feature. You can use the Cloud Control ADM feature to create sensitive types and discover a list of sensitive columns. Then you can import this list of sensitive columns and their corresponding sensitive types into your database. From there, you can create and manage transparent sensitive data protection policies using this information.

Privileges Required for Using Transparent Sensitive Data Protection

To use transparent sensitive data protection, you must have the EXECUTE privilege for the following PL/SQL packages:

  • DBMS_TSDP_MANAGE, which enables you to import and manage sensitive columns and sensitive types into your database. The procedures in this package execute with invoker's rights. Typically, an application database administrator will be granted privileges for this package.

  • DBMS_TSDP_PROTECT, which you use to create the TSDP policy. The procedures in this package execute with invoker's rights. Typically, a security database administrator will be granted privileges for this package.

  • DBMS_REDACT, if you plan to create Data Redaction policies. Typically, a security database administrator will be granted privileges for this package.

  • DBMS_RLS, if you plan to incorporate Oracle Virtual Private Database functionality into your TSDP policies. Typically, a security database administrator will be granted privileges for this package.

For better separation of duty, these packages are designed so that either an application database administrator has control over one area of the TSDP policy creation (as in the case of the DBMS_TSDP_MANAGE package) or a security database administrator (for the DBMS_TSDP_PROTECT, DBMS_REDACT, and DBMS_RLS packages).

Creating Transparent Sensitive Data Protection Policies

This section contains:

Step 1: Create a Sensitive Type

The sensitive type is a class of data that you designate as sensitive. For example, you can create a credit_card_type sensitive type for all credit card numbers.

You can create the sensitive type either from an Enterprise Manager Cloud Control Application Data Model or by using the DBMS_TSDP_MANAGE.ADD_SENSITIVE_TYPE PL/SQL procedure. To drop a sensitive type, use the DBMS_TSDP_MANAGE.DROP_SENSITIVE_TYPE procedure.

After you create the sensitive type, it resides in the SYS schema.

Example 11-1 shows how to create the sensitive type credit_card_num_type:

Example 11-1 Creating a Sensitive Type

BEGIN
 DBMS_TSDP_MANAGE.ADD_SENSITIVE_TYPE (
  sensitive_type  => 'credit_card_num_type',
  user_comment    => 'Type for credit card columns using a number data type');
END;
/

In this example:

  • sensitive_type: Create a name that describes the sensitive type that you want to capture. This value is case sensitive, so when you reference it later on, ensure that you use the case in which you created it. You can find existing sensitive types by querying the DBA_SENSITIVE_COLUMN_TYPES data dictionary view.

  • user_comment: Optionally, enter a description for the sensitive type.

See Also:

Step 2: Identify the Sensitive Columns to Protect

To identify the columns to protect, based on the sensitive type that you defined in "Step 1: Create a Sensitive Type", you either can use an Enterprise Manager Cloud Control Application Data Model to identify these columns, or you can use the DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMN procedure. To remove the column from the list of sensitive columns for the database, use the DBMS_TSDP_MANAGE.DROP_SENSITIVE_COLUMN procedure.

To identify the columns to protect:

  1. Find the sensitive type that you want to use.

    For example:

    SELECT NAME FROM DBA_SENSITIVE_COLUMN_TYPES;
    
    NAME
    ---------------------
    credit_card_num_type
    
  2. Execute the DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMN procedure to associate the sensitive type with a table column. Ensure that you enter the sensitive_type parameter using the case in which you used to create the sensitive type.

    For example:

    BEGIN
     DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMN(
     schema_name        => 'OE',
     table_name         => 'CUST_CC',
     column_name        => 'CREDIT_CARD',
     sensitive_type     => 'credit_card_num_type',
     user_comment       => 'Sensitive column addition of credit_card_num_type');
    END;
    /
    

Step 3: Import the Sensitive Columns List from ADM into Your Database

If you had used an Application Data Model to create the list of sensitive columns, then you must import this list into your database by running the DBMS_TSDP_MANAGE.IMPORT_DISCOVERY_RESULT procedure. If you had used the DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMN procedure to identify these columns, then you can bypass this step.

Example 11-2 shows how to import the Cloud Control Application Data Model into the current database.

Example 11-2 Importing a Sensitive Columns List from ADM

BEGIN
 DBMS_TSDP_MANAGE.IMPORT_DISCOVERY_RESULT (
 discovery_result      => xml_adm_result,
 discovery_source      => 'ADM_Demo');
END;
/

In this example:

  • discovery_result refers to the list of sensitive columns and their associated sensitive types. This list is in XML format.

  • discover_source refers to the name of the Application Data Model that contains the list of sensitive columns referred by the discovery_result setting. You can find a list of the Application Data Models from the Data Discovery and Modeling page in Enterprise Manager Cloud Control. (To access this page, from the Enterprise menu, select Quality Management, and then Data Discovery and Modeling. You can find a list of the sensitive columns and their associated types in the Sensitive Columns tab.)

Step 4: Create the Transparent Sensitive Data Protection Policy

To create the policy, you must configure it for the Virtual Private Database or Oracle Data Redaction settings that you want to use, and then apply these settings to a transparent sensitive data protection policy defined by the DBMS_TSDP_PROTECT.ADD_POLICY procedure. This section shows how to configure it for Oracle Data Redaction. (See "Tutorial: Creating a TSDP Policy That Uses Virtual Private Database Protection" for an example of how you can create a TSDP policy for Virtual Private Database.)

You can create the policy by defining an anonymous block that has the following components:

  • If you are using Oracle Data Redaction for your policy, a specification of the type of Data Redaction that you want to use, such as partial Data Redaction

  • If you are using Oracle Virtual Private Database for your policy, a specification of the VPD settings that you want to use

  • Conditions to test when the policy is enabled. For example, the data type of the column which should be satisfied before the policy can be enabled.

  • A named transparent sensitive data protection policy to tie these components together, by using the DBMS_TSDP_PROTECT.ADD_POLICY procedure

After you create the sensitive type, it resides in the SYS schema.

Example 11-3 shows how to create a transparent sensitive data protection policy that uses a partial number data type-based Data Redaction policy. If you want to see an example of a similar policy for VPD, see "Step 4: Create and Enable a Transparent Sensitive Data Protection Policy". (You can copy and paste the following text by positioning the cursor at the start of DECLARE in the first line.)

Example 11-3 Creating a Transparent Sensitive Data Protection Policy

1
2
3
4
5
6
7
8
9
10
11
12
13
14
DECLARE
  redact_feature_options DBMS_TSDP_PROTECT.FEATURE_OPTIONS;
  policy_conditions DBMS_TSDP_PROTECT.POLICY_CONDITIONS;
BEGIN
  redact_feature_options ('expression') := 
   'SYS_CONTEXT(''USERENV'',''SESSION_USER'') =''APPUSER''';
  redact_feature_options ('function_type') := 'DBMS_REDACT.PARTIAL';
  redact_feature_options ('function_parameters') := '0,1,6';
  policy_conditions(DBMS_TSDP_PROTECT.DATATYPE) := 'NUMBER';
  policy_conditions(DBMS_TSDP_PROTECT.LENGTH) := '16';
 DBMS_TSDP_PROTECT.ADD_POLICY ('redact_partial_cc', DBMS_TSDP_PROTECT.REDACT,
  redact_feature_options, policy_conditions);
END;
/

In this example:

  • Line 2: Creates the variable redact_feature_options, which uses the FEATURE_OPTIONS data type. See "Setting Oracle Data Redaction or Virtual Private Database Feature Options" for more information.

  • Line 3: Creates the variable policy_conditions, which uses the POLICY_CONDITIONS data type. See "Setting the Conditions for the Policy" for more information.

  • Lines 5–8: Writes the Data Redaction policy settings to the redact_feature_option variable. This example applies the Data Redaction policy to the user APPUSER and defines the policy as a partial data redaction for number data types. See Oracle Database Advanced Security Guide for information about how the function_parameters parameter works for this case.

  • Lines 9–10: Writes the TSDP policy conditions to the policy_conditions variable (that is, the data type and length) for the protected NUMBER data type column.

  • Lines 11–12: Executes the DBMS_TSDP_PROTECT.ADD_POLICY procedure, which creates the redact_partial_cc TSDP policy. See "Specifying the DBMS_TSDP_PROTECT.ADD_POLICY Procedure" for more information.

Setting Oracle Data Redaction or Virtual Private Database Feature Options

The feature options describe the Oracle Data Redaction or Virtual Private Database settings that you may want to use for the transparent sensitive data protection policy. For Data Redaction, you define the feature options by using the name redact_feature_options variable and for the type, you must use the type DBMS_TSDP_PROTECT.FEATURE_OPTIONS, which is an associative array of the data type VARCHAR2(TSDP_PARAM_MAX). Initialize these options with the parameter-value pairs that correspond with the DBMS_REDACT.ADD_POLICY parameters. For example, to specify a TSDP policy that uses partial Data Redaction, Example 11-3 shows the following parameter-value pair:

redact_feature_options ('function_type')       := 'DBMS_REDACT.PARTIAL';

For a partial Data Redaction policy that uses a number data type for the protected column, Example 11-3 specifies the following additional parameter-value pairs:

redact_feature_options ('expression')          := 'expression';
redact_feature_options ('function_parameters') := 'values';

See Oracle Database Advanced Security Guide for more information about Data Redaction policy creation parameters.

Similarly, for Virtual Private Database, you use the vpd_feature_options variable to define the VPD feature options. For example:

vpd_feature_options ('statement_types')   := 'SELECT, INSERT, UPDATE, DELETE';

See "DBMS_RLS.ADD_POLICY Parameters That Are Used for TSDP Policies" for more information about available VPD parameters.

Setting the Conditions for the Policy

Optionally, you can specify conditions for the policy. However, if you choose to omit conditions, you still must include the following line in the DECLARE variables. (In this case, the default value for policy_conditions is an empty associative array.)

policy_conditions SYS.DBMS_TSDP_PROTECT.POLICY_CONDITIONS;

You define the conditions by using the name policy_conditions for the variable and for the type, you must use type DBMS_TSDP_PROTECT.POLICY_CONDITIONS, which is an associative array of the data type VARCHAR2(TSDP_PARAM_MAX). Ensure that no two conditions are satisfied by a single target sensitive column. The target column's properties should satisfy all the condition properties for the corresponding DBMS_TSDP_PROTECT.FEATURE_OPTIONS settings to be applied on the column.

Example 11-3 shows the policy conditions as follows:

policy_conditions(DBMS_TSDP_PROTECT.DATATYPE) := 'NUMBER';
policy_conditions(DBMS_TSDP_PROTECT.LENGTH)   := '16';

Optionally, you can specify one or more of the following keys for the POLICY_CONDITIONS settings:

  • DBMS_TSDP_PROTECT.DATATYPE enables you to specify a data type.

  • DBMS_TSDP_PROTECT.LENGTH enables you to specify a data type length for the DBMS_TSDP_PROTECT.DATATYPE key.

  • DBMS_TSDP_PROTECT.PARENT_SCHEMA enables you to restrict the policy to a specific schema. If you omit this setting, then the policy applies to all schemas in the database.

  • DBMS_TSDP_PROTECT.PARENT_TABLE enables you to restrict the policy to a table specified by the DBMS_TSDP_PROTECT.PARENT_SCHEMA key. If you omit this setting, then the policy applies to all tables within the specified schema.

Specifying the DBMS_TSDP_PROTECT.ADD_POLICY Procedure

The DBMS_TSDP_PROTECT.ADD_POLICY procedure names the transparent sensitive data protection policy and executes settings from the FEATURE_OPTIONS and POLICY_CONDITIONS settings. In the policy, the redact_feature_options and the policy_conditions settings work together: When the policy is enabled (using any of the DBMS_TSDP_PROTECT.ENABLE_PROTECTION* procedures) on the target object, then the redact_feature_options settings apply only if the corresponding policy_condition settings are satisfied. You must enter the following parameters:

  • policy_name creates a name for the TSDP policy. The name that you enter is stored in the database using the case sensitivity that you used when you created it. For example, if you had entered redact_partial_cc, then the database stores it as redact_partial_cc, not redact_partial_cc.

  • security_feature refers to the security feature the TSDP policy will use. Enter DBMS_TSDP_PROTECT.REDACT to specify Oracle Data Redaction.

  • policy_enable_options refers to the variable that you defined for the DBMS_TSDP_PROTECT.FEATURE_OPTIONS type.

  • policy_apply_condition refers to the variable that you defined for the DBMS_TSDP_PROTECT.POLICY_CONDITIONS type.

Example 11-3 shows the policy set as follows:

DBMS_TSDP_PROTECT.ADD_POLICY('redact_partial_cc', DBMS_TSDP_PROTECT.REDACT, redact_feature_options, policy_conditions);

Step 5: Associate the Policy with a Sensitive Type

After you have created the transparent sensitive data protection policy, you can use the DBMS_TSDP_PROTECT.ASSOCIATE_POLICY procedure to associate the policy with a sensitive type.

  1. Find the sensitive type that you want to use.

    For example, to find a list of all sensitive types:

    SELECT NAME FROM DBA_SENSITIVE_COLUMN_TYPES ORDER BY NAME;
    
    NAME
    --------------------
    credit_card_num_type
    
  2. Run the DBMS_TSDP_PROTECT.ASSOCIATE_POLICY procedure to associate the policy with a sensitive column type.

    For example:

    BEGIN
     DBMS_TSDP_PROTECT.ASSOCIATE_POLICY(
     policy_name        => 'redact_partial_cc',
     sensitive_type     => 'credit_card_num_type',
     associate          => true);
    END;
    /
    

    The following query shows that the credit_card_num_type is now associated with the redact_partial_cc policy.

    SELECT POLICY_NAME, SENSITIVE_TYPE FROM DBA_TSDP_POLICY_TYPE ORDER BY SENSITIVE_TYPE;
    
    POLICY_NAME       SENSITIVE_TYPE
    ----------------- --------------------
    redact_partial_cc  credit_card_num_type
    

Step 6: Enable the Transparent Sensitive Data Protection Policy

You can enable the transparent sensitive data protection policy in any of the following ways:

Enabling Protection for the Current Database in a Protected Source

The DBMS_TSDP_PROTECT.ENABLE_PROTECTION_SOURCE procedure enables protection for the current database for this source. To disable the protection, run the DBMS_TSDP_PROTECT.DISABLE_PROTECTION_SOURCE procedure.

Example 11-4 shows how to enable transparent sensitive data protection policies for the orders_db database.

Example 11-4 Enabling TSDP Protection for All Columns Identified By a Source

BEGIN
 DBMS_TSDP_PROTECT.ENABLE_PROTECTION_SOURCE(
  discovery_source       => 'orders_db');
END;
/

Enabling Protection for a Specific Table Column

To enable protection for a specific table schema, run the DBMS_TSDP_PROTECT.ENABLE_PROTECTION_COLUMN procedure. To disable the protection, run the DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN procedure. Remember that you can enable only one policy per table.

Example 11-5 shows how to enable the transparent sensitive data protection policy redact_partial_cc for a specific table column.

Example 11-5 Enabling TSDP Protection for a Table Column

BEGIN
 DBMS_TSDP_PROTECT.ENABLE_PROTECTION_COLUMN(
  schema_name          => 'OE',
  table_name           => 'CUST_CC',
  column_name          => 'CREDIT_CARD',
  policy               => 'redact_partial_cc');
END;
/

If an ORA-45622: warnings generated during policy enforcement error appears, then check the configuration of the policy. In this example, the redact_partial_cc policy is enabled on a column if this column is of the NUMBER data type and has a length of 16. Even though the OE.CUST_CC.CREDIT_CARD column is associated with the redact_partial_cc policy, the policy is not enabled if this column fails to satisfy the conditions (data type and length).

Enabling Protection for a Specific Column Type

You can run the DBMS_TSDP_PROTECT.ENABLE_PROTECTION_TYPE procedure to enable protection for all table columns that are identified by a specific column type. To disable the protection, run the DBMS_TSDP_PROTECT.DISABLE_PROTECTION_TYPE procedure

Example 11-6 shows how to enable transparent sensitive data protection for all columns that use the credit_card_num_type sensitive type.

Example 11-6 Enabling TSDP Protection for a Column Type

BEGIN
 DBMS_TSDP_PROTECT.ENABLE_PROTECTION_TYPE(
  sensitive_type           => 'credit_card_num_type');
END;
/

Step 7: Optionally, Export the Policy to Other Databases

If you want to export or import the policy to or from another database, then you must use Oracle Data Pump to perform a full export or import of the database that contains the policy. Remember that the export and import operations apply to the entire database, not just the transparent sensitive data protection policy.

See Also:

Altering Transparent Sensitive Data Protection Policies

To alter a transparent sensitive data protection policy, you use the DBMS_TSDP_PROTECT.ALTER_POLICY procedure. Similar to creating the policy, you must define how the Data Redaction settings must change, and then apply these changes to the transparent sensitive data protection policy itself. You can find a list of existing policies and their protection definitions by querying the DBA_TSDP_POLICY_FEATURE data dictionary view.

Example 11-7 shows how to alter an existing transparent sensitive data protection policy.

Example 11-7 Altering a Transparent Sensitive Data Protection Policy

1
2
3
4
5
6
7
8
9
10
11
12
13
14
DECLARE
  redact_feature_options SYS.DBMS_TSDP_PROTECT.FEATURE_OPTIONS;
  policy_conditions SYS.DBMS_TSDP_PROTECT.POLICY_CONDITIONS;
  BEGIN
  redact_feature_options ('expression') := 
   'SYS_CONTEXT(''USERENV'',''SESSION_ USER'') =''APPUSER''';
  redact_feature_options ('function_type') := 'DBMS_REDACT.PARTIAL';
  redact_feature_options ('function_parameters') := '9,1,6';
  policy_conditions(DBMS_TSDP_PROTECT.DATATYPE) := 'NUMBER';
  policy_conditions(DBMS_TSDP_PROTECT.LENGTH) := '22';
 DBMS_TSDP_PROTECT.ALTER_POLICY ('redact_partial_cc',  
  redact_feature_options, policy_conditions);
END;
/

In this example:

  • Line 2: Creates the variable redact_feature_options, which uses the FEATURE_OPTIONS data type.

  • Line 3: Creates the variable policy_conditions, which uses the POLICY_CONDITIONS data type.

  • Lines 5–8: Writes the Data Redaction policy settings to the redact_feature_option variable. This example applies the Data Redaction policy to the user APPUSER, defines the policy as a partial data redaction for number data types. See Oracle Database Advanced Security Guide for information about how the function_parameters parameter works for this case.

  • Lines 9–10: Writes the TSDP policy conditions to the policy_conditions variable (that is, the data type and length) for the protected NUMBER data type column.

  • Lines 11–12: Executes the DBMS_TSDP_PROTECT.ALTER_POLICY procedure, which alters the redact_partial_cc TSDP policy to use the definitions set in the redact_feature_options and policy_conditions variables.

Disabling Transparent Sensitive Data Protection Policies

You can execute the DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN procedure to disable one or all transparent sensitive data protection policies.

To disable transparent sensitive data protection policies:

  1. Query the DBA_TSDP_POLICY_PROTECTION data dictionary view to find the protected columns and their associated Transparent Sensitive Data Protection policies.

    For example:

    SELECT COLUMN_NAME, TSDP_POLICY FROM DBA_TSDP_POLICY_PROTECTION WHERE TABLE_NAME = 'CUST_CC';
    
    COLUMN_NAME   TSDP_POLICY
    ------------  ------------------
    CREDIT_CARD   redact_partial_cc
    
  2. Run the DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN procedure.

    For example, to disable the redact_partial_cc policy on the CREDIT_CARD column of the CUST_CC table:

    BEGIN
     DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN(
      schema_name          => 'OE',
      table_name           => 'CUST_CC',
      column_name          => 'CREDIT_CARD',
      policy               => 'redact_partial_cc');
    END;
    /
    

    You can use the % wildcard in this procedure to specify multiple items. For example, to disable protection for any columns that begin with CREDIT, you could enter the following:

    BEGIN
     DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN(
      schema_name          => 'OE',
      table_name           => 'CUST_CC',
      column_name          => 'CREDIT%',
      policy               => 'redact_partial_cc');
    END;
    /
    

    To disable all Transparent Sensitive Data Protection policies for a table, you can omit the policy parameter. For example:

    BEGIN
     DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN(
      schema_name          => 'OE',
      table_name           => 'CUST_CC',
      column_name          => '%');
    END;
    /
    

Dropping Transparent Sensitive Data Protection Policies

You can drop an entire transparent sensitive data protection policy, or you can drop a condition-enable-options combination from the policy. If the policy only has one condition-enable-options combination, then Oracle Database drops the entire policy. You do not need to disable a policy before dropping it, but you do need to drop its associated sensitive column first, then its sensitive type.

To drop a transparent sensitive data protection policy:

  1. Query the POLICY_NAME column of the DBA_TSDP_POLICY_FEATURE data dictionary view to find the policy that you want to drop.

    SELECT POLICY_NAME FROM DBA_TSDP_POLICY_FEATURE;
    
    POLICY_NAME
    -----------------
    redact_partial_cc
    

    Remember that you must be granted the SELECT_CATALOG_ROLE role to query the transparent sensitive data protection data dictionary views.

  2. Find the sensitive column that is associated with this policy.

    For example:

    SELECT COLUMN_NAME FROM DBA_TSDP_POLICY_PROTECTION WHERE TSDP_POLICY = 'redact_partial_cc';
    
    COLUMN_NAME
    -----------------
    CREDIT_CARD
    
  3. Drop this sensitive column.

    For example:

    BEGIN
     DBMS_TSDP_MANAGE.DROP_SENSITIVE_COLUMN (
       schema_name        => 'OE',
       table_name         => 'CUST_CC',
       column_name        => 'CREDIT_CARD');
    END;
    /
    
  4. Find the sensitive type that is associated with this policy.

    For example:

    SELECT SENSITIVE_TYPE FROM DBA_TSDP_POLICY_TYPE WHERE POLICY_NAME = 'redact_partial_cc'; 
    
    SENSITIVE_TYPE
    --------------------
    credit_card_num_type
    
  5. Drop this sensitive type.

    For example:

    BEGIN
     DBMS_TSDP_MANAGE.DROP_SENSITIVE_TYPE (   sensitive_type     => 'credit_card_num_type');END;
    /
    
  6. Run the DBMS_TSDP_PROTECT.DROP_POLICY procedure to drop the policy.

    For example, to completely drop the policy:

    BEGIN
     DBMS_TSDP_PROTECT.DROP_POLICY(
       policy_name     => 'redact_partial_cc');
    END;
    /
    

    To drop the default condition-enable options combination from the policy:

    DECLARE
       policy_conditions DBMS_TSDP_PROTECT.POLICY_CONDITIONS;
    BEGIN
       DBMS_TSDP_PROTECT.DROP_POLICY ('redact_partial_cc', policy_conditions);
    END;
    /
    

    To drop the default condition-enable options combination from the policy based on a specific condition:

    DECLARE
       policy_conditions DBMS_TSDP_PROTECT.POLICY_CONDITIONS;
    BEGIN
       policy_conditions (DBMS_TSDP_PROTECT.DATATYPE) := 'NUMBER';
       DBMS_TSDP_PROTECT.DROP_POLICY ('redact_partial_cc', policy_conditions);
    END;
    /
    

Using the Predefined REDACT_AUDIT Policy to Mask Bind Values

This section contains:

About the REDACT_AUDIT Policy

The bind values of the bind variables that are used in SQL statements can appear in audit records when auditing is configured. Similarly, bind values can appear in trace files when the appropriate event is set. Bind values can also appear when you query the V$SQL_BIND_DATA dynamic view.

You can use the predefined REDACT_AUDIT Transparent Sensitive Data Protection policy to mask bind values. This policy displays the data as an asterisk (*) in audit records, trace files, and in V$SQL_BIND_DATA view queries. By default the REDACT_AUDIT policy is associated with every sensitive type in the database. When you identify a column as sensitive, by default, the REDACT_AUDIT policy is enabled for it.

You can disable and enable the REDACT_AUDIT policy, but you cannot alter or drop it.

How Bind Variables Are Considered to be Associated with Sensitive Columns

Bind variables are considered to be sensitive or "associated" with sensitive columns in the following cases:

Bind Variables and Sensitive Columns in the Expressions of Conditions

In comparison conditions, a sensitive column and a bind variable appear in the expressions that are being compared. The examples in this section illustrate how bind variables and sensitive columns work with condition expressions.

In the following comparison query, the bind value in VAR1 is masked because VAR1 and SALARY appear in the expression that is compared using the comparison condition >.

SELECT EMPLOYEE_ID FROM HR.EMPLOYEES WHERE SALARY > :VAR1;

In the next comparison query, the bind values in VAR1 and VAR2 are masked because VAR1, VAR2, and SALARY appear in expressions that use the comparison equality condition =.

SELECT EMPLOYEE_ID FROM HR.EMPLOYEES WHERE SALARY + :VAR1 = TO_NUMBER(:VAR2, '9G999D99');

For floating point conditions, the sensitive column and the bind variable appear in the expression that is evaluated. In the following example, the bind value in VAR1 is masked because VAR1 and SALARY appear in the expression for the IS NOT NAN condition.

SELECT COUNT( ) FROM HR.EMPLOYEES WHERE (SALARY * :VAR1) IS NOT NAN;

In pattern matching conditions, the sensitive column and the bind variable appear as arguments. In the following example, the bind value in VAR1 is masked because VAR1 and LAST_NAME are the arguments for the LIKE condition.

SELECT LAST_NAME FROM HR.EMPLOYEES WHERE LAST_NAME LIKE :VAR1;

For BETWEEN conditions, the sensitive column and the bind variable appear in the expressions that are arguments. In the following example, bind values in VAR1 and VAR2 are masked because VAR1, VAR2, and SALARY appear in expressions that are arguments to the BETWEEN condition.

SELECT EMPLOYEE_ID FROM HR.EMPLOYEES WHERE SALARY BETWEEN :VAR1 AND :VAR2;

In the next example, the sensitive column and the bind variable are the arguments of the IN condition. Here, the bind values in VAR1 and VAR2 are masked because VAR1, VAR2, and SALARY appear as arguments to the IN condition.

SELECT COUNT( ) FROM HR.EMPLOYEES WHERE SALARY IN ( :VAR1, :VAR2);

When a condition has a nested subquery as an argument, the bind variables and sensitive columns that appear in the nested subquery are not considered to be associated with the condition. For example, suppose HR.EMPLOYEES.SALARY is a sensitive column. In the following query, the SALARY column and the subquery are expressions for the greater-than condition >.

SELECT EMPLOYEE_ID FROM HR.EMPLOYEES WHERE SALARY > (SELECT SALARY FROM HR.EMPLOYEES WHERE MANAGER_ID = :VAR1);

However, variable VAR1 is associated with column MANAGER_ID as variable VAR1 and MANAGER_ID appears in expressions being compared using the condition =. Because MANAGER_ID is not a sensitive column, variable VAR1 is not considered sensitive. The variable VAR1 is not considered to be associated with the sensitive column SALARY.

In the case of the logical conditions, model conditions, multiset conditions, XML conditions, compound conditions, IS OF type conditions, and EXISTS conditions, there can be no cases where a bind variable and a sensitive column are associated with each other. This is due to the structure or the nature of these conditions.

A Bind Variable and a Sensitive Column Appearing in the Same SELECT Item

If a column in a SELECT item is sensitive, then all the binds in the SELECT item are considered sensitive. For example, assume that HR.EMPLOYEES.SALARY and HR.EMPLOYEES.COMMISSION_PCT are sensitive columns. In the following query, the bind variable VAR1 is considered sensitive because it appears in the same SELECT item as the sensitive column SALARY, so its bind value is masked.

SELECT (SALARY * VAR1) AS BONUS AS FROM HR.EMPLOYEES WHERE EMPLOYEE_ID = :VAR2;

In the next example, the bind variable VAR1 is considered sensitive because it appears in the same SELECT item as SALARY. VAR2 is considered sensitive because it appears in the same SELECT item as the sensitive column COMMISSION_PCT.

SELECT (SALARY * VAR1), (COMMISSION_PCT * :VAR2), (EMPNO + :VAR3) AS BONUS AS FROM PAYROLL.ACCOUNT;

Bind Variables in Expressions Assigned to Sensitive Columns in INSERT or UPDATE Operations

You can assign multiple bind variables to different columns in one INSERT or UPDATE statement.

Consider the following INSERT statement:

INSERT INTO PAYROLL.ACCOUNT (ACCOUNT_NUM, SALARY) VALUES (:VAR1 * :VAR2 , :VAR3); 

In this INSERT statement, the following takes place:

  • The bind variables VAR1 and VAR2 appear in the expression (:VAR1 * :VAR2), which is assigned to the sensitive column ACCOUNT_NUM.

  • The bind variable VAR3 is assigned to sensitive column SALARY.

Consider the following UPDATE statement:

UPDATE PAYROLL.ACCOUNT SET ACCOUNT_NUM = :VAR1, SALARY = :VAR2;

In this UPDATE statement, the following takes place:

  • The bind variable VAR1 is assigned to sensitive column ACCOUNT_NUM.

  • The bind variable VAR2 is assigned to sensitive column SALARY.

How Bind Variables on Sensitive Columns Behave with Views

A bind variable that appears in a query on a view is considered sensitive if the view column references a sensitive column. For example, suppose you identify the SALARY column in the HR.EMPLOYEES table as sensitive. Then you create the view EMPLOYEES_VIEW as follows:

CREATE OR REPLACE VIEW HR.EMPLOYEES_VIEW AS SELECT * FROM HR.EMPLOYEES;

When a user references the SALARY column from this view in a SQL statement, any bind variable that has been associated with the SALARY column is considered sensitive and its bind value then masked.

SELECT EMPLOYEE_ID FROM HR.EMPLOYEES_VIEW WHERE SALARY = :VAR1;

In this case, the bind variable VAR1 is masked because it is associated with the HR.EMPLOYEES_VIEW.SALARY column, which references the sensitive column HR.EMPLOYEES.SALARY.

Disabling and Enabling the REDACT_AUDIT Policy

By default, the REDACT_AUDIT policy is enabled for all sensitive columns. You can disable it for a specific sensitive column or all sensitive columns, and when needed, re-enable it. Remember that you cannot alter or delete the REDACT_AUDIT policy.

Example 11-8 shows how to disable the REDACT_AUDIT policy for the SALARY column of HR.EMPLOYEES.

Example 11-8 Disabling the REDACT_AUDIT Policy for One Sensitive Column

BEGIN
 DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN(
  schema_name          => 'HR',
  table_name           => 'EMPLOYEES',
  column_name          => 'SALARY',
  policy               => 'REDACT_AUDIT');
END;
/

Example 11-8 shows how to disable the REDACT_AUDIT policy for all sensitive columns in the current database.

Example 11-9 Disabling the REDACT_AUDIT Policy for All Columns in the Database

BEGIN
 DBMS_TSDP_PROTECT.DISABLE_PROTECTION_COLUMN(
  policy               => 'REDACT_AUDIT');
END;
/

Example 11-8 shows how to re-enable the REDACT_AUDIT policy for the SALARY column of HR.EMPLOYEES.

Example 11-10 Enabling the REDACT_AUDIT Policy for One Sensitive Column

BEGIN
 DBMS_TSDP_PROTECT.ENABLE_PROTECTION_COLUMN(
  schema_name          => 'HR',
  table_name           => 'EMPLOYEES',
  column_name          => 'SALARY',
  policy               => 'REDACT_AUDIT');
END;
/

Example 11-8 shows how to enable the REDACT_AUDIT policy for all sensitive columns in the current database.

Example 11-11 Enabling the REDACT_AUDIT Policy for All Columns in the Database

BEGIN
 DBMS_TSDP_PROTECT.ENABLE_PROTECTION_COLUMN(
  policy               => 'REDACT_AUDIT');
END;
/

Using Transparent Sensitive Data Protection Policies with Other Oracle Features

This section contains:

Using Transparent Sensitive Data Protection Policies with Data Redaction

You can use Oracle Data Redaction features with TSDP policies by using the Data Redaction function types, function parameters, and expressions in the TSDP policy definition. For example, you can set the enable the TSDP policy to use FULL or PARTIAL data redaction.

See Also:

Using Transparent Sensitive Data Protection Policies with Oracle VPD Policies

This section contains:

About Using TSDP Policies with Oracle Virtual Private Database Policies

You can incorporate Oracle Virtual Private Database protection with Transparent Sensitive Data Protection policies. This feature works as follows:

  1. You create a VPD policy function with a suitable predicate. Later on, when you create the TSDP policy, you will refer to this VPD policy function by using the policy_function setting for the feature_options parameter.

    See "Creating a Function to Generate the Dynamic WHERE Clause" for more information about VPD functions.

  2. You create a TSDP policy with the necessary VPD settings similar to the VPD policy function.

    The TSDP policy uses parameter settings from the DBMS_RLS.ADD_POLICY procedure to provide VPD protection. Table 11-1 lists these parameters. Be aware that parameters from the DBMS_RLS.ADD_GROUPED_POLICY policy are not supported.

  3. You associate the TSDP policy with the necessary sensitive types by using the DBMS_TSDP_PROTECT.ASSOCIATE_POLICY procedure.

  4. You then enable TSDP protection by using any of the DBMS_TSDP_PROTECT_ENABLE_PROTECTION_* procedures.

  5. You enable the TSDP policy. At this point, Oracle Database creates an internal VPD policy that uses the function that you created in Step 1.

    The name of the internal policy begins with ORA$VPD followed by an identifier (for example, ORA$VPD_6J6L3RSJSN2VAN0XF). You can find this policy by querying the POLICY_NAME column of the DBA_POLICIES data dictionary view.

  6. When users query the table, the output for the column is based on both the VPD protections and the TSDP policy that are now in place.

  7. These protections remain in place until you disable the TSDP policy for this column. At this point, Oracle Database automatically drops the VPD policy, because it is no longer needed. If you reenable the TSDP policy, then the VPD policy is recreated.

DBMS_RLS.ADD_POLICY Parameters That Are Used for TSDP Policies

Table 11-1 describes the DBMS_RLS.ADD_POLICY parameters that are permissible in the FEATURE_OPTIONS parameter when you use the DBMS_TSDP_PROTECT.ADD_POLICY or DBMS_TSDP_PROTECT.ALTER_POLICY procedure.

Table 11-1 DBMS_RLS.ADD_POLICY Parameters Used for TSDP Policies

Parameter Description Default

function_schema

Schema of the policy function (current default schema, if NULL). If no function_schema is specified, then the current user's schema is assumed.

NULL

policy_function

Name of a function that generates a predicate for the policy. If the function is defined within a package, then you must include the name of the package (for example, my_package.my_function).

NULL

statement_types

Statement types to which the policy applies. It can be any combination of INDEX, SELECT, INSERT, UPDATE, or DELETE. The default is to apply to most of these types except INDEX.

NULL

update_check

Optional argument for INSERT or UPDATE statement types. The default is FALSE. Setting update_check to TRUE sets Oracle Database to check the policy against the value after an INSERT or UPDATE operation.

FALSE

static_policy

If you set this value to TRUE, then Oracle Database assumes that the policy function for the static policy produces the same predicate string for anyone accessing the object, except for SYS or the privileged user who has the EXEMPT ACCESS POLICY privilege.

FALSE

policy_type

Default is NULL, which means policy_type is decided by the value of the static_policy parameter. Specifying any of these policy types overrides the value of static_policy.

NULL

long_predicate

Default is FALSE, which means the policy function can return a predicate with a length of up to 4000 bytes. TRUE means the predicate text string length can be up to 32K bytes. Policies existing before the availability of the long_predicate parameter retain a 32K limit.

FALSE

sec_relevant_cols_opt

If you specify this parameter, then Transparent Sensitive Data Protection inputs the sensitive column on which the protection is enabled to the sec_relevant_cols parameter of the DBMS_RLS.ADD_POLICY procedure.

Allowed values are for sec_relevant_cols_opt are as follows:

  • NULL enables the filtering defined with sec_relevant_cols to take effect.

  • DBMS_RLS.ALL_ROWS displays all rows, but with sensitive column values, which are filtered by the sec_relevant_cols parameter, they display as NULL.

NULL


Tutorial: Creating a TSDP Policy That Uses Virtual Private Database Protection

The following tutorial demonstrates how to use Transparent Sensitive Data Protection with Virtual Private Database to control

Step 1: Create the hr_appuser User Account

  1. Log into the database instance as user SYS with the SYSDBA administrative privilege.

    sqlplus sys as sysdba
    Enter password: password
    
  2. In a multitenant environment, connect to the appropriate pluggable database (PDB).

    For example:

    CONNECT SYS@hrpdb AS SYSDBA
    Enter password: password
    

    To find the available PDBs, query the DBA_PDBS data dictionary view. To check the current PDB, run the show con_name command.

  3. Create the following user accounts:

    GRANT CREATE SESSION TO hr_appuser IDENTIFIED BY password;
    GRANT CREATE SESSION TO tsdp_admin IDENTIFIED BY password;
    

    Replace password with a password that is secure. See "Minimum Requirements for Passwords" for more information.

  4. Grant user tsdp_admin the following privileges:

    GRANT CREATE PROCEDURE TO tsdp_admin;
    GRANT EXECUTE ON DBMS_TSDP_MANAGE TO tsdp_admin;
    GRANT EXECUTE ON DBMS_TSDP_PROTECT TO tsdp_admin; 
    GRANT EXECUTE ON DBMS_RLS to tsdp_admin;
    
  5. Connect as user SCOTT.

    CONNECT SCOTT -- Or, CONNECT SCOTT@hrpdb
    Enter password: password
    
  6. Grant the hr_appuser the SELECT privilege for the EMP table.

    GRANT SELECT ON EMP TO hr_appuser;
    

Step 2: Identify the Sensitive Columns

  1. Connect as user tsdp_admin.

    CONNECT tsdp_admin -- Or, CONNECT tsdb_admin@hrpdb
    Enter password: password
    
  2. Create the salary_type sensitive type:

    BEGIN
     DBMS_TSDP_MANAGE.ADD_SENSITIVE_TYPE (
      sensitive_type  => 'salary_type',
      user_comment    => 'Type for SCOTT.EMP column');
    END;
    /
    
  3. Associate the salary_type sensitive type with the SCOTT.EMP table.

    BEGIN
     DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMN (
     schema_name        => 'SCOTT',
     table_name         => 'EMP',
     column_name        => 'SAL',
     sensitive_type     => 'salary_type',
     user_comment       => 'Sensitive column addition of SALARY_TYPE');
    END;
    /
    

Step 3: Create a Virtual Private Database Function

Create the Oracle Virtual Private Database policy function that Transparent Sensitive Data Protection will associate with the VPD policy that will be automatically created when you enable the TSDP policy.

CREATE OR REPLACE FUNCTION vpd_function (
  v_schema IN VARCHAR2, 
  v_objname IN VARCHAR2) 
 RETURN VARCHAR2 AS 
BEGIN
 RETURN 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''HR_APPUSER'''; 
END vpd_function;
/

Step 4: Create and Enable a Transparent Sensitive Data Protection Policy

  1. Create the Transparent Sensitive Data Protection policy.

    DECLARE 
     vpd_feature_options DBMS_TSDP_PROTECT.FEATURE_OPTIONS;
     policy_conditions DBMS_TSDP_PROTECT.POLICY_CONDITIONS;
    BEGIN
     vpd_feature_options ('policy_function') := 'vpd_function';   
     vpd_feature_options ('sec_relevant_cols_opt') := 'DBMS_RLS.ALL_ROWS';   
     dbms_tsdp_protect.add_policy('tsdp_vpd', DBMS_TSDP_PROTECT.VPD, vpd_feature_options, policy_conditions); 
    END; 
    /
    

    In this example, the vpd_feature_options parameter refers to the sec_relevant_cols_opt parameter from the DBMS_RLS.ADD_POLICY procedure. When the TSDP policy is enabled, the VPD policy that is automatically created will have its sec_relevant_cols parameter (of DBMS_RLS.ADD_POLICY) set to the name of the sensitive column on which TSDP enables the VPD policy. If you had not used the sec_relevant_cols_opt parameter, then TSDP would not have used the DBMS_RLS.ADD_POLICY sec_relevant_cols_opt parameter.

  2. Associate the tsdp_vpd1 TSDP policy with the salary_type sensitive type.

    BEGIN
     DBMS_TSDP_PROTECT.ASSOCIATE_POLICY(
     policy_name        => 'tsdp_vpd',
     sensitive_type     => 'salary_type',
     associate          => TRUE);
    END;
    /
    
  3. Enable protection to enforce the Virtual Private Database policy on all columns identified as SALARY_TYPE:

    BEGIN
     DBMS_TSDP_PROTECT.ENABLE_PROTECTION_TYPE(
      sensitive_type           => 'salary_type');
    END;
    /
    

Step 5: Test the Transparent Sensitive Data Protection Policy

  1. Connect as user hr_appuser.

    CONNECT hr_appuser -- Or, CONNECT hr_appuser@hrpdb
    Enter password: password
    
  2. Query the SCOTT.EMP table as follows:

    SELECT SAL, COMM, EMPNO FROM SCOTT.EMP;
    

    The following output appears:

        SAL   COMM   EMPNO
    --------- ------ ----------
        800          7369
       1600    300   7499
       1250    500   7521
       2975          7566
       1250   1400   7654
       2850          7698
       2450          7782
       3000          7788
       5000          7839
       1500     0    7844
       1100          7876
        950          7900
       3000          7902
       1300          7934
    14 rows selected. 
    

    The vpd_function function enables user hr_appuser to see the salaries in the SAL column of the EMP table.

  3. Connect as user SCOTT and then perform the same query.

    CONNECT SCOTT -- Or, CONNECT SCOTT@hrpdb
    Enter password: password
    
    SELECT SAL, COMM, EMPNO FROM SCOTT.EMP;
    

    The following output appears:

        SAL   COMM   EMPNO
    --------- ------ ----------
                     7369
               300   7499
               500   7521
                     7566
              1400   7654
                     7698
                     7782
                     7788
                     7839
                0    7844
                     7876
                     7900
                     7902
                     7934
    14 rows selected. 
    

    Even though SCOTT owns the EMP table, the vpd_function function prevents him from seeing the salaries in the SAL column of this table

Step 6: Remove the Components for This Tutorial

  1. Connect as user tsdp_admin.

    CONNECT tsdp_admin -- Or, CONNECT tsdp_admin@hrpdb
    Enter password: password
    
  2. Execute the following statements in the order shown.

    BEGIN
     DBMS_TSDP_MANAGE.DROP_SENSITIVE_COLUMN (
       schema_name        => 'SCOTT',
       table_name         => 'EMP',
       column_name        => 'SAL');
    END;
    /
    
    BEGIN
     DBMS_TSDP_MANAGE.DROP_SENSITIVE_TYPE(
     sensitive_type     => 'salary_type');
    END;
    /
    
    BEGIN
     DBMS_TSDP_PROTECT.DROP_POLICY(
       policy_name     => 'tsdp_vpd');
    END;
    /
    
  3. Connect as user SYSTEM.

    CONNECT SYSTEM -- Or, CONNECT SYSTEM@hrpdb
    Enter password: password
    
  4. Drop the tsdp_admin and hr_appuser accounts.

    DROP USER tsdp_admin CASCADE;
    DROP USER hr_appuser
    

How a Multitenant Environment Affects Transparent Sensitive Data Protection

In a multitenant environment, you can apply TSDP policies to the current PDB only. You cannot apply them to the entire multitenant container database (CDB).

Transparent Sensitive Data Protection Data Dictionary Views

Table 11-2 describes data dictionary views that you can use to find information about transparent sensitive data protection policies. Before you can use these views, you must be granted the SELECT_CATALOG_ROLE role.

Table 11-2 Transparent Sensitive Data Protection Views

View Description

DBA_DISCOVERY_SOURCE

Describes discovery import information with regard to transparent sensitive data protection policies

DBA_SENSITIVE_COLUMN_TYPES

Describes the sensitive column types that have been defined for the current database

DBA_SENSITIVE_DATA

Describes the sensitive columns in the database

DBA_TSDP_IMPORT_ERRORS

Shows information regarding the errors encountered during import of discovery result. It shows information with regard to the error code, schema name, table name, column name, and sensitive type.

DBA_TSDP_POLICY_CONDITION

Describes the transparent sensitive data protection policy and condition mapping. This view also lists the property-value pairs for the condition.

DBA_TSDP_POLICY_FEATURE

Shows the transparent sensitive data protection policy security feature mapping. (At this time, only Oracle Data Redaction and Oracle Virtual Private Database are supported.)

DBA_TSDP_POLICY_PARAMETER

Describes the parameters of transparent sensitive data protection policies

DBA_TSDP_POLICY_PROTECTION

Shows the list of columns that have been protected through transparent sensitive data protection

DBA_TSDP_POLICY_TYPE

Shows the policy to sensitive column type mapping