Fabric 數據倉儲中的數據列層級安全性

  • 發行項

適用於： Microsoft Fabric 中的 SQL 分析端點和倉儲

資料列層級安全性 (RLS) 讓您能夠使用群組成員資格或執行內容，對資料庫資料表中資料列的存取。 例如，您可以確保員工只能存取與其部門相關的資料列。 另一個範例是將客戶的數據存取限制為只有多租用戶架構中與其公司相關的數據。 此功能類似於 SQL Server 中的數據列層級安全性。

數據層級的數據列層級安全性

資料列層級安全性簡化您的應用程式中安全性的設計和編碼。 數據列層級安全性可協助您實作數據列存取的限制。

存取限制邏輯位於資料庫層中，而不是在任何單一應用層中。 資料庫會在每次嘗試數據存取時，從包括 Power BI 在內的任何應用程式或報告平臺套用存取限制。 這可藉由縮小安全性系統的接觸區，讓安全性系統更加可靠和健全。 數據列層級安全性僅適用於 Fabric 中倉儲或 SQL 分析端點上的查詢。 Direct Lake 模式中倉儲上的 Power BI 查詢將會回復為 Direct Query 模式，以遵守數據列層級安全性。

將特定數據列的存取限制為特定使用者

使用 CREATE SECURITY POLICY Transact-SQL 陳述式，以及作為內嵌資料表值函式建立的述詞來實作 RLS。

數據列層級安全性會套用至 共用倉儲或 Lakehouse，因為基礎數據源尚未變更。

述詞型數據列層級安全性

Fabric Synapse 數據倉儲中的數據列層級安全性支援述詞型安全性。 篩選述詞會以無訊息方式篩選可供讀取作業的數據列。

定義為內嵌資料表值函數的安全性述詞，會限制資料表中資料列層級資料的存取權。 然後叫用函式並強制執行安全性原則。 針對篩選述詞，應用程式不會知道從結果集篩選的資料列。 若所有資料列皆經過篩選，將會傳回 Null 集合。

從基底資料表中讀取資料時會套用篩選述詞。 它們會影響所有取得作業：SELECT、DELETE 及 UPDATE。 使用者無法選取或刪除已篩選的資料列。 使用者無法更新已篩選的資料列。 但是，可以更新數據列的方式，以便之後篩選數據列。

篩選述詞和安全策略具有下列行為：

  • 您可以定義與另一個數據表和/或叫用函式聯結的述詞函式。 若在 SCHEMABINDING = ON (預設值) 的情況下建立安全性原則，則聯結或函式可從查詢存取並如預期般運作，而不需任何額外的權限檢查。

  • 您可以針對已定義但停用安全性述詞的數據表發出查詢。 不會影響任何已篩選或封鎖的資料列。

  • 若 dbo 使用者、db_owner 角色的成員或資料表擁有者對已定義且啟用安全性原則的資料表進行查詢，資料列便會依安全性原則所定義而受到篩選或封鎖。

  • 若您嘗試變更結構描述繫結安全性原則所繫結資料表的結構描述，將會導致錯誤。 不過，您可以改變述詞不參考的資料行。

  • 若嘗試在已替指定作業定義述詞的資料表上加入述詞，會導致錯誤。 不論是否已啟用述詞都會發生。

  • 嘗試修改在已繫結結構描述之安全性原則內的資料表上作為述詞的函式會導致錯誤。

  • 定義包含非重疊的述詞的多個作用中的安全性原則，就會成功。

篩選器述詞具有下列行為：

  • 定義篩選資料表的資料列的安全性原則。 應用程式不會知道針對 SELECT、UPDATE 和 DELETE 作業篩選的任何資料列。 包括已篩選出所有資料列的情況。應用程式可以 INSERT 資料列，即使它們會在任何其他作業期間進行篩選。

權限

建立、改變或卸除安全性原則需要 ALTER ANY SECURITY POLICY 權限。 建立或卸除安全性原則需要對結構描述的 ALTER 權限。

此外，每個新增的述詞都需要下列許可權：

  • 正做為述詞使用之函式的 SELECT 和 REFERENCES 權限。

  • 正繫結至原則之目標資料表的 REFERENCES 權限。

  • 目標資料表中做為引數使用之每個資料行的 REFERENCES 權限。

安全性原則套用到所有使用者，包括資料庫中的 dbo 使用者。 Dbo 使用者可以改變或卸除安全性原則，不過可稽核的安全性原則變更。 如果角色的成員，例如 管理員 istrator、Member 或參與者需要查看所有數據列來疑難解答或驗證數據，則必須寫入安全策略以允許這些數據。

如果以 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

相關內容

後續步驟

在 Fabric 資料倉儲 中實作數據列層級安全性