With Cyral, you can create policies to govern how sensitive data can be accessed by various identities.

Policies consist of a definition of sensitive data and a set of rules specifying how the data can be accessed, expressed in YAML format. Here is a sample policy:

data:
  - EMAIL
  - CCN
  - SSN
rules:
  - identities: 
      groups: [analyst]
    reads:
      data: any
      rows: 10
    updates:
      data: [EMAIL, CCN]
      rows: 1
      severity: medium
    deletes:
      data: any
      rows: 1
      severity: medium
  - identities: 
      users: [bob]
    reads:
      data: any
      rows: any
    updates:
      data: [EMAIL, CCN]
      rows: any
    deletes:
      data: any
      rows: any
  - reads:
      data: [EMAIL]
      rows: 1

This document breaks down the policy structure and defines each field, and includes a comprehensive interpretation of the above policy at the end.

Policy Definition

A policy can be considered in two sections: data specification, comprising top-level field data referencing your Data Map; and data access rules, contained by the top-level field rules.

Data Specification

Users specify sensitive data to be managed by the policy by first creating a mapping for the data in the Data Map and including its label in the list at top-level field data.

NOTE: Each sensitive attribute must be governed by a single policy, (i.e., no two policies should have overlap in sensitive attributes).

Data Map

The Data Map is an inventory of your sensitive data which maps between the locations of your data and labels you choose to give them. It follows this structure:

{LABEL}:
  - repo: {REPOSITORY_NAME}
    attributes: [{ATTRIBUTE_LOCATION},...]

And the fields are defined as such:

In the below example, we assign labels to data in two repos, claims and loans. The label CCN is assigned to the attribute ccn in the table customers in the finance schema of the claims repository as well as the attribute credit_card_number in the table customers in the applications schema of the loans repository. The labels EMAIL and SSN are also assigned to email and social security number data from each repo, respectively, following the same pattern.

CCN:
  - repo: claims
    attributes: [finance.customers.ccn]
  - repo: loans
    attributes: [applications.customers.credit_card_number]
EMAIL:
  - repo: claims
    attributes: [finance.customers.email]
  - repo: loans
    attributes: [applications.customers.email]
SSN:
  - repo: claims
    attributes: [finance.customers.ssn]
  - repo: loans
    attributes: [applications.customers.social_security_number]

The sample policy references each of these data labels—CCN, EMAIL, and SSN—in the data field, denoting that the policy will manage access to the data associated with these labels through the Data Map.

Data Access Rules

Users can manage how sensitive data can be accessed by specifying a list of data access rules in the field rules. Each rule is comprised of an identity specification for the rule and a set of contexted rules for each access type reads, updates, and deletes.

Identity Specification

For each rule, you can specify a set of identities for which the rule will apply. This specification is contained by the field identities and has the following optional fields:

For example, the following identity specification indicates that the rule will apply to users bob and sara, any users going through the service looker, and any users belonging to the user group analyst.

identities:
  user: [bob, sara]
  services: [looker]
  groups: [analyst]

To prevent conflicts, no two rules in a single policy can contain the same user/service/Group (e.g., the user bob can only appear in one rule for a given policy). However, it is possible to define multiple rules that apply to the same user in certain circumstances. For example, one rule in the sample policy applies to the user bob and another applies to the user group analyst, and the user bob belongs to the user group analyst. In cases like this, we apply a single rule with the following precedence: user > group > service. So, in the case of bob who's part of the user group analyst, we would apply the rule specified for the user bob and ignore the rule specified for the group analyst.

Contexted Rules

Each contexted rule comprises these fields describing the allowed access for a given access type:

Users can also specify the optional field severity

For example, the following rule from the sample policy specifies that individuals belonging to the user group analyst can read 10 rows of any of the sensitive data (EMAIL, CCN, and SSN). They can also write 1 row of attributes CREDIT_LIMIT and CARD_FAMILY and delete 1 row of any sensitive attributes.

identities: 
  groups: [analyst]
reads:
  data: any
  rows: 10
