Skip to main content
Version: v4.17

Policy framework

With Cyral, you create policies that limit how your organization's data can be acted on by people and applications. Your policies specify attribute based access control rules that can completely block access to sensitive data, or allow access with one or more of the following constraints:

For any query executed by the user, Cyral finds the policies applicable to that query based on the data accessed by the query and evaluates these policies. The results of individual policies are composed using the "least privilege principle" to determine the final policy enforcement actions. Policy evaluation and composition are explained in more detail here.

Every query generates a log entry showing which policies were evaluated and which were violated.

Policies can be created in the following ways.

  • Create global policies as explained in Global policies.
  • Create repo-level policies from the Policies tab in the Repository Details page. Repo-level policies are specific to a repository and can be created in one of two ways:
    • instantiate a pre-defined policy templates for common use cases.
    • Create custom policies as described in Local policies.

Policy enforcement actions​

Cyral supports multiple types of policy enforcement actions, explained in the subsections below. Note that the corresponding policy enforcement flag (explained in subsections below) must be enabled in the repository config for the enforcement action to be actually performed. If the enforcement flag is off, the policy result is recorded in the activity log but the action is not actually enforced.

Blocking access​

The block on violation enforcement action stops the user from receiving the database results for a query, if that query violates a policy.

Cyral global and local policies have a deny by default nature. This means that you specify rules that allow access when certain conditions are met. If none of the rules in an applicable policy match, the request is blocked.

caution

You must enable blocking on each repository where you wish to block data access.

Row limiting​

A maxRows constraint can be specified in a global or local policy to limit the number of rows that can be read, deleted, or updated from a data location. Note that the row limit cannot be enforced on the delete and update operations - in these cases, an alert is raised if the row limit is exceeded.

caution

You must enable blocking on each repository where you wish to impose row limits.

Rate limiting​

Use the rateLimit constraint in a global policy to limit the rate at which a user can read, update, and/or delete data. The limit is expressed as the number of rows or documents accessed per hour. Limits are tracked independently for each user and for each data label. Again, the rate limit cannot be enforced on the delete and update operations - in these cases, an alert is raised if the limit is exceeded.

caution

You must enable blocking on each repository where you wish to impose rate limits.

Dataset rewriting​

The dataset rewriting action lets you specify a filter on the set of rows that the user is allowed to access.

This action rewrites table expressions in the user query, replacing them with a substitution query that you've specified in the policy. Rewriting is typically used to filter the set of rows the user can see. The most common use case is to specify a query of the form SELECT * FROM table WHERE ... and including a WHERE clause that specifies a filter allowing only the rows that the user is allowed to access. However, you also have the option to supply a more complex replacement query.

A dataset rewrite is specified using the datasetRewrite constraint in a local policy.

Note that dataset rewrites only apply to read operations. Statements that modify data (such as update, or delete) are not rewritten in order to preserve data integrity.

caution

You must enable dataset rewrites on each repository where you wish to perform rewrites.

tip

See policy evaluation to understand how dataset rewriting interacts with other actions like blocking, rate limiting, and masking data.

Masking data​

The data masking enforcement action hides or replaces specific field values in each row returned, rather than filtering the set of rows returned.

To mask the contents of a data location, specify a mask constraint in a rule in a global policy. The masking function can be one of:

  • null to replace the field's contents with a null value.
  • constant to replace the field's contents with a value you provide; or
  • format-preserving to replace the field's contents with a semi-randomized string that preserves the original format; or
  • a custom masking function that you define as a user defined function in your database.
caution

You must enable masking and install helper functions in each repository where you wish to perform masking. See Mask data for instructions.