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.
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
.
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).
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:
{LABEL}
(string): label given to the data specified in the corresponding listrepo
(string): name of the repository containing the data as specified through
the Cyral management consoleattributes
([string]): contains the specific locations of the data within the
repo, following the pattern {SCHEMA}.{TABLE}.{ATTRIBUTE}
.
. 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 Data Map.
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
.
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:
users
([string]): individual usersservices
([string]): applications
looker
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
.
Each contexted rule comprises these fields describing the allowed access for a given access type:
data
([string]): the data for which access is allowed
any
can be specified to mean all sensitive data can be accessedrows
(int): the number of rows that can be accessed/affected in a single statement
any
can be specified to mean an unlimited number of rows can be accessed/affected in
a single statementUsers can also specify the optional field severity
severity
(string): severity level of violation (low
|
medium
| high
) default=lowFor 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
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
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,
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.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.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
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
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
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
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
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.