https://community.databricks.com/t5/technical-blog/fine-grained-access-control-at-scale-with-abac/ba-p/147786 <H2><SPAN>Stop Wiring Security Table by Table: How ABAC Changes Everything in Unity Catalog</SPAN></H2> <P><SPAN>If you have ever managed column masks or row filters across more than a handful of tables in Unity Catalog, every new table that lands with PII means another <FONT color="#0000FF"><STRONG><FONT face="courier new,courier">ALTER TABLE ... SET MASK</FONT></STRONG></FONT> command. Another function to create. Another thing to forget. ABAC (Attribute-Based Access Control) fixes this: <EM><STRONG>you tag data once and let policies do the rest</STRONG></EM>.</SPAN><BR /><BR /><SPAN>This article walks through the three approaches to fine-grained access control (FGAC) in Unity Catalog, explains why ABAC is the one that actually scales.</SPAN></P> <H2><SPAN>The Challenge: Scaling Fine-Grained Access Control (FGAC)</SPAN></H2> <P><SPAN>Imagine you have a <FONT face="courier new,courier"><STRONG><FONT color="#0000FF">customers</FONT></STRONG></FONT> table with email addresses and phone numbers. You need to mask those columns so that only members of the <FONT face="courier new,courier" color="#0000FF"><STRONG>data_admins</STRONG></FONT> group can see them in clear text. Easy enough.</SPAN><BR /><BR /><SPAN>Now imagine you have 50 tables with email columns. Or 200. Every time a data engineer adds a new table with an email field, someone has to remember to create and attach a mask. If they forget, that PII sits there unprotected until an audit catches it. The security model becomes a to-do list instead of a system.</SPAN><BR /><BR /><SPAN>Unity Catalog gives you three ways to solve this. Let's look at each one, then talk about why only one of them holds up at scale.</SPAN></P> <H3><SPAN>Approach 1: Manual Column Masks and Row Filters</SPAN></H3> <P><SPAN>This is the most common starting point. You write a SQL function that defines both <FONT color="#FF0000"><EM><STRONG>what</STRONG></EM></FONT> to mask and <FONT color="#FF0000"><EM><STRONG>who</STRONG></EM></FONT> gets to see the original value, then you attach this function to a specific column on a specific table.</SPAN><BR /><BR /><SPAN>Here is a column mask for email addresses on <STRONG><FONT face="courier new,courier" color="#0000FF">samples.bakehouse.customers</FONT></STRONG>:</SPAN></P> <PRE><SPAN>-- The function defines WHAT to mask AND WHO sees what</SPAN><BR /><SPAN>CREATE OR REPLACE FUNCTION silver.mask_email(email_</SPAN><WBR /><SPAN>address STRING)</SPAN><BR /><SPAN>RETURNS STRING</SPAN><BR /><SPAN>RETURN CASE</SPAN><BR /><SPAN>&nbsp; WHEN is_account_group_member('data_</SPAN><WBR /><SPAN>admins') THEN email_address</SPAN><BR /><SPAN>&nbsp; ELSE CONCAT('****@', SPLIT(email_address, '@')[1])</SPAN><BR /><SPAN>END;</SPAN></PRE> <P><SPAN>Then you attach it:</SPAN></P> <PRE><SPAN>ALTER TABLE silver.customers</SPAN><BR /><SPAN>ALTER COLUMN email_address SET MASK silver.mask_email;</SPAN></PRE> <P><SPAN>Row filters follow the same pattern. You write a function that returns <FONT face="courier new,courier"><STRONG><FONT color="#0000FF">TRUE</FONT></STRONG></FONT> for rows the user is allowed to see, then attach it to the table:</SPAN></P> <PRE><SPAN>-- Again: WHAT to filter AND WHO sees what</SPAN><BR /><SPAN>CREATE OR REPLACE FUNCTION silver.country_filter(country STRING)</SPAN><BR /><SPAN>RETURNS BOOLEAN</SPAN><BR /><SPAN>RETURN CASE</SPAN><BR /><SPAN>&nbsp; WHEN is_account_group_member('data_</SPAN><WBR /><SPAN>admins') THEN TRUE</SPAN><BR /><SPAN>&nbsp; WHEN is_account_group_member('</SPAN><WBR /><SPAN>account users')</SPAN><BR /><SPAN>&nbsp; &nbsp; THEN country IN ('Australia', 'Japan')</SPAN><BR /><SPAN>&nbsp; ELSE FALSE</SPAN><BR /><SPAN>END;</SPAN><BR /><BR /><SPAN>ALTER TABLE silver.franchises</SPAN><BR /><SPAN>SET ROW FILTER silver.country_filter ON (country);</SPAN></PRE> <P><SPAN>This works fine for a few tables. The problem is that both the function and the binding are per-table, per-column. The function itself encodes the <STRONG><FONT color="#FF0000">WHO</FONT></STRONG> (which groups see what) alongside the <STRONG><FONT color="#FF0000">WHAT</FONT></STRONG> (how to transform the data). There is no separation of concerns.</SPAN></P> <P><SPAN>Every column needs its own <STRONG><FONT face="courier new,courier" color="#0000FF">ALTER TABLE</FONT></STRONG> statement. Every new table needs manual attention.</SPAN></P> <H3><SPAN>Approach 2: Dynamic Views</SPAN></H3> <P><SPAN>Dynamic views embed security logic directly in a view definition using <FONT face="courier new,courier"><STRONG><FONT color="#0000FF">CASE</FONT></STRONG></FONT> expressions and context functions. They combine row filtering and column masking in a single object.</SPAN></P> <PRE><SPAN>CREATE OR REPLACE VIEW silver.v_customers_secure AS</SPAN><BR /><SPAN>SELECT</SPAN><BR /><SPAN>&nbsp; customerID,</SPAN><BR /><SPAN>&nbsp; first_name,</SPAN><BR /><SPAN>&nbsp; last_name,</SPAN><BR /><SPAN>&nbsp; CASE</SPAN><BR /><SPAN>&nbsp; &nbsp; WHEN is_account_group_member('data_</SPAN><WBR /><SPAN>admins') THEN email_address</SPAN><BR /><SPAN>&nbsp; &nbsp; ELSE CONCAT('****@', SPLIT(email_address, '@')[1])</SPAN><BR /><SPAN>&nbsp; END AS email_address,</SPAN><BR /><SPAN>&nbsp; CASE</SPAN><BR /><SPAN>&nbsp; &nbsp; WHEN is_account_group_member('data_</SPAN><WBR /><SPAN>admins') THEN phone_number</SPAN><BR /><SPAN>&nbsp; &nbsp; ELSE CONCAT('***-***-', RIGHT(phone_number, 4))</SPAN><BR /><SPAN>&nbsp; END AS phone_number,</SPAN><BR /><SPAN>&nbsp; city,</SPAN><BR /><SPAN>&nbsp; country</SPAN><BR /><SPAN>FROM silver.customers</SPAN><BR /><SPAN>WHERE is_account_group_member('data_</SPAN><WBR /><SPAN>admins') OR country = 'Australia';</SPAN></PRE> <P><SPAN>Dynamic views are the recommended approach when sharing data via <FONT color="#FF0000"><STRONG>Delta Sharing</STRONG></FONT>, because row filters and column masks are not applied to Delta Sharing recipients. The security logic in a dynamic view is enforced because recipients query the view, not the underlying table.</SPAN><BR /><BR /><SPAN>But dynamic views still suffer from the same scaling problem. Each view is hand-crafted for a specific table. Add a new table with PII and you need a new view. The security logic is spread across dozens of view definitions with no central point of control.</SPAN></P> <H3><SPAN>Approach 3: ABAC <EM>(The One That Scales)</EM></SPAN></H3> <P><SPAN>ABAC separates the concerns. The masking function defines only the <STRONG><FONT color="#FF0000">WHAT</FONT></STRONG>. A policy object defines the <STRONG><FONT color="#FF0000">WHO</FONT></STRONG> and the <FONT color="#FF0000"><STRONG>WHERE</STRONG></FONT> (which scope it applies to). A governed tag connects them.</SPAN></P> <P><span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="abac_overview.png" style="width: 999px;"><img src="https://community.databricks.com/t5/image/serverpage/image-id/23881i2177A3EDB30A763E/image-size/large?v=v2&amp;px=999" role="button" title="abac_overview.png" alt="abac_overview.png" /></span><BR /><BR /><SPAN>Here is the key difference. Look at the mask function for ABAC:</SPAN></P> <PRE><SPAN>-- The function defines ONLY the WHAT</SPAN><BR /><SPAN>-- No is_account_group_member() check, no WHO logic</SPAN><BR /><SPAN>CREATE OR REPLACE FUNCTION silver.mask_email(email_</SPAN><WBR /><SPAN>address STRING)</SPAN><BR /><SPAN>RETURNS STRING</SPAN><BR /><SPAN>RETURN CONCAT('****@', SPLIT(email_address, '@')[1]);</SPAN></PRE> <P><SPAN>There is no <FONT face="courier new,courier"><STRONG><FONT color="#0000FF">is_account_group_member()</FONT></STRONG></FONT> call. The function does not care who is querying. It only knows how to mask an email address. The <FONT color="#FF0000"><STRONG>WHO</STRONG></FONT> is handled entirely by the policy.</SPAN></P> <H4><SPAN>Step 1: Tag the Column</SPAN></H4> <P><SPAN>Governed tags are the bridge between your data and your policies. You apply a tag to any column that contains a certain class of data:</SPAN></P> <PRE><SPAN>ALTER TABLE silver.customers</SPAN><BR /><SPAN>ALTER COLUMN email_address SET TAGS ('class.email_address');</SPAN></PRE> <P><SPAN>Unity Catalog ships with system-defined governed tags like <FONT face="courier new,courier"><STRONG><FONT color="#0000FF">class.email_address</FONT></STRONG></FONT>, <FONT face="courier new,courier"><STRONG><FONT color="#0000FF">class.us_ssn</FONT></STRONG></FONT>, and others. You can also create your own through the Catalog Explorer UI or programmatically via the Databricks API.</SPAN></P> <H4><SPAN>Step 2: Create the Policy</SPAN></H4> <P><SPAN>The policy ties it all together. It says: for a given scope, find all columns with a matching tag, apply this mask function, and apply it to these groups:</SPAN></P> <PRE><SPAN>CREATE OR REPLACE POLICY pii_email_policy</SPAN><BR /><SPAN>ON SCHEMA silver</SPAN><BR /><SPAN>COLUMN MASK silver.mask_email</SPAN><BR /><SPAN>TO `account users`</SPAN><BR /><SPAN>EXCEPT `adminuser@mycompany.com`</SPAN><BR /><SPAN>FOR TABLES</SPAN><BR /><SPAN>MATCH COLUMNS hasTag('class.email_address') AS email_address</SPAN><BR /><SPAN>ON COLUMN email_address;</SPAN></PRE> <P><SPAN>That is it. Every column in the <STRONG><FONT face="courier new,courier" color="#0000FF">silver</FONT></STRONG> schema that carries the <FONT face="courier new,courier"><STRONG><FONT color="#0000FF">class.email_address</FONT></STRONG></FONT> tag is now masked for all members of <FONT face="courier new,courier"><STRONG><FONT color="#0000FF">`account users`</FONT></STRONG></FONT>&nbsp;(everyone essentially) except for specific principals (users or service principals which are exempt from the policy).</SPAN></P> <P><SPAN>You can also scope policies at the <STRONG><FONT color="#FF0000">catalog level</FONT></STRONG>.&nbsp; A single <FONT face="courier new,courier"><STRONG><FONT color="#0000FF">ON CATALOG</FONT></STRONG></FONT>&nbsp;policy would cover every schema and every table in the entire catalog.</SPAN></P> <P><STRONG><FONT color="#FF0000">Tag</FONT></STRONG> columns once (which is a good practice anyway) -&gt; define the <STRONG><FONT color="#FF0000">Policy</FONT></STRONG> once -&gt; That's it!</P> <H3><SPAN>ABAC for Row Filters Too</SPAN></H3> <P><SPAN>Everything above focused on column masking, but ABAC works for row filters as well. The pattern is the same: write a function that defines the filter logic (the <STRONG><FONT color="#FF0000">WHAT</FONT></STRONG>), tag the relevant column, and create a policy.</SPAN></P> <PRE><SPAN>-- Function: WHAT only (returns TRUE for permitted rows)</SPAN><BR /><SPAN>CREATE OR REPLACE FUNCTION silver.filter_apac_only(region STRING)</SPAN><BR /><SPAN>RETURNS BOOLEAN</SPAN><BR /><SPAN>RETURN region = 'APAC';</SPAN><BR /><BR /><SPAN>-- Tag the column</SPAN><BR /><SPAN>ALTER TABLE silver.customers</SPAN><BR /><SPAN>ALTER COLUMN region SET TAGS ('region_filter');</SPAN><BR /><BR /><SPAN>-- Policy: WHO + WHERE</SPAN><BR /><SPAN>CREATE OR REPLACE POLICY filter_apac_rows_policy</SPAN><BR /><SPAN>ON CATALOG bakehouse</SPAN><BR /><SPAN>ROW FILTER silver.filter_apac_only</SPAN><BR /><SPAN>TO `apac-users`</SPAN><BR /><SPAN>FOR TABLES</SPAN><BR /><SPAN>MATCH COLUMNS hasTag('region_filter') AS region</SPAN><BR /><SPAN>USING COLUMNS (region);</SPAN></PRE> <P><SPAN>Now every table in the <STRONG><FONT face="courier new,courier">bakehouse</FONT></STRONG> catalog that has a column tagged with <FONT face="courier new,courier"><STRONG>region_filter</STRONG></FONT> will automatically restrict <FONT face="courier new,courier"><STRONG>apac-users</STRONG></FONT> to APAC rows only. No per-table wiring needed.</SPAN></P> <H2>Deciding on the FGAC Approach</H2> <P>Manual column masks, row filters and dynamic views may still have their place in your FGAC strategy, the attached decision tree provides some guidance on what to use when and why.</P> <P><span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="fgac_decision_tree.png" style="width: 999px;"><img src="https://community.databricks.com/t5/image/serverpage/image-id/23882i450AAAD0944C3A06/image-size/large?v=v2&amp;px=999" role="button" title="fgac_decision_tree.png" alt="fgac_decision_tree.png" /></span></P> <H2><SPAN>Things to Know Before You Start</SPAN></H2> <P><SPAN>1. Governed tags are not the same as regular tags. Regular tags (the ones you create implicitly with <FONT color="#0000FF"><STRONG><FONT face="courier new,courier">SET TAGS</FONT></STRONG></FONT>) are for search and discovery. ABAC policies only work with governed tags, which are defined through the Catalog Explorer API/UI and have controlled allowed values.</SPAN><BR /><BR /><SPAN>2. Manual masks and ABAC policies cannot coexist on the same column.&nbsp; If a column already has a manual mask, you need to drop it before an ABAC policy can take effect. Run <STRONG><FONT face="courier new,courier" color="#0000FF">ALTER TABLE ... ALTER COLUMN ... DROP MASK</FONT></STRONG> first.</SPAN></P> <P><SPAN>3. Only one row filter policy can apply to a table per user at a time. Plan your policy scoping accordingly.</SPAN><BR /><BR /><SPAN>4. Policies inherit downward. A catalog-level policy covers all schemas and tables within it. A schema-level policy covers all tables in the schema. Use narrower scopes for exceptions.</SPAN><BR /><BR /><SPAN>5. DBR 16.4+ or Serverless is required. Users on older runtimes cannot query ABAC-secured tables at all. If you have mixed runtime versions, consider scoping policies to specific groups so that users outside those groups can still access the tables on older runtimes.</SPAN></P> <H2><SPAN>Wrapping Up</SPAN></H2> <P><SPAN>Manual masks and row filters are fine when you have a small number of tables. Dynamic views are useful when you are sharing data through Delta Sharing. But if you are operating at any real scale, ABAC is the approach that actually works long term.</SPAN><BR /><BR /><SPAN>The core insight is simple: separate the <STRONG><FONT color="#FF0000">WHAT</FONT></STRONG> from the WHO. Let the function be a pure transformation. Let the policy handle targeting. Let the tag be the glue. When your next data engineer creates a table and tags the email column, the mask is already there waiting for it.</SPAN><BR /><BR /><SPAN>That is security that scales.</SPAN></P> Wed, 11 Feb 2026 21:32:33 GMT jeffreyaven 2026-02-11T21:32:33Z https://community.databricks.com/t5/technical-blog/fine-grained-access-control-at-scale-with-abac/ba-p/147786 <P><SPAN>Manual column masks and row filters work at small scale, but you need a solution that scales, tag once, define a policy, enforce everywhere. This post covers how ABAC uses governed tags and policies to apply fine-grained access control across your catalog without wiring up every table individually.&nbsp;</SPAN></P> Wed, 11 Feb 2026 21:32:33 GMT https://community.databricks.com/t5/technical-blog/fine-grained-access-control-at-scale-with-abac/ba-p/147786 jeffreyaven 2026-02-11T21:32:33Z https://community.databricks.com/t5/technical-blog/fine-grained-access-control-at-scale-with-abac/bc-p/148102#M909 <P>Really nice post. I have a wish that someday I would see this solution in our company.&nbsp;<a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/43054">@jeffreyaven</a>&nbsp;Masking is great, but what about ABAC for table privileges? Are you planning something on this area?</P><P>For example:</P><P>I could tag the tables as domain = procurement. Then I could create a policy saying, if user is in group procurement they have select privileges. If user is in group procurement + procurement-dev then they have also insert/update etc. With column masking and row filtering we could get to interesting combinations <span class="lia-unicode-emoji" title=":slightly_smiling_face:">🙂</span></P><P>The reason why I'm asking. With UC you can inherit privileges on tables from schema level. But if you want lower granularity you have to do it on table level. Then you are basically granting privileges on table by table which is not that great...</P><P>&nbsp;</P> Thu, 12 Feb 2026 01:34:49 GMT https://community.databricks.com/t5/technical-blog/fine-grained-access-control-at-scale-with-abac/bc-p/148102#M909 pepco-personal 2026-02-12T01:34:49Z https://community.databricks.com/t5/technical-blog/fine-grained-access-control-at-scale-with-abac/bc-p/148103#M910 <P>thanks&nbsp;<a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/204567">@pepco-personal</a>&nbsp;you raise some good points, at this stage ABAC implements FGAC at row or column level (at scale), table privs would still rely on permission assignments at catalog, schema or object level, the two work in concert (to override inheritance and protect data at column or row level).&nbsp; I can do some more investigation however.</P> Thu, 12 Feb 2026 03:23:43 GMT https://community.databricks.com/t5/technical-blog/fine-grained-access-control-at-scale-with-abac/bc-p/148103#M910 jeffreyaven 2026-02-12T03:23:43Z