SQLServer動態(tài)掩碼的詳細(xì)介紹（代碼示例）

本篇文章給大家?guī)淼膬?nèi)容是關(guān)于sqlserver動態(tài)掩碼的詳細(xì)介紹（代碼示例），有一定的參考價值，有需要的朋友可以參考一下，希望對你有所幫助。

動態(tài)數(shù)據(jù)掩碼（DDM）是SQL Server 2016引入的一個新功能。目的就是限制沒有權(quán)限的人去看到一些隱私信息。管理員用戶能夠決定哪些字段是需要被掩碼的，那么如何在不改變應(yīng)用程序代碼的基礎(chǔ)上掩碼？還要保證無論如何訪問數(shù)據(jù)，都是一致的。

這是Azure SQL數(shù)據(jù)庫中首次引入的特性，它在云上接受用戶的測試，并已遷移到本地產(chǎn)品。我想很多其他的新特性也會遵循這條方式（云–本地）。

需要注意的是與我之前的行級別數(shù)據(jù)安全一樣，這些都是數(shù)據(jù)安全相關(guān)內(nèi)容（推薦課程：MySQL教程）

列數(shù)據(jù)掩碼

首先創(chuàng)建一個在一些數(shù)據(jù)上帶有掩碼版的表。我將在表定義中開始的一個字段中添加一個掩碼。注意，這樣做的方式是在數(shù)據(jù)類型之后使用“mask with()”格式，但是在NULL和默認(rèn)選項之前，要在圓括號內(nèi)包含F(xiàn)UNCTION = “，它指定了我們的函數(shù)。在引號內(nèi)，我們指定掩碼。CREATE TABLE語句如下

CREATE?TABLE?MyTable ??(?MySSN?VARCHAR?(10)?MASKED?WITH?(FUNCTION?=?'default()')?DEFAULT?('0000000000'?) ?,?MyName?VARCHAR?(200)?DEFAULT?(?'?') ?,?MyEmail?VARCHAR?(250)?DEFAULT?(?'') ?,?MyInt?int ) GO INSERT?dbo.?MyTable ?(?MySSN?,?MyName,?MyEmail?,?MyInt) VALUES ?(?'1234567890',?'Steve?Jones',?'SomeSteve@SomeDomain.com',?10?)

如果創(chuàng)建者查詢這個表，就會看到一個普通的表。我得到所有的數(shù)據(jù)，當(dāng)它被插入時。這是因為我是一個有權(quán)限的用戶。同理那些具有dbo特權(quán)(db_owner或sysadmin角色)的用戶將不會看到屏蔽數(shù)據(jù)。現(xiàn)在創(chuàng)建一個正常的用戶沒有高權(quán)限的用戶。當(dāng)然，我需要授予普通的SQL Server權(quán)限來查看表中的數(shù)據(jù)。

CREATE?USER?mytest?WITHOUT?LOGIN GRANT?SELECT?ON?mytable?TO?mytest

現(xiàn)在我們可以用這個用戶查詢這個表，看一下有什么不同。

我們可以看到第一列包含掩碼數(shù)據(jù)。只有x出現(xiàn)在數(shù)據(jù)的位置。這就實現(xiàn)了我想要的，即對非特權(quán)用戶隱藏數(shù)據(jù)。注意，磁盤上的數(shù)據(jù)沒有更改。數(shù)據(jù)只有在返回給非特權(quán)用戶時才會被屏蔽。
我可以在執(zhí)行計劃的最后一部分看到這種情況。我需要授予用戶查看計劃的權(quán)限，但是當(dāng)我這樣做時，我看到的是用戶的計劃，使用的是上面相同的查詢。

我可以在表上定義其他類型的掩碼。有一個自定義的掩碼格式，允許控制顯示的內(nèi)容，一個電子郵件地址的遮罩，和一個隨機(jī)的數(shù)字遮罩。我們將在另一篇文章中詳細(xì)討論這些問題。

現(xiàn)在可以添加掩碼到另一列上面，比如郵件MyEmail列，可以使用郵件掩碼的格式，具體代碼如下：

ALTER?TABLE?dbo.MyTable ?ALTER?COLUMN?MyEmail?VARCHAR(250)?MASKED?WITH?(FUNCTION='email()') GO

然后查詢結(jié)果如下:

也可以對多個和列進(jìn)行掩碼

CREATE?TABLE?MySecondTable?( ??MyEmail?VARCHAR(?250)?MASKED?WITH?(FUNCTION=?'email()') ,?MySSN?VARCHAR?(10)?MASKED?WITH?(FUNCTION?='default()') ,?MyID?INT?MASKED?WITH?(FUNCTION?='random(1,4)') )GOINSERT?MySecondTable?VALUES ???(?'myname@mydomain.com',?'1234567890',?100?) ?,?(?'abrother@mycorp.com'?,?'0123456789'?,?555) ?,?(?'somesister@somecompany.org'?,?'9876543210'?,?999)

查詢結(jié)果如下:

正如我們所看到的，我從不同的行得到不同的掩碼，每個掩碼應(yīng)用于特定行的數(shù)據(jù)。

允許用戶看到掩碼真實數(shù)據(jù)

SQL Server 2016中有一個新的DDM權(quán)限。這是UNMASK權(quán)限，它和其他任何權(quán)限一樣被授予。讓我們來看看這是如何工作的。我將創(chuàng)建一個具有與現(xiàn)有用戶相同權(quán)限的新用戶。然后我將查詢該表。

與之前相似的結(jié)果，然后我們在給用授權(quán)打開掩碼。

現(xiàn)在我們可以看到數(shù)據(jù)的顯示方式與特權(quán)用戶的顯示方式相同。對于NewTester用戶，所有的數(shù)據(jù)都是“未屏蔽的”。
然而，這也有不利的一面。UNMASK權(quán)限在數(shù)據(jù)庫范圍內(nèi)授予用戶。沒有按表或列劃分的粒度。如果用戶具有UNMASK，他們可以查看存儲在數(shù)據(jù)庫中的表中具有SELECT權(quán)限的所有數(shù)據(jù)。我們可以通過使用Newtest查詢第一個表來看到這一點。

移除掩碼

代碼如下：

ALTER?TABLE?dbo.MySecondTable ??ALTER?COLUMN?MySSN?DROP?MASKED;

一旦我這樣做，用戶將直接看到真實數(shù)據(jù)。

MySSN列的數(shù)據(jù)是未屏蔽的，但是MyEmail和MyID的數(shù)據(jù)仍然是屏蔽的

總結(jié)

動態(tài)數(shù)據(jù)屏蔽是一個很好的新特性，旨在更容易地保護(hù)數(shù)據(jù)不受非特權(quán)用戶的影響。這可以在數(shù)據(jù)庫中實現(xiàn)，而不需要更改任何應(yīng)用程序代碼，從而允許您以最小的成本和工作量對應(yīng)用程序用戶屏蔽敏感數(shù)據(jù)。我還要提醒您，這并不是真正的安全特性。存儲在磁盤和表中的數(shù)據(jù)不會以任何方式更改。這仍然是純文本數(shù)據(jù)，如果用戶能夠查詢系統(tǒng)，他們?nèi)匀豢梢詽撛诘夭樵兡臄?shù)據(jù)并發(fā)現(xiàn)其值。

無論如何，這個特性對于尤其是需要數(shù)據(jù)脫密使用的系統(tǒng)來說無疑是有幫助的。當(dāng)然17以后功能也有了長足的進(jìn)步后面有機(jī)會我會繼續(xù)介紹。