updates:
  data: [EMAIL, CCN]
  rows: 1
  severity: medium
deletes:
  data: any
  rows: 1
  severity: medium

Default rule

A default rule can be specified in the form of a rule with no identity specification (i.e., no identitites field). If sensitive data is accessed by an identity without a specified data access rule, the access will be evaluated against this rule. If no default rule is specified in a policy, then minimal permissions are assumed in the default case, allowing no access other than what is specified in the identity-specific rules. The following default rule from the sample policy specifies that identities without a specified rule can only read 1 row of EMAIL at a time. Updates and deletes are disallowed in this default case, since the fields updates and deletes aren't specified.

reads:
  data: [EMAIL]
  rows: 1

Interpretting the Sample Policy

Here we show the same sample policy presented at the beginning of this document. This policy manages the sensitive data EMAIL, CCN, and SSN, which map to email, credit card number, and social security number data located in repositories claims and loans as defined in the Data Map. Based on the rules specified in this policy,

data:
  - EMAIL
  - CCN
  - SSN
rules:
  - identities: 
      groups: [analyst]
    reads:
      data: any
      rows: 10
    updates:
      data: [EMAIL, CCN]
      rows: 1
      severity: medium
    deletes:
      data: any
      rows: 1
      severity: medium
  - identities: 
      users: [bob]
    reads:
      data: any
      rows: any
    updates:
      data: [EMAIL, CCN]
      rows: any
    deletes:
      data: any
      rows: any
  - reads:
      data: [EMAIL]
      rows: 1

Sample Policy Use Cases

Example 1: Read-only access

Here, we modify the policy from the previous example to give bob read-only access, disallowing update and delete access.

data: [EMAIL, CCN, SSN]
rules:
  - identities:
      users: [bob]
    reads:
      data: any
      rows: any
  - identities:
      users: [alice]
    reads:
      data: [EMAIL, CCN]
      rows: 1
    updates:
      data: [EMAIL]
      rows: 1

Example 2: Add a default rule

This policy includes a default rule (rule with no identities specified) which allows reads of EMAIL up to 1 row at a time if the accessing user is neither bob nor alice. In the previous cases where the default rule isn't specified, no accesses (reads, updates, or deletes) are allowed for users for which an identified rule is not specified.

data: [EMAIL, CCN, SSN]
rules:
  - identities:
      users: [bob]
    reads:
      data: any
      rows: any
    updates:
      data: [CCN]
      rows: 1
    deletes:
      data: any
      rows: 1
  - identities:
      users: [alice]
    reads:
      data: [EMAIL, CCN]
      rows: 1
    updates:
      data: [EMAIL]
      rows: 1
  - reads:
      data: [EMAIL]
      rows: 1

Example 3: Apply the same rules to a group of users

The following policy specifies bob, tom, and alex have unlimited read access and limited update and delete access, whereas alice and jeff have limited read and update access and no delete access.

data: [EMAIL, CCN, SSN]
rules:
  - identities:
      users: [bob, tom, alex]
    reads:
      data: any
      rows: any
    updates:
      data: [CCN]
      rows: 1
    deletes:
      data: any
      rows: 1
  - identities:
      users: [alice, jeff]
    reads:
      data: [EMAIL, CCN]
      rows: 1
    updates:
      data: [EMAIL]
      rows: 1

Example 4: Apply rule to a service identified by its name

The following policy specifies that the service operatingCostPredictor can read unlimited rows of the attribute CCN and cannot update or delete any of the sensitive data.

data: [EMAIL, CCN, SSN]
rules:
  - identities:
      services: [operatingCostPredictor]
    reads:
      data: [CCN]
      rows: any

Example 5: Apply rule to users accessing data through Looker

The following policy specifies that users accessing data through Looker have unlimited read access and no update or delete privileges.

data: [EMAIL, CCN, SSN]
rules:
  - identities:
      services: [looker]
    reads:
      data: any
      rows: any

© Copyright 2020 Cyral Inc. All rights reserved.