Privacera Platform master publication

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 Ranger policy enforcement points

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.

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 syncrhonization. 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. For details on configuring PolicySync, see https://docs.privacera.com/latest/platform/pm-ig/policysync_advanced_custom_prop/

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.

For details on configuring Data Access Server, see AWS.

Automated access request workflows

Privacera provides enterprises with a seamless and automated method to manage user access provisioning and de-provisioning for their data. Using the proven open source business process workflow engine Flowable, which is embedded with Privacera platform, enterprises can now automatically manage the creation and updating of policies based on requests from users based on their roles or based on the attributes such as location and other metadata for the data that they need to get access instead of prior manual authoring of access control policies and managing entitlements through manual user intervention of the policy administrators.

Using Access Workflows feature, enterprise users who need access to data that they need to do their jobs, for example, data associated with a particular project or based on their corporate role or need for accessing all data that has specific data classifications attached to it, can now raise an access request ticket directly within Access Management. These requests are then routed to the appropriate approvers who control access to the data using the workflow engine. Approvers can be set up using a specific role. Such approvers can be the policy administrators or data owners or data stewards, for example, who typically control access to the data by writing access control policies within Access Management.

Once the users file such a ticket requesting access to a specific role or the data directly, a ticket is created and the user is provided an email notifying that a ticket for access has been raised and the appropriate approvers for that data are also notified by email. The approvers can then log in to Access Management and make a decision whether to approve or reject this request. For example, the approvers can review the ticket details to validate the business purpose, the scope of data requested and the duration of access requested and make any modifications to these based on enterprise-wide standards and policies. If the request is approved by the approver, Privacera platform automatically creates relevant policies to reflect the user's requested data entitlements whether by creating policies or adding users to the roles without any manual intervention from the approver. An audit entry linking this approval action to the ticket id is generated to provide traceability and for compliance purposes automatically in Access Management.

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 non-repudiable 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”.