前言
https://ithelp.ithome.com.tw/articles/10214095
成本評估
Azure SQL Structure Security 依下列定價面向計費:
Azure SQL Database v12 版本原生就支援資料列層級安全,讓存在資料庫裡的資料本身提供更有別於從前的保護機制更為精細控制。
SQL 單一/彈性 (DTU / vCore) 資料庫費用計算
SQL Manage Instance
服務架構
簡單說就是可以讓使用者客戶根據各自不同的的使用者屬性透過被賦予不同群組本身的權限資格或執行的內容本身來控制資料庫中各資料列的存取。以公司為例你可以為AI專案部成員僅能夠存取與AI專案相關資料列但非AI的其他專案部門則能存取(不包含 AI 相關資料列)的所有專案資料列。
簡易實測環境
圖1. 已先建立好一台 Azure SQL Database (Only 5 DTU Level) Lab
圖2. 任何要連到Azure SQL都需要設置白名單信任IP才能連進去執行操作
圖3. 登入此建立的SQL伺服器連線FQDN與建立服務時一併設置的帳密
圖4. 已經登入無誤,目前沒有任何資料表
圖5. 建立三組帳戶分別是Sale1,Sale2及Manager
圖6. 確實已經建立無誤
圖7. 來建立一張業務資料表包含有以下欄位
圖8. 我們塞幾筆Sale1與Sale2各自的資料進去
圖9. 每組帳戶對此資料表給予讀取權限
圖10. 建立結構描述及內嵌資料表值函式。SalesRep 資料行中資料列相同且帳戶執行查詢時 (@SalesRep = USER_NAME()
)或執行查詢的帳戶是管理員(USER_NAME() = 'Manager'
) 時,函數會傳回 1。
圖11. 建立篩選器述詞加入安全性原則。 啟用此原則須設為 ON。
圖12. 允許 fn_securitypredicate 函式的 SELECT 權限
圖13. 現在從每組帳戶的 Sales 資料表來作查詢測試是否有做安全篩選,結果很明顯只有管理者可以看到兩邊的業務資料,而各自業務的Owner只能看到自己的
圖14. 停用此安全原則為 Off
圖15. 所有人就都可以相互看到對方資料無安全可言