Security, Authorization & Governance

7.1 · Unity Catalog hierarchy & grants

Unity Catalog is the single, account-level authorization layer — one place to say "who can do what to which object," enforced everywhere. Switch the diagram between the securable hierarchy, the three gates a read needs, and workspace-catalog binding; click any box for the "what + why."

Grant scope vs blast radius (inheritance)

Illustrative config — the GRANT model

SQL is the primary surface. A reader needs all three grants together.

GRANT USE CATALOG ON CATALOG prod             TO `data-analysts`;  -- gate: enter floor
GRANT USE SCHEMA  ON SCHEMA  prod.sales       TO `data-analysts`;  -- gate: enter room
GRANT SELECT      ON TABLE   prod.sales.orders TO `data-analysts`; -- the actual read
GRANT SELECT ON SCHEMA prod.sales TO `data-analysts`;  -- inherits to ALL current+future tables
GRANT BROWSE ON CATALOG prod TO `account users`;       -- discovery without data access

Binding (no clean SQL): databricks catalogs update prod_catalog --isolation-mode ISOLATED then workspace-bindings update-bindings. Catalog Explorer: object → Permissions → Grant; catalog → Workspaces tab → Assign.

7.2 · ABAC, row filters & column masks

Once a user has SELECT they see every row and column — often too much. Fine-grained access control (FGAC) narrows what SELECT returns at query time. Switch the diagram between the query-time enforcement path and the three mechanisms; click a box for the "what + why."

Which mechanism?

Illustrative config — one snippet per mechanism

-- A) Dynamic view: only `auditors` see real emails (grant SELECT on the VIEW).
CREATE VIEW prod.customers.sales_redacted AS
SELECT user_id,
  CASE WHEN is_account_group_member('auditors') THEN email ELSE 'REDACTED' END AS email
FROM prod.customers.sales_raw;

-- B) Table-level row filter (RETURNS BOOLEAN; identity runs as INVOKER) + bind.
CREATE FUNCTION prod.customers.us_filter(region STRING)
  RETURN IF(is_account_group_member('admin'), true, region = 'US');
ALTER TABLE prod.customers.sales SET ROW FILTER prod.customers.us_filter ON (region);

-- C) ABAC: governed tag → one policy auto-covers every tagged column in the schema.
CREATE GOVERNED TAG pii VALUES ('ssn','ccn','dob');
ALTER TABLE prod.customers.accounts ALTER COLUMN ssn SET TAGS ('pii' = 'ssn');
CREATE POLICY mask_ssn ON SCHEMA prod.customers
  COLUMN MASK prod.governance.ssn_last TO us_analysts EXCEPT admins
  FOR TABLES MATCH COLUMNS has_tag_value('pii','ssn') AS ssn ON COLUMN ssn USING COLUMNS (4);

Governed tags: Account Console → Catalog/Settings → Governed tags. Policies: workspace → Catalog → scope → Policies tab → New policy. CREATE GOVERNED TAG SQL needs DBR 18.1+.

7.3 · Storage credentials, external locations & the access connector

The keyless bridge from a governed query to ADLS Gen2 — entirely Path ③ (compute → storage), the identity-and-authorization half. Switch the diagram between the credential chain and physical isolation; click a box for the "what + why."

How to authenticate UC to ADLS

Illustrative config — the two UC securables

CREATE STORAGE CREDENTIAL `finance_mi`
  WITH AZURE_MANAGED_IDENTITY
    ACCESS_CONNECTOR_ID = '/subscriptions//resourceGroups//providers/Microsoft.Databricks/accessConnectors/';

CREATE EXTERNAL LOCATION IF NOT EXISTS `finance_lake`
  URL 'abfss://finance@mystorageacct.dfs.core.windows.net/'
  WITH (STORAGE CREDENTIAL `finance_mi`);

GRANT READ FILES, WRITE FILES ON EXTERNAL LOCATION `finance_lake` TO `finance-engineers`;

Order: (1) access connector → (2) RBAC on ADLS (Storage Blob Data Contributor to the connector's identity) → (3) storage credential → (4) external location → (5) grants.

7.4 · Cluster policies & access modes

Three locks on the compute door — what compute can be (policy), who shares it and whether UC trusts it (access mode), and who can touch the object (ACL). Switch the diagram between the three locks and the access-mode comparison; click a box for the "what + why."

Standard vs Dedicated access mode

Illustrative config — the cost + UC-compliance enforcer

{
  "cluster_type":       { "type": "fixed", "value": "all-purpose" },
  "data_security_mode": { "type": "fixed", "value": "USER_ISOLATION", "hidden": true }, // = Standard
  "dbus_per_hour":      { "type": "range", "maxValue": 50 },          // THE cost cap
  "autotermination_minutes": { "type": "fixed", "value": 30, "hidden": true },
  "node_type_id":       { "type": "allowlist",
                          "values": ["Standard_DS3_v2","Standard_DS4_v2"],
                          "defaultValue": "Standard_DS3_v2" }
}

UI: Compute → Policies → Create policy → set Max DBUs/hr + Definitions JSON → grant CAN USE to groups. Access mode: Create compute → Advanced → Access mode. Premium plan required.

Decision guide — what an architect recommends

Customer Q&A — what the security team actually asks

Common asks & the answer

What breaks in the field — and the FIRST check

Three questions to ask before designing governance

1. Is there a regulatory mandate to prove environment isolation (dev can't touch prod), or is least-privilege grants enough?
2. How many tables need FGAC, and is there a central governance team — i.e. ABAC, or per-table views/masks?
3. Are they on Premium, on a UC-compliant access mode, and above the ABAC compute floor (serverless / DBR ≥ 16.4)?