借助 OneLake 安全性，Microsoft Fabric 正在擴展組織跨工作負載管理和強制執行數據訪問的方式。 這個新的安全框架為管理員提供了更大的靈活性來配置權限。 系統管理員可以在 透過 OneLake 進行集中式控管 ，或在 SQL 分析端點內進行以 SQL 為基礎的細微控制 之間進行選擇。
SQL 分析端點中的存取模式
使用 SQL 分析端點時，選取的存取模式會決定如何強制執行資料安全性。 Fabric 支援兩種不同的存取模型，每種模型都根據您的作業和合規性需求提供不同的優點：
使用者身分識別模式：使用 OneLake 角色和原則強制執行安全性。 在此模式中，SQL 分析端點會將登入使用者的身分識別傳遞至 OneLake， 而讀取存取權完全由 OneLake 內定義的安全性規則控管。 支援資料表的 SQL 層級許可權，確保 Power BI、筆記本和 Lakehouse 等工具之間的治理一致。
委派身分模式：透過 SQL 提供完全控制。 在此模式中，SQL 分析端點會使用 工作區或專案 擁有者的身分識別連線到 OneLake， 而安全性只會由資料庫內定義的 SQL 許可權控管 。 此模型支援傳統的安全性方法，包括 GRANT、REVOKE、自訂角色、Row-Level 安全性和動態資料遮罩。
每種模式都支援不同的治理模型。 了解它們的影響對於在 Fabric 環境中選擇正確的方法至關重要。
存取模式之間的比較
以下是一個清晰簡潔的比較表，重點介紹了在使用者身分模式與委派身分模式中設定安全性的方式和位置，並按物件類型和資料存取策略細分：
| 安全目標 | 使用者身分識別模式 | 委派身分識別模式 |
|---|---|---|
| Tables | 存取是由 OneLake 資訊安全角色所控制。 不允許使用 SQL GRANT/REVOKE 。 |
使用 SQL GRANT/REVOKE進行完全控制。 |
| Views | 使用 SQL GRANT/REVOKE 來指派權限。 | 使用 SQL GRANT/REVOKE 來指派權限。 |
| 預存程序 | 使用 SQL GRANT EXECUTE 來指派權限。 | 使用 SQL GRANT EXECUTE 來指派權限。 |
| 函數 | 使用 SQL GRANT EXECUTE 來指派權限。 | 使用 SQL GRANT EXECUTE 來指派權限。 |
| Row-Level 安全 （RLS） | 在 OneLake UI 中定義為 OneLake 資訊安全角色的一部分。 | 使用 SQL CREATE SECURITY POLICY 定義。 |
| Column-Level 安全 （CLS） | 在 OneLake UI 中定義為 OneLake 資訊安全角色的一部分。 | 使用具有直欄清單的 SQL GRANT SELECT 定義。 |
| 動態資料遮罩 （DDM） | OneLake 安全性不支援。 | 使用 SQL ALTER TABLE 和 MASKED 選項定義。 |
OneLake 安全性中的使用者身分識別模式
在使用者身分識別模式中，SQL 分析端點會使用 透通驗證機制 來強制執行資料存取。 當使用者連線到 SQL 分析端點時，其 Entra ID 身分識別會傳遞至 OneLake，以執行許可權檢查。 所有資料表的讀取作業都會使用 OneLake Lakehouse 內定義的安全性規則來評估，而不是由任何 SQL 層級 GRANT 或 REVOKE 陳述式來評估。
此模式可讓您集中管理安全性，確保所有 Fabric 體驗的強制執行一致，包括 Power BI、筆記本、Lakehouse 和 SQL 分析端點。 它專為治理模型而設計，其中存取權應在 OneLake 中定義一次，並在任何地方自動遵守。
在使用者身分識別模式中：
資料表存取完全由 OneLake 安全性控管。 會忽略表格上的 SQL GRANT/REVOKE 陳述式。
RLS （Row-Level 安全性）、CLS （Column-Level 安全性） 和 Object-Level 安全性都是在 OneLake 體驗中定義的。
視圖、預存程序和函數等非資料物件允許 SQL 權限，從而能夠靈活地定義自訂邏輯或面向使用者的資料入口點。
SQL 分析端點不支援寫入作業。 所有寫入都必須透過 Lakehouse UI 進行，並由工作區角色 （系統管理員、成員、參與者） 控管。
這很重要
SQL Analytics 端點需要項目許可權與 OneLake 安全性角色中的成員之間的一對一對應，才能正確同步。 如果您授與 OneLake 資訊安全角色的身分識別存取權，則相同的身分識別也必須具有湖屋的 Fabric 讀取許可權。 例如，如果使用者將 “user123@microsoft.com” 指派給 OneLake 安全角色，則也必須將 “user123@microsoft.com” 指派給該 Lakehouse。
工作區角色行為
在工作區層級具有 系統管理員、 成員或 參與者 角色的使用者不受 OneLake 安全性強制執行的約束。 這些角色具有提高的許可權，而且會完全略過 RLS、CLS 和 OLS 原則。 請遵循下列需求，以確保遵守 OneLake 安全性：
在工作區中為使用者指派 檢視者角色 ，或
使用 唯讀 許可權與使用者共用 Lakehouse 或 SQL 分析端點。 只有具有唯讀存取權的使用者才能根據 OneLake 資訊安全角色篩選其查詢。
角色優先順序：大多數寬鬆存取獲勝
如果使用者屬於 多個 OneLake 角色，則最寬鬆的角色會定義其有效存取權。 例如：
如果一個角色授與資料表的完整存取權，而另一個角色套用 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 （動態資料遮罩） 原則會參考已刪除或重新命名的資料行 | OneLake Security 不支援 DDM，必須透過 SQL 實作。 | 錯誤：欄名稱<欄名稱>無效 | 更新或移除一或多個受影響的 DDM 規則，或還原遺漏的資料行。 | 更新 SQL Analytics 端點中的 DDM 原則。 |
| 系統錯誤（非預期的失敗） | 錯誤： 發生非預期的系統錯誤。請重試或聯絡支援人員。 | 錯誤： 將資料表變更套用至 SQL 時發生內部錯誤。 | 重試操作;如果問題仍然存在，請聯絡 Microsoft 支援服務。 | 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、角色等） 來驗證存取權。
如果查詢獲得授權，系統將繼續存取儲存在 OneLake 中的資料。
此資料存取是使用 Lakehouse 或 SQL 分析端點擁有者的身分識別來執行，也稱為 專案帳戶。
在此模型中：
登入的使用者不會傳遞至 OneLake。
假設所有強制執行的存取都會在 SQL 層處理。
專案擁有者負責在 OneLake 中擁有足夠的許可權，以代表工作負載讀取基礎檔案。
因為這是委派的模式，所以擁有者的 SQL 許可權與 OneLake 存取權之間的任何未一致都會導致查詢失敗。 此模式提供與以下項目的完全相容性：
所有物件層級的 SQL GRANT/REVOKE
SQL 定義的 Row-Level 安全、 Column-Level 安全及 動態資料遮罩
DBA 或應用程式所使用的現有 T-SQL 工具和做法
如何變更 OneLake 存取模式
存取模式會決定透過 SQL 分析端點查詢 OneLake 時，如何驗證和強制執行資料存取。 您可以使用下列步驟在使用者身分識別模式與委派身分識別模式之間切換：
流覽至 Fabric 工作區，然後開啟 Lakehouse。 從右上角，從 Lakehouse 切換至 SQL 分析端點。
從頂端導覽中，移至 [ 安全性 ] 索引標籤，然後選取下列其中一種 OneLake 存取模式：
使用者身分 — 使用登入使用者的身分。 它會強制執行 OneLake 角色。
委派身分 — 使用項目擁有者的身分;僅強制執行 SQL 權限。
隨即啟動快顯視窗以確認您的選擇。 選取 [ 是 ] 以確認變更。
切換模式時的注意事項
切換至使用者身分識別模式
會忽略 SQL RLS、CLS 和資料表層級許可權。
必須設定 OneLake 角色，讓使用者保持存取權。
只有具有檢視者權限或共用唯讀存取權的使用者才會受到 OneLake 安全性的控管。
現有的 SQL 角色會刪除，且無法復原。
切換至委派身分識別模式
不再套用 OneLake 角色和安全原則。
SQL 角色和安全策略會變成作用中。
專案擁有者必須具有有效的 OneLake 存取權，否則所有查詢都可能失敗。
局限性
僅適用於讀取者：OneLake 安全性會控管以 檢視者身分存取資料的使用者。 其他工作區角色 （系統管理員成員或參與者） 的使用者會略過 OneLake 安全性，並保留完整存取權。
SQL 物件不會繼承擁有權：捷徑會在 SQL 分析端點中顯示為資料表。 直接或透過檢視存取這些資料表時，預存程序和其他衍生 SQL 物件不具有物件層級擁有權;所有權限都會在執行階段進行檢查，以防止安全繞過。
捷徑變更會觸發驗證停機時間：當捷徑目標變更 （例如，重新命名、URL 更新） 時，資料庫會短暫進入 單一使用者模式 ，同時系統會驗證新目標。 在此期間，查詢被阻止，這些操作相當快，但有時取決於不同的內部進程可能需要長達 5 分鐘才能同步。
- 建立結構描述捷徑可能會導致已知錯誤，進而影響驗證並延遲中繼資料同步。
延遲權限傳播：權限變更不是即時的。 在安全性模式 （使用者身分識別與委派） 之間切換可能需要一段時間才能生效，但應該需要不到 1 分鐘的時間。
控制平面相依性：許可權無法套用至工作區控制平面中尚不存在的使用者或群組。 您需要共用來源項目，或使用者必須是「檢視者」工作區角色的成員。 請注意，這兩個位置必須有完全相同的物件識別碼。 群組和該群組的成員不會被計為匹配。
最寬鬆的存取優先：當使用者屬於多個群組或角色時，會遵循最寬鬆的有效權限 範例：如果使用者透過一個角色同時具有 DENY 和透過另一個角色的 GRANT，則 GRANT 優先。
委派模式限制：在委派模式中，如果來源專案具有未授與專案擁有者完整資料表存取權的 OneLake 安全性原則，捷徑資料表上的中繼資料同步處理可能會失敗。
DENY 行為：當多個角色套用至單一快捷方式資料表時，許可權的交集會遵循 SQL Server 語意：DENY 會覆寫 GRANT。 這可能會產生非預期的存取結果。
預期錯誤情況：使用者可能會遇到以下場景的錯誤：
捷徑目標已重新命名或無效
- 範例：如果刪除了表格的來源。
RLS （Row-Level Security） 設定錯誤
OneLake 不支援某些 RLS 篩選運算式，而且可能會允許未經授權的資料存取。
卸除篩選運算式上所使用的資料行會使 RLS 失效，而中繼資料同步處理將會過時，直到 RLS 在 OneLake 安全性面板上修正為止。
針對公開預覽版，我們僅支援單一運算式資料表。 目前不支援動態 RLS 和多表 RLS。
Column-Level 安全性 （CLS） 限制
CLS 的工作原理是維護列的允許清單。 如果移除或重新命名允許的資料行，則 CLS 原則會變成無效。
當 CLS 無效時，會封鎖中繼資料同步處理，直到 [OneLake 安全性] 面板中修正 CLS 規則為止。
中繼資料或權限同步失敗
- 如果資料表有變更，例如重新命名資料行，則不會在新物件上複寫安全性，而且您會收到 UI 錯誤，顯示資料行不存在。
資料表重新命名不會保留安全性原則：如果在結構描述層級定義 OneLake 安全性 （OLS） 角色，則只有在資料表名稱不變時，這些角色才會保持有效。 重新命名資料表會中斷關聯，而且不會自動移轉安全性原則。 這可能會導致意外的資料外洩，直到重新套用原則為止。
OneLake 安全性角色的名稱最多不可超過 124 個字元;否則將導致安全性角色同步無法同步這些角色。
OneLake 安全角色會以 OLS_ 前置詞傳遞到 SQL 分析端點上。
不支援OLS_角色上的使用者變更，而且可能會導致非預期的行為。
不支援郵件啟用的安全性群組和通訊清單。
Lakehouse 的擁有者必須是系統管理員、成員或參與者工作區角色的成員;否則，安全性不會套用至 SQL 分析端點。
Lakehouse 的擁有者不能是安全性同步處理運作的服務主體。