- Platform Release 6.5
- Privacera Platform Installation
- Privacera Platform User Guide
- Privacera Discovery User Guide
- Privacera Encryption Guide
- Privacera Access Management User Guide
- AWS User Guide
- Overview of Privacera on AWS
- Configure policies for AWS services
- Using Athena with data access server
- Using DynamoDB with data access server
- Databricks access manager policy
- Accessing Kinesis with data access server
- Accessing Firehose with Data Access Server
- EMR user guide
- AWS S3 bucket encryption
- Getting started with Minio
- Plugins
- How to Get Support
- Coordinated Vulnerability Disclosure (CVD) Program of Privacera
- Shared Security Model
- Privacera Platform documentation changelog
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
, tabletb1
,col1
.The user
user1
is ingroup1
and all users, includinguser1
, are in grouppublic
:resource: database=db1, table=tb1, column=col1 - users:[user1] maskType=NO_MASK - groups:[group1] maskType=HASH - groups:[public] maskType=NULL
When
user1
accesses columndb1.tbl1.col1
,user1
can see the unmasked value becausemaskType NO_MASK
is applied.For other users in
group1
,maskType HASH
is applied and so the column is displayed but the values are not visible.For all other users
NULL
is returned: access is denied and the column is not displayed.