Лучшие практики для секретов Unity Catalog

Организуйте секреты Unity Catalog так, чтобы каждое приложение могло получить доступ только к своим собственным секретам, большинство субъектов использовали секрет без считывания его значения, а вы управляли ключом, который шифрует значения. О том, как создавать, предоставлять доступ к секретам и читать их, см. Секреты в Unity Catalog.

Группируйте секреты по тому, кому они нужны

Создайте схему для каждого приложения, среды или команды и предоставляйте CREATE SECRET права на схему, а не на каталог. Схема содержит до 1 000 секретов, а метахранилище — до 10 000.

• Разрешение на один секрет: Разрешение на схему применяется ко всем секретам в ней, включая добавленные позже. Если субъекту безопасности нужен только один секрет, предоставьте READ SECRET для этого секрета, а не для схемы секрета.
• Дайте производственным секретам отдельный каталог, когда это необходимо: привязка рабочего пространства и ключи под управлением клиента применяются ко всему каталогу. Чтобы производственные секреты не попадали в рабочие пространства разработки или были зашифрованы собственным ключом, поместите их в отдельный каталог. См. Workspace-catalog binding и Шифрование секретов, управляемых Azure Databricks, с помощью собственного ключа.

Чтобы предоставить приложению заказов собственную схему базы данных и позволить задаче формирования отчетов читать только один из его секретов, выполните следующее:

-- 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`;

Для секретов, хранящихся в Azure Key Vault, используйте по одному Key Vault для каждой схемы с собственными учетными данными службы и подключением. Соединения Key Vault не поддерживают фильтры тегов, поэтому границей служит хранилище. Если в хранилище хранится более 1000 секретов, Unity Catalog импортирует сначала самые старые и пропускает остальные.

Не используйте для схемы один общий Key Vault, к которому могут обращаться многие приложения.

Управляйте разрешениями для поиска, ротации и чтения секретов по отдельности

Каждая из этих привилегий — отдельная привилегия, поэтому принципал, обновивший секрет или находивший его в Catalog Explorer, не должен видеть его значение:

Чтобы позволить принципалу	Грант	Возвращает значение
Найдите секреты и запросите доступ	BROWSE на каталоге. Он показывает метаданные каждого секрета, такие как имя, владелец и дата истечения срока действия.	No
Ротируйте секрет, обновляя его значение	WRITE SECRET	No
Считайте значение, например с помощью dbutils.secrets в задании	READ SECRET	Yes

Полный список привилегий см. в «Предоставление доступа к секретам».

Чтобы все могли найти секреты и запросить доступ, а ротационная задача могла обновить пароль хранилища без его прочтения, выполните следующее:

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 показывает комментарии всем, у кого есть доступ. Используйте комментарий к секрету, чтобы указать, кому он принадлежит и как запросить доступ. Никогда не указывайте значение или даже намек на него в комментариях.

Шифруйте секреты, управляемые Azure Databricks, с помощью собственного ключа

Настройки ключа, управляемого клиентом (CMK) в каталоге, применяются к каждому секрету, управляемому Azure Databricks в нём. Чтобы зашифровать производственные секреты отдельным ключом, поместите их в отдельный каталог. О том, как CMK применяется к секретам, см. Шифрование значений секрета с помощью ключей, управляемых клиентом.

Ротируйте секреты у источника

Для секретов, хранящихся в Azure Key Vault, выполняйте ротацию значений в Azure Key Vault, например с помощью политики ротации Key Vault. Не копируйте их значения в секреты, управляемые Azure Databricks, потому что каждая копия — это ещё одно значение для ротации.

Для секретов, управляемых Azure Databricks, обновите значение в Catalog Explorer или с помощью REST API. Установите дату истечения срока действия так, чтобы Catalog Explorer показывал предупреждение, когда срок действия секрета истечет.

Код, который уже содержит значение, сохраняет его, пока не прочитает секрет снова. В долгосрочных работах читайте секрет каждый раз при открытии соединения, а не только при запуске.

Пусть рабочие нагрузки используют секреты, не читая их

Большинство пользователей, полагающихся на секрет, никогда не должны видеть его значение. UDF из каталога Unity, который объявляет секрет, читает его с разрешениями владельца, поэтому вызывающим сторонам требуется только разрешение EXECUTE на UDF, например для маскирования или хеширования личных данных. В отличие от этого, любому, кто запускает SQL-функцию, вызывающую secret() для области секретов рабочего пространства, требуются READ для этой области, что раскрывает все секреты в ней. См. Использование секретов в UDF.

• Предоставляйте READ SECRET только субъектам-службам, которые запускают задания, владельцам UDF, которые объявляют секрет, и небольшой группе, владеющей секретами.
• Сделайте группу или субъект-службу владельцем каждого UDF, который объявляет секрет, чтобы UDF не завершалась с ошибкой, когда кто-то уходит.
• Используйте сессионные UDF только тогда, когда каждый, кто вызывает функцию, уже может прочитать секрет. Они читают секреты с правами вызывающего.

Предупреждение

Никогда не возвращайте секретное значение из UDF. Маскирование не мешает коду UDF возвращать значение в результатах запроса.

Сервис-провайдер модели также может использовать секрет Unity Catalog в качестве учетных данных провайдера, поэтому вызывающие стороны отправляют запросы к модели, не видя ключа. См. Как защитить учетные данные поставщика с помощью секрета Unity Catalog.

Контролируйте, кто может предоставлять доступ и проверять его

• Передайте владение секретами и их схемами группе, а не отдельному человеку.
• Администраторы Metastore и субъекты безопасности с MANAGE не могут прочитать значение, но могут предоставить себе READ SECRET. Оставьте MANAGE для небольшой группы.
• Просматривайте чтение секретов и выдачу прав в системной таблице system.access.audit. См. Аудит секретного доступа.

Дополнительные ресурсы

Resource	Description
Каталог Secrets in Unity	Создавайте, предоставляйте и читайте секреты Unity Catalog.
Управление секретами	Сравните секреты Unity Catalog с областями секретов рабочего пространства и посмотрите, где можно использовать каждый из них.