保護機敏資料的幫手 - 再談 Azure SQL Database 動態資料遮罩
本文大綱如下：
說明
上一篇我們談到使用 Azure SQL Database 動態資料遮罩可以幫助 DBA 或系統管理員，有效防止機敏資料洩漏給未經授權的人員，針對比較單純的情境，只需使用【資料表和資料行】的遮罩方式，就可以在用戶端直接查詢基礎資料表時，提供機敏資料的保護。
甚至是透過預存程序或內崁資料表值函數（inline table-valued function）回傳基礎資料表的內容時，也幾乎不需太多的程式修改成本，就可以防止資料直接外洩。
下圖示範透過預存程序及內崁資料表值函數來取得機敏資料，一樣會被動態資料遮罩功能所保護。
但現實環境當中，資訊系統的複雜度往往不會這麼單純，需要 JOIN 多個基礎資料表，或搭配子查詢及衍生資料表來組合出系統所需的結果集，都是很常見的狀況。
如果只用【資料表和資料行】的遮罩方式可能，在較複雜的情境下會顯得捉襟見肘。
假設我們針對 SalesLT.ProductCategory 資料表的Name資料行、SalesLT.Product 的 ProductID 和 Name 資料行建立遮罩規則（如上圖），在遇到下列 T-SQL 查詢時就會發生，應該被遮罩的 ProdID（原 SalesLT.Product 資料表的 ProductID 資料行）和 ProdName（原 SalesLT.Product 資料表的 Name 資料行）資料行並沒有如預期的被保護，如果這是重要的機敏資料，在這種狀況下則會全都露。
該怎麼防止這種狀況發生，Azure SQL Database 提供了另一種遮罩方式，詳見下一節的說明。
使用別名來建立遮罩
針對非基礎資料表的查詢，如衍生資料表或子查詢或是資料表函數回傳的結果，必須使用【別名】的遮罩方式才能有效防堵機敏資料外洩，在不修改現有應用程式中的查詢語法，將查詢結果集的欄位名稱填入【遮罩項目別名】，其餘遮罩功能則和【資料表和資料行】遮罩規則建立方式相同。
下圖示範在 Azure 入口網站中針對 ProdID 和 ProdName 資料行建立遮罩規則，針對別名 ProdID，以 1 到 100 的隨機號碼來呈現。
針對別名ProdName，前後六個字元依照原始內容呈現，中間則是以【______】字串來取代。
下圖示範在預覽版 Azure 入口網站中針對 ProdID 和 ProdName 資料行建立遮罩規則，規則設定方式與在 Azure 入口網站相同。
一旦上述遮罩規則生效後，重新執行前一節的 T-SQL 指令碼，可以看到 ProdID 和 ProdName 資料行原本直接回傳基礎資料表未經遮罩的內容，已經順利被套用成遮罩規則所設定的結果。
結論
或許這樣的做法未能滿足所有機敏資料保護的需求，但至少讓您幾乎不須額外修改程式就可以達到讓資料不直接暴露出去，若要釜底抽薪或許明文規定並嚴格執行拒絕直接存取基礎資料表會是比較治本的做法。
本文一直提到基礎資料表用意就在這裡，若是讓使用者能夠直接存取基礎資料表，無法有效控制使用者會怎麼命名查詢結果集所回傳的資料行名稱，一旦有遺漏就會造成機敏資料沒被保護的狀況。
避免使用者直接存取資料表，讓資料表的內容一律只能使用預存程序等中介層來取得，除了有助於簡化管理資料存取的工作外，對於資料存取的安全性也較能集中管理，甚至能夠避免特定查詢（ad-hoc query）容易造成無法重用執行計畫時，所衍生的效能問題。
參考資料
1. 保護機敏資料的幫手 - SQL Database 動態資料遮罩
2. What's new in the Latest SQL Database Update V12 (preview)
3. Get started with SQL Database Dynamic Data Masking
4. Plan and prepare to upgrade to the Latest SQL Database Update V12 (preview)
5. Limit the exposure of sensitive data in Azure SQL Database using Dynamic Data Masking
本文原始發布於「TechNet 台灣部落格」