Skip to main content

Privacera Documentation

Access management policies

You want to ensure that your data access is consistent and controlled across your computing ecosystem.

Implementing data access policies through Privacera Access Management gives you a single pane of glass to see what data your users can access.

Privacera access management policies are the key mechanism for protecting the data in your connected application datasources.

An access management policy is a set of rules you write that determine whether an attempt to access data is allowed or denied. The requested data can also be transformed via filtering, masking, or encryption, based on the context of the request and the desired results of the policy.

A policy consists of datasources, principals, and conditions:

  • Datasource objects (also called resources) such as namespaces, databases, tables, columns, and rows are what your policy protects. Examples of datasources include PostgreSQL, Google BigQuery, and Microsoft SQL Server. The examples and discussion here focus on databases, but there are many other kinds of datasources.

  • A principal is a user, group, or role whose access to the resource you want to allow, deny, or otherwise manage.

  • The exact rules you write, called conditions, define how the policy allows, denies, or otherwise operates on the datasource to produce the managed results seen by the principal.

Types of policies

A Privacera access management policy is a high-level abstraction. When the policy is associated with a datasource, Privacera transforms the abstract policy into the datasource-specific enforcement mechanism, such as an SQL GRANT.

Access policy enforcement depends on the underlying native capability of the datasource. Not all datasources are capable of natively implementing your Privacera policies. Features such as fine-grained access control (FGAC) and attribute based access control (ABAC) need additional configuration.

There are two types of policies:

  • Resource policies

  • Tag policies

Resource policies are associated directly with the actual data in the connected application. To create database permissions necessary to control access, a resource policy details the specific names of a namespace, database, column, row, view, or other types of resources.

If a new column or other resource is added to a database table, a new resource policy must be written to protect it. if the data is constantly increasing or changing, this resource policy maintenance can become burdensome.

Tag policies are based on classification metadata (also called tags) that Privacera creates when you scan a datasource.

For example, a Privacera scan might analyze the columns in a database table to determine the likelihood of the column containing sensitive data. A column whose values match a pattern like somebody@somewhere.com is probably PII that needs to be protected. Privacera might classify this column with the tag PERSON_EMAIL.

You then write policy against that PERSON_EMAIL tag, rather than against a specific named column.

Tag policies are automatically associated with any new data every time the datasource is scanned, helping to alleviate manual maintenance.

Principals: users, groups, and roles

The key focus of a policy is "Whose data access does this policy manage?" This is the principal of the policy.

A principal can be a single user or multiple users, a single group or multiple groups, a single role or multiple roles.

  • User information is typically brought into Privacera from your IdP, such as LDAP, Azure Active Directory, or Okta. This process is called Privacera UserSync.

  • Groups of users can be defined via the Privacera user interface or can be brought in with Privacera UserSync, relying on the grouping information in your IdP. For instance, you might have a group in your LDAP IdP called OU:DATA_ANALYST_GROUP and user attributes with this group name. This group and associated users are synced by Privacera UserSync.

  • Roles are defined in Privacera and associated with users or groups or both. For instance, you can create a role called DATA_ANALYST and assign that role to the DATA_ANALYST_GROUP of data analysts in your organization.

Datasources and resources

A datasource is an application you have connected to Privacera. This is the data you manage with policies.

A resource is any part of a datasource. For example, a datasource with namespaces and databases with tables and columns is represented as a hierarchy of resources:

namespacedatabasetablecolumn

The types of resources vary depending on the type of datasource.

A datasource or resource does not have to exist when you create a policy for it.

A common practice is to write policy beforehand so the datasource is protected from the moment you connect it to PrivaceraCloud.

Conditions: access rules

The heart of the policy is the conditions or rules that allow or deny access to the datasource by the principal, or otherwise transform the data via filtering, masking, or encrypting.

By default, Privacera denies access to most datasources, until your policy condition allows the access.

An allow condition on a resource can be represented like the following in Basic Normal Form (BNF) notation:

(Allow namespace )→ (Allow (database ) → (Allow table) → (Allow column)

Depending on the type of datasource, some of the transformations you can define in conditions are:

  • Filtering of rows, so that only certain rows containing specific values can be seen.

    (Allow (database ) → (Allow table) → (Filter row = someColumnValue)

  • Masking of columns, that is, obfuscating the values in the column with a masking string you specify.

    (Allow (database ) → (Allow table) → (Mask column with someMaskString)

  • Encrypting of column values either permanently one-way or two-way for later decryption.

    (Allow (database ) → (Allow table) → (Encrypt column)