Enforcing table, column, and row-level access control

Unity Catalog lets you secure data at the table, column, and row level using standard SQL GRANT statements and specialized functions applied directly to catalog objects. Column-level security uses masking functions, while row-level security relies on row filters, both defined once and enforced consistently across all engines and BI tools connected to the catalog. These controls integrate with Unity Catalog's centralized identity model, allowing permissions to be tied to users, groups, or service principals.

1 · Learn the must-know

• 1Table-level access is controlled via GRANT/REVOKE statements (e.g., SELECT, MODIFY) on catalog, schema, or table objects, following the three-level namespace (catalog.schema.table).
• 2Column masking is implemented by creating a SQL function that transforms or redacts a column's value and applying it with ALTER TABLE ... ALTER COLUMN ... SET MASK, so the function runs at query time based on the caller's identity or group membership.
• 3Row-level security uses row filter functions defined in SQL and attached to a table via ALTER TABLE ... SET ROW FILTER, which filters returned rows based on conditions like the querying user's group or attribute.
• 4Both masking and row filter functions typically use functions like is_account_group_member() or current_user() to dynamically apply different rules per user without needing separate views per audience.
• 5Access controls defined this way are enforced uniformly across all compute types (SQL warehouses, all-purpose clusters) and BI tools, avoiding the need to duplicate logic in each consuming application.
• 6Dynamic views (using CASE WHEN with is_account_group_member()) remain a valid alternative/legacy pattern for row- and column-level security when native masking/row filter features are not used or for finer custom logic.

2 · Check your understanding