Centralizing row and column access rules with Unity Catalog ABAC policies

Unity Catalog Attribute-Based Access Control (ABAC) policies let admins centrally define row filters and column masks using tags and conditions instead of hand-writing per-table SQL functions. Policies are attached at the catalog, schema, or table level and apply automatically to any matching object, reducing per-object governance overhead. This replaces manual row filter and column mask functions with a scalable, tag-driven approach.

1 · Learn the must-know

• 1ABAC policies use governed tags (on columns, tables, or attributes) as conditions to decide when a row filter or column mask applies, so tagging data correctly is essential for policies to take effect.
• 2Policies can be defined once at a catalog or schema level and automatically inherited by all matching tables/columns, avoiding the need to write a separate masking function for every table.
• 3Column masking policies can redact, hash, or partially obscure sensitive column values based on the querying user's group membership or attributes, without altering the underlying stored data.
• 4Row filter policies restrict which rows a user sees based on attribute matches (e.g., region or department tags), enforced transparently at query time regardless of how the data is accessed.
• 5ABAC policies are managed via SQL (CREATE POLICY / governance UI) and require appropriate metastore-level privileges to create or attach; policy changes take effect without needing to rewrite views or tables.
• 6Because enforcement happens centrally in Unity Catalog, ABAC policies apply consistently across all compute (SQL warehouses, clusters, notebooks) and access paths, unlike ad hoc view-based filtering.

2 · Check your understanding