OneLake 安全性存取控制模型 （預覽版）

本文件提供 OneLake 安全性存取控制模型運作方式的詳細指南。 它包含角色結構方式、角色如何套用至資料，以及與 Microsoft Fabric 內其他結構的整合的詳細數據。

OneLake 資訊穩定角色

OneLake 安全性會使用角色型存取控制 （RBAC） 模型來管理 OneLake 中資料的存取。 每個角色都由幾個關鍵組成部分組成。

• 型： 角色是否提供存取權 （GRANT） 或移除存取權 （DENY）。 僅支援 GRANT 類型角色。
• 許可： 授予或拒絕的一或多個特定動作。
• 範圍： 具有權限的 OneLake 物件。 物件是資料表、資料夾或結構描述。
• 成員： 指派給角色的任何 Microsoft Entra 身分識別，例如使用者、群組或非使用者身分識別。 角色會授與 Microsoft Entra 群組的所有成員。

透過將成員指派給角色，該使用者就會受到該角色範圍的相關聯許可權的約束。 由於 OneLake 安全性會使用預設拒絕模型，因此除非 OneLake 資訊安全角色明確授與，否則所有使用者都會從無法存取資料開始。

權限和支援的項目

OneLake 資訊穩定角色支援下列許可權：

• 讀： 授與使用者從表格讀取資料以及檢視相關聯的資料表和資料行中繼資料的能力。 在SQL術語中，此權限相當於VIEW_DEFINITION和SELECT。 如需詳細資訊，請參閱 中繼資料安全性。
• 閱讀： 賦予使用者從資料表或資料夾讀取與寫入資料的能力，並查看相關的資料表與欄位中繼資料。 用 SQL 術語來說，這個權限相當於 ALTER、DROP、UPDATE 和 INSERT。 更多資訊請參閱 ReadWrite 權限。

OneLake 安全性可讓使用者只定義下列 Fabric 項目的數據存取角色。

OneLake 安全性和工作區許可權

工作區權限是 OneLake 內資料的第一個安全性邊界。 每個工作區代表單一網域或專案區域，團隊可在其中進行資料協作。 您可以通過 Fabric 工作區角色來管理工作區的安全性。 深入了解 Fabric 角色型存取控制 (RBAC)：工作區角色

Fabric 工作區角色會授與套用至工作區中所有專案的許可權。 下表概述工作區角色允許的基本權限。

*由於工作區管理員、成員與參與者角色會自動授予 OneLake 寫入權限，因此會覆蓋任何 OneLake 的安全性讀取權限。

工作區角色會管理控制平面資料存取，這表示與建立和管理 Fabric 成品和權限的互動。 此外，工作區角色也會使用 OneLake 安全性預設角色，提供資料項目的預設存取層級。 （請注意，預設角色僅適用於檢視者，因為管理員、成員和參與者透過寫入許可權提高了存取權）預設角色是一般的 OneLake 資訊安全角色，會使用每個新專案自動建立。 它會為具有特定工作區或項目權限的使用者提供該項目中資料的預設存取層級。 例如，Lakehouse 專案具有 DefaultReader 角色，可讓具有 ReadAll 權限的使用者查看 Lakehouse 中的資料。 這可確保存取新建立項目的使用者具有基本層級的存取權。 所有預設角色都使用成員虛擬化功能，因此角色的成員是該工作區中具有必要權限的任何使用者。 例如，對 Lakehouse 具有 ReadAll 許可權的所有使用者。 下表顯示標準預設角色是什麼。 項目可能具有僅適用於該項目類型的特殊預設角色。

OneLake 安全性和專案許可權

在工作區內，Fabric 項目權限可與工作區角色分開設定。 您可透過共用項目或管理項目權限來設定權限。 下列權限決定使用者對 OneLake 資料執行動作的能力。 如需專案共用的詳細資訊，請參閱 Lakehouse 共用的運作方式

*取決於 SQL 分析端點模式。

建立角色

您可透過湖存放庫資料存取設定來定義及管理 OneLake 安全性角色。

了解更多請參閱開始使用資料存取角色。

