Privacera Platform master publication

How Polices are evaluated


To authorize access to a resource, the system evaluates the resource- and tag-based policies associated with the resource as shown in the following diagram.


Tag-based policies

The system's policy engine evaluates the tag-based policies applicable to the tags:

  • If a policy results in a deny, access is denied.

  • If none of the tags is denied, and if a policy allows for one of the tags, access is allowed.

  • If there is no result for any tag, or if there are no tags for the resource, the policy engine then evaluates the resource-based policies (as opposed to the tag-based policies).

Using tags in conditions

You can use custom conditions for evaluating authorization policies. The system policy engine makes various request details – such as user, groups, resource, and context – available to the conditions. Tags in the request context are available to the conditions and can be used to influence the authorization decision.

The default policy in tag service instances, the EXPIRES_ON tag, uses such conditions to verify that the request date is later than the value specified in tag attribute expiry_date. This default policy does not work unless an EXPIRES_ON tag has been created, which the Privacera Platform defaults to "never".

Allow deny and exclude conditions

The system supports the following access conditions:

  • Allow

  • Exclude from Allow

  • Deny

  • Exclude from Deny

These access conditions are for fine-grained access control policies.

For example, you can allow access to a "manufacturing" database to all users in the "manufacturing" group, but deny access to all users in the "design" group. Suppose that "scott", a member of the "design" group, must work on an assignment that requires access to the "manufacturing" database. In that case, you can add an Exclude from Deny condition so user "scott" can access the "manufacturing" database. The following diagram shows how this policy can be defined in the system:


Normal vs override priority

You can define the priority of a resource-based and tag-based policy as normal (the default) or override.

A matching override policy takes precedence over all normal-priority policies.

If there are multiple override policies the relationship among them is governed by the same flow normal policies.

  • Any applicable override policy overrides all normal policies.

  • Multiple override policies interact the same rules as multiple normal policies.

Evaluation order for row filtering and column masking

Within a single row-filter/column-masking policy, the defined order of filters/masks determines the choice of masking type.

For example, consider this logical representation of a masking policy.

  • The protected data are database db1, table tb1, col1.

  • The user user1 is in group1 and all users, including user1, are in group public:

    resource: database=db1, table=tb1, column=col1 - users:[user1] maskType=NO_MASK - groups:[group1] maskType=HASH - groups:[public] maskType=NULL
  1. When user1 accesses column db1.tbl1.col1, user1 can see the unmasked value because maskType NO_MASK is applied.

  2. For other users in group1, maskType HASH is applied and so the column is displayed but the values are not visible.

  3. For all other users NULL is returned: access is denied and the column is not displayed.