Attribute Based Access Control (ABAC) Overview¶

Attribute-Based Access Control (ABAC) in Privacera allows you to define dynamic policies based on attributes of users, groups, roles, and tags. Instead of maintaining static lists of users or resources, ABAC enables context-aware enforcement, ensuring that access decisions adapt based on identity metadata and business logic such as department, location, clearance level, or sensitivity labels attached to users and data resources.

Privacera also supports policies based on resources, which is covered in the Tag Based Access Control (TBAC).

Key benefits of ABAC in Apache Ranger include:¶

• Dynamic Authorization: Access decisions automatically adjust based on changing attributes without frequent policy updates.
• Fine-Grained Access: Enables precise control by using multiple attributes to define complex access rules.
• Policy Simplification: Reduces administrative overhead by managing fewer, attribute-driven policies rather than numerous static rules.
• Enhanced Security: Minimizes risks by ensuring access is continuously evaluated and enforced according to real-time attribute values.

Implementation Design¶

Most data engines do not support ABAC natively, so depending on the integration, it is handled differently:

1. Apache Ranger Plugin: ABAC is handled by the plugin during query execution.
2. PolicySync: ABAC is translated into the target system's native constructs and applied to the data engine using custom User Defined Functions (UDFs) or explicit user or group based permissions.

Examples of ABAC Policies¶

Here are some examples of how ABAC can be implemented in Privacera using Apache Ranger policies. These examples illustrate how to leverage user attributes and group attributes to create dynamic access control policies.

1. Resource Access Based on User Attributes¶

In this example, table access is dynamically controlled based on the user's department attribute (${{USER.dept}}).

Policy Expression:

Allow Access: ${{USER.dept}} == 'finance'

2. Dynamic Row-Level Filtering Based on User's Group Membership¶

Here, users can view only the rows matching their assigned group membership, utilizing UG_NAMES_CSV().

Dataset (sales.records):

Policy Expression (Row-Level Filter):

region in ('${{UG_NAMES_CSV.replace(",", "','")}}')

3. Dynamic Column Masking Based on User's Group Membership¶

Sensitive columns are masked dynamically, depending on whether the user belongs to a specific group.

Dataset (employee.payroll):

| Employee ID | Name | Salary | SSN |Role | ----------- | ----- | --------- | ----------- | | 101 | Grace | $120,000 | 123-45-6789 |payroll_mgr | 102 | Heidi | $95,000 | 987-65-4321 |intern

Policy Expression (Column Masking Rule):

CASE WHEN Role in ('${{UG_NAMES_CSV.replace(",", "','")}}') THEN {col} ELSE 'MASKED' END

Here is the updated version of the Tag-Based Masking Policy example using User Attributes instead of group membership:

4. Tag-Based Masking Policy Using User Attributes¶

Columns tagged as PII are masked unless the user has an attribute data_clearance set to high.

Dataset with Tags:

Masking Policy Expression:

Mask if: ${{USER.data_clearance}} != 'high'

Explanation:

• All columns tagged as PII will be masked for users who do not have a data_clearance value of high.
• Non-sensitive columns (no tag) remain fully visible to all users.

Comments