引擎和使用者對資料的存取權

OneLake 的資料存取會以下列兩種方式之一進行：

• 透過 Fabric 查詢引擎或
• 透過使用者存取 （來自非 Fabric 引擎的查詢會被視為使用者存取）

OneLake 安全性可確保資料始終保持安全。 由於儲存層級作業不支援某些 OneLake 安全性功能，例如資料列和資料行層級安全性，因此並非所有類型的資料列或資料行層級安全資料都可以存取。 這可確保使用者無法看到他們不允許看到的資料列或資料行。 Microsoft Fabric 引擎已啟用，可將資料列和資料行層級安全性篩選套用至資料查詢。 這表示當使用者查詢具有 OneLake 安全性 RLS 或 CLS 的 Lakehouse 或其他專案中的資料時，使用者看到的結果會移除隱藏的資料列和資料行。 針對使用者存取 OneLake 中具有 RLS 或 CLS 的資料，如果不允許要求存取的使用者查看該資料表中的所有資料列或資料行，則會封鎖查詢。

下表概述哪些 Microsoft Fabric 引擎支援 RLS 和 CLS 篩選。

OneLake 安全性存取控制模型詳細數據

本節提供 OneLake 資訊安全角色如何授與特定範圍的存取權、該存取權的運作方式，以及如何跨多個角色和存取類型解析存取權的詳細資料。

資料表層級安全

所有 OneLake 資料表都會由 Lake 中的資料夾表示，但從 Fabric 中 OneLake 安全性和查詢引擎的觀點來看，並非所有 Lake 資料夾都是資料表。 若要被視為有效資料表，必須符合下列條件：

• 資料夾存在於項目的 Tables/ 目錄中。
• 資料夾包含一個_delta_log資料夾，其中包含表格中繼資料的對應 JSON 檔案。
• 資料夾不包含任何子捷徑。

如果對任何不符合這些準則的表格配置了表格層級安全性，則會拒絕存取。

中繼資料安全性

OneLake 安全性對資料的讀取存取權會授與資料表中資料和中繼資料的完整存取權。 對於無法存取資料表的使用者，資料永遠不會公開，而且中繼資料通常不可見。 這也適用於資料行層級安全性，以及使用者看到或不看到該資料表中資料行的能力。 不過，OneLake 安全性不保證無法存取資料表的 中繼資料 ，特別是在下列情況下：

• SQL 端點查詢：SQL Analytics 端點會使用與 SQL Server 相同的中繼資料安全性行為。 這意味著，如果使用者無權存取資料表或資料行，則該查詢的錯誤訊息將明確說明使用者無權存取的資料表或資料行名稱。
• 語意模型：授予使用者語意模型的建置權限，可讓他們存取模型中包含的資料表名稱，而不論使用者是否有權存取這些名稱。 此外，包含隱藏資料行的報表視覺效果會在錯誤訊息中顯示資料行名稱。

權限繼承

對於任何指定資料夾，OneLake 安全性權限一律繼承至該資料夾的所有檔案與子資料夾的整個階層。

例如，假設 OneLake 中的湖存放庫具有下列階層：

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

您為此湖倉創建了兩個角色。 Role1 會授與 folder1 的讀取權限，而 Role2 則會授與 folder2 的讀取權限。

針對指定的階層，OneLake 安全性許可權Role1Role2會以下列方式繼承：

• Role1：讀取資料夾1

  │   │   file11.txt
  │   │
  │   └───subfolder11
  │       │   file1111.txt
  |       │
  │       └───subfolder111
  |            │   file1111.txt
  

• Role2：讀取資料夾2

      │   file21.txt
  

OneLake 安全性中的巡覽及列出

OneLake 安全功能提供自動遍歷父項目，以確保容易發現數據。 授與使用者讀取 subfolder11 的權限，可讓使用者列出並進入和瀏覽上層目錄 folder1。 此功能類似 Windows 資料夾權限，其中授予子資料夾存取權即可搜尋及周遊上層目錄。 給予父項目的列舉和遍歷權限不會擴展到直接父項目以外的其他項目，從而確保其他資料夾的安全性。

