OneLake 捷徑可作為存放在各種儲存帳戶中的資料指標，無論是 OneLake 本身或 Azure Data Lake Storage (ADLS) 等外部系統。 本文將介紹建立捷徑與使用它們存取資料所需的權限。
為了確保捷徑元件的清晰度，本文使用下列術語：
- 目標路徑：捷徑指向的位置。
- 捷徑路徑：捷徑顯示的位置。
建立並刪除捷徑
若要建立捷徑，使用者需要對建立捷徑的 Fabric 項目具有寫入權限。 此外，使用者需要對捷徑指向資料的讀取存取權。 外部來源的捷徑可能需要外部系統中的特定權限。 什麼是捷徑？ 本文章具有捷徑類型與所需權限的完整列表。
| 功能 | 捷徑路徑的權限 | 目標路徑的權限 |
|---|---|---|
| 建立捷徑 | 寫2 | ReadAll1 |
| 刪除捷徑 | 寫2 | N/A |
1 如果已啟用 OneLake 安全性 ，使用者必須處於授與目標路徑存取權的角色中。 2 如果已啟用 OneLake 資料存取角色 ，使用者必須處於授與目標路徑存取權的角色中。
存取捷徑
捷徑路徑中的權限與目標路徑的組合會控制捷徑的權限。 當使用者存取捷徑時，會套用兩個位置中最嚴格的權限。 因此，在 Lakehouse 中具有讀取/寫入權限，但僅在目標路徑中讀取權限的使用者無法寫入目標路徑。 同樣地，只有在 Lakehouse 中具有讀取權限，但在目標路徑中讀取/寫入的使用者也無法寫入目標路徑。
下表顯示每個捷徑動作所需的權限。
| 功能 | 捷徑路徑的權限 | 目標路徑的權限 |
|---|---|---|
| 讀取捷徑的文件/資料夾內容 | ReadAll1 | ReadAll1 |
| 寫入捷徑目標位置 | 寫2 | 寫2 |
| 透過 TDS 端點從 lakehouse 表格部分中的捷徑讀取資料 | 參閱 | 閱讀全部3 |
1 ：如果已啟用 OneLake 安全性 ，使用者必須處於授與目標路徑存取權的角色中。
2 或者，在 OneLake 中對捷徑路徑設置具有讀寫（ReadWrite）權限的安全性。
重要
3身份直通例外： 雖然 OneLake 的安全通常會通過呼叫使用者的身份來強制執行權限，但某些查詢引擎的運作方式不同。 當透過 SQL 使用 DirectLake 或者透過配置為委派身份模式的 T-SQL 引擎來存取 Power BI 語意模型的捷徑資料時，這些引擎不會將呼叫使用者的身份傳遞給捷徑目標。 相反地，他們會使用 專案擁有者的身分識別 來存取資料，然後套用 OneLake 資訊安全角色來篩選呼叫使用者可以看到的內容。
也就是說：
- 捷徑目標是使用項目擁有者的權限 （而不是一般使用者的權限） 來存取的
- OneLake 資訊安全角色仍會決定使用者可以讀取哪些資料
- 直接在捷徑目標路徑上為一般使用者設定的任何權限都會略過
OneLake 安全性
OneLake 安全性 （預覽） 是一項功能，可讓您將角色型存取控制 （RBAC） 套用至儲存在 OneLake 中的資料。 您可以定義資訊安全角色，以授與 Fabric 專案內特定資料表和資料夾的讀取存取權，並將它們指派給使用者或群組。 存取權限會決定使用者在 Fabric 中所有引擎中的內容，以確保一致的存取控制。
無論定義的 OneLake 資料存取角色為何，管理員、成員與參與者角色的使用者都可以從捷徑讀取資料的完整存取權限。 但是，他們仍然需要存取捷徑與目標路徑，如 Workspace 角色所述。
具有檢視器角色或直接與他們共用 lakehouse 的使用者，會根據使用者是否透過 OneLake 資料存取角色具有存取權限，限制存取權限制。 如需具有捷徑的存取控制模型的詳細資訊，請參閱 OneLake 的資料存取控制模型。
處於檢視器角色的使用者若擁有對捷徑建立路徑的 ReadWrite 權限，就能建立捷徑。
下表說明執行捷徑操作所需的權限。
| 捷徑操作 | 捷徑路徑的權限 | 目標路徑的權限 |
|---|---|---|
| 創造 | Fabric 讀取 與 OneLake 安全讀寫 | OneLake 安全檢閱 |
| 閱讀（GET/LIST 捷徑） | Fabric 讀取 與 OneLake 安全讀取 | N/A |
| Update | Fabric 讀取 與 OneLake 安全讀寫 | OneLake 安全閱讀（關於新目標） |
| 刪除 | Fabric 讀取以及OneLake 安全讀寫權限 | N/A |
捷徑驗證模型
快捷方式使用兩種具有 OneLake 安全性的身份驗證模型：直通和委派。
在直通模型中，捷徑透過將使用者的身分「傳遞」到目標系統來存取目標位置的資料。 這可確保任何存取捷徑的使用者只能在目標中看到他們有權存取的任何內容。
使用 OneLake 到 OneLake 的快捷方式，僅支援傳遞模式。 這種設計可確保來源系統保留對其資料的完全控制。 組織受益於增強的安全性，因為無需複製或重新定義快捷方式的存取控制。 不過，請務必瞭解 OneLake 快捷方式的安全性無法直接從下游專案修改。 存取權限的任何變更都必須在來源位置進行。
委派的快捷方式會使用某些中繼認證 （例如其他使用者或帳戶金鑰） 來存取資料。 這些捷徑允許將權限管理分開或「委派」給另一個團隊或下游使用者進行管理。 委派的快捷方式總是會中斷從一個系統到另一個系統的安全性流程。 OneLake 中的所有委派快捷方式都可以為其定義 OneLake 安全性角色。
從 OneLake 到外部系統 （多雲端捷徑） （例如 AWS S3 或 Google Cloud Storage ） 的所有捷徑都會委派。 這允許用戶連接到外部系統，而無需直接訪問。 然後可以在快捷方式上設定 OneLake 安全性，以限制可以存取外部系統中的哪些資料
OneLake 安全性限制
- 除了目標路徑的 OneLake 安全性存取之外，透過 Spark 或直接 API 呼叫存取外部捷徑也需要包含外部捷徑路徑之專案的讀取許可權。