Create Masking Policies

You can create a masking policy from a sensitive data model or create an empty masking policy for a target database and add columns later.

About Creating Masking Policies

You can create masking policies from the Masking Policies page in Oracle Data Safe. You have two options when creating a masking policy:

  • Create a masking policy starting with a sensitive data model. To use this option, you need to have access to a pre-built sensitive data model. Oracle Data Safe lists all the sensitive columns from the sensitive data model and automatically associates them with default masking format. You can then modify and edit the selections as needed.
  • Create an empty masking policy and associate it with a target database. Later, you add columns to the masking policy and associate masking formats with them.

Create a Masking Policy Starting From a Sensitive Data Model

  1. Under Data Safe - Database Security, select Data masking.
  2. Under Data masking, select Masking policies.
  3. Click Create masking policy. The Create masking policy window is displayed.
  4. Enter a name for your masking policy.
  5. Select a compartment in which to store your masking policy.
  6. (Optional) Enter a brief description of your masking policy.
  7. Leave the Using a sensitive data model tile selected.
  8. Select a sensitive data model from the correct compartment.
  9. (Optional) To upload pre-masking and post-masking scripts, do the following:
    1. Expand Upload Scripts.
    2. In the Upload Pre-Masking Script area, drop or select your SQL file.

      Note:

      If the pre-masking script does not successfully execute within 12 hours and one retry (two runs total), the masking report will provide details about any failed or skipped statements. The overall masking job will not fail.
    3. In the Upload Post-Masking Script area, drop or select your SQL file.

      Note:

      If the post-masking script does not successfully execute within 14 hours and two retrys (three runs total), the masking report will provide details about any failed or skipped statements. The overall masking job will not fail.
    Limitations and usage notes of using pre-masking or post-masking scripts:
    • SQL statements and PL/SQL blocks are executed sequentially from the provided pre or post masking scripts.
    • When processing the scripts, Oracle Data Safe is capable of creating and executing all PL/SQL stored program units (procedures, functions, packages, anonymous block).
    • If execution of any statement or block fails, the errors and warnings are ignored and execution of subsequent statements is continued.
    • Oracle Data Safe automatically retries the script execution, up to seven times, from the beginning if interrupted due to database connectivity issues. Therefore, we recommend ensuring that pre and post masking scripts can be run repetitively without impacting the results.
    • Along with successfully executed statements, errors of failed statements can be viewed in the downloadable masking log file.

      Failed statements and the errors are also available as part of work-request errors which can be viewed on the Oracle Data Safe console.

    • Oracle Data Safe does not support printing the output of DBMS_OUTPUT.PUT_LINE() statements to the downloadable masking log file.
    • Oracle Data Safe does not support printing the output of any third-party PL/SQL logging libraries to the downloadable masking log file.

      The output of SELECT queries is also not printed in the downloadable masking log file. The workaround for this is to write the output of SELECT queries to a table which could be queried later.

    • Oracle Data Safe does not support execution of another SQL script file from the pre or post masking scripts.
    • Oracle Data Safe does not support functionality specific to the SQL*Plus client.
  10. (Optional) To customize the processing of the masking job, do the following:
    1. Expand Masking Options
    2. Disable or enable redo log generation during masking. This is disabled by default. Redo log generation allows you to use a flashback database to retrieve the original unmasked data after it has been masked.
    3. Specify the value for parallel execution:
      • None - No parallelism is used when data masking process is running.
      • Default - The default value is the optimum number of CPUs to be used in parallel. This is calculated by the Oracle Database.
      • Degree of Parallelism - Allows you to input an integer to set the number of CPUs to be used in parallel. Refer to Using Parallel Execution in the Oracle AI Database VLDB and Partitioning Guide when choosing an integer value.

      Note:

      The degree of parallelism is limited by the number of CPUs you have available. If the integer entered in Degree of Parallelism exceeds the number of available CPUs, it will default to the maximum CPUs available when processing.
    4. Specify how you would like invalid objects to recompile after data masking:
      • None - Invalid objects do not recompile.
      • Default- Invalid objects recompile serially, only when the previous objects has finished compiling.
      • Parallel - Invalid objects recompile using the same value for parallelism as specified above.

        Note:

        If a value for parallelism was not specified, the value used will be the optimized value calculated by the Oracle AI Database.
    5. Enable or disable dropping temporary tables created during data masking after masking is completed. This is enabled by default. Data Masking creates temporary tables that map the original sensitive data values to the mask values. Preserve these table to track how masking changed your data.

      Note:

      Disabling dropping the temporary tables compromises security. These tables must be dropped before the database is available for unprivileged users.
    6. Enable or disable refreshing the statistics gathered on masked database tables after masking. This is enabled by default.
  11. (Optional) To create tags, expand the Tags section and configure tags for your masking policy.
  12. Click Create masking policy.

    Note:

    It's important that you wait for the masking policy to be created before closing the window so that all sensitive columns from the sensitive data model are successfully added to the masking policy. When the masking policy is fully created, the Masking Policy Details page is displayed and the status is set to ACTIVE.
  13. Review your masking policy.
    • The Details tab shows you the name and OCID of your masking policy, the work request information, the compartment in which the masking policy is stored, the target database with which the masking policy is associated, the name of the sensitive data model, and when the masking policy was created and last updated.
    • The Masking columns tab shows you the list of sensitive columns, their associated default masking formats, and if they have associated child columns.
  1. Under Data Safe - Database Security, select Data discovery.
  2. Under Data discovery, select Sensitive data models.
  3. Click on the name of a specific Sensitive Data Model. The Sensitive data model details page is displayed.
  4. Under the Actions menu, select Create masking policy. The Create masking policy window is displayed.
  5. Enter a name for your masking policy.
  6. Select a compartment in which to store your masking policy.
  7. (Optional) Enter a brief description of your masking policy.
  8. Leave the Sensitive data model as listed.
  9. (Optional) To upload pre-masking and post-masking scripts, do the following:
    1. Expand Upload Scripts.
    2. In the Upload Pre-Masking Script area, drop or select your SQL file.

      Note:

      If the pre-masking script does not successfully execute within 12 hours and one retry (two runs total), the masking report will provide details about any failed or skipped statements. The overall masking job will not fail.
    3. In the Upload Post-Masking Script area, drop or select your SQL file.

      Note:

      If the post-masking script does not successfully execute within 14 hours and two retrys (three runs total), the masking report will provide details about any failed or skipped statements. The overall masking job will not fail.
    Limitations and usage notes of using pre-masking or post-masking scripts:
    • SQL statements and PL/SQL blocks are executed sequentially from the provided pre or post masking scripts.
    • When processing the scripts, Oracle Data Safe is capable of creating and executing all PL/SQL stored program units (procedures, functions, packages, anonymous block).
    • If execution of any statement or block fails, the errors and warnings are ignored and execution of subsequent statements is continued.
    • Oracle Data Safe automatically retries the script execution, up to seven times, from the beginning if interrupted due to database connectivity issues. Therefore, we recommend ensuring that pre and post masking scripts can be run repetitively without impacting the results.
    • Along with successfully executed statements, errors of failed statements can be viewed in the downloadable masking log file.

      Failed statements and the errors are also available as part of work-request errors which can be viewed on the Oracle Data Safe console.

    • Oracle Data Safe does not support printing the output of DBMS_OUTPUT.PUT_LINE() statements to the downloadable masking log file.
    • Oracle Data Safe does not support printing the output of any third-party PL/SQL logging libraries to the downloadable masking log file.

      The output of SELECT queries is also not printed in the downloadable masking log file. The workaround for this is to write the output of SELECT queries to a table which could be queried later.

    • Oracle Data Safe does not support execution of another SQL script file from the pre or post masking scripts.
    • Oracle Data Safe does not support functionality specific to the SQL*Plus client.
  10. (Optional) To customize the processing of the masking job, do the following:
    1. Expand Masking Options
    2. Disable or enable redo log generation during masking. This is disabled by default. Redo log generation allows you to use a flashback database to retrieve the original unmasked data after it has been masked.
    3. Specify the value for parallel execution:
      • None - No parallelism is used when data masking process is running.
      • Default - The default value is the optimum number of CPUs to be used in parallel. This is calculated by the Oracle Database.
      • Degree of Parallelism - Allows you to input an integer to set the number of CPUs to be used in parallel. Refer to Using Parallel Execution in the Oracle AI Database VLDB and Partitioning Guide when choosing an integer value.

      Note:

      The degree of parallelism is limited by the number of CPUs you have available. If the integer entered in Degree of Parallelism exceeds the number of available CPUs, it will default to the maximum CPUs available when processing.
    4. Specify how you would like invalid objects to recompile after data masking:
      • None - Invalid objects do not recompile.
      • Default- Invalid objects recompile serially, only when the previous objects has finished compiling.
      • Parallel - Invalid objects recompile using the same value for parallelism as specified above.

        Note:

        If a value for parallelism was not specified, the value used will be the optimized value calculated by the Oracle AI Database.
    5. Enable or disable dropping temporary tables created during data masking after masking is completed. This is enabled by default. Data Masking creates temporary tables that map the original sensitive data values to the mask values. Preserve these table to track how masking changed your data.

      Note:

      Disabling dropping the temporary tables compromises security. These tables must be dropped before the database is available for unprivileged users.
    6. Enable or disable refreshing the statistics gathered on masked database tables after masking. This is enabled by default.
  11. (Optional) To create tags, expand the Tags section and configure tags for your masking policy.
  12. Click Create masking policy.

    Note:

    It's important that you wait for the masking policy to be created before closing the window so that all sensitive columns from the sensitive data model are successfully added to the masking policy. When the masking policy is fully created, the Masking Policy Details page is displayed and the status is set to ACTIVE.
  13. Review your masking policy.
    • The Details tab shows you the name and OCID of your masking policy, the work request information, the compartment in which the masking policy is stored, the target database with which the masking policy is associated, the name of the sensitive data model, and when the masking policy was created and last updated.
    • The Masking columns tab shows you the list of sensitive columns, their associated default masking formats, and if they have associated child columns.