例如，請考慮 OneLake 中的湖倉架構的以下階層。

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

對於指定階層，「Role1」的 OneLake 安全性權限提供以下存取權。 對 file11.txt 的存取不可見，因其並非 subfolder11 的上層目錄。 同理，對於 Role2，file111.txt 也不可見。

• Role1：讀取子資料夾11

  Files/
  ────folder1
  │   │
  │   └───subfolder11
  │       │   file111.txt
  |       │
  │       └───subfolder111
  |            │   file1111.txt
  

• Role2：讀取「subfolder111」

  Files/
  ────folder1
  │   │
  │   └───subfolder11
  |       │
  │       └───subfolder111
  |            │   file1111.txt
  

捷徑的列舉方式有所不同。 外部資料來源的捷徑行為與資料夾相同，但其他 OneLake 位置的捷徑具特殊行為。 捷徑的目標權限會決定對 OneLake 捷徑的存取權。 在列舉捷徑時，不會進行任何呼叫來檢查目標存取權。 因此，列舉目錄時，無論使用者對目標的存取權為何，都會傳回所有內部捷徑。 當使用者嘗試開啟捷徑時，會進行存取檢查，使用者只能看到他們具備必要權限查看的資料。 如需捷徑的詳細資訊，請參閱捷徑安全性區段。

請考慮包含捷徑的下列資料夾階層。

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

• Role1：讀取資料夾1

  Files/
  ────folder1
  │   
  └───shortcut2
  |
  └───shortcut3
  

• Role2：未定義任何權限

  Files/
  │   
  └───shortcut2
  |
  └───shortcut3
  

行層級安全性

OneLake 安全性可讓使用者藉由撰寫 SQL 述詞來指定資料列層級安全性，以限制向使用者顯示的資料。 RLS 的運作方式是顯示述詞評估為 true 的資料列。 如需詳細資訊，請參閱 資料列層級安全性。

資料列層級安全性會將字串資料評估為不區分大小寫，並使用下列定序進行排序和比較： Latin1_General_100_CI_AS_KS_WS_SC_UTF8

使用資料列層級安全性時，請確定 RLS 陳述式乾淨且易於理解。 使用整數資料行進行排序，以及大於或小於運算。 如果您不知道輸入資料的格式，請避免字串對等，尤其是與 Unicode 字元或重音敏感度相關的字串。

資料行層級安全性

OneLake 安全性支援移除 （隱藏） 使用者對資料行的存取權，以限制資料行的存取權。 隱藏資料行會被視為未指派任何許可權，因此預設原則為無存取權。 隱藏資料行不會對使用者可見，而且對包含隱藏資料行的資料進行查詢時，不會傳回該資料行的資料。 如 中繼資料安全性 中所述，在某些情況下，資料行的中繼資料可能仍會顯示在某些錯誤訊息中。

資料行層級安全性也會遵循 SQL 端點中更嚴格的行為，方法是透過拒絕語意進行操作。 拒絕 SQL 端點中資料行可確保封鎖對資料行的所有存取，即使多個角色會結合來提供資料行的存取權。 因此，SQL 端點中的 CLS 會使用使用者所屬所有角色之間的交集來運作，而不是所有其他權限類型的聯合行為。 如需角色如何組合的詳細資訊，請參閱評估多個 OneLake 資訊安全角色一節。

讀寫權限

ReadWrite 權限賦予唯讀使用者對特定項目執行寫入操作的能力。 ReadWrite 權限僅適用於擁有某項目讀取權限的 Viewer 或使用者。 將 ReadWrite 權限指派給管理員、成員或貢獻者不會有影響，因為這些角色本身就已經隱含擁有這些權限。

ReadWrite 存取允許使用者透過 Spark 筆記本、OneLake 檔案總管或 OneLake API 執行寫入操作。 不支援透過 Lakehouse UX 對檢視者進行寫入操作。

ReadWrite 權限的運作方式如下：

