0 / 0
Planning to author data protection rules
Last updated: Jun 19, 2024
Planning to author data protection rules

The goal of this topic is to establish a guideline on designing data protection rules to maximize protection that uses data and user attributes. Explore the steps to create rules based on identified partitions used to form disjoint sets of assets that can then be effectively governed by using data protection rules.

Consider an example use case where data assets can contain business terms such as sensitive personal information (SPI), personally identifiable information (PII), and data classes such as social security number (SSN). In addition, users can belong to user groups such as ADMINISTRATORS, DATA STEWARDS and DEVELOPERS. To simplify this example, user group membership is assumed to be disjoint and use data protection rules without relying on precedence.

Remember:

The term partition means a logical division of a group of objects. For example, partitioning all assets or users to be in certain meaningful sets based on their assigned attributes.

Illustrating the partition of assets into logical sets by sets of assigned attributes:

A Venn diagram that shows the partition of assets by assigned attributes.

Complete the following tasks to author data protection rules:

  1. Configuring rule settings.
  2. Identifying or partitioning the asset and user space.
  3. Choosing the outcome for each partition.
  4. Defining rules for each partition.
  5. Optional: Defining dynamic meta rules for decision exception processing.

Configuring rule settings

  1. Set the data access convention. You can choose from the following two convention options:
API setting UI setting Convention
AEAD
(default)
Unlocked 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.
DEAA Locked 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

If a user attempts to access an asset and if no rules are triggered, the convention determines either one of the following outcomes:

Deny
When the data access convention is set in the user interface as Locked or configured in the API as DEAA, the outcome is Deny.
Allow
When the data access convention is set in the user interface as Unlocked or configured in the API as AEAD, the outcome is Allow.
  1. Set the rule action precedence. Choose one of the following options to determine the course of action to take if multiple conflicting rules are triggered at the same time for a specific asset and a specific user:
Most secure action wins (default setting)
  • If the data access convention is set in the user interface as Locked or configured in the API as DEAA, the precedence order is the Transform rule then the Allow rule.
  • If the data access convention is set in the user interface as Unlocked or configured in the API as AEAD, the precedence order is the Deny rule then the Transform rule.
Most lenient action wins
  • If the data access convention is set in the user interface as Locked or configured in the API as DEAA, the precedence order is the Allow rule then the Transform rule.
  • If the data access convention is set in the user interface as Unlocked or configured in the API as AEAD, the precedence order is the Transform rule then the Deny rule.

In an example of the Locked (DEAA) convention, if a user tries to access an asset and two rules are triggered such that one rule transforms one or more columns and the other rule allows full access to the asset, and the Most lenient action wins is selected, the user can access the entire asset because the Allow rule overrides the Transform rule.

  1. Set the rule masking method precedence. Choose one of the following option:
Method with most privacy wins (default setting)
The transformation precedence order is Redact, Substitute, and then Obfuscate.
Method with most utility wins
The transformation precedence order is Obfuscate, Substitute, and then Redact.

For example, if a user attempts to access an asset and two rules are triggered such that one rule redacts a particular column and the other rule obfuscates the same column, and the Method with most privacy wins is selected, that column is redacted because the Redact rule overrides the Obfuscate rule.

For more information about the rule settings, see the Managing rule settings topic. In addition, see the following screen capture of the Manage rule settings window where you can configure the user interface.

A screen capture of the Manage rule settings window

Identifying or partitioning the asset and user space

  1. Take note of the attributes in the asset space and the values of those attributes that you want to mask or protect to form the basis of data protection rules. Examples of attributes in the asset space are data classes, business terms, tags, and column names.
  2. Take note of the attributes in the user space and the values of those attributes that you want to mask or protect to form the basis of data protection rules. Examples of attributes in the user space are user roles, and user groups.

For example, consider building rules based on the business terms SPI and PII. In addition, the user group user attribute with values ADMINISTRATORS, DATA STEWARDS, and DEVELOPERS. The asset space and user space can be partitioned as illustrated in the following table:

Business term User group
SPI ADMINISTRATORS
SPI DATA STEWARDS
SPI DEVELOPERS
SPI --
PII ADMINISTRATORS
PII DATA STEWARDS
PII DEVELOPERS
PII --
-- ADMINISTRATORS
-- DATA STEWARDS
-- DEVELOPERS
-- --
SPI, PII ADMINISTRATORS
SPI, PII DATA STEWARDS
SPI, PII DEVELOPERS
SPI, PII --

A Venn diagram that illustrates this example with the assets partitioned:

A Venn diagram that shows this example with aseets partitioned.

Choosing the outcome for each partition

Decide what the outcome is for each combination of the example attributes and values.

Business term User group Action or outcome selected
SPI ADMINISTRATORS ALLOW
SPI DATA STEWARDS REDACT (SPI)
SPI DEVELOPERS DENY
SPI -- DENY
PII ADMINISTRATORS ALLOW
PII DATA STEWARDS OBFUSCATE (PII)
PII DEVELOPERS REDACT (PII)
PII -- DENY
-- ADMINISTRATORS ALLOW
-- DATA STEWARDS ALLOW
-- DEVELOPERS ALLOW
-- -- DENY
SPI, PII ADMINISTRATORS ALLOW
SPI, PII DATA STEWARDS REDACT (SPI), OBFUSCATE (PII)
SPI, PII DEVELOPERS DENY
SPI, PII -- DENY