Create an Empty Masking Policy and Associate it With a Target Database

  1. Under Data Safe - Database Security, select Data masking.
  2. Under Data masking, select Masking policies.
  3. Click Create masking policy. The Create Masking Policy window is displayed.
  4. Enter a name for your masking policy.
  5. Select a compartment in which to store your masking policy.
  6. (Optional) Enter a brief description of your masking policy.
  7. Select the Using a target database tile.
  8. Select a target database from the appropriate compartment.
  9. (Optional) To upload pre-masking and post-masking scripts, do the following:
    1. Expand Upload Scripts.
    2. In the Upload Pre-Masking Script area, drop or select your SQL file.

      Note:

      If the pre-masking script does not successfully execute within 12 hours and one retry (two runs total), the masking report will provide details about any failed or skipped statements. The overall masking job will not fail.
    3. In the Upload Post-Masking Script area, drop or select your SQL file.

      Note:

      If the post-masking script does not successfully execute within 14 hours and two retrys (three runs total), the masking report will provide details about any failed or skipped statements. The overall masking job will not fail.
    Limitations and usage notes of using pre-masking or post-masking scripts:
    • SQL statements and PL/SQL blocks are executed sequentially from the provided pre or post masking scripts.
    • When processing the scripts, Oracle Data Safe is capable of creating and executing all PL/SQL stored program units (procedures, functions, packages, anonymous block).
    • If execution of any statement or block fails, the errors and warnings are ignored and execution of subsequent statements is continued.
    • Oracle Data Safe automatically retries the script execution, up to seven times, from the beginning if interrupted due to database connectivity issues. Therefore, we recommend ensuring that pre and post masking scripts can be run repetitively without impacting the results.
    • Along with successfully executed statements, errors of failed statements can be viewed in the downloadable masking log file.

      Failed statements and the errors are also available as part of work-request errors which can be viewed on the Oracle Data Safe console.

    • Oracle Data Safe does not support printing the output of DBMS_OUTPUT.PUT_LINE() statements to the downloadable masking log file.
    • Oracle Data Safe does not support printing the output of any third-party PL/SQL logging libraries to the downloadable masking log file.

      The output of SELECT queries is also not printed in the downloadable masking log file. The workaround for this is to write the output of SELECT queries to a table which could be queried later.

    • Oracle Data Safe does not support execution of another SQL script file from the pre or post masking scripts.
    • Oracle Data Safe does not support functionality specific to the SQL*Plus client.
  10. (Optional) To customize the processing of the masking job, do the following:
    1. Expand Masking Options
    2. Disable or enable redo log generation during masking. This is disabled by default. Redo log generation allows you to use a flashback database to retrieve the original unmasked data after it has been masked.
    3. Specify the value for parallel execution:
      • None - No parallelism is used when data masking process is running.
      • Default - The default value is the optimum number of CPUs to be used in parallel. This is calculated by the Oracle Database.
      • Degree of Parallelism - Allows you to input an integer to set the number of CPUs to be used in parallel. Refer to Using Parallel Execution in the Oracle AI Database VLDB and Partitioning Guide when choosing an integer value.

      Note:

      The degree of parallelism is limited by the number of CPUs you have available. If the integer entered in Degree of Parallelism exceeds the number of available CPUs, it will default to the maximum CPUs available when processing.
    4. Specify how you would like invalid objects to recompile after data masking:
      • None - Invalid objects do not recompile.
      • Default- Invalid objects recompile serially, only when the previous objects has finished compiling.
      • Parallel - Invalid objects recompile using the same value for parallelism as specified above.

        Note:

        If a value for parallelism was not specified, the value used will be the optimized value calculated by the Oracle AI Database.
    5. Enable or disable dropping temporary tables created during data masking after masking is completed. This is enabled by default. Data Masking creates temporary tables that map the original sensitive data values to the mask values. Preserve these table to track how masking changed your data.

      Note:

      Disabling dropping the temporary tables compromises security. These tables must be dropped before the database is available for unprivileged users.
    6. Enable or disable refreshing the statistics gathered on masked database tables after masking. This is enabled by default.
  11. (Optional) To create tags, expand the Tags section and configure tags for your masking policy.
  12. Click Create masking policy. The Masking Policy Details page is displayed. When the masking policy is successfully created, the status is set to ACTIVE.
  13. Review your empty masking policy.
    • The Details tab shows you the name and OCID of your masking policy, the work request information, the compartment in which the masking policy is stored, the target database with which the masking policy is associated, and when the masking policy was created and last updated.
    • The Masking columns tab is empty. You can add and remove columns as needed.