OverviewQuickstart
Using Cyral
How to
Reference
TerminologyPolicy GuidePolicy definitionInterpreting the sample policySample policy use casesNext stepLog SpecificationMetrics Specification
API Reference

See how Security as Code can help your organization.

Get a Demo

Policy Guide

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

Your policy consists of two main parts:

  • The data block is your data specification. It lists the sensitive data this policy covers. Here, each piece of sensitive data is referred to only by its short name. The actual location of that data (the names of fields, columns, or databases that hold it) is listed in a separate document called your datamap.
  • The rules block holds your data access rules that govern who can perform which operations on which sensitive data. Each rule holds:
    • an identities block, which is your identity specification saying who this rule applies to; and
    • a set of contexted rules, one per access type. That is, the rule can include a contexted-rule block for reads, one for updates, and one for deletes. We call each of these a contexted rule because it applies only in the context of its specified operation type. For example the reads rule applies only when someone tries to retrieve data. The rules block does not need to include all three operation types; those you omit are disallowed.

Unless you create a default rule (see below), users and groups only have the rights you explicitly grant them.

Data Specification

A policy protects specific columns or fields in your data repositories, and Cyral keeps your policies clean by separating each field name from the actual database connection details for it. This is set up in Cyral with a combination of your policy and your datamap. Together, we refer to this as your Data Specification. The Data Specification is made up of:

  • In the datamap, you establish your admin-friendly names for each sensitive data field, and
  • in the policy, you refer to each sensitive data field using only its admin-friendly name.

Let's look at how these names are established and used.

In the data block of your policy

In your policy, you use the data block to specify which sensitive data fields this policy manages. In the data block, you list each field using its admin-friendly name that was established in your Data Map.

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

In your datamap

The datamap 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:

  • {LABEL} (string): label given to the data specified in the corresponding list
  • each value in the list assigned to a label is an object comprising two fields:
    • repo (string): name of the repository containing the data as specified through the Cyral management console
    • attributes ([string]): contains the specific locations of the data within the repo, following the pattern {SCHEMA}.{TABLE}.{ATTRIBUTE}
      • When referencing data in a Dremio repository, please include the complete location, with each nested Dremio space separated by a .. For example, an attribute my_attr contained by table my_tbl within space inner_space within space outer_space would be referenced as outer_space.inner_space.my_tbl.my_attr.

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 datamap.

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 optional fields listed below. (Note that you can omit the identity specification entirely, in which case this becomes a default rule, as explained later.)

  • users ([string]): individual users

  • services ([string]): applications

    • for users going through Looker, use the service name looker
    • for custom services use the application name provided in the connection URL when connecting to the database
  • groups ([string]): user groups as defined in SSO services such as GSuite or Okta

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:

  • data ([string]): the data for which access is allowed

    • the value any can be specified to mean all sensitive data can be accessed
  • rows (int): the number of rows that can be accessed/affected in a single statement

    • the value any can be specified to mean an unlimited number of rows can be accessed/affected in a single statement

A rule can also specify the optional field severity

  • severity (string): severity level of violation (low | medium | high) default=low

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

Interpreting 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 datamap. Based on the rules specified in this policy,

  • Users belonging to the user group analyst are allowed to read up to 10 rows of any of the sensitive data, update 1 row of EMAIL or CCN data, and delete 1 row of any of the sensitive data at a time.

  • As an exception, the user bob can read any amount of rows for any of the sensitive data, update any amount of rows of EMAIL or CCN, and delete any amount of rows for any of the sensitive data.

  • All other users (those who are not bob nor belonging to the group analysts) can read 1 row of EMAIL at a time. Any other access to the sensitive data EMAIL, CCN, and SSN is disallowed.

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, the user bob has unlimited read-only access to the data EMAIL, CCN, and SSN, disallowing update and delete access.

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

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

Next step

See Manage policies in GitHub to see how you can manage your policies with an audit trail and the ability to roll back unwanted changes.


© Copyright 2020 Cyral Inc. All rights reserved.