透過 OneLake 安全性，Microsoft Fabric 擴展了組織跨工作負載管理和控制資料存取的方式。 這個新的安全框架為管理員提供了更大的靈活性來配置權限。 系統管理員可以在 透過 OneLake 進行集中式控管 ，或在 SQL 分析端點內進行以 SQL 為基礎的細微控制 之間進行選擇。
SQL 分析端點中的 Access 模式
使用SQL分析端點時，所選access模式決定了資料安全的執行方式。 Fabric 支援兩種截然不同的 access 模式，每種模式根據您的營運與合規需求提供不同的優勢：
使用者身分識別模式：使用 OneLake 角色和原則強制執行安全性。 在此模式下，SQL 分析端點會將登入使用者的身份傳給 OneLake，read access完全受 OneLake 中定義的安全規則所控制。 支援資料表上的 SQL 層級許可權，確保 Power BI、筆記本和 Lakehouse 等工具之間的治理一致。
委派身分模式：透過 SQL 提供完全控制。 在此模式中，SQL 分析端點會使用 工作區或專案 擁有者的身分識別連線到 OneLake， 而安全性只會由資料庫內定義的 SQL 許可權控管 。 此模型支援傳統的安全性方法，包括 GRANT、REVOKE、自訂角色、Row-Level 安全性和動態資料遮罩。
每種模式都支援不同的治理模型。 了解它們的影響對於在 Fabric 環境中選擇正確的方法至關重要。
存取模式比較
以下是一張清晰且簡潔的比較表，重點介紹使用者身份模式與委派身份模式中如何以及在哪裡設定安全性——並依物件類型及資料access政策細分：
| 安全目標 | 使用者身分識別模式 | 委派身分識別模式 |
|---|---|---|
| Tables | Access 由 OneLake 的安全角色控制。 不允許使用 SQL GRANT/REVOKE 。 |
使用 SQL GRANT/REVOKE進行完全控制。 |
| 瀏覽次數 | 使用 SQL GRANT/REVOKE 來指派權限。 | 使用 SQL GRANT/REVOKE 來指派權限。 |
| 預存程序 | 使用 SQL GRANT EXECUTE 來指派權限。 | 使用 SQL GRANT EXECUTE 來指派權限。 |
| 函數 | 使用 SQL GRANT EXECUTE 來指派權限。 | 使用 SQL GRANT EXECUTE 來指派權限。 |
| 資料列層級安全性 (RLS) | 在 OneLake UI 中被定義為 OneLake 安全角色的一部分。 | 使用 SQL CREATE SECURITY POLICY 定義。 |
| 欄位級別安全性 (CLS) | 在 OneLake UI 中被定義為 OneLake 安全角色的一部分。 | 使用具有欄位清單的 SQL GRANT SELECT 定義。 |
| 動態資料遮罩 （DDM） | 不支援 OneLake 的安全功能。 | 使用 SQL ALTER TABLE 和 MASKED 選項定義。 |
OneLake 安全性中的使用者身分識別模式
在使用者身份模式下，SQL 分析端點會使用 passthrough 認證機制來強制資料access。 當使用者連線到 SQL 分析端點時，其 Entra ID 身分識別會傳遞至 OneLake，以執行許可權檢查。 所有資料表的讀取作業都會使用 OneLake Lakehouse 內定義的安全性規則來評估，而不是由任何 SQL 層級 GRANT 或 REVOKE 陳述式來評估。
此模式可讓您集中管理安全性，確保所有 Fabric 體驗的強制執行一致，包括 Power BI、筆記本、Lakehouse 和 SQL 分析端點。 它被設計用於治理模型，存取應在 OneLake 中定義一次，並在所有地方自動適用。
在使用者身分識別模式中：
Table access 完全由 OneLake 安全系統管理。 會忽略表格上的 SQL GRANT/REVOKE 陳述式。
RLS （Row-Level 安全性）、CLS （Column-Level 安全性） 和 Object-Level 安全性都是在 OneLake 體驗中定義的。
視圖、預存程序和函數等非資料物件允許 SQL 權限，從而能夠靈活地定義自訂邏輯或面向使用者的資料入口點。
SQL 分析端點不支援寫入作業。 所有寫入必須透過 Fabric 入口網站的 Lakehouse 頁面進行，並由工作區角色（管理員、成員、貢獻者）管理。
這很重要
SQL Analytics 端點需要項目許可權與 OneLake 安全性角色中的成員之間的一對一對應，才能正確同步。 如果您給予某個身份 OneLake 安全角色的存取權，該身份也需要對資料湖屋擁有 Fabric Read 權限。 例如，如果使用者將 “user123@microsoft.com” 指派給 OneLake 安全角色，則也必須將 “user123@microsoft.com” 指派給該 Lakehouse。
工作區角色行為
在工作區層級具有 系統管理員、 成員或 參與者 角色的使用者不受 OneLake 安全性強制執行的約束。 這些角色具有提升的權限，而且會完全略過 RLS、CLS 和 OLS 策略。 請遵循下列需求，以確保遵守 OneLake 安全性：
在工作區中為使用者指派 檢視者角色 ，或
使用 唯讀 許可權與使用者共用 Lakehouse 或 SQL 分析端點。 只有具有唯讀存取權的使用者，他們的查詢會依照 OneLake 安全角色被過濾。
角色優先順序：最寬鬆的存取權限勝出
若使用者屬於多個 OneLake 角色，最寬鬆的角色定義其有效存取權限。 例如：
若一個角色賦予資料表完整access，而另一個角色則套用 RLS 限制資料列，則 RLS 將不會被強制執行。
更廣泛的存取角色優先於其他。 此行為可確保使用者不會無意中遭到封鎖，但需要仔細的角色設計以避免衝突。 建議在執行列級或欄級存取控制時，保持限制性與允許性角色互斥。
欲了解更多資訊，請參閱 OneLake 安全性的資料存取控制模型。
OneLake 與 SQL 分析端點之間的安全性同步處理
使用者身分識別模式的重要元件是 安全性同步服務。 此背景服務會監視對 OneLake 中資訊安全角色所做的變更，並確保這些變更反映在 SQL 分析端點中。
安全性同步服務負責下列事項：
偵測 OneLake 角色的變更，包括新角色、更新、使用者指派和資料表變更。
將 OneLake 定義的原則 （RLS、CLS、OLS） 轉譯成對等的 SQL 相容資料庫角色結構。
確保 捷徑物件（來自其他 Lakehouse 的資料表）已正確驗證，以便遵循原始 OneLake 安全性設定，即使遠端存取也是如此。
這種同步可確保 OneLake 安全性定義保持權威性，無需手動 SQL 層級幹預來複製安全性行為。 因為安全性是集中強制執行的：
您無法在此模式中直接使用 T-SQL 來定義 RLS、CLS 或 OLS。
您仍然可以使用 GRANT 或 EXECUTE 陳述式將 SQL 權限套用至檢視、函數和預存程序。
安全性同步處理錯誤和解決方法
| Scenario | 使用者身分識別模式中的行為 | 委派模式下的行為 | 糾正措施 | 註釋 |
|---|---|---|---|---|
| RLS 政策涉及到已刪除或重新命名的資料行 | 錯誤：*列級安全策略會引用已不存在的資料行。*在策略修正之前，資料庫會進入錯誤狀態。 | 錯誤：欄名稱<欄名稱>無效 | 更新或移除一或多個受影響的角色，或還原遺失的資料行。 | 必須在角色最初建立的湖屋中進行更新。 |
| CLS 規則參考了已刪除或重新命名的欄 | 錯誤：*資料欄位層級安全性策略參考了一個已不存在的欄位。*資料庫將進入錯誤狀態，直到此策略被修正為止。 | 錯誤：欄名稱<欄名稱>無效 | 更新或移除一或多個受影響的角色，或還原遺失的資料行。 | 必須在角色最初建立的湖屋中進行更新。 |
| RLS/CLS 原則會參考已刪除或重新命名的資料表 | 錯誤： 安全性原則參考不再存在的資料表。 | 沒有出現錯誤;如果缺少表格，則查詢會以無訊息方式失敗。 | 更新或移除一或多個受影響的角色，或還原遺失的資料表。 | 必須在角色最初建立的湖屋中進行更新。 |
| DDM （動態資料遮罩） 原則會參考已刪除或重新命名的資料行 | DDM 不支援 OneLake 安全，必須透過 SQL 實作。 | 錯誤：欄名稱<欄名稱>無效 | 更新或移除一或多個受影響的 DDM 規則，或還原遺漏的資料行。 | 更新 SQL Analytics 端點中的 DDM 原則。 |
| 系統錯誤（非預期的失敗） | 錯誤： 發生非預期的系統錯誤。請重試或聯絡支援人員。 | 錯誤： 將資料表變更套用至 SQL 時發生內部錯誤。 | 重試操作;若問題持續，請聯絡 Microsoft Support。 | N/A |
| 使用者沒有構件的許可權 | 錯誤： 使用者沒有成品的許可權 | 錯誤： 使用者沒有成品的許可權 | 為使用者提供構件的 objectID {objectID} 許可權。 | 物件識別碼必須在 OneLake 安全性角色成員與 Fabric 項目權限間完全匹配。 如果將群組新增至角色成員資格，則必須為該群組提供 Fabric 讀取許可權。 將該群組中的成員新增至專案不會計為直接相符。 |
| 不支援使用者主體。 | 錯誤： 不支援使用者主體帳號。 | 錯誤： 不支援使用者主體帳號。 | 請從角色 DefaultReader 中刪除用戶 {username} | 如果使用者不再是有效的 Entra ID，例如使用者已離開您的組織或已被刪除，則會發生此錯誤。 將它們從角色中移除，以解決此錯誤。 |
安全性同步的捷徑行為
OneLake 的安全性會在真實來源中被強制執行，因此安全性同步會停用涉及捷徑的資料表和檢視的所有權鏈結。 這可確保一律評估和遵守來源系統權限，即使對於來自另一個資料庫的查詢也是如此。
因此：
使用者必須在兩者的來源（目前的 Lakehouse 或 SQL 分析端點）以及資料實際存放的目的地擁有有效的存取權限。
若使用者在任一方都缺乏權限，查詢將失敗並出現存取錯誤。
設計參照捷徑的應用程式或檢視時，請確定在捷徑關係的 兩端 都正確設定角色指派。
此設計保留了跨 Lakehouse 邊界的安全完整性，但如果跨 Lakehouse 角色未對齊，可能發生存取失敗的情況。
OneLake 安全性中的委派模式
在 委派身份模式中，SQL 分析端點仍使用與現今 Microsoft Fabric 中相同的 安全模型。 安全性與權限完全由 SQL 層管理，且資料表層級的存取不由OneLake 角色或存取政策強制執行。 當使用者連線到 SQL 分析端點並發出查詢時：
SQL 根據 SQL 權限（GRANT、REVOKE、RLS、CLS、DDM、角色等）來驗證存取。
若查詢獲授權，系統會access儲存在 OneLake 的資料。
此資料存取是使用 Lakehouse 或 SQL 分析端點擁有者的身份執行，亦稱為項目帳戶。
在此模型中：
使用者的登入資訊不會傳遞至 OneLake。
所有 access 的強制執行假設皆由 SQL 層負責。
專案擁有者負責在 OneLake 中擁有足夠的許可權，以代表工作負載讀取基礎檔案。
由於這是委派模式，SQL 權限與 OneLake 存取權之間的任何不一致都會導致查詢失敗。 此模式提供與以下項目的完全相容性：
所有物件層級的 SQL GRANT/REVOKE
SQL 定義的 列級安全性、 欄級安全性及 動態資料遮罩
DBA 或應用程式所使用的現有 T-SQL 工具和做法
如何更改 OneLake 的 access 模式
存取模式決定了在透過 SQL 分析端點查詢 OneLake 時，資料存取的認證與執行方式。 您可以使用下列步驟在使用者身分識別模式與委派身分識別模式之間切換：
流覽至 Fabric 工作區，然後開啟 Lakehouse。 從右上角，從 Lakehouse 切換至 SQL 分析端點。
從上方導覽點，前往Security分頁，選擇以下 OneLake access模式之一：
使用者身分 — 使用登入使用者的身分。 它會強制執行 OneLake 角色。
委派身分 — 使用項目擁有者的身分;僅強制執行 SQL 權限。
隨即啟動快顯視窗以確認您的選擇。 選取 [ 是 ] 以確認變更。
切換模式時的注意事項
這很重要
目前在使用者身分與授權模式間進行轉換（任一方向）時，會移除內聯中繼資料物件，包括 TVF 和標量值函數。 此行為僅影響元資料定義;OneLake 的底層資料則不受影響。
切換至使用者身分識別模式
會忽略 SQL RLS、CLS 和資料表層級許可權。
OneLake 角色必須設定，讓使用者能保持存取權。
只有擁有查看者權限或共享唯讀存取權的使用者才會受到 OneLake 安全保護的規範。
現有的 SQL 角色會刪除，且無法復原。
切換至委派身分識別模式
不再套用 OneLake 角色和安全原則。
SQL 角色和安全策略啟用。
物品擁有者必須擁有有效的 OneLake access，否則所有查詢都可能失敗。
Troubleshooting
在 使用者身份模式下 ，安全同步結果可透過使用者體驗驗證。 打開 SQL Analytics 端點，在檔案總管中展開 Security 資料夾，然後選擇資料庫角色（自訂）。 如果同步成功，你會看到角色以「ols_」為前綴列出。 例如，「ols_TestRole」。 帶有「ols_{alphanumericString}_rolename」的角色名稱是來自其他湖屋的角色，這些角色透過捷徑傳播而來。
常見安全同步錯誤的修復方法
如果任何角色引用已丟棄的資料表，安全同步將失敗。 把那些資料表從角色中刪除，然後再嘗試安全同步。
SPN不能成為湖邊別墅的擁有者。 確保父湖屋項目是由使用者帳號擁有。
所有 OneLake 安全角色成員都需要獲得 Fabric 讀取 資料湖倉權限，以便安全同步能識別使用者或群組。
局限性
僅適用於閱讀器：OneLake 安全措施規範以 Viewer 身份存取資料的使用者。 其他工作區角色（管理員、成員或貢獻者）的使用者可繞過 OneLake 的安全性設定，並保留完整的存取權限。
SQL 物件不會繼承擁有權：捷徑會在 SQL 分析端點中顯示為資料表。 直接或透過檢視存取這些資料表時，預存程序和其他衍生 SQL 物件不具有物件層級擁有權;所有權限都會在執行階段進行檢查，以防止安全繞過。
捷徑變更會觸發驗證停機時間：當捷徑目標變更 （例如，重新命名、URL 更新） 時，資料庫會短暫進入 單一使用者模式 ，同時系統會驗證新目標。 在此期間，查詢被阻止，這些操作相當快，但有時取決於不同的內部進程可能需要長達 5 分鐘才能同步。
- 建立結構描述捷徑可能會導致已知錯誤，進而影響驗證並延遲中繼資料同步。
延遲權限傳播：權限變更不是即時的。 在安全性模式 （使用者身分識別與委派） 之間切換可能需要一段時間才能生效，但應該需要不到 1 分鐘的時間。
控制平面相依性：許可權無法套用至工作區控制平面中尚不存在的使用者或群組。 您需要共用來源項目，或使用者必須是「檢視者」工作區角色的成員。 請注意，這兩個位置必須有完全相同的物件識別碼。 群組和該群組的成員不會被計為匹配。
最寬鬆許可權優先：當使用者屬於多個群組或角色時，會採用最寬鬆的有效權限範例：若使用者在一個角色中被拒絕權限，且透過另一個角色獲得授權，則該授權優先。
委派模式限制：在委派模式下，若來源項目有 OneLake 安全政策，且未授予項目擁有者完整資料表access，捷徑表格的元資料同步可能會失敗。
DENY 行為：當多個角色套用於相同的一個快捷方式表時，權限的交集遵循 SQL Server 語意：DENY 凌駕於 GRANT。 這可能會產生意想不到的存取結果。
預期錯誤情況：使用者可能會遇到以下場景的錯誤：
捷徑目標已重新命名或無效
- 範例：如果刪除了表格的來源。
RLS （Row-Level Security） 設定錯誤
OneLake 不支援某些 RLS 過濾的表達式，可能會允許未經授權的資料存取。
刪除篩選式中使用的欄位會使 RLS 失效，且元資料同步會處於過時狀態，直到 OneLake 安全面板上的 RLS 問題得到解決。
針對公眾預覽版，我們僅支援單一表達式資料表。 目前不支援動態 RLS 和多表 RLS。
欄位層級安全性（CLS）限制
CLS 的工作原理是維護列的允許清單。 如果移除或重新命名允許的資料行，則 CLS 原則會變成無效。
當 CLS 無效時，元資料同步會被阻擋，直到 OneLake 安全面板中 CLS 規則修正。
元資料或權限同步失敗
- 如果資料表有變更，例如重新命名資料行，則不會在新物件上複寫安全性，而且您會收到 UI 錯誤，顯示資料行不存在。
資料表重命名不會保留安全政策：如果 OneLake 安全（OLS）角色是在結構層級定義的，這些角色僅在資料表名稱未變更時持續有效。 重新命名資料表會中斷關聯，而且不會自動移轉安全性原則。 這可能會導致意外的資料外洩，直到重新套用原則為止。
OneLake 安全性角色的名稱最多不可超過 124 個字元;否則將導致安全性角色同步無法同步這些角色。
不支援OLS_角色上的使用者變更，而且可能會導致非預期的行為。
不支援郵件啟用的安全性群組和通訊清單。
Lakehouse 的擁有者必須是系統管理員、成員或參與者工作區角色的成員;否則，安全性不會套用至 SQL 分析端點。
Lakehouse 的擁有者不能是安全性同步處理運作的服務主體。