An example set of outcomes where green indicates Allow, red indicates Deny, yellow indicates Obfuscate, and brown indicates Redact in the following Venn diagrams for each user group:

Venn diagrams for each user group.

The example table and diagrams help provide clarity to the selected behavior for all the partitions.

Defining rules for each partition

Depending on the convention Unlocked (AEAD) or Locked (DEAA) appropriate rules can be designed to enforce the outcome requirements. For example, consider a scenario where the following rule settings are chosen:

  • Convention: Locked (DEAA) where without any rules, no users get access to any data.
  • Rule action precedence: Most secure action wins
  • Rule masking method precedence: Method with most privacy wins

With the specified settings and outcomes, rules can be designed with the following rules:

Rule 1
Condition
IF (userGroup contains ADMINISTRATORS)
Action
ALLOW
Rule 2
Condition
IF (userGroup contains DATA STEWARDS) AND (businessTerm contains SPI)
Action
REDACT (SPI)
Rule 3
Condition
IF (userGroup contains DATA STEWARDS) AND (businessTerm contains PII)
Action
OBFUSCATE (PII)

Rule 4 The following rules 4.1 and 4.2 are two different rules for each user group DEVELOPERS and DATA STEWARDS:

Rule 4.1
Condition
IF (userGroup contains DEVELOPERS) AND NOT (businessTerm CONTAINS {SPI, PII})
Action
ALLOW
Rule 4.2
Condition
IF (userGroup contains DATA STEWARDS) AND NOT (businessTerm CONTAINS {SPI, PII})
Action
ALLOW
Optional The following rule combines rules 4.1 and 4.2 into a single rule:
Condition
IF (userGroup contains {DATA STEWARDS, DEVELOPERS}) AND NOT (businessTerm CONTAINS {SPI, PII})
Action
ALLOW
Rule 5
Condition
IF (userGroup contains DEVELOPERS) AND (businessTerm CONTAINS PII) AND NOT (businessTerm CONTAINS SPI)
Action
REDACT (PII)

If more asset or user attributes are included when data protection is designed, the outcome table requires extra columns to enumerate all possibilities.

A screen capture of Rule 2 in a user interface:

A screen capture of Rule 2 in a user interface.

Continuing with the example, consider including another asset attribute, such as a data class with SSN value to the rule space. To design rules in this scenario, repeat the following previous tasks with this new partitioning of the asset space:

Business term Data class User group Action or outcome selected
SPI SSN ADMINISTRATORS ALLOW
SPI SSN DATA STEWARDS REDACT (SPI, SSN)
SPI SSN DEVELOPERS DENY
SPI SSN -- DENY
PII SSN ADMINISTRATORS ALLOW
PII SSN DATA STEWARDS OBFUSCATE (PII), REDACT (SSN)
PII SSN DEVELOPERS REDACT (PII, SSN)
PII SSN -- DENY
-- SSN ADMINISTRATORS ALLOW
-- SSN DATA STEWARDS REDACT (SSN)
-- SSN DEVELOPERS REDACT (SSN)
-- SSN -- DENY
SPI -- ADMINISTRATORS ALLOW
SPI -- DATA STEWARDS REDACT (SPI)
SPI -- DEVELOPERS DENY
SPI -- -- DENY
PII -- ADMINISTRATORS ALLOW
PII -- DATA STEWARDS OBFUSCATE (PII)
PII -- DEVELOPERS REDACT (PII)
PII -- -- DENY
-- -- ADMINISTRATORS ALLOW
-- -- DATA STEWARDS ALLOW
-- -- DEVELOPERS ALLOW
-- -- -- DENY
SPI, PII SSN ADMINISTRATORS ALLOW
SPI, PII SSN DATA STEWARDS REDACT (SPI, SSN), OBFUSCATE (PII)
SPI, PII SSN DEVELOPERS DENY
SPI, PII SSN -- DENY
SPI, PII -- ADMINISTRATORS ALLOW
SPI, PII -- DATA STEWARDS REDACT (SPI), OBFUSCATE (PII)
SPI, PII -- DEVELOPERS DENY
SPI, PII -- -- DENY

Venn diagrams for each user group which includes a data class with SSN value to the rule space:

Venn diagrams for each user group which includes a data class with  value to the rule space.

With the added attribute and corresponding selected outcomes, the following rules are modified in the rule space:

Rule 6
Condition
IF (userGroup contains DATA STEWARDS) AND (dataClass contains SSN)
Action
REDACT (SSN)
Rule 7
Condition
IF (userGroup contains DEVELOPERS) AND (dataClass contains SSN) AND NOT (businessTerm CONTAINS SPI)
Action
REDACT (SSN)
Rule 4' (modification of Rule 4)
Condition
IF (userGroup contains {DATA STEWARDS, DEVELOPERS}) AND NOT (businessTerm CONTAINS {SPI, PII}) AND NOT (dataClass CONTAINS SSN)
Action
ALLOW

