OneLake 安全是一個基於角色的系統，決定誰可以存取 OneLake 的資料，以及他們可以對這些資料採取哪些行動。 了解資料存取控制模型，能幫助你只授權使用者所需的存取權限，這樣你就能保護敏感資料，同時讓合適的人能處理。
本文說明 OneLake 安全角色的結構、它們如何與工作區及項目權限整合、OneLake 如何應用並解析你資料的存取權限，以及需要注意的限制。
OneLake 安全性角色
OneLake 安全採用基於角色的存取控制（RBAC）模型來管理 OneLake 中的資料存取。 在 OneLake 的安全經驗中，每個角色包含以下組成部分：
- 權限： 角色對資料授與的權限，例如讀取或讀寫。
- 類型： 角色類型。 OneLake 安全性僅支援 Grant 角色，該角色會授予成員存取角色內資料的權限。 它不支援用來移除存取權的 Deny 角色。
- 角色中的資料： 角色授權存取的資料表、資料夾或結構。 你也可以在資料表上定義以列級和欄級安全性來定義資料存取。
- 角色成員：指派給該角色的 Microsoft Entra 身份，例如使用者、群組或非使用者身份。 如果你指派一個 Microsoft Entra 群組，OneLake 安全系統會將該角色授予該群組的所有成員。
OneLake 的安全採用預設拒絕模式，因此使用者一開始無法存取資料，除非 OneLake 的安全角色明確授權存取權限。 部分 Fabric 項目以預設角色開始，根據使用者的工作區權限提供基本存取權限。
權限和支援的項目
OneLake 的安全角色支援以下權限：
-
讀： 授與使用者從表格讀取資料以及檢視相關聯的資料表和資料行中繼資料的能力。 就 SQL 術語而言，這個權限等同於
VIEW_DEFINITION和SELECT兩者。 欲了解更多資訊，請參閱 元資料安全性。 -
讀寫： 賦予使用者讀取與寫入資料表或資料夾資料的能力，並查看相關的資料表與欄位中繼資料。 用 SQL 術語來說，此權限等同於
ALTER、DROP、UPDATEINSERT和 。 欲了解更多資訊，請參閱 ReadWrite 權限。
你可以為以下 Fabric 項目建立 OneLake 安全角色：
| 布料項目 | 支援的權限 |
|---|---|
| Lakehouse | 讀取、讀取寫入 |
| Azure Databricks 鏡像目錄 | 參閱 |
| 鏡像資料庫 | 參閱 |
| 鏡像目錄 | 參閱 |
讀寫權限
使用 ReadWrite 權限，讓只讀使用者對項目中特定資料的寫入權限。
ReadWrite 僅適用於對某個項目具有讀取權限的使用者，例如具有工作區檢視者角色的使用者。 將 ReadWrite 指派給工作區管理員、成員或貢獻者不會有影響，因為這些工作區角色已經擁有寫入權限。
ReadWrite 包含所有由讀取權限賦予的權限，並且還能授權寫入對所選物件及其內容的存取權限。 例如，對資料夾的 ReadWrite 權限會同時授予該資料夾及其資料的寫入權限。
擁有 ReadWrite 權限的使用者可執行以下操作：
- 建立、刪除或重新命名資料夾或資料表。
- 上傳或編輯檔案。
- 建立、刪除或重新命名捷徑。
使用者可透過 Spark 筆記本、OneLake 檔案總管或 OneLake API 執行寫入操作。 由於 Fabric 僅支援單一引擎寫入資料，擁有 ReadWrite 權限的使用者只能透過 OneLake 寫入該資料。 所有查詢引擎持續一致執行讀取操作。
授予 ReadWrite 權限的 OneLake 安全角色不得包含列級安全（RLS）或欄位級安全（CLS）約束。
OneLake 安全性和工作區許可權
在 OneLake 中，工作區角色是資料的第一道安全邊界。 他們管理控制平面——建立並管理 Fabric 項目及權限——並套用到工作空間中的所有項目。 如需了解各工作區角色所授與的特定 OneLake 權限，請參閱 使用工作區角色授與存取權。 想了解更多關於工作區角色的資訊，請參閱 Fabric 中的工作區角色。
除了控制平面的存取權限外，工作區角色也可以透過 OneLake 的安全性預設角色，取得資料項目的存取權限。 （預設角色僅適用於檢視者，因為管理員、成員和貢獻者角色透過寫入權限擁有提升權限。）預設角色是 OneLake 的一般安全角色，Fabric 會隨著每個新項目自動建立。 它會為具有特定工作區或項目權限的使用者提供該項目中資料的預設存取層級。 例如，湖屋項目有一個 DefaultReader 角色，讓擁有 ReadAll 權限的使用者能看到湖屋內的資料。 此預設存取權確保使用新建立物品的使用者擁有基本的存取權限。 所有預設角色都使用成員虛擬化功能，因此該角色的成員即為該工作空間中擁有所需權限的使用者。 例如，所有對 Lakehouse 具有 ReadAll 權限的使用者。
下表顯示標準預設角色。 物品可能有專門的預設角色，只適用於該物品類型。
| 布料項目 | 角色名稱 | 已獲得許可 | 已指派成員 |
|---|---|---|---|
| Lakehouse | DefaultReader |
參閱 | 具 ReadAll 權限的所有使用者 |
| Azure Databricks 鏡像目錄 | DefaultReader |
參閱 | 擁有閱讀權限的所有使用者 |
| 鏡像目錄 | DefaultReader |
參閱 | 擁有閱讀權限的所有使用者 |
| 鏡像資料庫 | DefaultReader |
參閱 | 具 ReadAll 權限的所有使用者 |
你可以修改或移除 Fabric 項目中的預設角色，以更改該成員群組使用者的存取權限。
引擎和使用者對資料的存取權
OneLake 的安全預設是最低權限存取。 部分儲存層級操作無法強制執行 RLS 或 CLS，因此當查詢無法安全過濾時，OneLake 會完全封鎖查詢，以避免暴露使用者無法看到的資料。 查詢是否被過濾或阻擋，取決於存取路徑——是支援的查詢引擎或直接使用者存取。
關於支援 RLS 與 CLS 篩選的引擎及其各自需求，請參閱 讀取受 OneLake 安全性保護的資料。
範圍與執法
本節提供 OneLake 資訊安全角色如何授與特定範圍的存取權、該存取權的運作方式，以及如何跨多個角色和存取類型解析存取權的詳細資料。
資料表層級安全性
OneLake 將所有資料表都視為資料夾，但從 Fabric 中 OneLake 的安全性與查詢引擎來看，並非所有資料夾都是資料表。 要成為有效的資料表，資料夾必須符合以下條件：
- 該資料夾存在於項目的
Tables/目錄中。 對於啟用結構的項目，該資料夾也必須同時位於有效的結構資料夾中。 - 該資料夾包含
_delta_log一個資料夾，並包含對應的 JSON 檔案，用於表中繼資料。 - 這個資料夾裡沒有子快捷鍵。
如果你在資料表上設定 RLS 或 CLS，當資料表資料夾不符合這些條件時，OneLake 會拒絕存取。 若沒有 RLS 或 CLS，OneLake 會將不符合這些條件的資料夾視為資料夾，並套用資料夾層級的安全。
列層級和行層級安全性
在角色內，你可以透過使用列級安全性和欄級安全性來限制對特定資料表的列與欄存取。 欲了解更多關於每個控制項的功能及 OneLake 如何強制執行，請參閱 OneLake 中的表格、欄位及列級安全性。 關於 RLS 與 CLS 如何解決使用者屬於多個角色的資訊，請參閱 評估多個 OneLake 安全角色。
中繼資料安全性
OneLake 安全性中的讀取權限設定允許完全存取資料表中的資料與元資料。 對於無法存取資料表的使用者，資料永遠不會被揭露。 此規則也適用於欄位層級安全性，以及使用者是否看得到該資料表中的某個欄位。 然而，OneLake 的安全並不保證資料表的元資料無法存取。 某些錯誤訊息和體驗可能會顯示欄位名稱。
資料夾權限繼承與遍歷
資料夾權限會從兩個方向影響階層結構：
- 繼承： 資料夾所授予的權限會向下延伸至其檔案及子資料夾。
- 遍歷與列出： 當使用者對子項目有權限時，OneLake 安全系統允許他們列出並遍歷其父資料夾，以便他們能發現並導航到可存取的資料。 遍歷不會授權存取姊妹檔案或資料夾。
請考慮 OneLake 中湖屋的以下階層結構：
Tables/
──── (empty folder)
Files/
────folder1
│ │ file11.txt
│ │
│ └───subfolder11
│ │ file111.txt
│ │
│ └───subfolder111
│ │ file1111.txt
│
└───folder2
│ file21.txt
你建立一個角色 Role1，在 subfolder11 上賦予 Read 權限。 透過繼承，該角色的成員可以讀取 file111.txt 以及 subfolder111 中的所有內容。 成員可以檢視並穿過 folder1 以到達 subfolder11，但他們看不到 file11.txt，因為它是 subfolder11 的同層節點；而且他們也看不到 Tables，因為它是 Files 的同層節點。
Files/
│
└───folder1
│ │
│ └───subfolder11 <-- READ
│ │ file111.txt
│ │
│ └───subfolder111
│ │ file1111.txt
你建立另一個角色 Role2，授與對 的 folder2 權限。 透過繼承，成員可以讀取 file21.txt。 成員可經由 folder2 和 Files 到達該處，但他們無法看見 folder1 或其任何子項目。
Files/
│
└───folder2 <-- READ
│ file21.txt
至於捷徑，其行為略有不同。 指向外部資料來源的捷徑行為與資料夾相同。 然而，前往其他 OneLake 位置的捷徑則具有特殊行為。 捷徑的目標權限會決定對 OneLake 捷徑的存取權。 在列出捷徑時，OneLake 不會呼叫檢查目標存取權限。 因此，當你列出目錄時，OneLake 會回傳所有內部捷徑，不論你是否能存取該目標。 當你嘗試開啟捷徑時，存取檢查會評估，然後你只會看到你有權限查看的資料。
捷徑
OneLake 的安全整合了捷徑，以保護 OneLake 內外的資料安全。 捷徑使用兩種認證模式之一：
- 直通： 捷徑利用查詢使用者的身份來存取目標。 OneLake 到 OneLake 的捷徑預設為直通模式。
- 委派： 捷徑使用已設定的連線身份或憑證來存取目標。 OneLake 到 OneLake 的捷徑可以使用委派驗證，而通往外部系統的捷徑一律使用委派驗證。
建立捷徑需要對建立捷徑的路徑和目標路徑都有權限。 關於建立及存取每種捷徑類型的需求，請參見 OneLake 捷徑安全性。
直通捷徑中的 OneLake 安全性
當使用者透過 OneLake 對 OneLake 的直通捷徑存取資料時，OneLake 會利用呼叫使用者的身份授權存取目標路徑。 使用者的有效存取權限受限於捷徑與目標路徑的權限。
備註
查詢引擎身份與捷徑認證是不同的設定。 直通捷徑通常使用呼叫使用者的身份來存取目標。 然而，使用 Direct Lake over SQL 的 Power BI 語意模型，以及處於委派身分模式的 SQL 分析端點，會使用取用者項目或資料來源的擁有者身分。 這種行為不會改變捷徑設定的認證模式。 端對端使用者身份直通時，可使用 Direct Lake 而非 OneLake，或設定 SQL 分析端點使用使用者身份存取模式。
您無法直接在 OneLake 到 OneLake 的捷徑上定義 OneLake 的安全性權限。 包含捷徑資料夾的權限會與目標路徑的權限合併。 若目標項目支援 OneLake 安全，使用者需透過 OneLake 安全角色存取。 如果目標項目不支援 OneLake 安全，使用者需要對目標項目取得 Fabric ReadAll 權限。 使用者不需要對目標項目取得 Fabric Read 權限，就能透過捷徑存取其資料。
委派快捷方式中的 OneLake 安全性
委派捷徑使用已設定的連線身份或憑證，而非呼叫使用者的身份來存取目標。 OneLake 的安全限制了來電使用者透過該連線可存取的內容。
委派的 OneLake 捷徑
對於委派的 OneLake 到 OneLake 捷徑，發出呼叫的使用者只能看到其在捷徑路徑上的存取權，與已設定的連線身分識別在目標路徑上的存取權兩者的交集。 兩條路徑均支援欄位層級安全（CLS）。 目標路徑支援列級安全（RLS），但你無法在捷徑上定義 RLS。
委派的外部快捷方式
通往外部系統的捷徑，如 ADLS、Amazon S3 和 Dataverse，則使用已設定的連線憑證來存取外部來源。 OneLake 的安全措施會套用在該憑證所授予的存取權限之上。
例如，假設 user1 建立了一個 lakehouse 捷徑，指向 Amazon S3 儲存桶中的某個資料夾，而 user2 透過 lakehouse 存取該捷徑。 User2 只有在設定的 S3 連線憑證能存取來源且 OneLake 安全授權 user2 存取捷徑時，才能存取 S3 資料。
你可以授權 OneLake 對整個外部捷徑或選定子路徑的安全存取權。 資料夾的權限會遞迴繼承到所有子資料夾，包括捷徑內的資料夾。 使用者若透過另一個 OneLake 捷徑進入外部捷徑，仍須獲得原本外部捷徑所適用的 OneLake 安全機制授權。
透過 Spark 或直接呼叫 OneLake API 存取外部捷徑，也需要對包含該外部捷徑的項目進行 Fabric Read 權限。 此權限是安全解決與外部系統連線的必要條件。
評估多個 OneLake 安全角色
使用者可以同時屬於多個 OneLake 安全角色。 OneLake 將這些角色所授予的存取權合併成一個 有效角色，決定使用者可存取的資料。 OneLake 分階段評估有效角色。
在每個角色內解決存取權
OneLake 會先個別解析每個角色。 在角色內，使用者只能存取三個安全元件所允許的資料：
- 物件層級安全性（OLS）決定角色可存取哪些資料表或資料夾。
- 資料列層級安全性（RLS）會限制角色可存取特定資料表中的哪些資料列。
- 欄位層級安全性（CLS）限制角色能存取給定資料表的欄位。
由於三個成分都適用，OneLake 採用了它們的交叉點。 例如，若 Role1 授權存取 Table1 並限制其列與欄，則 Role1 的解析存取權限為：
Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS
交叉符號（∩）表示使用者僅接收該角色中 OLS、RLS 和 CLS 允許的存取權限。
跨職務合併存取權限
在解析完每個角色後，OneLake 會使用聯集（亦即限制最少）的模型來合併這些角色。 聯合符號（∪）表示任何角色所授予的存取權成為有效角色的一部分。 如果 Role1 授權存取 TableA，而 Role2 授權存取 TableB，則同時屬於兩個角色的使用者可以存取這兩個資料表。
若有兩個角色，生效角色為：
Effective role = Role1 ∪ Role2
當多個角色同時授權存取同一資料表時，列級安全規則會與一個 OR 操作員結合。 例如，允許 city = 'Redmond' 和 city = 'New York' 的謂詞會組合為 city = 'Redmond' OR city = 'New York'。
欄位層級的安全規則也會合併成聯合體，但 SQL 分析端點除外。 在 SQL 分析端點中，CLS 採用更嚴格的 deny 語意。 如果任何角色隱藏了某欄，端點就會阻擋該欄的存取。 因此，端點會與所有使用者角色的 CLS 允許清單相交，而非將它們合併成聯合體。
重要
將必須一併套用的 RLS 和 CLS 規則保留在同一角色中。 OneLake 不支援角色組合，即兩個角色允許同一資料表有不同的欄位，且任一角色都會對該資料表套用 RLS。 例如，使用者不能屬於 Role1，允許欄位 c1 和 c2 及部分列，也不能屬於 Role2，允許欄位 c2 和 c3。
結合捷徑與目標存取
針對捷徑，OneLake 會分別評估捷徑位置與捷徑目標處的角色。 目標角色會在捷徑所在位置成為推論角色。 OneLake 接著會將捷徑角色的合併存取與推斷目標角色的合併存取相交。 此步驟防止捷徑位置繼承的存取權限覆蓋目標的限制。
對於兩個捷徑角色和兩個推斷目標角色，有效存取為：
Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)
在此表達式中， ShortcutRole1 和 ShortcutRole2 是捷徑位置上的角色。
InferredRole1 和 InferredRole2 是從捷徑目標推斷出來的對應角色。 在 OneLake 合併這些角色之前，系統會先根據每個角色的 OLS、RLS 與 CLS 元件進行解析。
OneLake 安全性限制
如果您將 OneLake 安全性角色指派給 B2B 來賓使用者，則必須在 Microsoft Entra 外部 ID 中配置 B2B 外部協作設定。 將 訪客使用者存取 設定設為 訪客用戶擁有與會員相同的存取權限（最包容）。
如果你在 OneLake 安全中的角色新增一個分發清單，SQL 分析端點無法解析清單中的成員來強制存取。 因此，使用者在存取 SQL 分析端點時，似乎並非該角色的成員。 Direct Lake 在 SQL 語意模型上也受此限制。
Spark 筆記本需要 3.5 或更新版本的環境，且使用 Fabric 執行階段 1.3。
非結構湖屋不支援 RLS 和 CLS 安全資料表的資料預覽。 使用支援結構描述並採用 OneLake 安全性的湖屋。
OneLake 安全性無法在 Azure Data Share 或 Purview Data Share 上運作。 欲了解更多資訊，請參閱 Azure 資料分享。
下表列出 OneLake 安全角色的限制。
情境 限制 每個 Fabric 項目的 OneLake 安全性角色數量上限 每個項目 250 個角色（請參閱註解） 每個 OneLake 安全性角色的成員數量上限 每個角色 500 個使用者或使用者群組 每個 OneLake 安全性角色的權限數量上限 每個角色 500 個權限 備註
你可以申請將每個項目的角色數量上限提高到 1,000。 如需申請加薪，請聯絡Azure Support。
潛伏期
角色定義的變更需要約 5 分鐘才能套用。
若您變更 OneLake 安全性角色的使用者群組，OneLake 約需要一小時才能將角色權限套用至更新的使用者群組。 某些 Fabric 引擎有自己的快取層，因此可能需要額外的一小時來更新所有系統中的存取權。