Global policy structure

A Cyral global policy consists of these main parts:

• data block: The data block lists the data locations (schemas, tables, columns, and so on) that this policy covers, using the data labels and/or tags you've established in your Data Map. In other words, the data block establishes the scope of the policy within your data environment.
• tags block: The optional tags block allows you to have this policy cover a set or sets of data labels. Each tag name listed here represents a set of data labels covered by this policy.
• rules block: The rules block holds your data access rules that govern who can perform which operations on which data.
• meta block: The optional meta block is used only for policies managed via GitOps. It contains the policy's name.

tip

This rest of this page describes fully customizable Cyral global policies. Cyral repo-level policies do not follow this structure. For those, see the policy wizard documentation.

To understand policy structure, let's look at a sample policy. We'll explain this policy in detail in Interpreting the 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]
    hosts: [192.0.2.22, 203.0.113.16/28]
    reads:
      - data: any
        rows: any
    updates:
      - data: [EMAIL, CCN]
        rows: any
    deletes:
      - data: any
        rows: any
  - reads:
      - data: [EMAIL]
        rows: 1

The data block of a policy

In your policy, you use the data block to specify which data locations this policy manages. In the data block, you list each location using the data label you established for it in your Data Map. The actual location of that data (the names of fields, columns, or databases that hold it) is listed in the Data Map.

caution

All label names and tag names are case sensitive; when you write your policy, take care to write labels and tags exactly as you have declared them in your Data Map.

tip

As mentioned earlier, each data label must be used in only one policy. In other words, no two policies may overlap in terms of the data locations they protect. Within a single policy, you may use a single data label many times in many rules.

The tags block of a policy

The optional tags block allows you to have this policy cover a tag, which usually represents a set of similar data labels.

In your policy, you can use tags as a supplement to, or as a replacement for data labels, but in either case a tag is a collection of one or more data labels and must be defined as such in your Data Map.

Below, we show an example of a policy that uses both a data label and a tag. Users in the group account-auditor can read data tagged as PCI data, and anyone can read data labeled as EMAIL. Don't worry if you don't understand the rule syntax yet; we'll explain that in the section, Interpreting the sample policy.

data:
  - EMAIL
tags:
  - PCI
rules:
  - identities:
      groups: [account-auditor]
    reads:
      - tags: [PCI]
        rows: 25
  - reads:
      - data: [EMAIL]
        rows: 1

The rules block of a policy

The set of rules is the core of the policy. It lists, for each user or group, the rules that govern what data they can see, and what they can do with data in each labeled location.

A rule contains:

• an identities specification (the users and groups this rule applies to), and
• a set of contexted rules. Each contexted rule specifies:
  • the labels and/or tags of the data locations it applies to (a subset of the scope established in your data block at the top of the policy) and
  • the policy enforcement actions it imposes on users who want to access data stored in those locations. Policy enforcement actions include measures such as blocking access to data, rewriting a dataset returned by a query, or masking the contents of a data field.

See the rules section to learn about the syntax of Cyral rules.

info

To understand how Cyral finds the right rule for a data access request, see Policy evaluation.

For a guided tour showing how Cyral evaluates a set of rules at query time, see Interpreting the sample policy.

The meta block of a policy

The optional meta block is where you give your policy a name and optional tags. This section is only required if you're automating your policy publishing via Github integration.

caution

If you move a policy to a version control system for automated policy management, you must leave the policy and its name unchanged in the Cyral UI.

Learn more

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