If instead, the convention that is chosen is Unlocked (AEAD), rules can instead be designed in the following settings:

  • Convention: Unlocked (AEAD) where without any rules, all users get access to all data.
  • Rule action precedence: Most secure action wins
  • Rule masking method precedence: Method with most privacy wins
Business term User group Action or outcome selected
SPI ADMINISTRATORS ALLOW
SPI DATA STEWARDS REDACT (SPI)
SPI DEVELOPERS DENY
SPI -- DENY
PII ADMINISTRATORS ALLOW
PII DATA STEWARDS OBFUSCATE (PII)
PII DEVELOPERS REDACT (PII)
PII -- DENY
-- ADMINISTRATORS ALLOW
-- DATA STEWARDS ALLOW
-- DEVELOPERS ALLOW
-- -- DENY
SPI, PII ADMINISTRATORS ALLOW
SPI, PII DATA STEWARDS REDACT (SPI), OBFUSCATE (PII)
SPI, PII DEVELOPERS DENY
SPI, PII -- DENY
Rule 1
Condition
IF (userGroup contains DATA STEWARDS) AND (businessTerm contains SPI)
Action
REDACT (SPI)
Rule 2
Condition
IF (userGroup contains DATA STEWARDS) AND (businessTerm contains PII)
Action
OBFUSCATE (PII)
Rule 3
Condition
IF (userGroup contains DEVELOPERS) AND (businessTerm CONTAINS SPI)
Action
DENY
Rule 4
Condition
IF (userGroup contains DEVELOPERS) AND (businessTerm CONTAINS PII)
Action
REDACT (PII)
Rule 5
Condition
IF NOT (userGroup contains {ADMINISTRATORS, DATA STEWARDS, DEVELOPERS})
Action
DENY

If the asset attribute, such as data class with SSN value is added to the rule space, rules can be modified based on this new partitioning of the asset space.

Business term Data class User group Action or outcome selected
SPI SSN ADMINISTRATORS ALLOW
SPI SSN DATA STEWARDS REDACT (SPI, SSN)
SPI SSN DEVELOPERS DENY
SPI SSN -- DENY
PII SSN ADMINISTRATORS ALLOW
PII SSN DATA STEWARDS OBFUSCATE (PII), REDACT (SSN)
PII SSN DEVELOPERS REDACT (PII, SSN)
PII SSN -- DENY
-- SSN ADMINISTRATORS ALLOW
-- SSN DATA STEWARDS REDACT (SSN)
-- SSN DEVELOPERS REDACT (SSN)
-- SSN -- DENY
SPI -- ADMINISTRATORS ALLOW
SPI -- DATA STEWARDS REDACT (SPI)
SPI -- DEVELOPERS DENY
SPI -- -- DENY
PII -- ADMINISTRATORS ALLOW
PII -- DATA STEWARDS OBFUSCATE (PII)
PII -- DEVELOPERS REDACT (PII)
PII -- -- DENY
-- -- ADMINISTRATORS ALLOW
-- -- DATA STEWARDS ALLOW
-- -- DEVELOPERS ALLOW
-- -- -- DENY
SPI, PII SSN ADMINISTRATORS ALLOW
SPI, PII SSN DATA STEWARDS REDACT (SPI, SSN), OBFUSCATE (PII)
SPI, PII SSN DEVELOPERS DENY
SPI, PII SSN -- DENY
SPI, PII -- ADMINISTRATORS ALLOW
SPI, PII -- DATA STEWARDS REDACT (SPI), OBFUSCATE (PII)
SPI, PII -- DEVELOPERS DENY
SPI, PII -- -- DENY
Rule 6
Condition
IF (userGroup contains {DATA STEWARDS, DEVELOPERS}) AND (dataClass contains SSN)
Action
REDACT (SSN)
Tip:

For Unlocked (AEAD) convention, if assets with a public tag and without PII, SPI, or SSN were preferred to be accessible to all users, such as the outcome selected was Allow, then the existing Rule 5 would need to be modified by adding the following extra predicates:

Rule 5' (modification of Rule 5)
Condition
IF NOT (userGroup contains { ADMINISTRATORS, DATA STEWARDS, DEVELOPERS } ) AND NOT (tag CONTAINS PUBLIC) AND ((businessTerm CONTAINS {SPI, PII}) OR (dataClass CONTAINS SSN))
Action
DENY

(Optional) Defining dynamic meta rules for decision exception processing

Dynamic meta rules are created to add exceptions for certain super users. When a dynamic meta rule is defined for a certain user or user group, all data protection rules that are defined in Defining rules for each partition section, are skipped and access is granted to all assets to the users in the dynamic meta rule. For example, if a SUPERADMINS user group needs a super user access, the following dynamic meta rule can be defined:

Dynamic meta rule
Condition
IF (userGroup contains SUPERADMINS)
Action
ALLOW

A dynamic meta rule is only defined with action of ALLOW in both Locked and Unlocked systems.

Learn more

Parent topic: Planning to implement data governance