整理 Unity Catalog 的密碼，讓每個應用程式只能存取自己的密碼，大多數主體身分使用密碼時不會讀取其值，而你則控制加密這些值的金鑰。 關於如何建立、授予及讀取祕密，請參見 Unity Catalog 中的祕密。
依需要者將秘密分組
為每個應用程式、環境或團隊建立一個綱要，並在綱要上賦予 CREATE SECRET 權限，而不是在目錄上賦予權限。 一個結構描述可容納最多 1,000 個密鑰，而一個元儲存庫則可容納多達 10,000 個密鑰。
- 對單一密鑰的授權：對結構描述的授權適用於其中的每個密鑰，包括後續加入的密鑰。 當主體只需要一個秘密時，應在該秘密上授予
READ SECRET，而非其結構描述。 - 在需要時，為正式環境的秘密建立專屬目錄：Workspace 綁定和客戶管理的金鑰套用到整個目錄。 為了讓生產機密不進入開發工作區，或用自己的金鑰加密它們，就把它們放在獨立的目錄集中。 請參閱 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 支援的祕密，每個結構描述都使用一個 金鑰保存庫，並有自己的服務憑證和連線。 金鑰保存庫 連線不支援標籤篩選器，因此 金鑰保存庫 就是邊界。 如果一個保存庫包含超過 1,000 個密鑰，Unity Catalog 會先匯入最舊的，並跳過其他。
不要用一個共用的 金鑰保存庫 來支援一個多個應用程式都能存取的結構描述。
分別管理探索、輪替及讀取密鑰的權限
這些都是獨立的權限，因此主體若更新密鑰或在 Catalog Explorer 中找到密鑰，則不需要看到其值：
| 讓主體能夠 | 獎助金 | 回傳該值 |
|---|---|---|
| 尋找機密並申請存取權限 |
BROWSE
它會顯示每個秘密的元資料，例如名稱、擁有者和到期日。 |
No |
| 透過更新祕密值來輪替祕密 | WRITE SECRET |
No |
讀取值，例如在某個作業中dbutils.secrets |
READ SECRET |
Yes |
完整權限列表請參見 「授予 Secrets 存取權限」。
為了讓每個人都能找到密密並請求存取，並且輪替工作能在不讀取資料倉儲密碼的情況下更新資料倉儲密碼，請執行以下操作：
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 會向所有擁有它的人顯示註解。 使用 Secret 的註解來說明誰擁有它以及如何申請存取權限。 絕不要在註解中透露值或任何相關暗示。
使用您自己的金鑰加密由 Azure Databricks 管理的祕密##
目錄上的 Customer-managed key （CMK） 設定會套用到其中每個 Azure Databricks 管理的祕密。 若要用獨立金鑰加密生產機密，請將它們放在獨立的型錄中。 關於 CMK 如何應用於密碼，請參見 「以客戶管理的金鑰加密密碼值」。
在源頭輪替密鑰
對於由 Azure Key Vault 支援的祕密，請在 Azure Key Vault 中輪替值，例如使用 金鑰保存庫 輪替原則。 不要把它們的值複製到 Azure Databricks 管理的祕密裡，因為每次複製都會多出另一個需要輪替的值。
對於 Azure Databricks 管理的祕密，請在 Catalog Explorer 或使用 REST API 更新該值。 設定一個過期日期，讓 Catalog Explorer 在秘密到期時顯示警告。
已經持有某個值的程式碼會保留該值，直到再次讀取祕密。 在長時間執行的工作中，每次開啟連線時都要讀取機密，而不是只在啟動時。
讓工作負載使用秘密資料而不讀取它們
大多數依賴 Secret 的使用者根本不需要查看其值。 宣告秘密的 Unity Catalog UDF 會以其擁有者的權限讀取該秘密，因此呼叫者只需要有 UDF 的 EXECUTE，例如用來遮蔽或雜湊個人資料。 相較之下，任何執行呼叫 secret() 且該呼叫作用於工作空間秘密範圍的 SQL 函式時，都需要對該範圍具有 READ，因為這會暴露其中的所有秘密。 參見 在 UDF 中使用 Secrets。
- 僅授予給執行工作的服務主體、宣告秘密的 UDF 擁有者，以及擁有秘密的小型團體。
- 讓一個群組或服務主體成為每個宣告秘密的 UDF 的擁有者，這樣當有人離開時，UDF 就不會失敗。
- 只有在每個呼叫者都能讀取秘密時，才使用會話範圍的 UDF。 他們以呼叫者的權限讀取機密資料。
Warning
絕不要回傳 UDF 的機密值。 遮罩並不會阻止 UDF 程式碼在查詢結果中回傳某個值。
模型提供者服務也可以使用 Unity Catalog 密鑰作為提供者憑證，因此呼叫者在不看到金鑰的情況下查詢模型。 請參閱使用 Unity Catalog 密鑰支援提供者認證。
控制誰可以授予存取權，並加以稽核
- 將秘密及其結構描述的所有權指派給群組，而非個人。
- Metastore 管理員和具有
MANAGE的主體無法讀取數值，但他們可以自行授與READ SECRET。 將MANAGE限制在小範圍內。 - 在
system.access.audit系統表中檢視秘密讀取與授權。 請參見 稽核 Secret 存取權限。
其他資源
| 資源 | Description |
|---|---|
| Unity 目錄中的秘密 | 建立、授予並讀取 Unity Catalog 的祕密。 |
| 秘密管理 | 比較 Unity Catalog 的密鑰與工作空間的密鑰範圍，看看你可以在哪裡使用兩者各自。 |