Nejlepší postupy pro tajné klíče v Unity Catalogu

Organizujte tajné údaje Unity Catalog tak, aby každá aplikace mohla přistupovat pouze ke svým vlastním tajným údajům, většina principalů používá tajný údaj bez čtení jeho hodnoty a vy ovládáte klíč, který hodnoty šifruje. Pro informace o tom, jak vytvářet, udělovat a číst secrets, viz Secrets v katalogu Unity.

Seskupte tajemství podle toho, kdo je potřebuje

Vytvořte schéma pro každou aplikaci, prostředí nebo tým a udělujte na schéma oprávnění CREATE SECRET místo na katalog. Schéma uchovává až 1 000 tajných klíčů a metastore až 10 000.

• Oprávnění pro jeden secret: Oprávnění pro schéma se vztahuje na všechny secrety v něm, včetně secretů přidaných později. Když objekt zabezpečení potřebuje pouze jedno tajemství, udělte READ SECRET k tomuto tajemství místo k jeho schématu.
• Dopřejte produkčním tajným údajům vlastní katalog, když je to potřeba: Propojení s pracovním prostorem a klíče spravované zákazníky platí pro celý katalog. Aby se produkční tajemství nedostala do vývojových pracovních prostor, nebo aby byla šifrována vlastním klíčem, dejte je do samostatného katalogu. Viz Workspace-catalog binding a Encrypt Azure Databricks-managed secrets with your own key.

Aby aplikace orders měla vlastní schéma a aby reportovací úloha četla pouze jedno ze svých tajemství, spusťte následující:

-- The application's service principal reads every secret in its schema
CREATE SCHEMA main.orders_app;
GRANT USE CATALOG ON CATALOG main TO `orders-service-principal`;
GRANT USE SCHEMA, READ SECRET ON SCHEMA main.orders_app TO `orders-service-principal`;

-- The reporting job reads only the warehouse password
GRANT USE CATALOG ON CATALOG main TO `reporting-service-principal`;
GRANT USE SCHEMA ON SCHEMA main.orders_app TO `reporting-service-principal`;
GRANT READ SECRET ON SECRET main.orders_app.warehouse_password TO `reporting-service-principal`;

Pro tajemství krytá službou Azure Key Vault použijte jeden Key Vault pro každé schéma s vlastními přihlašovacími údaji služby a připojením. Připojení Key Vault nepodporují filtry značek, takže trezor představuje hranici. Pokud trezor obsahuje více než 1 000 tajných klíčů, Unity Catalog nejprve importuje nejstarší a zbytek přeskočí.

Nepoužívejte pro schéma, ke kterému má přístup mnoho aplikací, jedno sdílené úložiště Key Vault.

Spravovat oprávnění k objevování, rotaci a čtení tajných údajů samostatně

Každé z těchto oprávnění je samostatné, takže principál, který aktualizuje tajný klíč nebo ho najde v Catalog Exploreru, nemusí vidět jeho hodnotu:

Nechat principála	Grant	Vrátí hodnotu
Najdi tajemství a požádej o přístup	BROWSE v katalogu. Zobrazuje metadata každého tajemství, jako je jeho jméno, vlastník a datum expirace.	No
Obměňte secret aktualizací jeho hodnoty	WRITE SECRET	No
Přečtěte si hodnotu, například v úloze dbutils.secrets	READ SECRET	Yes

Pro úplný seznam privilegií viz Udělit přístup k tajným klíčům.

Aby všichni mohli najít tajemství a požádat o přístup, a aby rotační úloha mohla aktualizovat heslo datového skladu bez jeho přečtení, spusťte následující:

GRANT BROWSE ON CATALOG main TO `account users`;

GRANT USE CATALOG ON CATALOG main TO `rotation-service-principal`;
GRANT USE SCHEMA ON SCHEMA main.orders_app TO `rotation-service-principal`;
GRANT WRITE SECRET ON SECRET main.orders_app.warehouse_password TO `rotation-service-principal`;

