摘要：本期月報我們分享使用實現隱私數據列的打碼技術最佳實踐。最后總結本期月報我們分享了使用引入的新特性實現客戶數據打碼技術，防止未授權用戶查看導出用戶關鍵隱私數據，最大限度保證用戶數據安全性。

在SQL Server安全系列專題月報分享中，我們已經分享了：如何使用對稱密鑰實現SQL Server列加密技術、使用非對稱密鑰加密方式實現SQL Server列加密、使用混合密鑰實現SQL Server列加密技術、列加密技術帶來的查詢性能問題以及相應解決方案和行級別安全解決方案這五篇文章，文章詳情可以參見往期月報。本期月報我們分享使用SQL Server 2016 dynamic data masking實現隱私數據列的打碼技術最佳實踐。

在平日的生活中，我們或多或少都經歷過廣告推銷、電話詐騙，不厭其煩，甚至更為嚴重到銀行卡號泄漏、身份證號泄漏等更為嚴重的情況。這個時候，于是我們就在想有沒有技術手段來盡量或最大限度的保護我們隱私數據安全呢？答案是肯定的，SQL Server 2016版本首次引入了dynamic data masking來實現隱私數據列的打碼技術，讓我們一起來看看如何實現類似于手機號、身份證號、駕照號等隱私數據打碼技術。

數據列打碼技術的本身我們并不陌生，就是將一些比較私密的數據信息隱藏起來，僅開放給有較高權限的用戶查看完整數據。打碼技術本身并不會對數據做任何的加密、解密等操作。嚴格意義上講，數據打碼不是一個完整的數據安全解決方案，但是它可以作為安全策略中重要的一環來有效避免用戶隱私數據列的泄漏。讓我們一起來看看在SQL Server 2016 dynamic data masking是如何實現的。

創建測試數據庫

為了測試方便，我們專門創建了測試數據庫TestDb。

--Step 1 - Create MSSQL sample database
USE master
GO
IF DB_ID("TestDb") IS NULL
    CREATE DATABASE [TestDb];
GO

創建測試表

首先，我們創建一張常規表CustomerInfo，來存放客戶信息，其中，CustomerPhone列為用戶隱私數據，存放了用戶的手機號碼。

--Step 2 - Create Test Table, init records
USE [TestDb]
GO
IF OBJECT_ID("dbo.CustomerInfo", "U") IS NOT NULL
    DROP TABLE dbo.CustomerInfo
CREATE TABLE dbo.CustomerInfo
(
CustomerId        INT IDENTITY(10000,1)    NOT NULL PRIMARY KEY,
CustomerName    VARCHAR(100)            NOT NULL,
CustomerPhone    CHAR(11)                NOT NULL
);

-- Init Table
INSERT INTO dbo.CustomerInfo 
VALUES ("CustomerA","13402872514")
,("CustomerB","13880674722")
,("CustomerC","13487759293")
GO

創建測試用戶

為了方便觀察和檢查測試效果，我們創建一個測試賬號DemoUser。

-- Step3: Create a DemoUser to test
USE [TestDb]
GO
CREATE USER DemoUser WITHOUT LOGIN;
GRANT SELECT ON dbo.CustomerInfo TO DemoUser;
GO

EXECUTE AS USER = "DemoUser";
-- Verify data
SELECT * 
FROM dbo.CustomerInfo

REVERT

常規情況下，測試賬號，可以清清楚楚，明明白白看到用戶所有數據，包含客戶手機號這種關鍵的隱私數據。如果，這個用戶有不軌之心是非常容易將這些信息泄漏、導出的，安全風險較大。

客戶手機號打碼

于是，我們想，如果能夠將客戶隱私數據，比如，電話號碼（身份證號碼、銀行卡號等）打碼的話，那么測試賬號就無法查看到用戶完整的數據信息了。打碼方法如下：

-- Step4: Alter phone column add data mask
USE [TestDb]
GO

ALTER TABLE dbo.CustomerInfo
ALTER COLUMN CustomerPhone ADD MASKED WITH(FUNCTION="partial(3, "****", 4)");

由于CustomerPhone是11位數字，我們使用partial方法打碼隱藏中間四位，打碼符號使用星號，保留前三位和后四位數數字即可。

查詢打碼列

打碼完畢，我們使用系統試圖查看打碼列和打碼函數：

-- Step5. Query system view to check data mask
SELECT
    db_name() as database_name, 
    SCHEMA_NAME(schema_id) AS schema_name, 
    tbl.name as table_name, 
    c.name as column_name, 
    c.is_masked, 
    c.masking_function  
FROM sys.masked_columns AS c  WITH (NOLOCK)
    INNER JOIN sys.tables AS tbl   WITH(NOLOCK)
    ON c.[object_id] = tbl.[object_id]  
