Managing rule settings | IBM Cloud Pak for Data as a Service

Managing rule settings

Specifying business term inheritance, defining data access conventions, rule action precedence, and masking method precedence before you create data protection rules and data location rules streamline how the rules that are created behave and protect data consistently.

Determine whether you want business terms that have dependent business terms of is a type of relationship to also be included when data protection rules and data location rules are evaluated.

Choose between two types of data access conventions for data protection rules and data location rules. You can allow access to data unless a rule prevents it, or you can deny access to data unless a rule allows it.

You can also choose a precedence for rules and masking methods. The rule action precedence is applied when multiple rules have different actions that apply to the same data values. The masking method is applied when multiple rules that have different masking methods apply to the same data values.

Before you create data protection rules and data location rules, plan and evaluate who the rules are allowing to access the data or denying access to the data. Designing your rules after your careful planning provides a solid foundation for determining the criteria for enforcing the rules and the corresponding enforcement actions. This careful planning process also minimizes chance for a future decision to switch rule access. If you decide later to change your access paradigm for your rules, you must first delete all of the existing rules, and then re-create the new rules for that rule class.

The following business term option, conventions, and precedences apply to both data protection rules and data location rules.

Required permissions

You must be an IBM Cloud account administrator to set rule conventions.

Evaluating rules and business term inheritance

Select Business term inheritance when you want dependent business terms of a hierarchical type relationship to be included when data protection rules and data location rules are evaluated. For example, the business term Loan has a type of relationship with Student loan and Personal loan. The business term Loan and its subtypes Student loan and Personal loan are all included when the data protection rules and data location rules are evaluated. For more information about hierarchical type relationships between business terms, see Designing business terms.

Allowing access to data convention

The default behavior in the allow access convention is for data access to be granted. If you want to protect specific data, you must write rules that explicitly deny certain data access based on user or data attributes.

With the allow access data convention, data protection rules and data location rules have these available actions:

Deny access to data
Mask data
Filter rows

An example of using this convention might include creating data protection rules that allow all company employees to access fellow employee data in general, but to restrict access to payroll information. To accomplish this, you can write a rule specifying that any asset containing attributes denoting it is related to payroll data must be denied for any user who is not in the human resource department. Thus all data of all types is allowed, and only the exception of payroll data for employees who are not in human resources is denied.

The allow access convention is the default data convention for data protection rules.

Denying access to data convention

The default behavior for the deny access convention is to deny access to data. If you want to reveal specific data, you must write rules that explicitly allow specific users to see the data. In an environment where most data access needs to be restricted, the deny convention allows you to write a few rules where data is allowed instead of writing a rule for every case where data must be restricted.

An example of using the deny convention for data protection rules might be a catalog containing sensitive personal information that is not allowed to be viewed between departments. In that case, any data asset that is tagged as marketing being accessed by any user other than a member of the marketing group must be denied. However, a user who is a member of the marketing user group is allowed to see assets that are tagged as marketing. The convention results in all users being denied access to all data, except users in the marketing user group, who are allowed to access data that is tagged as marketing by the data protection rule.

The example also applies to data location rules, and the default data convention for data location rules is deny access.

An example of using the deny convention for data location rules might be a catalog containing sensitive personal information that is not allowed to cross country boundaries. In that case, create a data location rule that specifies any data moving from any location to another is to be denied. However, since there are data sharing allowances between certain locations all data movement would be denied except for a rule specifying that data moving from a location in Chile to a location in Argentina is to be allowed.

With the deny access data convention, data protection rules and data location rules have these available actions:

Allow access to data
Mask data
Filter rows

Setting the data access convention

The rule convention must be set before your team creates data protection rules and data location rules. You must delete any existing rules before you change the convention. When you change the convention, rules have a different set of allowed actions.

To set the rule conventions, go to the Manage rule settings page by selecting Governance > Rules and then clicking Manage rule settings. Alternatively, you can call the rule enforcement setting API.

The Rule Settings

Rule convention for data protection rules

To set the rule convention, use the Manage rule settings UI or call the rule enforcement setting API and set governance_access_type to one of these values:

UI setting	API setting	Convention
Unlocked	AEAD	Default. Follows the allow everything author deny (AEAD) convention . Allows access to data unless a rule denies it. You write rules that deny access to data, mask data, and filter rows from data.
Locked	DEAA	Follows the deny everything author allow (DEAA) convention. Denies access to data unless a rule allows it. You write rules that allow access to data, mask data, and filter rows from data.

Tip:

If no transform rule can be evaluated, the result defaults to the following convention decisions:

Deny for Locked
Allow for Unlocked

Rule convention for data location rules

To set the rule convention, use the Manage rule settings UI or call the rule enforcement setting API and set governance_dlr_type to one of these values:

UI setting	API setting	Convention
Unlocked	AEAD	Follows the allow everything author deny (AEAD) convention. Allows access to data unless a rule denies it. You write rules that deny access to data, mask data, and filter rows from data.
Locked	DEAA	Default. Follows the deny everything author allow (DEAA) convention. Denies access to data unless a rule allows it. You write rules that allow access to data, mask data, and filter rows from data.

Setting the precedence for rule actions and masking methods

After defining the rule conventions, establishing a precedence for rules and masking methods helps you determine:

The action to apply when multiple rules that have different actions apply to the same data values.
The masking method to apply when multiple rules that have different masking methods apply to the same data values.

