0 / 0
Data protection rules enforcement

Data protection rules enforcement

Data protection rules are enforced in catalogs when all prevailing conditions for enforcement are met. Conditions for enforcement can include catalog settings, the identity of the user, the data format, and the tool that is reading the data. Enforcement can extend to projects and virtualized tables in some circumstances.

When you create a data protection rule, it is enforced immediately, unless the affected asset has a cached preview. In that case, the rule enforcement might be delayed for up to one day. If you change the profile of an asset in a way that triggers the enforcement of a data protection rule, the rule is enforced after the asset preview is refreshed. The asset preview is refreshed daily by default. Alternatively, you can manually refresh the preview.

Scope of enforcement

Data protection rules are enforced in the following workspaces:

Catalogs: Rules are dynamically enforced when both of these conditions are true:

  • The catalog has governance enforcement that is enabled. Governance enforcement is set during catalog creation and can't be changed after the catalog is created.
  • The user is not the asset owner. The asset owner always sees the original data and is not affected by the rule.

Projects: The enforcement of rules are carried over to projects when both of these conditions are true:

  • The asset is added to the project from a governed catalog by a user who is not the asset owner. The rule is enforced based on the user who adds the asset and appears the same for all other users in the project. However, if the asset is protected by a deep enforcement solution (such as Watson Query or Guardium), and you have no masking nor row-filtering rule that is applied to the data asset carried over from a governed catalog to a project; then, the preview of the project asset is subject to the access controls and enforcement of data protection rules of the deep enforcement solution.
  • The asset is previewed or is opened in the Data Refinery tool. Data Refinery does not support data protection rules for row filtering. Data Refinery jobs might fail if the asset is governed by row-filtering data protection rules. Other tools in projects do not support dynamic masking or row filtering and allow full access to the original data. Additionally, if you add an asset from IBM Knowledge Catalog to a project that is governed by row-filtering data protection rules, the masking will not be enforced in Data Refinery.

Data assets that are masked by a masking flow are permanently masked for all users. See Masking in projects.

Data virtualization: Rules are enforced when all of these conditions are true:

  • Data protection rule enforcement is enabled for virtualized tables.
  • The object is accessed as a result of a query.
  • The data asset is published to a catalog that is configured to enforce data protection rules.

See Masking virtual data.

Data protection rules are not enforced in these situations:

  • If you access the asset in a catalog that is not governed.
  • If you copy a masked or filtered asset to a project and then access the asset in any way other than refining the asset in Data Refinery, viewing the asset preview or profile, or downloading the asset.
  • If you access the primary data asset at its source location by a method that bypasses the catalog.
  • If you access the data with the Watson REST APIs that are associated with IBM Knowledge Catalog.
  • If you add an asset that is governed by data protection rules with row filtering to a project from a catalog and use it in Data Refinery. Data Refinery does not support data protection rules with row level filtering.

Also check the known issues for other situations where data protection rules are not enforced. For more information, see Known issues and limitations.

Data protection rules can permanently mask data in an asset with masking flow. See Masking data with Masking flow.

Evaluation precepts for data protection rules

Data protection rules evaluate requests to access data assets by using the precepts described in the following table.

Precept Explanation
Don't enforce rules for asset owners If the user who is trying to access the asset is the owner of the asset (by default, the user who created the asset), then the rule is not enforced.
Restrict access to assets during profiling If the asset is being profiled at the same time as data protection rules that depend on profiling are being evaluated, then only the owner can access the asset. If profiling and evaluation fail to complete within 24 hours, the asset is blocked to all users except the owner of the asset.
Allow or deny access if no rules apply When the asset does not meet the criteria for any data protection rule, the behavior depends on the data access convention setting:
• (Default) If the data access convention is set to Unlocked, the user is allowed access to the data.
• If the data access convention is set to Locked, the user is denied access to the data.

See Managing rule settings.
Enforce rules on assets based on a tenant modality setting for aliases Two data assets that have the same resource key are perceived to represent the same underlying data, therefore these assets are termed as aliases. You can set how to determine which aliases to use upon an evaluate resource operation by a tenant modality setting. Call the update tenant settings API to configure the asset_dealiasing_item_selection option to one of the following values:
- Oldest (default): By creation date.
- Latest: By last modification date.
- Merge: Merges annotations such as terms and tags of all aliases.
Enforce most secure or most lenient action When a user who is not the owner of the asset attempts to access the asset, all data protection rules are evaluated. If the asset meets the criteria for multiple rules, the behavior depends on the rule action precedence setting.

(Default) If the rule action precedence is set to Most secure action wins, the following order of security precedence is applied:
1. Deny access
2. Mask columns or filter rows
3. Allow access

If the rule action precedence is set to Most lenient action wins, the following order of lenience precedence is applied:
1. Allow access
2. Mask columns or filter rows
3. Deny access

See Rule action precedence.
Mask with most privacy or most utility When a user who is not the owner of the asset attempts to access the asset, all data protection rules are evaluated. If the asset meets the criteria for multiple rules, and more than one of the rules masks data, the masking method precedence is applied.

(Default) If the masking method precedence is set to Method with the most privacy wins, the following order of most privacy precedence is applied:
1. Redact method
2. Substitute method
3. Obfuscate method

If the masking method precedence is set to Method with the most utility wins, the following order of most utility precedence is applied:
1. Obfuscate method
2. Substitute method
3. Redact method

See Masking method precedence for more information.

Masking enforcement

Masking has these effects on the appearance of an asset in a catalog, a project, or the Data virtualization workspace:

  • The data preview shows a shield icon a shield icon in the header of affected columns and a tooltip displays the name of the rule.
  • The data preview shows masked values in the affected columns.
  • The Profile page does not show profiling details for masked data columns.
  • If the data asset is downloadable, the file contains the masked values.

The schema information for the asset always reflects the total number of columns that are contained in the original asset.

For virtual data, masking enforcement in Watson Query has restrictions and other differences. See Masking virtual data.

Masking in projects

Masking flow jobs, write a masked copy of the source asset data in the configured target tables.

Data protection rules are enforced by some tools in projects. However, enforcement is based on the user who copied the asset from the catalog to the project, instead of each user in the project.

Data protection rule enforcements apply in projects when these conditions are true:

  • The asset is added to the project from a governed catalog.
  • The asset meets the criteria for a data protection rule.
  • The user who added the asset to the project is not the owner of the asset in the catalog.

An asset that is masked by data protection rules appears the same for all project collaborators:

  • If a user who is not the owner of the asset adds the asset to the project from a catalog, the asset is masked for all other project collaborators.
  • If the owner of the asset in the catalog adds the asset to a project, the asset is not masked in the project for any project collaborator.

Masking by data protection rules in projects has the following effects:

  • The affected column in the asset preview is masked for all project collaborators.
  • The asset can't be downloaded from the project.
  • The asset can't be published to a different catalog.
  • Masking is applied in the Data Refinery tool. Data masking is applied to the whole affected column in the data set when the Data Refinery flow is run. Project collaborators can then save the Data Refinery flow to create a new data asset with masked data in the specified target. Data Refinery does not support data protection rules for row filtering. Data Refinery jobs might fail if the asset is governed by row filtering data protection rules. Additionally, if you add an asset from IBM Knowledge Catalog to a project that is governed by row-filtering data protection rules, the masking will not be enforced in Data Refinery.

Data processing tools in projects other than Data Refinery and masking flows do not support masking by data protection rules.

Learn more

Parent topic: Data protection rules

Generative AI search and answer
These answers are generated by a large language model in watsonx.ai based on content from the product documentation. Learn more