Skip to main content

Data Security overview

Data Security decides which catalogs, schemas, tables, rows, and columns each person can see in the Lakehouse. You set this with policies, and Lakehouse checks them on every query in Data Explorer, Query Editor, and connected tools.

Policy types​

The Security policies page (Data Security → Security policies) has one tab for each policy type.

TabWhat the policy doesExample
AccessLets people read or change a catalog, schema, table, or the functions in a schema.The bi-sale group can run SELECT on every table in analytics.sales.
Row level filterShows only the rows that match a condition, for one table.The bi-sale group sees only rows where region = 'North'.
MaskingHides the values of one column, for example by replacing them with a hash.The bi-sale group sees customer_phone as a hash.

Without an access policy, a person sees no data at all, even the tpcds sample catalog. Row level filter and masking policies only narrow what an access policy already allows.

Who a policy applies to​

Each policy lists one or more of these:

  • Users, by email address.
  • Groups. Every member of the group gets the policy. Groups are managed in Access Management.
  • Service accounts, for tools and pipelines that connect without a person.

Prefer groups. When someone joins or leaves a team, you change the group once instead of every policy.

How scope works​

An access policy covers everything below the level you pick.

Catalog       analytics         policy here covers every schema and table
└── Schema    analytics.sales   policy here covers every table in sales
    └── Table analytics.sales.orders   policy here covers only orders
  • Access never flows upward. Access to one table does not open the rest of its schema or catalog.
  • With access to one table, the person still sees its catalog and schema in Data Explorer, but only that branch.
  • If several policies apply to the same person, they get everything the policies allow together.

See Access policy permissions for what each permission allows at each level.

Row level filter and masking​

A row level filter adds a condition to every query on the table, as if the person had written it in a WHERE clause. Rows that do not match never reach the person. Their query history still shows the SQL they wrote.

A masking policy changes how one column is shown. The data stored in the table does not change. Masking applies everywhere the person reads data, including Query Editor and sample data in Data Explorer.

note

If several masking policies apply to the same person and column, for example through two groups, you cannot choose which one wins. Avoid overlapping masking policies on the same column.

When changes take effect​

A new, changed, or deleted policy applies to queries that start about 1 minute after you save it. Queries already running are not affected.

warning

After you delete a policy or remove someone from it, they can still read the data for about 1 minute.

What Data Security does not change​

  • Deactivating a user in Access management keeps their policies. If you reactivate the user, their old access returns. Remove them from the policies if they should not get it back.
  • Portal roles decide which pages a person can open. Policies in Data Security decide which data they can query. A person needs both.

Next steps​