Sql-Server
連接欄位時的動態數據屏蔽問題
您可以在此處重現該問題:
CREATE TABLE [dbo].[EmployeeDataMasking]( [RowId] [int] IDENTITY(1,1) NOT NULL, [EmployeeId] [int] NULL, [LastName] [varchar](50) MASKED WITH (FUNCTION = 'partial(2, "XXXX", 2)') NOT NULL, [FirstName] [varchar](50) MASKED WITH (FUNCTION = 'partial(2, "XXXX", 2)') NOT NULL, CONSTRAINT [PK_EmployeeDataMasking] PRIMARY KEY CLUSTERED ( [RowId] ASC )WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY], ) ON [PRIMARY] GO Insert Into dbo.EmployeeDataMasking (EmployeeId, LastName, FirstName) VALUES( 1,'Smithsonian','Daniel'),( 2,'Templeton','Ronald') Select EmployeeId, LastName, FirstName, LastName + ', ' + FirstName From dbo.EmployeeDataMasking
請注意 LastName 和 FirstName 欄位被部分屏蔽(如預期的那樣)。但是,組合名稱欄位包含預設遮罩。我不知道這是否被認為是一個錯誤。但是,我認為組合欄位將保留它包含的兩個欄位的遮罩。至少這是我更喜歡的,因為我不知道如何為組合欄位提供遮罩。
文件對於遮罩列是表達式的一部分時的行為是可恥的沉默。
這是執行計劃中屏蔽列的表示方式:
Scalar Operator(DataMask([LastName],0x05000000,(3),(2),'XXXX',(2)))
這裡
(3)
表示屏蔽函式類型,對應partial
屏蔽。這就是
LastName + ', ' + FirstName
表達式的表示方式:Scalar Operator(DataMask([LastName]+', '+[FirstName],0x05000000,(1),(0),(0),(0)))
如您所見,行為是“計算,然後屏蔽”。本例中的屏蔽函式類型為
(1)
,對應於default
屏蔽。這是掩蔽功能調整和有意修改的結果。使用“計算,然後遮罩”的方法,這(遮罩調整)顯然是必要的措施,因為否則簡單的表達式涉及
LEFT
,RIGHT
或SUBSTRING
函式可以輕鬆地取消遮罩數據。並且確定表達式是否“安全”可能太複雜了。我只能猜測為什麼方法是“計算,然後遮罩”而不是“遮罩,然後計算”,但我認為後者在實施時會遇到自己的問題。我能想到的一些包括數字類型的算術錯誤的可能性(例如除以零,例如,如果將某些內容劃分為屏蔽列),或邏輯偏差的可能性(如果存在依賴於屏蔽的條件表達式柱子)。