OneLake 中的捷徑作為指向存放於各種儲存帳號的資料，無論是在 OneLake 內部，還是外部系統如 Azure Data Lake Storage（ADLS）。 本文說明建立捷徑及使用捷徑存取資料所需的權限。
為了確保捷徑組成部分的清晰說明，本文使用以下術語：
- 目標路徑：捷徑指向的位置。
- 捷徑路徑：捷徑顯示的位置。
建立並刪除捷徑
要建立捷徑，你需要在建立捷徑的 Fabric 項目上取得 Write 權限。 此外，你還需要具備對捷徑所指向資料的讀取權限。 外部來源的捷徑可能需要外部系統中的特定權限。 什麼是捷徑？ 本文章具有捷徑類型與所需權限的完整列表。
| 功能 | 捷徑路徑的權限 | 目標路徑的權限 |
|---|---|---|
| 建立捷徑 | 項目寫入權限或 OneLake 安全性讀取/寫入 | OneLake 安全性讀取1 |
| 刪除捷徑 | 項目寫入權限或 OneLake 安全性讀取/寫入 | N/A |
1 對於尚未支援 OneLake 安全性的項目，此權限為項目 ReadAll 權限。
存取捷徑
捷徑路徑中的權限與目標路徑的組合會控制捷徑的權限。 當使用者存取捷徑時，會套用兩個位置中最嚴格的權限。 因此，在 Lakehouse 中具有讀寫權限、但在目標路徑中只有讀取權限的使用者，無法寫入目標路徑。 同樣地，即使使用者在 Lakehouse 中只有讀取權限，但對目標路徑具有讀寫權限，也無法寫入目標路徑。
下表顯示每個捷徑動作所需的權限。
| 功能 | 捷徑路徑的權限 | 目標路徑的權限 |
|---|---|---|
| 讀取快捷鍵的檔案或資料夾內容 | OneLake 安全性讀取1 | OneLake 安全性 參閱1, 2 |
| 寫入捷徑目標位置 | 項目寫入權限或 OneLake 安全性讀取/寫入 | 項目寫入權限或 OneLake 安全性讀取/寫入 |
1 對於尚未支援 OneLake 安全性的項目，此權限為項目 ReadAll 權限。
重要
2身分識別傳遞的例外狀況： 雖然 OneLake 安全性通常會透過呼叫使用者的身分識別來強制執行許可權，但某些查詢引擎的運作方式不同。 當透過 SQL 使用 DirectLake 或者透過配置為委派身份模式的 T-SQL 引擎來存取 Power BI 語意模型的捷徑資料時，這些引擎不會將呼叫使用者的身份傳遞給捷徑目標。 相反地，他們會使用 專案擁有者的身分識別 來存取資料，然後套用 OneLake 資訊安全角色來篩選呼叫使用者可以看到的內容。
此條件表示：
- 捷徑目標是使用項目擁有者的權限 （而不是一般使用者的權限） 來存取的
- OneLake 資訊安全角色仍會決定使用者可以讀取哪些資料
- 直接在捷徑目標路徑上為一般使用者設定的任何權限都會略過
OneLake 安全性
OneLake 安全性 讓您能對儲存在 OneLake 的資料套用基於角色的存取控制（RBAC）。 您可以定義資訊安全角色，以授與 Fabric 專案內特定資料表和資料夾的讀取存取權，並將它們指派給使用者或群組。 存取權限會決定使用者在 Fabric 的所有引擎中可執行哪些操作，確保存取控制的一致性。
OneLake 安全性角色不會限制在工作區中具有 Admin、Member 和 Contributor 角色的使用者對捷徑資料的存取。 這些使用者仍必須同時存取捷徑與目標路徑，如 工作區角色所述。 他們也必須擁有目標路徑的讀取權限，以建立或更新捷徑。
處於檢視者角色的使用者，或擁有 項目閱讀權限的使用者，皆由其 OneLake 安全角色決定存取權限。 為了執行捷徑操作，這些使用者除了 Fabric 讀取權限外，還需要相應的 OneLake 安全權限。
下表顯示每個捷徑操作所需的綜合權限：
| 捷徑操作 | 捷徑路徑的權限 | 目標路徑的權限 |
|---|---|---|
| 創造 | Fabric Read 與 OneLake 安全 ReadWrite 結合 | OneLake 安全檢閱 |
| 閱讀（GET/LIST 捷徑） | Fabric 讀取 加上 OneLake 安全性讀取 | N/A |
| Update | Fabric Read 與 OneLake 安全 ReadWrite 結合 | OneLake 安全閱讀（關於新目標） |
| 刪除 | Fabric Read 與 OneLake 安全 ReadWrite 結合 | N/A |
欲了解更多帶有捷徑的存取控制模型，請參閱 OneLake 中的資料存取控制模型。
捷徑認證模型
OneLake 捷徑使用兩種認證模式：通過式與委派式。 模型取決於捷徑的類型。
| 捷徑類型 | 驗證模型 | 詳細資料 |
|---|---|---|
| 同租戶 OneLake 對 OneLake | 傳遞或委派 | 直通是預設。 若要使用委派認證，請在建立捷徑時選擇委派身份。 |
| 跨租用戶 OneLake 到 OneLake | 僅限授權 | 在 建立跨租戶捷徑時，請在生產者的租戶中設定組織帳號或服務主體。 |
| 外部（多雲） | 僅限授權 | 使用者可以在不直接存取外部系統的情況下存取外部資料。 在捷徑上設定 OneLake 安全性，以控制外部系統中可存取的資料。 |
傳遞式驗證
在直通模型中，捷徑透過將使用者身份傳給目標系統，存取目標位置的資料。 任何存取捷徑的使用者只能看到他們在目標中能存取的資料。 來源系統保有對其資料的完全控制權，無需複製或重新定義存取控制。
委派驗證
在委派模型中，捷徑透過中介憑證存取資料，例如其他使用者的身份、服務主體或帳號金鑰。 委派捷徑允許權限管理分離或「委派」給其他團隊或下游使用者管理。 OneLake 中的所有委派快捷方式都可以為其定義 OneLake 安全性角色。
當預設的通過行為與你想要的資料存取模式不符時，請使用委派認證。 例如，委派捷徑可以使用固定的連線身份來代表一個事業單位，而不必要求每個下游使用者都能存取來源資料。 該事業單位能管理使用者的 OneLake 安全 存取，同時尊重對連線身份所適用的安全控制。
像 Amazon S3 或 Google Cloud Storage 這類外部系統的捷徑總是使用委派認證。 如果在建立捷徑時已設定委派驗證，指向 OneLake 內部目標的捷徑即可使用委派驗證。
委派的 OneLake 捷徑
委派 OneLake 捷徑使用設定的連線身份，而非登入使用者的身份。 當存取委派捷徑時，呼叫使用者會看到其安全措施與委派身份安全措施的交集。 下表列出範例情境。
對於同租戶的 OneLake 捷徑，委派認證是可選的。 如果您未選取此項目，捷徑會使用傳遞驗證。 跨租戶的 OneLake 捷徑總是使用委派認證。 被設定的連線身份需要存取目標資料。 若要在直通與委派驗證之間切換現有捷徑，請刪除並以所需的認證方式重建捷徑。
| 捷徑路徑的一般使用者權限 | 目標路徑許可（製作人） | 由此產生的存取 |
|---|---|---|
| 完整權限 | 完整權限 | 完整權限 |
| 完整權限 | CLS - 僅列 C1、C2 | CLS - 僅列 C1、C2 |
| CLS - 僅限 C1 欄 | CLS - 僅列 C1、C2 | CLS - 僅限 C1 欄 |
以下安全考量適用於委派捷徑：
- 如果生產者端也有 RLS，則使用者在消費者端只能屬於一個具有 CLS 的 OneLake 安全性角色。
- 欄位層級安全（CLS）支援委託捷徑的生產者與使用者。
- 列級安全性（RLS）支援用於委派捷徑的提供者端，但無法在取用者端設定。
- 除了 OneLake 對生產者路徑的安全存取外，透過 Spark 或直接 API 呼叫存取外部捷徑也需要對包含該外部捷徑的項目取得讀取權限。