Najlepsze praktyki dotyczące sekretów Unity Catalog

Zorganizuj sekrety Unity Catalog tak, aby każda aplikacja mogła uzyskać dostęp tylko do swoich sekretów, większość podmiotów zabezpieczeń używała sekretu bez odczytywania jego wartości, a ty kontrolujesz klucz, który szyfruje te wartości. Aby dowiedzieć się, jak tworzyć, udzielać i odczytywać sekrety, zobacz Secrets in Unity Catalog.

Grupuj sekrety według tych, którzy ich potrzebują

Stwórz schemat dla każdej aplikacji, środowiska lub zespołu i przyznaj CREATE SECRET uprawnienia na schemacie zamiast na katalogu. Schemat zawiera do 1 000 wpisów tajnych, a metastore do 10 000.

• Nadanie uprawnienia do pojedynczego sekretu: Nadanie uprawnienia do schemy dotyczy każdego sekretu w niej zawartego, włącznie z sekretami dodanymi później. Gdy podmiot potrzebuje tylko jednego sekretu, przyznaj READ SECRET do tego sekretu zamiast do jego schematu.
• Nadaj sekretom produkcyjnym własny katalog, gdy tego potrzebujesz: Powiązanie obszaru roboczego i klucze zarządzane przez klienta dotyczą całego katalogu. Aby utrzymać sekrety produkcyjne z dala od przestrzeni roboczych lub zaszyfrować je własnym kluczem, umieść je w osobnym katalogu. Zobacz Workspace-catalog binding oraz Encrypt Azure Databricks-managed secrets with your own key.

Aby nadać aplikacji zamówień własny schemat i pozwolić zadaniu raportującemu odczytać tylko jeden ze swoich sekretów, wykonaj następujące czynności:

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

Dla sekretów wspieranych przez Azure Key Vault użyj jednego Key Vault dla każdego schematu, z własnym poświadczeniem serwisowym i połączeniem. Połączenia Key Vault nie obsługują filtrów tagów, więc magazyn jest granicą. Jeśli magazyn zawiera więcej niż 1000 sekretów, Unity Catalog najpierw importuje najstarsze i pomija pozostałe.

Nie zabezpieczaj schematu, do którego wiele aplikacji ma dostęp, za pomocą jednego współdzielonego magazynu Key Vault.

Zarządzaj uprawnieniami do odkrywania, rotacji i odczytu sekretów osobno

Każde z tych uprawnień jest odrębne, więc podmiot, który aktualizuje sekret lub znajduje go w Catalog Explorer, nie musi widzieć jego wartości:

Pełną listę przywilejów można znaleźć w artykule Przyznawanie dostępu do sekretów.

Aby wszyscy mogli znaleźć sekrety i poprosić o dostęp, a zadanie rotacyjne zaktualizowało hasło magazynu bez jego czytania, uruchom poniższe polecenie:

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 pokazuje komentarze wszystkim, którzy go mają. Użyj komentarza sekretu, aby powiedzieć, kto jest właścicielem i jak poprosić o dostęp. Nigdy nie umieszczaj wartości ani aluzji na jej temat w komentarzu.

Szyfruj sekrety zarządzane przez Azure Databricks własnym kluczem

Ustawienia klucza zarządzanego przez klienta (CMK) w katalogu dotyczą każdego sekretu zarządzanego przez Azure Databricks w katalogu. Aby szyfrować tajemnice produkcyjne osobnym kluczem, umieść je w osobnym katalogu. Aby dowiedzieć się, jak CMK odnosi się do wpisów tajnych, zobacz Szyfruj wartości wpisów tajnych za pomocą kluczy zarządzanych przez klienta.

Rotuj sekrety u źródła

Dla sekretów wspieranych przez Azure Key Vault, rotuj wartości w Azure Key Vault, na przykład za pomocą polityki rotacji Key Vault. Nie kopiuj ich wartości do sekretów zarządzanych przez Azure Databricks, ponieważ każda kopia to kolejna wartość do rotacji.

Dla sekretów zarządzanych przez Azure Databricks zaktualizuj wartość w Catalog Explorer lub za pomocą REST API. Ustaw datę ważności tak, aby Catalog Explorer wyświetlał ostrzeżenie o wygaśnięciu sekretu.

Kod programu, który już przechowuje wartość, przechowuje ją, dopóki ponownie nie odczyta sekretu. W długoterminowych zadaniach czytaj sekret za każdym razem, gdy otwierasz połączenie, a nie tylko przy starcie.

Pozwól obciążeniom korzystać z sekretów bez ich czytania

Większość użytkowników, którzy polegają na sekrecie, nigdy nie musi dostrzegać jego wartości. Funkcja UDF Unity Catalog, która deklaruje sekret, odczytuje go z uprawnieniami właściciela, więc wywołujący potrzebują jedynie uprawnienia EXECUTE do UDF, na przykład w celu maskowania lub haszowania danych osobowych. Dla porównania, każdy, kto uruchamia funkcję SQL, która wywołuje secret() w zakresie wpisów tajnych obszaru roboczego, musi mieć uprawnienie READ do tego zakresu, co ujawnia wszystkie zawarte w nim wpisy tajne. Zobacz Używanie sekretów w UDF-ach.

• Przyznajemy READ SECRET tylko nazwom głównym usługi, które uruchamiają zadania, właścicielom UDF, którzy deklarują klucz tajny, oraz małej grupie, która posiada te klucze tajne.
• Ustaw grupę lub jednostkę usługi jako właściciela każdego UDF, który deklaruje wpis tajny, aby UDF nie zawiódł, gdy ktoś odejdzie.
• Używaj UDF-ów ograniczonych do sesji tylko wtedy, gdy każdy wywołujący już może odczytać sekret. Czytają sekrety z uprawnieniami wywołującego.

Usługa dostawcy modelu może również używać sekretu Unity Catalog jako swojego poświadczenia dostawcy, dzięki czemu wywołujący mogą wysyłać zapytania do modelu bez widoczności klucza. Zobacz Jak zabezpieczyć poświadczenie dostawcy za pomocą wpisu tajnego w Unity Catalog.

Kontroluj, kto może przyznawać dostęp i audytować go

• Przypisz własność sekretów i ich schematów grupie, a nie jednostce.
• Administratorzy i principale w metastore nie mogą odczytać wartości MANAGE, ale mogą nadać sobie READ SECRET. Ogranicz MANAGE do małej grupy.
• Przeglądaj sekretne odczyty i uprawnienia w systemowej tabeli system.access.audit. Zobacz Audyt dostępu do wpisów tajnych.

Dodatkowe zasoby