• ReadWrite 權限包含了由 Read 權限所賦予的所有權限。
• 擁有物件讀寫權限的使用者可對該物件執行所有寫入操作。 也就是說，任何操作也可以對物件本身執行。
• ReadWrite 允許以下操作：
  • 建立一個新的資料夾或表格
  • 刪除資料夾或表格
  • 重新命名資料夾或表格
  • 上傳或編輯檔案
  • 建立捷徑
  • 刪除捷徑
  • 重新命名捷徑
• 如果 OneLake 的安全角色具有讀寫存取權限，則不得包含 RLS 或 CLS 約束。
• 由於 Fabric 只支援單一引擎寫入資料，擁有物件讀寫權限的使用者只能透過 OneLake 寫入該資料。 然而，讀取操作將在所有查詢引擎上一致套用。

捷徑

捷徑概觀

OneLake 安全性與 OneLake 中的快捷方式集成，以確保可以輕鬆保護 OneLake 內部和外部的數據。 捷徑有兩種主要的驗證模式：

• 傳遞捷徑 （SSO）：會根據捷徑目標評估查詢使用者的認證，以判斷允許查看哪些資料。
• 委派的快捷方式：快捷方式會使用固定認證來存取目標，並在檢查委派認證對來源的存取之前，先根據 OneLake 安全性評估查詢使用者。

此外，在 OneLake 中建立任何快捷方式時，會評估 OneLake 安全性許可權。 閱讀捷徑安全性文件中有關捷徑權限的資訊。

直通捷徑中的 OneLake 安全性

OneLake 資料夾上設定的安全性一律會流過任何 內部快捷方式 ，以限制對快捷方式來源路徑的存取。 當使用者透過到另一個 OneLake 位置的捷徑存取資料時，呼叫使用者的身分識別會用於授權對捷徑目標路徑的資料存取。 因此，此使用者在目標位置必須有 OneLake 安全性權限才能讀取資料。

不允許針對內部捷徑定義 OneLake 安全性權限，且必須在位於目標項目的目標資料夾加以定義。 目標項目必須是支援 OneLake 安全性角色的項目類型。 如果目標專案不支援 OneLake 安全性，則會根據使用者是否具有目標專案的 Fabric ReadAll 許可權來評估使用者的存取權。 使用者不需要專案的 Fabric 讀取權限，即可透過捷徑存取專案。

委派快捷方式中的 OneLake 安全性

OneLake 支援為捷徑定義權限，例如 ADLS、S3 與 Dataverse 捷徑。 在此案例中，權限會套用在針對此類型捷徑啟用的委派授權模型之上。

假設 user1 在數據湖倉中建立 S3 捷徑，指向 AWS S3 儲存桶中的資料夾。 然後 user2 試圖存取此快捷方式中的資料。

OneLake 的安全性權限可以針對捷徑的整體範圍或選定的子資料夾加以定義。 資料夾上設定的權限會以遞迴方式繼承至所有子資料夾，即使子資料夾位於捷徑內也一樣。 外部捷徑上設定的安全性範圍可以授予對整個捷徑或捷徑內任何子路徑的存取權。 另一個指向外部快捷方式的內部快捷方式仍然需要用戶能夠訪問原始外部快捷方式。

不同於 OneLake 安全性中的其他類型存取，存取外部快捷方式的使用者需要外部快捷方式所在資料項目的 Fabric 讀取許可權。 這是安全地處理與外部系統連接的必要措施。

在 OneLake 捷徑 中深入了解 S3、ADLS 與 Dataverse 捷徑。

評估多個 OneLake 資訊穩定角色

使用者可以是多個不同 OneLake 資訊安全角色的成員，每個角色都會提供自己的資料存取權。 這些角色的組合稱為「有效角色」，也是使用者在 OneLake 中存取資料時會看到的內容。 角色會使用 UNION 或限制最少的模型，在 OneLake 安全性中結合。 這表示如果 Role1 授予對 TableA 的存取權，而 Role2 授予對 TableB 的存取權，則使用者將能夠同時看到 TableA 和 TableB。

