前言回顧

技能解封最終對決-卷軸解封金鑰重鎮(Azure Key Vault)

已領取技能符石

解封技能樹(Start)

適合的勇者？

曾經遭逢資安事件打擊者。

資安事件觀望者。

資安探索者。

IT過路人。

資安潛水幫。

資安擺渡人。*

學完可以帶走甚麼？

種下資安的芽在自己心中讓資安意識更強大。

自己的資安生涯規劃師。

帶走心中的這棵樹，把樹傳出去。

你也可以是小小資安擺渡人。

單挑資安認證更有信心。

泰瑞爾 vs 巴爾

世界之石的保護枷鎖

遺忘之石的符咒陣原來有個法老在鎮守著，雖然泰瑞爾釋出極大的善意表態這次的來訪希望能夠得到認同幫助我們能一臂之力，但仍無法遊說給予我們幫助，正放棄準備打道回城時，不愧是遺忘之石陣地充斥著先人的遺跡，其中一個巨石下隙縫緩緩發亮，秘術士大叫一聲，這這....不就是傳說可以合成秘文的無暇寶石原料，我們只要把世界之石上部份後段的符文做為辨識的枷鎖，即便讓邪惡方擁有世界之石也因為招喚過程部份符文是受到辨識控制而無法破解(只有天使秘術士才能解開)，而又不能破壞此石的原貌而進退兩難，回到人類聽得懂的代名詞"資料列層級安全"小弟先簡述一下此服務究竟為何？

說明此安全功能我們先綜觀 Azure SQL Database 安全涵蓋範圍如下：

• 網路安全(防火牆規則限制 / 服務端點)
• 身份驗證(SQL本身 / Azure AD 系統管理員帳戶)
• 存取授權(資料列層級安全)
• 威脅防護(監視器記錄審核 / 進階威脅防護)
• 資訊加密保護(傳輸中TLS加密 / 透明資料加密TDE / Key Vault / 一律加密 / 動態資料遮罩)
• 安全管理(弱點評估 / 探索分類與合規性)
  

本次主角會以資料列層級安全(Row-Level Security)來做主軸
簡單說就是可以讓使用者客戶根據各自不同的的使用者屬性透過被賦予不同群組本身的權限資格或執行的內容本身來控制資料庫中各資料列的存取。以公司為例你可以為AI專案部成員僅能夠存取與AI專案相關資料列但非AI的其他專案部門則能存取(不包含 AI 相關資料列)的所有專案資料列。

源頭一開始是從 Azure SQL Database v12 版本開始了資料列層級安全，讓存在資料庫裡的資料本身提供更有別於從前的保護機制更為精細控制。
資料安全本身是依附在資料庫層級之間，而原來應用程式連接資料庫做存取資料這行為本身並無改變，而是藉由資料列層級安全機制來達到資料安全隔離的效果，避免因程式開發階段安全意識薄弱而導致寫入了不屬於自己在專案範圍外的資料。而主要使用工具會透過 Security Policy ransact-SQL 陳述式及作為內嵌資料表函式來施作其資料列層級安全(RLS)。

資料列層級安全所需具備權限如下：

• ALTER ANY SECURITY POLICY 權限。
• ALTER 結構描述權限。
• 篩選述詞函式 SELECT 和 REFERENCE 權限。
• 目的資料表和資料行 REFERENCE 權限。

資料列層級安全(RLS)也有其限制：

• 不支援 In-Memory OLTP 資料表。
• 不支援異動資料擷取（Change Data Capture）。
• 全文檢索索引(Full-Text index)本身會略過安全原則撈取完整資訊。

資料列層級安全(RLS)本身支援兩種安全性述詞：

• 篩選述詞的讀取作業如：SELECT、UPDATE、DELETE。
• 封鎖述詞的寫入作業如：AFTER INSERT、AFTER UPDATE、BEFORE UPDATE、BEFORE DELETE。

本次 Security Policy 靈魂
SQL 主要透過資料列層級安全原則依函式條件篩選後來回傳資料，故 T-SQL 只需建立此原則並引用前面建立篩選述詞函式讓資料庫自行幫你做篩選即可，也就是程式無需判斷要查詢哪些條件就符合安全性原則內規範的資料。
以下為公司中分別有業務一部 User1 與二部 User2 各自成員分別想要查詢客戶資料，而業務BU主管是可以同時看到這兩個部門的客戶狀況的，透過此原則會根據不同的身份而給予各自經過規則過濾後的客戶結果，包含想要啟用或停用的

陳述函式範例如下：

1. 移除篩選函式
   ALTER SECURITY POLICY Security.spo_GetCustomerByUserID
   DROP FILTER PREDICATE ON [SalesLT].[Customer]

2. 加入篩選函式
   ALTER SECURITY POLICY Security.spo_GetCustomerByUserID
   ADD FILTER PREDICATE Security.fn_securitypredicate(UserID)
   ON [SalesLT].[Customer]

3. 停用安全性原則
   ALTER SECURITY POLICY Security.spo_GetCustomerByUserID
   WITH(STATE=OFF)

4. 啟用安全性原則
   ALTER SECURITY POLICY Security.spo_GetCustomerByUserID
   WITH(STATE=ON)

安全性原則仍有以下狀況會被無視：

• 惡意的安全性原則管理員 - 已經具有權限就可在任意資料包含機敏資料行上建立安全原則及改變內嵌資料表函式，與具資料表選取權限的用戶共謀惡意設計來藉此洩漏資料。
• 規避的查詢技巧 - 如：SELECT 1/(SALARY-1000) FROM PAYROLL WHERE NAME='Bill' 可讓有心人士知道 Bill 目前的薪水為 $1000。雖然透過安全原則來防止惡意使用者直接查詢他人的薪資，但是當查詢傳回除以0而產生例外狀況後，即可下一步由有心人士任意操作後續。

資料列層級安全篩選前...

資料列層級安全篩選後...

欲知詳情請參考以下傳送門>>>>

實作工坊

而光說不練怎麼行，實驗環境中會把持續關注的你/妳帶到小弟我的 wordpress.com Blog連結內容如下：

技能解封最終對決-重要機要防竊攻防 (Azure SQL Structure Security)

1. Azure SQL Structure Security 成本計價。
2. 簡易實作體驗。

上屆鐵人主題

如果有興趣對您有幫助也請多多支持，歡迎給小弟建議或互相交流!

Google Cloud 勇者的試煉

玩轉 Azure 於指尖隨心所欲