本文將說明SQL Server 2016中三項與安全性有關的新功能：一律加密、資料列層級安全性及動態資料遮罩，讓企業即使將資料放在公有雲上也能擁有資料的所有權，並且可以管理資料存取權限，為資料建立遮罩避免外流。
若使用自行開發的應用程式，一樣只需在連線字串中加入上述連線參數，並擁有建立資料行主要金鑰（Column Master Keys）的憑證，同樣可以看到解密後的資料內容。
簡介資料列層級安全性（Row-Level Security）
資料列層級安全性提供DBA或者是開發人員更為細緻地控制存取資料表的權限，讓企業得以依照所需要之商業邏輯來設計篩選述詞函式（Filter Predicate Functions），進而限制查詢所回傳的資料結果集。
如圖12所示，即使是執行相同T-SQL指令碼，依照登入的使用者不同而有不同的結果，這是因為受到安全性原則所控管。
 |
| ▲圖12 比較使用不同身分登入查詢相同資料表有不同結果。 |
這一切是如何運作的呢？首先在SQL Server Management Studio（SSMS）的物件總管視窗，於AdventureWorks2016CTP3資料庫的安全性原則節點，可以看到安全性原則customerPolicy，該原則使用Security.customerAccessPredicate資料表值函式來當作篩選述詞函式，並將FILTER和BLOCK動作套用到目標物件Sales.CustomerPII資料表，如圖13所示。
 |
| ▲圖13 比較使用不同身分登入查詢相同資料表有不同結果。 |
而Security.customerAccessPredicate資料表值函式的邏輯主要是依據資料庫使用者、使用者的TerritoryID和角色來限制可以查看的資料列（圖14）。
 |
| ▲圖14 篩選述詞函式範例。 |
若以michael9的使用者身分連接至資料庫，安全性原則就會依照篩選述詞函式來判斷有權存取的資料列，即使未使用任何WHERE條件來查詢Sales.CustomerPII資料表，僅有TerritoryID等於2的資料列會被傳回，如圖15所示。
 |
| ▲圖15 取得michale9的TerritoryID及其可以查詢的資料。 |
一旦安全性原則套用至所指定的目標物件後，該資料表的CRUD（新增、查詢、更新和刪除）就會先被攔截，確認符合原則才會繼續往下做。承襲前面的範例，倘若michael9嘗試更新或刪除不屬於權限範圍的資料列（非TerritoryID等於2）則會被拒絕，如圖16所示。
 |
| ▲圖16 嘗試更新或刪除不具權限的資料列。 |
至於新增動作也是一樣，若故意嘗試新增TerritoryID等於3的資料列，也會因為安全性原則而遭到封鎖（BLOCK），以確保新增資料時也不會誤將權限外的資料新增到資料表（圖17）。
 |
| ▲圖17 嘗試更新或刪除不具權限的資料列。 |
經由上述示範，可見資料列層級安全性（Row-Level Security）所帶來的便利，針對應用程式所使用的登入（Login）或使用者的權限來規劃安全性原則，就能有效避免因為程式開發的疏忽而危及資料的安全性和正確性。
何謂動態資料遮罩（Dynamic Data Masking）
處理機敏資料往往是應用程式開發上的一項負擔，為了避免像是個人資料等資訊被有心人士有意或無意窺視，往往需要在資料傳送到應用程式端的時候，自行撰寫程式來模糊化或遮蔽，以避免呈現資料的原始樣貌。
現在這個工作可以交給SQL Server代為處理，藉由SQL Server 2016的動態資料遮罩（Dynamic Data Masking），可以輕易地在回傳查詢結果集時就將其遮罩，應用程式不須額外處理就可以避免資料外洩，對於測試環境或企業需要委外開發資訊系統，這是一項相當便利的功能。