To set rule precedences, go to the Manage rule settings page by selecting Governance > Rules and then clicking Manage rule settings.

Rule action precedence

The rule action precedence specifies the most secure, the most lenient, or hierarchical enforcement access users have to an asset. The actions, in order of leniency, are: Allow access, Mask and Filter, Deny access.

An example of applying this precedence is human resources assets are shared among the human resources department. The rule convention is set to deny access. A rule specifies whether an asset is marked as a human resources document, and if the user is within the human resources user group, then allow access. Another rule states that if a rule contains employee financial information, that information must be masked.

The employee financial information is kept in a database with tables that combine jobs, salary, and retirement data. The Jobs table has data for all types of employees and a RetireType column that indicates the retirement status of employees. A third rule excludes all rows if the value of the RetireType column is Retired.

When all rules are in effect, the decision of Allow access from the first rule is overruled by the decision to mask data of the second rule when Most secure action wins. The third rule filters out all rows where the RetireType is set to Retired.

Hierarchial enforcement as a rule action precedence

Hierarchical enforcement is of particular interest if you need a more restrictive data access and still want to write more generic rules. However, the resulting behavior is possible by writing disjoint rules for each access combination of types of users and data. The hierarchical enforcement option as your rule action precedence, provides a simplified thought process by thinking as two separate questions:

Who can be granted access to what asset? Then you can remove many of the questions of masking certain data types and simplify the decision into solely two options of either Allow or Deny.
What data needs masking? Then you can mostly ignore the state of the first question for granting access. You can now write a more abstract masking rule, such as If data asset contains column of data class sensitive personal data then redact columns with data class sensitive personal data. This rule outside of a hierarchical configuration includes an implicit grant of access to the asset with masking applied.

The option to set rule decision precedence to Hierarchical enforcement can be set from the Manage rule settings wizard or alternatively from setting the HIERARCHICAL value for the access_decision_precedence API. The hierarchical enforcement setting configures a two-layer evaluation for data protection rules. The first layer evaluates the rules for a decision, which results in either Allow or Deny actions, without considering any masking actions. Then only if the decision from the first layer is to Allow access, a second layer is evaluated considering rules with a Transform action. To see any masked or raw data, at least one Allow decision is needed.

For Locked convention, this Allow decision can be achieved only with a rule with Allow action. In Locked convention, if you have rules that results in Transform or Mask decisions, but have no Allow rule that grants access, the outcome remains as Deny. However, if you have multiple rules with actions of Allow and Transform, then the Allow proceeds to evaluate the Transform and the resulting combined decision is the resulting masking actions.
For Unlocked convention, hierarchical precedence becomes equivalent to Most secure action wins (RESTRICTIVE API option) precedence since an Allow decision from the first hierarchical layer is achievable only with no effective rules that result in Deny. Therefore, if you have both a Deny action and a Transform action then the result for both Hierarchical enforcement (HIERARCHICAL API option) and Most secure action wins (RESTRICTIVE API option) is Deny action.

Masking method precedence

The masking method precedence specifies the transformation of data values from the most privacy or the most utility. The precedence is applied when a rule action is Mask and determines how the data values are masked. The masking methods, in privacy order, are: Redact, Substitute, Obfuscate. The masking methods, in utility order, are: Obfuscate, Substitute, Redact.

An example of applying this precedence is an accountant created a rule that specifies credit card numbers must be obfuscated. Masking the numbers allow only claims representatives to see a card number to help customers who want to return their merchandise. The accountant created another rule that redacts all credit card numbers if you're in the sales department.

When an employee who is in both the sales department and claims department accesses the same credit card information, both masking methods are acting on the same data. If the rule convention is most secure, the masking method precedence redacts the information that is accessed by sales. However, because the employee is also in the claims department, that employee can see the last four digits of the obfuscated credit card number.

Scenario: Applying conventions and precedence

The following example combines the rule convention, the rule action precedence, and the masking method precedence. Used together, they create flexible options for protecting data.

Clarice created an employee spreadsheet and uses the rule settings and data protection rules to protect employee data from other teams in her company. She protects the employee data by first establishing conventions and precedence for the rules she is creating, and then designing the rules.

Scenario: Establishing conventions and precedence

From Managing rule settings, Clarice chose the following options:

Convention: Unlocked data access convention that follows the allow everything author deny (AEAD) convention.
Rule action precedence: Most lenient action wins
Rule masking method precedence: Method with most privacy wins

Scenario: Creating data protection rules

Clarice creates three rules to protect the data in the following Employee Spreadsheet:

The Employee Spreadsheet example

Rule 1: If the user group is the Sales team, then deny access to the data in the asset. Anyone from the Sales team can't see any data that is owned by Clarice.

Rule 2: If the asset name is Employee Spreadsheet and it contains columns named Last Name, Email Address, then mask by obfuscating all columns named Last Name and Email Address. The following example shows the Last Name and Email Address columns are obfuscated in the Employee Spreadsheet when it's accessed by someone in Finance.

The obfuscate columns named last name and email address example

Rule 3: If the user group is the Sales team and that user is accessing the Employee Spreadsheet, then mask by redacting the column named Email Address. The following example shows when the Sales team accesses the spreadsheet, they aren't denied access because of the lenient rule precedence. They can see the obfuscated last names. However, because Clarice selected the most private masking method precedence, the email addresses are redacted.

The obfuscate last name and redact email address example

Learn more

Parent topic: Managing IBM Knowledge Catalog