Fabric 資料倉儲中的資料列層級安全性
適用於：✅ Microsoft Fabric 中的 SQL 分析端點和倉儲
資料列層級安全性 (RLS) 讓您能夠使用群組成員資格或執行內容，對資料庫資料表中資料列的存取。 例如，您可以確保員工只能存取與其部門相關的資料列。 另一個範例是在多租用戶架構中將客戶的資料存取限制為僅與其公司相關的資料。 此功能類似於 SQL Server 中的資料列層級安全性。
資料層級的資料列層級安全性
資料列層級安全性簡化您的應用程式中安全性的設計和編碼。 資料列層級安全性可協助您在資料列存取上進行實作限制。
存取限制邏輯在資料庫層中，而不是在任何單一應用程式層中。 在每次嘗試資料存取時，資料庫會從包括 Power BI 在內的任何應用程式或報告平台套用存取限制。 這可藉由縮小安全性系統的接觸區，讓安全性系統更加可靠和健全。 資料列層級安全性僅適用於 Fabric 中倉儲或 SQL 分析端點上的查詢。 Direct Lake 模式中倉儲上的 Power BI 查詢將會回復為 [直接查詢] 模式，以遵守資料列層級安全性。
將特定資料列的存取限制為特定使用者
使用 CREATE SECURITY POLICY Transact-SQL 陳述式，以及作為內嵌資料表值函式建立的述詞來實作 RLS。
資料列層級安全性會套用至共用倉儲或 Lakehouse，因為基礎資料來源尚未變更。
述詞型資料列層級安全性
Fabric 數據倉儲中的數據列層級安全性支援述詞型安全性。 篩選述詞以無訊息方式篩選讀取作業可用的資料列。
定義為內嵌資料表值函數的安全性述詞，會限制資料表中資料列層級資料的存取權。 然後叫用函式並強制執行安全性原則。 針對篩選述詞，應用程式不會知道從結果集篩選的資料列。 若所有資料列皆經過篩選，將會傳回 Null 集合。
從基底資料表中讀取資料時會套用篩選述詞。 它們會影響所有取得作業：SELECT、DELETE 及 UPDATE。 每個資料表必須分別定義自己的資料列層級安全性。 在沒有資料列層級安全性原則的情況下查詢資料表的使用者將檢視未篩選的資料。
使用者無法選取或刪除已篩選的資料列。 使用者無法更新已篩選的資料列。 但是，可以更新資料列使其在之後會被篩選。
篩選器述詞和安全性原則具有下列行為：
您可以定義與另一個資料表聯結和/或叫用函數的述詞函數。 若在
SCHEMABINDING = ON(預設值) 的情況下建立安全性原則，則聯結或函式可從查詢存取並如預期般運作，而不需任何額外的權限檢查。您可以對己定義但停用安全性述詞的資料表發出查詢。 不會影響任何已篩選或封鎖的資料列。
若 dbo 使用者、
db_owner角色的成員或資料表擁有者對已定義且啟用安全性原則的資料表進行查詢，資料列便會依安全性原則所定義而受到篩選或封鎖。若您嘗試變更結構描述繫結安全性原則所繫結資料表的結構描述，將會導致錯誤。 不過，您可以改變述詞不參考的資料行。
若嘗試在已替指定作業定義述詞的資料表上加入述詞，會導致錯誤。 不論是否已啟用述詞都會發生。
嘗試修改在已繫結結構描述之安全性原則內的資料表上作為述詞的函式會導致錯誤。
定義包含非重疊的述詞的多個作用中的安全性原則，就會成功。
篩選器述詞具有下列行為：
- 定義篩選資料表的資料列的安全性原則。 應用程式不會知道針對
SELECT、UPDATE和DELETE作業篩選的任何資料列。 包括已篩選出所有資料列的情況。應用程式可以INSERT資料列，即使它們會在任何其他作業期間進行篩選。
權限
建立、改變或卸除安全性原則需要 ALTER ANY SECURITY POLICY 權限。 建立或卸除安全性原則需要對結構描述的 ALTER 權限。
此外，每個加入的述詞還需要下列權限：
正做為述詞使用之函式的
SELECT和REFERENCES權限。正繫結至原則之目標資料表的
REFERENCES權限。目標資料表中做為引數使用之每個資料行的
REFERENCES權限。
安全性原則套用到所有使用者，包括資料庫中的 dbo 使用者。 Dbo 使用者可以改變或卸除安全性原則，不過可稽核的安全性原則變更。 如果系統管理員、成員或參與者等角色的成員需要查看所有資料列才能對資料進行疑難排解或驗證，則必須寫入安全性原則以允許這些資料。
如果以 SCHEMABINDING = OFF 來建立安全性原則，則為了查詢目標資料表，使用者必須對述詞函式和述詞函式內使用的任何其他資料表、檢視或函式具有 SELECT 或 EXECUTE 權限。 如果以 SCHEMABINDING = ON (預設值) 來建立安全性原則，則當使用者查詢目標資料表時，會略過這些權限檢查。
安全性考量：旁路攻擊
請考量並準備下列兩種案例。
惡意的安全性原則管理員
請注意，具有足夠權限可在敏感性資料行上建立安全性原則，以及有權建立或改變內嵌資料表值函式的惡意安全性原則管理員，可以與具有資料表選取權限的其他使用者共謀，藉由惡意建立設計成使用旁路攻擊推斷資料的內嵌資料表值函式，來洩漏資料。 這類攻擊需要共謀 (或授與惡意使用者過多權限)，並可能需要反覆修改原則 (需要移除述詞權限才能中斷結構描述繫結)、修改內嵌資料表值函式，並在目標資料表上重複執行 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