OneLake 資訊識別角色也包含資料列和資料行層級安全性，這會限制資料表資料列和資料行的存取權。 每個 RLS 和 CLS 原則都存在於一個角色中，並限制該單一角色內所有使用者對資料的存取。 例如，如果 Role1 提供對 Table1 的存取權，但在 Table1 上具有 RLS，且僅顯示 Table1 的部分直欄，則 Role1 的有效角色將是 Table1 的 RLS 和 CLS 子集。 這可以表示為 （R1ols n R1cls n R1rls），其中 n 是角色中每個組件的交集。

處理多個角色時，RLS 和 CLS 會與個別資料表上的 UNION 語意結合。 CLS 是每個角色中可見的表格的直接集 UNION。 RLS 會使用 OR 運算子在述詞之間結合。 例如，WHERE city = 'Redmond' OR city = 'New York'。

若要評估每個角色都有 RLS 或 CLS 的多個角色，會先根據角色本身所提供的存取權來解析每個角色。 這表示要評估所有物件、列及資料行層級安全性的 INTERSECTION。 然後，每個評估的角色都會透過 UNION 作業與使用者所屬的所有其他角色結合。 輸出是該使用者的有效角色。 這可以表示為：

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) )

最後，湖屋中的每個捷徑都會產生一組推斷角色，用來將捷徑目標的權限傳播到所查詢的專案。 推斷角色的運作方式與非推斷角色類似，只不過它們會先在捷徑目標上解析，然後再與捷徑湖屋中的角色結合。 這可確保捷徑湖屋上的任何許可權繼承都會中斷，並正確評估推斷的角色。 完整的組合邏輯可以表示為：

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) ) n ( (R1'ols n R1'cls n R1'rls) u (R2'ols n R2'cls n R2'rls)) )

其中 R1' 和 R2' 是推斷的角色，而 R1 和 R2 是捷徑湖屋角色。

OneLake 安全性限制

• 如果您將 OneLake 安全性角色指派給 B2B 來賓使用者，則必須在 Microsoft Entra 外部 ID 中配置 B2B 外部協作設定。 來賓使用者存取 設定必須設定為 來賓使用者具有與成員相同的存取權（最具包容性）。

• OneLake 安全性不支援跨區域捷徑。 任何存取跨不同容量區域資料捷徑的嘗試，都會導致 404 錯誤。

• 如果您在 OneLake 安全性中將通訊組清單新增至角色，SQL 端點就無法解析清單的成員以強制執行存取權。 結果是使用者在存取 SQL 端點時，會顯示為不是該角色的成員。 SQL 語意模型上的 DirectLake 也會受到此限制。

• 若要使用 Spark SQL 從 Spark 筆記本查詢資料，使用者必須在他們正在查詢的工作區中至少具有檢視者存取權。

• 不支援混合模式查詢。 同時存取 OneLake 安全啟用與非 OneLake 安全資料的單一查詢都會因查詢錯誤而失敗。

• Spark 筆記本需要環境為 3.5 或更高版本，且使用 Fabric 執行環境 1.3。

• OneLake 安全性不適用於 私人連結保護。

• 外部資料共用預覽功能與資料存取角色預覽不相容。 當您在 Lakehouse 上啟用資料存取角色預覽時，任何現有的外部資料共用都可能會停止運作。

• 如果在該項目上啟用 OneLake 安全性，Azure Mirror Databricks 目錄不支援管理目錄功能。 此功能將於 2025 年 11 月推出。

• 下表提供 OneLake 資料存取角色限制。

  情境	限制
  每個 Fabric 項目的 OneLake 安全性角色數量上限	每個湖屋 250 個角色
  每個 OneLake 安全性角色的成員數量上限	每個角色 500 個使用者或使用者群組
  每個 OneLake 安全性角色的權限數量上限	每個角色 500 個權限

OneLake 安全性中的延遲

• 角色定義的變更需要約 5 分鐘才能套用。
• 若您變更 OneLake 安全性角色的使用者群組，OneLake 約需要一小時才能將角色權限套用至更新的使用者群組。
  • 某些 Fabric 引擎有自己的快取層，因此可能需要額外的一小時來更新所有系統中的存取權。