Databricks Data Analyst: Securing Data

The privilege hierarchy

Unity Catalog secures objects in a nested hierarchy: metastore → catalog → schema → table/view/volume/function. Privileges granted at a higher level are inherited by everything beneath it. Typical analyst setup: USE CATALOG, USE SCHEMA, and SELECT on the relevant tables - all three are needed, which is a classic trap: SELECT alone produces "schema not found" style errors.

Common privileges: USE CATALOG, USE SCHEMA, SELECT, MODIFY, CREATE TABLE, CREATE VIEW, EXECUTE (functions), BROWSE, and ownership. Owners and metastore admins can grant to others.

Fine-grained controls

• Row filters - a SQL user-defined function applied to a table that restricts which rows a given user sees (e.g., region = current_region()).
• Column masks - a function that returns a transformed value (NULL, hashed, redacted) for sensitive columns such as email or SSN.
• Dynamic views - a view using current_user() or is_member('group') to vary output by identity.
• Attribute-based access - drive filters from group membership rather than per-user grants.

Identity and auditing

Access is granted to users, groups, and service principals (for automation); avoid personal access tokens in production. Audit logs record access and grant changes; lineage shows column-level data flow, useful for impact analysis before revoking a grant.

Traps

1. Granting SELECT but forgetting USE CATALOG/USE SCHEMA.
2. Assuming revoking a schema privilege removes inherited catalog-level access.
3. Applying a row filter and expecting it to hide the column - filtering is row-level only.
4. Sharing data outside the organization without checking workspace vs account-level identity.

Rule of thumb

Grant to groups, at the highest sensible level, and mask at the column. Use row filters for tenant or region isolation and column masks for PII; audit before you revoke.