WHERE c.is_masked = 1
    AND tbl.name = "CustomerInfo";

從結果可以看到我們已經將表TestDb.dbo.CustomerInfo中字段CustomerPhone打碼，打碼函數為partial(3, "**", 4)，結果展示如下所示：

測試用戶查看數據

打碼完畢后，再次使用DemoUser測試賬號查看打碼后的數據：

-- Step6: Demo user to query and verify data
USE [TestDb]
GO
EXECUTE AS USER = "DemoUser";
-- Verify data
SELECT * 
FROM dbo.CustomerInfo

REVERT

從查詢結果展示來看，客戶手機號碼列中間四位已經成功打碼了，測試賬號已經無法獲取到完整的客戶電話號碼了。

修改打碼符號

有時候，有的人會說，我不喜歡星號，能否換個打碼姿勢，我更喜歡使用字母X。只要你喜歡，隨便切換，方法如下：

-- Step7: What if I want to change the mask sign from * to X
USE [TestDb]
GO

ALTER TABLE dbo.CustomerInfo
ALTER COLUMN CustomerPhone CHAR(11) MASKED WITH(FUNCTION="partial(3, "XXXX", 4)");

現在打碼符號變成了X，展示如下：

新增隱私打碼列

現在我們需要增加一個新的列，用來存放用戶email地址，也請同時打碼。非常簡單，新增列的時候使用email打碼函數即可，如下所示：

-- Step8: and I want to add a new email mask column
ALTER TABLE dbo.CustomerInfo
ADD Email varchar(100) MASKED WITH (FUNCTION = "email()")  NOT NULL DEFAULT("demo.user@test.com")

查詢打碼列特定值

有的人可能會問，手機號碼被打碼了，這個列會影響我的WHERE語句查詢嗎？當然不會，因為data mask技術本身并沒有對數據做任何修改，只是在展示的時候，打碼隱藏掉部分信息而已。

-- Step9: Demo user to query the specified phone customer info
USE [TestDb]
GO
EXECUTE AS USER = "DemoUser";
-- Verify data
SELECT * 
FROM dbo.CustomerInfo
WHERE CustomerPhone = "13880674722"

REVERT

查詢結果展示，手機號碼和email地址始終被打碼。

拷貝存在打碼列的表

我們說data mask技術并沒有加密、修改數據本身。到目前為止，測試賬號DemoUser已經無法獲取到客人的關鍵隱私數據了，那么他能夠將用戶數據Copy、導出嗎？讓我們做一個簡單的測試，DemoUser將表CustomerInfo復制到一個新表CustomerInfo_copied中：

-- Step10: Ops, if I copy a new table from the data masked table, I can"t get the unmasked data now.
USE [TestDb]
GO
GRANT CREATE TABLE TO DemoUser;
GRANT ALTER ON SCHEMA::dbo TO DemoUser;
EXECUTE AS USER = "DemoUser";
-- Verify data
SELECT * 
    INTO dbo.CustomerInfo_copied
FROM dbo.CustomerInfo

REVERT

GRANT SELECT ON dbo.CustomerInfo_copied TO DemoUser;
EXECUTE AS USER = "DemoUser";
SELECT * FROM dbo.CustomerInfo_copied
REVERT

DemoUser復制了客戶信息數據到新表后，查看新表中的數據，依然是被打碼的，測試用戶無法導出、復制客人的隱私數據。達到了安全策略保護客戶隱私數據的目的，展示結果如下：

我想要在無碼的世界

如果有一天DemoUser成了高權限用戶，確實需要查看客戶隱私數據列，這個時候，我們可以給予測試賬號unmask的權限，他就可以看到完整的客戶數據了。方法如下：

-- Step 11: But, how can demo user to query the unmasked data?
USE TestDB
GO

GRANT UNMASK TO DemoUser;  
EXECUTE AS USER = "DemoUser";  
SELECT * FROM dbo.CustomerInfo;  
REVERT;   

-- Removing the UNMASK permission  
REVOKE UNMASK TO DemoUser;

此時，DemoUser查詢到的數據，是非常完整的客人數據。

刪掉打碼

刪除打碼，讓所有用戶回歸無碼的世界。

-- Step 12: all the demos have been done, it"s time to drop the mask.
USE TestDB
GO
ALTER TABLE dbo.CustomerInfo   
ALTER COLUMN CustomerPhone DROP MASKED;  

本期月報我們分享了使用SQL Server 2016引入的新特性dynamic data masking實現客戶數據打碼技術，防止未授權用戶查看、導出用戶關鍵隱私數據，最大限度保證用戶數據安全性。

閱讀原文

本文為云棲社區原創內容，未經允許不得轉載。