Access Control & PBAC Governance

VDA enforces a Policy-Based Access Control (PBAC) framework that replaces rigid, all-or-nothing database grants with fine-grained, attribute-aware security policies across datasources, tables, and individual columns.

---

1. The PBAC Policy Model

Every access decision is governed by standard 4-tuple policy rules:

$$\text{Policy Rule} = \langle \text{Role}, \text{Action}, \text{Scope}, \text{Effect} \rangle$$

graph TD
    Rule["Policy Rule"]
    Rule --> Role["Role (e.g. DataAnalyst, RiskOfficer)"]
    Rule --> Action["Action (data:read, metadata:read, *)"]
    Rule --> Scope["Scope (datasource:*, dataset:*, column:*)"]
    Rule --> Effect["Effect (ALLOW or DENY)"]

Core Security Invariants

1. Explicit Deny Dominance: Any matching DENY rule overrides all ALLOW rules regardless of hierarchy.
2. Container Inheritance: An ALLOW rule on datasource:retail_banking grants implicit access to all datasets within that datasource, unless overridden by a child DENY.
3. Column-Level Restriction: An explicit DENY rule on column:retail_banking.transactions.customer_ssn removes that column from query results, previews, and SQL ASTs while leaving non-restricted columns accessible.
4. Action Implication: Granting data:read or data:query automatically implies visibility for metadata:read.

---

2. Managing Role Permissions in the Web UI

Navigate to Access Management from the sidebar (requires Administrator or Security Steward privileges).

Access Management, Role Permissions tab: pick a role, review its effective access summary, and manage its ALLOW/DENY rules.

Adding a Rule

1. Click + Add PBAC Rule.
2. Select the Action (metadata:read, data:read, data:query, admin:*, or *).
3. Choose the Scope Type:
4. Datasource: Apply across an entire database connection.
5. Dataset / Table: Apply to a specific table or view.
6. Column: Use the Interactive Column Picker to select columns from live schema metadata.
7. Select the Effect: ALLOW or DENY.
8. Click Save Policy.

AI Policy Assistant

Click AI Policy Assistant to author and review policies with an LLM, always checked by a strict grammar validator. It has three tabs: Prompt to Policy (describe the permissions you want in plain English and generate PBAC rules, or start from a quick preset), Role Explainer, and Security Auditor.

The AI Policy Assistant drawer on the Prompt to Policy tab, with quick presets for common roles.

---

3. Effective Access Profile Summary

The Effective Access Profile card summarizes what a role can do at a glance: - Catalog Visibility: Total accessible datasources and schemas. - Query Rights: Databases where interactive SQL querying is permitted. - Denied / Masked Columns: Complete count of columns stripped or masked for this role. - Administrative Privileges: Flag indicating whether the role can create connectors or edit policies.

---

4. The Permission Simulator

Test and audit access rules before deploying them to production users:

1. Click the Access Simulator & Audit tab.
2. Choose Simulate by Role (e.g. JuniorAnalyst) or Simulate by User (e.g. john.doe@company.com).
3. Enter the test evaluation parameters:
4. Action: data:read
5. Scope: dataset:retail_banking.transactions
6. Click Run Simulation.
7. The simulator displays:
8. Decision: PERMITTED or DENIED.
9. Winning Rule: The exact policy rule that triggered the decision.
10. Masked Columns: List of columns that will be redacted if the user queries this table.
11. Evaluation Trace: Full step-by-step breakdown of how deny dominance and container inheritance were evaluated.

Running the "HR SSN Column" preset: access is denied by an explicit column-level rule, and the restricted column is listed.