適用於：✅ Microsoft Fabric 中的 SQL 分析端點和倉儲
資料列層級安全性 (RLS) 可讓您使用群組成員資格或執行脈絡，來控制資料庫資料表中資料列的存取權限。 例如，您可以確保員工只能存取與其部門相關的資料列。 另一個範例是在多租用戶架構中將客戶的資料存取限制為僅與其公司相關的資料。 此功能類似於 SQL Server 中的資料列層級安全性。
資料層級的資料列安全性
資料列層級安全性簡化您的應用程式中安全性的設計和編碼。 資料列層級安全性可協助您在資料列存取上進行實作限制。
存取限制邏輯在資料庫層中，而不是在任何單一應用程式層中。 在每次嘗試資料存取時，資料庫會從包括 Power BI 在內的任何應用程式或報告平台套用存取限制。 這可藉由縮小安全性系統的接觸區，讓安全性系統更加可靠和健全。 資料列層級安全性僅適用於 Fabric 中倉儲或 SQL 分析端點上的查詢。 Direct Lake 模式中倉儲上的 Power BI 查詢將會回復為 [直接查詢] 模式，以遵守資料列層級安全性。
將特定資料列的存取限制為特定使用者
使用 CREATE SECURITY POLICY Transact-SQL 陳述式，以及作為內嵌資料表值函式建立的述詞來實作 RLS。
資料列層級安全性會套用到共用資料倉儲或資料湖倉，因為其基礎資料來源尚未變更。
以述詞為基礎的資料列層級安全性
Fabric 數據倉儲中的數據列層級安全性支援述詞型安全性。 篩選述詞以無訊息方式篩選讀取作業可用的資料列。
定義為內嵌資料表值函數的安全性述詞，會限制資料表中資料列層級資料的存取權。 接著會呼叫該函式，並由安全性原則強制約束其執行。 針對篩選述詞，應用程式不會知道從結果集篩選的資料列。 若所有資料列皆經過篩選，將會傳回 Null 集合。
從基底資料表中讀取資料時會套用篩選述詞。 它們會影響所有 Get 作業：SELECT、DELETE 和 UPDATE。 每個資料表必須分別定義自己的資料列層級安全性。 在沒有資料列層級安全性原則的情況下查詢資料表的使用者將檢視未篩選的資料。
使用者無法選取或刪除已篩選的資料列。 使用者無法更新已篩選的資料列。 但是，的確可以更新資料列，讓這些資料列之後被篩選掉。
篩選器述詞和安全性原則具有下列行為：
您可以定義可與另一個資料表連接及／或呼叫函數的述詞函數。 若在
SCHEMABINDING = ON(預設值) 的情況下建立安全性原則，則聯結或函式可從查詢存取並如預期般運作，而不需任何額外的權限檢查。您可以對已定義但已停用安全性述詞的資料表執行查詢。 不會影響任何已篩選或封鎖的資料列。
若 dbo 使用者、
db_owner角色的成員或資料表擁有者對已定義且啟用安全性原則的資料表進行查詢，資料列便會依安全性原則所定義而受到篩選或封鎖。若嘗試變更受結構描述繫結安全性原則繫結之資料表的結構描述，將會產生錯誤。 不過，您可以修改未被述詞參考的資料行。
若嘗試在已針對指定作業定義述詞的資料表上新增述詞，則會發生錯誤。 無論是否啟用述詞，這都會發生。
嘗試修改在已繫結結構描述之安全性原則內的資料表上作為述詞的函式會導致錯誤。
定義包含非重疊的述詞的多個作用中的安全性原則，就會成功。
篩選述詞有下列行為：
- 定義篩選資料表的資料列的安全性原則。 應用程式無法得知因
SELECT、UPDATE和DELETE作業而被篩選掉的任何資料列。 包括所有資料列都被篩選掉的情況。應用程式可以INSERT資料列，即使這些資料列會在其他任何作業期間被篩除。
權限
建立、改變或卸除安全性原則需要 ALTER ANY SECURITY POLICY 權限。 建立或刪除安全性原則需要具備結構描述上的 ALTER 權限。
此外，對於每個新增的述詞，還需要下列權限：
用作述詞的函式所需的
SELECT和REFERENCES權限。已繫結至原則的目標資料表上的
REFERENCES權限。對目標資料表中作為參數使用的每個資料行的
REFERENCES權限。
安全性原則套用到所有使用者，包括資料庫中的 dbo 使用者。 Dbo 使用者可以變更或卸除安全性原則，但他們對安全性原則所做的變更可接受稽核。 如果 Administrator、Member 或 Contributor 等角色的成員需要查看所有資料列，才能進行疑難排解或驗證資料，則安全性原則必須撰寫成允許這麼做。
如果以 SCHEMABINDING = OFF 來建立安全性原則，則為了查詢目標資料表，使用者必須對述詞函式和述詞函式內使用的任何其他資料表、檢視或函式具有 SELECT 或 EXECUTE 權限。 如果以 SCHEMABINDING = ON (預設值) 來建立安全性原則，則當使用者查詢目標資料表時，會略過這些權限檢查。
安全性考量：旁路攻擊
請考量並準備下列兩種案例。
惡意安全性原則管理員
必須注意的是，若惡意的安全性原則管理員具備足夠權限，能在敏感資料行上建立安全性原則，且具有建立或修改內嵌資料表值函式的權限，便可與另一位對資料表具有 SELECT 權限的使用者共謀，藉由惡意建立其設計是利用側通道攻擊來推斷資料的內嵌資料表值函式，進行資料外洩。 這類攻擊需要共謀 (或授與惡意使用者過多權限)，並可能需要反覆修改原則 (需要移除述詞權限才能中斷結構描述繫結)、修改內嵌資料表值函式，並在目標資料表上重複執行 select 陳述式。 我們建議您視需要限制權限，並監視任何可疑活動。 應監視諸如與資料列層級安全性相關且經常變更的原則和內嵌資料表值函式等活動。
精心設計的查詢
使用精心設計、利用錯誤訊息來竊取資料的查詢，可能會導致資訊外洩。 例如，SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; 可讓惡意使用者知道 John Doe 的確切薪資為 100,000 美元。 即使已設有安全性述詞來防止惡意使用者直接查詢他人的薪資，使用者仍可藉由查詢是否傳回除以零例外，判斷相關情況。
範例
我們可以示範 Microsoft Fabric 中的資料列層級安全性 Warehouse 和 SQL 分析端點。
下列範例會建立範例資料表，這些資料表將配合 Fabric 中的 Warehouse 使用，但在 SQL 分析端點中，會使用現有資料表。 在 SQL 分析端點中，您無法 CREATE TABLE，但可以 CREATE SCHEMA、CREATE FUNCTION 和 CREATE SECURITY POLICY。
在此範例中，請先建立結構描述 sales、資料表 sales.Orders。
CREATE SCHEMA sales;
GO
-- Create a table to store sales data
CREATE TABLE sales.Orders (
SaleID INT,
SalesRep VARCHAR(100),
ProductName VARCHAR(50),
SaleAmount DECIMAL(10, 2),
SaleDate DATE
);
-- Insert sample data
INSERT INTO sales.Orders (SaleID, SalesRep, ProductName, SaleAmount, SaleDate)
VALUES
(1, 'Sales1@contoso.com', 'Smartphone', 500.00, '2023-08-01'),
(2, 'Sales2@contoso.com', 'Laptop', 1000.00, '2023-08-02'),
(3, 'Sales1@contoso.com', 'Headphones', 120.00, '2023-08-03'),
(4, 'Sales2@contoso.com', 'Tablet', 800.00, '2023-08-04'),
(5, 'Sales1@contoso.com', 'Smartwatch', 300.00, '2023-08-05'),
(6, 'Sales2@contoso.com', 'Gaming Console', 400.00, '2023-08-06'),
(7, 'Sales1@contoso.com', 'TV', 700.00, '2023-08-07'),
(8, 'Sales2@contoso.com', 'Wireless Earbuds', 150.00, '2023-08-08'),
(9, 'Sales1@contoso.com', 'Fitness Tracker', 80.00, '2023-08-09'),
(10, 'Sales2@contoso.com', 'Camera', 600.00, '2023-08-10');
建立 Security 結構描述、函式 Security.tvf_securitypredicate 和安全原則 SalesFilter。
-- Creating schema for Security
CREATE SCHEMA Security;
GO
-- Creating a function for the SalesRep evaluation
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
-- Using the function to create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO
若要修改資料列層級安全性函數，您必須先刪除安全性原則。 在下列指令碼中，我們會先刪除原則 SalesFilter，然後再對 Security.tvf_securitypredicate 發出 ALTER FUNCTION 陳述式。 然後，我們會重新建立原則 SalesFilter。
-- Drop policy so we can change the predicate function.
DROP SECURITY POLICY SalesFilter;
GO
-- Alter the function for the SalesRep evaluation
ALTER FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'president@contoso.com';
GO
-- Re-create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO