Zabezpečení objektů Unity Catalogu

Než začneme rozdávat oprávnění, potřebujeme pochopit, co se vlastně děje, když uživatel spustí dotaz nad tabulkou spravovanou Unity Catalogem. Unity Catalog funguje jako control plane pro bezpečnost a governance: každý dotaz projde kontrolou oprávnění, zapíše se do audit logu a teprve pak dostane compute krátkodobý přístup k datům.

Kdo čeká, že cluster „prostě čte soubory ze storage", bude překvapen — compute nikdy nedostane trvalé přihlašovací údaje ke storage. Dostane jen scoped temporary access token platný pro konkrétní objekty v konkrétním dotazu.

Celý cyklus má osm kroků:

1) Odeslání dotazu — principal (uživatel, skupina nebo service principal) spustí dotaz z notebooku na all-purpose clusteru, z jobu na job clusteru, přes Databricks SQL warehouse, nebo z připojeného BI nástroje. 2) Validace v Unity Catalogu — compute předá request Unity Catalogu, ten jej zapíše do audit logu a ověří oprávnění ke všem objektům v dotazu. Zamítnutí se také loguje. 3) Převzetí cloud credential — pro každý objekt Unity Catalog převezme příslušný cloud credential (u managed tabulek storage metastoru, u external objektů storage credential dané external location). 4) Vydání scoped tokenů — Unity Catalog vygeneruje krátkodobý token a zabezpečenou URL pro každý objekt. 5–6) Přístup k datům — compute čte přímo z ADLS Gen2 endpointů (abfss://). 7) Fine-grained filtrování — row filtry a column masky se vyhodnocují na compute, takže každý principal vidí jen svou podmnožinu dat. 8) Vrácení výsledku volajícímu.

Access control v Unity Catalogu stojí na čtyřech doplňujících se mechanismech:

Základem je privilege model: grant říká, kdo (principal) smí provést jakou akci (privilege — SELECT, MODIFY, CREATE TABLE…) na jakém objektu (securable). Securables tvoří hierarchii metastore → catalog → schema → tabulka/view a oprávnění se z vyšších úrovní dědí dolů.

Klíčové pravidlo, na kterém padá většina začátečníků: SELECT na tabulce sám o sobě nestačí. Principal potřebuje projít celou cestou — USE CATALOG na katalogu, USE SCHEMA na schématu a teprve pak SELECT na tabulce. Chybí-li kterýkoli článek, dotaz selže.

Granty se zadávají standardním ANSI SQL (DCL), z notebooku, SQL editoru nebo přes Permissions tab v Catalog Exploreru:

-- cesta k tabulce: catalog -> schema -> tabulka
GRANT USE CATALOG ON CATALOG prodej TO `analysts`;
GRANT USE SCHEMA ON SCHEMA prodej.finance TO `analysts`;
GRANT SELECT ON TABLE prodej.finance.objednavky TO `analysts`;

-- varianta s dedicnosti: SELECT na urovni schematu
GRANT SELECT ON SCHEMA prodej.finance TO `analysts`;

-- pravo vytvaret tabulky ve schematu
GRANT CREATE TABLE ON SCHEMA prodej.finance TO `analysts`;

-- odebrani opravneni
REVOKE SELECT ON TABLE prodej.finance.objednavky FROM `analysts`;

Kontrolu proveďte příkazem SHOW GRANTS:

SHOW GRANTS ON TABLE prodej.finance.objednavky;
SHOW GRANTS `analysts` ON SCHEMA prodej.finance;

Granty z předchozí sekce fungují na principu „celá tabulka, nebo nic". V praxi ale často potřebujete z jedné kanonické tabulky ukázat různým skupinám jen část řádků nebo maskované hodnoty sloupců — regionální data jen regionálním týmům, PII jen compliance týmu. Duplikovat tabulky pro každé publikum je cesta do pekla: kopie zastarávají, synchronizace stojí orchestraci a bezpečnostní pravidla se rozjíždějí.

Unity Catalog nabízí dva manuální přístupy k fine-grained access control:

Row a column security (row filtry + column masky) je preferovaný moderní přístup: pravidla jsou připojená k metadatům tabulky, platí všude, kde se tabulka použije, a nevzniká „zvěřinec" odvozených views. Dynamic views jsou starší vzor, který má stále smysl, když potřebujete složit data z více tabulek, vytvořit explicitní kontrakt mezi producentem a konzumentem, nebo konzumenty úplně odstínit od existence zdrojových tabulek.

Implementace je překvapivě jednoduchá: napíšete SQL UDF s rozhodovací logikou a připojíte ji k tabulce. Pro kontrolu členství ve skupině slouží funkce is_account_group_member().

-- maskovaci funkce pro telefonni cislo
CREATE OR REPLACE FUNCTION phone_mask(c_phone STRING)
  RETURN CASE WHEN is_account_group_member('metastore_admins')
    THEN c_phone
    ELSE 'REDACTED PHONE NUMBER'
  END;

ALTER TABLE customers
  ALTER COLUMN c_phone
  SET MASK phone_mask;

-- admin vidi vse, ostatni jen nationkey = 21
CREATE OR REPLACE FUNCTION nation_filter(c_nationkey INT)
  RETURN IF(is_account_group_member('admin'), true, c_nationkey = 21);

ALTER TABLE customers
SET ROW FILTER nation_filter ON (c_nationkey);

CREATE OR REPLACE VIEW vw_customers AS
SELECT
  c_custkey, c_name, c_nationkey,
  CASE WHEN is_account_group_member('admins') THEN c_phone
       ELSE 'REDACTED PHONE NUMBER' END AS c_phone
FROM customers_new
WHERE CASE WHEN is_account_group_member('admins') THEN TRUE
           ELSE c_nationkey = 21 END;

GRANT SELECT ON VIEW vw_customers TO `account users`;

Hesla, API klíče ani connection stringy nikdy nepatří do kódu notebooku. Azure Databricks je organizuje do secret scopes — pojmenovaných kolekcí secrets, na jejichž úrovni se řídí přístup. Existují dva typy:

Pro produkci v Azure je standardem Key Vault-backed scope: secrets žijí v Key Vaultu, zapadají do firemní security infrastruktury a po aktualizaci secretu jej všechny workspaces převezmou automaticky. dbutils.secrets.get() čte aktuální hodnotu při každém volání — po rotaci secretu tedy stačí kód spustit znovu. Restart clusteru potřebujete jen u secrets referencovaných ve Spark konfiguraci nebo v environment proměnných clusteru: ty se rozvinou při startu, a dokud cluster běží, drží starou hodnotu.

Scope se vytváří přes speciální URL https://<databricks-instance>#secrets/createScope (velké „S" je povinné — URL je case-sensitive). Budete potřebovat DNS Name a Resource ID Key Vaultu (najdete v Properties). Databricks si při vytvoření sám nastaví Get/List oprávnění na vault.

V notebooku pak secret čtete přes dbutils.secrets.get(), v SQL přes funkci secret():

# nacteni prihlasovacich udaju ze scope "jdbc"
username = dbutils.secrets.get(scope="jdbc", key="username")
password = dbutils.secrets.get(scope="jdbc", key="password")

df = (spark.read
  .format("jdbc")
  .option("url", "jdbc:sqlserver://server.database.windows.net:1433")
  .option("dbtable", "customers")
  .option("user", username)
  .option("password", password)
  .load()
)

# seznam klicu ve scope (bez hodnot)
dbutils.secrets.list("jdbc")

-- secret() v SQL; try_secret() vraci NULL misto chyby
SELECT secret('jdbc', 'username') AS db_username;

Výstupy notebooku hodnoty secrets automaticky nahrazují textem [REDACTED]. To ale chrání jen proti náhodnému úniku — kdokoli s právem spouštět kód na clusteru se k hodnotě programově dostane. Přístup proto řiďte ACL na scope (úrovně READ / WRITE / MANAGE) přes Databricks CLI:

# READ pro skupinu data-engineers na scope jdbc
databricks secrets put-acl jdbc data-engineers READ
databricks secrets list-acls jdbc

Service principal je identita pro aplikace a automatizaci — „uživatelský účet pro roboty". Joby a pipelines se s ním autentizují bez osobních přihlašovacích údajů, konzistentně napříč prostředími. Skládá se ze tří komponent: Application (client) ID, Directory (tenant) ID a client secret (heslo s expirací).

V Unity Catalogu se service principal typicky schová za storage credential: administrátor jej jednou zaregistruje a vy pak jen dotazujete tabulky — Unity Catalog za scénou převezme identitu, vyžádá si od Microsoft Entra ID dočasný token a předá jej compute. Do kódu se žádné credentials nedostanou a audit log zaznamená, kdo k čemu přistoupil.

Přímou konfiguraci v notebooku potkáte u storage, které v Unity Catalogu registrované není, nebo u legacy řešení — OAuth 2.0 client credentials flow přes Spark konfiguraci:

# client secret vzdy ze secret scope, nikdy natvrdo v kodu
service_credential = dbutils.secrets.get(scope="storage-secrets", key="sp-client-secret")

spark.conf.set("fs.azure.account.auth.type.<storage-account>.dfs.core.windows.net", "OAuth")
spark.conf.set("fs.azure.account.oauth.provider.type.<storage-account>.dfs.core.windows.net",
               "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider")
spark.conf.set("fs.azure.account.oauth2.client.id.<storage-account>.dfs.core.windows.net",
               "<application-id>")
spark.conf.set("fs.azure.account.oauth2.client.secret.<storage-account>.dfs.core.windows.net",
               service_credential)
spark.conf.set("fs.azure.account.oauth2.client.endpoint.<storage-account>.dfs.core.windows.net",
               "https://login.microsoftonline.com/<directory-id>/oauth2/token")

df = spark.read.parquet("abfss://<container>@<storage-account>.dfs.core.windows.net/path/to/data")

Managed identity je identita, jejíž životní cyklus spravuje Azure — žádný client secret, žádná expirace, žádná rotace. Unity Catalog ji používá prostřednictvím Azure Databricks access connectoru: first-party Azure resource, který funguje jako most mezi managed identitou a vaším Databricks accountem. Connector může nést buď system-assigned identitu (vzniká a zaniká s connectorem), nebo jednu či více user-assigned identit (existují nezávisle a lze je připojit k více connectorům).

Postup nasazení:

1) V Azure portálu vytvořte access connector (ideálně ve stejném regionu jako storage). 2) Managed identitě přidělte na ADLS Gen2 účtu roli Storage Blob Data Contributor; pro file event notifikace se hodí i Storage Queue Data Contributor. 3) V Catalog Exploreru vytvořte storage credential typu Azure Managed Identity s resource ID connectoru. 4) Nad credentialem definujte external locations — kombinace credentialu a konkrétní cesty abfss://, na kterou pak grantujete oprávnění.

-- external tabulka nad external location krytou managed identitou
CREATE TABLE prodej.bronze.sales_data
USING DELTA
LOCATION 'abfss://data@mystorageaccount.dfs.core.windows.net/sales/';

SELECT * FROM prodej.bronze.sales_data WHERE sale_date >= '2026-01-01';

Proč je to preferovaná cesta? Dokumentace shrnuje výhody proti service principalům: „They have the benefit of allowing Unity Catalog to access storage accounts protected by network rules, which isn't possible using service principals, and they remove the need to manage and rotate secrets." Jinými slovy — funguje i za firewallem storage účtu a nemá co expirovat.

Fiktivní řetězec supermarketů NorthMart Retail se čtyřmi regiony (North, South, East, West) potřebuje zabezpečit zákaznická a věrnostní data: v labu vytvoříte skupinu retail-analysts a schema-level granty, row filter omezující záznamy podle regionu, column masku pro PII e-maily a Key Vault-backed secret scope retail-kv-scope pro bezpečné čtení API klíče v notebooku.

▶ Otevřít lab na GitHubu (EN) · Learn modul k tématu — s krátkými výukovými videy