Skip to main content

Privacera Platform

Privacera Access Management

:

How access policy enforcement works

Privacera Access Management works with and extends Apache Ranger to provide data access governance with centralized management of authorization policies and auditing.

There are several approaches to policy enforcement based on the data store and the type of access. All provide consolidated audit logging. And in all cases, data does not have to stream through Privacera’s code, so the overhead added by any policy enforcement is kept to a minimum.

Access control via Apache Ranger plug-ins

Where available, Privacera leverages Apache Ranger-style distributed policy enforcement points for access control. Many data processing engines, such as Hive, Spark and Presto, support these plugins. Policies created and managed in the Privacera portal are distributed to and synchronized with these policy enforcement points. Access control decisions happen at the engine, inline with query execution.

For the following plug-ins, the sync interval for retrieving Apache Ranger policies applies:

  • Databricks fine-grained access control (FGAC) plug-in: 3 seconds

  • Amazon EMR Presto plug-in: 2 seconds

  • Amazon EMR Hive plug-in: 2 seconds

  • Amazon EMR Trino (previously PrestoSQL): 5 seconds

Access control via PolicySync

For data sources like RDBMS where Ranger-style access control plugins are not available, access control policies are enforced via policy synchronization. Privacera’s PolicySync component translates the configured access control policies into the data source’s native access control framework, for example by sending a relational database GRANT/REVOKE statements, generating views where needed for additional layers of access control like data masking and row filtering, and so on. When there are policy changes in Privacera, new or changed objects in the data source, or changes to users, groups and roles, updates are pushed to the data source to keep it aligned with the latest policies.

PolicySync syncs Apache Ranger access policies at 3 second intervals by default, and this interval is configurable per PolicySync connector. In addition to the sync interval, PolicySync reconciles any access policy changes with the data source, and this requires additional time that varies with the complexity of the reconciliation required, such as adding and removing grants.

Access control via data access server

For data in object stores like S3 or ADLS, access requests flow through Privacera’s Data Access Server for policy enforcement. The Data Access Server integration method redirects data access requests to a Privacera ‘authentication broker’ inserted into the control and data flow. For requests that are allowed based on authentication and other policy checks, the authentication broker generates a signed URL that the requestor can use to fetch the requested data directly from the object store. All access attempts are audited.

Data Access Server syncs Apache Ranger access policies at 5 second intervals.

For details on configuring Data Access Server, see AWS.

Types of Access

  • Based on a user role

  • Based on tags applied to a data element

  • Based on a resource that is already connected to Access Management

  • Based on a resource that is not yet connected to Access Management

Access Type _ANY

The _ANY access type appears in the audit record when the Ranger plugin implicitly derives database permissions. This occurs when a user has any permission for any resource in a database, such as a single column.

Feature summary

  • Access Management through ABAC (Attribute-Based Access Control) and RBAC (Role-Based Access Control) policies

  • Resource-based (physical and logical metadata), as well as classification or tag-based (business metadata), access control policies

  • Comprehensive, normalized audits with rich event metadata that detail 'who', 'what', 'when', and 'where' along with business context for each access request - whether allowed or denied

  • Built-in reports and dashboards for access governance, audit, and compliance

Polices are applied to resources to control access. They consist of:

  • Controlled access datasets which are subsets of connected data repositories and databases, defined by any combination of database, table, and column access (wildcards supported) or for filesystem/object stores based on object, file, folder names (with wildcard support for paths).

  • Enforcement period with start and end dates and times for access policies.

  • Users, Roles, or Groups: Users and Groups can be synchronized from enterprise sources such as LDAP, Active Directory, Azure AD. Roles can be composed of any combination of users, groups or other roles (nested) to map to permissions in policy conditions.

  • Fine-grained Permissions: “Select”, “Update”, “Create”, “Drop”, “Alter”, "Read”, “Write”.

  • Flexible composition of schemes for positive and negative permissions: Policy conditions include “Allow”, and “Deny” access as well as layer permissions specifying “Exclude from Allow” and “Exclude from Deny”.