BROWSE ukazuje komentáře všem, kdo ho mají. Použijte komentář u tajemství k označení, kdo ho vlastní a jak požádat o přístup. Nikdy v komentáři nedávejte hodnotu ani narážku na nějakou hodnotu.

Šifrujte tajné klíče spravované službou Azure Databricks vlastním klíčem

Nastavení klíčů spravovaných zákazníkem (CMK) v katalogu platí pro každý secret spravovaný službou Azure Databricks v něm. Pro šifrování produkčních tajemství pomocí samostatného klíče je vložte do vlastního repozitáře. O tom, jak se CMK vztahuje na tajné údaje, viz Šifrování hodnot tajných údajů pomocí klíčů spravovaných zákazníkem.

Otáčejte tajné klíče u zdroje

U tajných kódů uložených v Azure Key Vault obměňujte hodnoty, například pomocí zásad obměny Key Vault. Nekopírujte jejich hodnoty do secrets spravovaných službou Azure Databricks, protože každá kopie je další hodnota, kterou je potřeba rotovat.

Pro Azure Databricks-managed secrets aktualizujte hodnotu v Catalog Explorer nebo pomocí REST API. Nastavte datum expirace tak, aby Catalog Explorer zobrazoval varování, když tajný klíč vyprší.

Kód, který už hodnotu drží, ji uchovává, dokud secret znovu nečte. U dlouhodobých úloh načtěte tajný klíč pokaždé, když otevřete spojení, ne jen při startu.

Nechte úlohy používat tajné údaje bez jejich čtení

Většina uživatelů, kteří spoléhají na secret, nikdy nemusí vidět jeho hodnotu. UDF Unity Catalog, který deklaruje tajný klíč, jej čte s oprávněními jeho vlastníka, takže volající potřebují pouze EXECUTE na UDF, například k maskování nebo hashování osobních údajů. Naproti tomu kdokoli, kdo spustí SQL funkci, která volá secret() v rozsahu tajných klíčů pracovního prostoru, potřebuje READ pro tento rozsah, což odhalí všechny tajné klíče v něm. Viz Použití secrets v UDF.

• Udělujte READ SECRET pouze instančním objektům služby, které spouštějí úlohy, vlastníkům UDF, kteří deklarují tajný klíč, a malé skupině, která vlastní tajné klíče.
• Udělejte skupinu nebo instanční objekt služby vlastníkem každého UDF, který deklaruje tajný klíč, aby UDF neselhal, když někdo odejde.
• Používejte UDF s rozsahem relace pouze tehdy, když už každý volající může tajný klíč přečíst. Tyto objekty čtou tajemství s oprávněními volajícího.

Warning

Nikdy nevracejte tajnou hodnotu z UDF. Maskování dat nebrání kódu UDF vracet hodnotu ve výsledcích dotazů.

Služba poskytovatele modelu může také použít tajné informace Unity Catalog jako přihlašovací údaje poskytovatele, takže volající se dotazují na model, aniž by viděli klíč. Viz Zabezpečení přihlašovacího údaje poskytovatele pomocí tajného klíče Unity Catalog.

Určete, kdo může udělovat přístup, a provádějte jeho audit

• Přidělte vlastnictví tajných klíčů a jejich schémat skupině místo jednotlivci.
• Správci metastore a principalové s MANAGE nemohou číst hodnotu, ale mohou si sami udělit READ SECRET. Omezte MANAGE na malou skupinu.
• Prohlédněte si tajná oprávnění ke čtení a udělování v systémové tabulce system.access.audit. Viz Audit přístupu k tajným klíčům.

Další prostředky

Resource	Description
Katalog Tajemství v Unity	Vytvářejte, udělujte a čtěte tajné klíče Unity Catalog.
Správa tajemství	Porovnejte tajné klíče v Unity Catalog s oblastmi tajných klíčů v pracovním prostoru a zjistěte, kde můžete jednotlivé z nich použít.