連接欄位時的動態數據屏蔽問題

您可以在此處重現該問題：

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函式可以輕鬆地取消遮罩數據。並且確定表達式是否“安全”可能太複雜了。

我只能猜測為什麼方法是“計算，然後遮罩”而不是“遮罩，然後計算”，但我認為後者在實施時會遇到自己的問題。我能想到的一些包括數字類型的算術錯誤的可能性（例如除以零，例如，如果將某些內容劃分為屏蔽列），或邏輯偏差的可能性（如果存在依賴於屏蔽的條件表達式柱子）。

引用自：https://dba.stackexchange.com/questions/278213