在Azure SQL數據庫中引入行級安全性
微軟發布了一個Azure SQL數據庫的預覽版新特性,它稱為行級安全性(RLS)。因為這個特性還是預覽版,因此它還不適合用于生產負載,并且還沒有得到全面支持。RLS可以根據用戶執行一個查詢的特征(如:分組成員或執行環境)來控制數據庫表中行的訪問。
在2015年4月,所有地區的V12部署都可以使用RLS。此外,這個特性也會出現在下一個本地版SQL Server中,即SQL Server 2016。由于微軟已經全力投身于云優先的戰略中,因此RLS等Azure特性出現在未來版本的SQL Server也在情理之中。
Oracle和DB2的DBMS產品在很多年前就有這個特性了。SQL Server用戶一直在使用各種方法來處理行級安全性的需求。如果要將一個使用了RLS的應用程序后臺從Oracle或DB2數據庫遷移到SQL Server,則需要在遷移過程中在應用程序或數據庫上增加很多代碼。新的RLS特性仍然需要一定的實現工作,但是工作量已經減少了,因為過濾功能已經根據一個集中定義的安全功能邏輯而自動部署到基本表上了。
我們仍然需要一種方法將特定行的安全性“映射”到一個用戶特征值上。它可能是一個具體的用戶名或用戶的數據庫角色成員。目標數據庫中每一個表都需要增加一個字段,或者讓安全函數聯合一個或多個幫助表,從而查找行的分配。安全邏輯可簡單可復雜,具體取決于實際的需求。此外,如果一個有RLS的表聯合了一個沒有RLS的表,那么其結果集仍然會根據安全上下文進行過濾。
行級安全性的優點
粗略地看,它的主要優點似乎是增加安全性和可能簡化查詢。但是,簡化查詢可能是考慮使用RLS的主要原因。在啟動RLS之后,系統會在更細粒度級別上限制用戶的訪問。如果用戶身份信息受到攻擊,那么可攻擊范圍將縮小,SQL注入攻擊的影響也很小。例如,一個應用程序可能現在使用了下面的語句:
現在很容易通過一個SQL注入攻擊將“A”改為“B”或其他的查詢條件,從而直接查詢數據庫,得到其他不同的結果。在啟動RLS之后,這種攻擊是不可能生效的。
使用等級安全性
最終用戶不會意識到RLS的存在。實現RLS需要一定的工作,但是完全不需要修改代碼。事實上,它可以讓查詢變得更簡單,因為用戶已經限制為只能查詢他們有訪問權限的特定行數。要考慮在現有應用程序中實現RLS。
按照預期,要實現這一層安全性還需要完成一定的工作。這其中包括確定哪一些表需要修改,以及如何更高效地將用戶身份映射到行級數據上。但是,這還不是全部開銷;RLS的本質是在基礎表的每一個查詢上增加另一層判斷邏輯,限制查詢所返回的行數。這可能會影響訪問該表的所有查詢的性能。
許多全新特性都一樣,它們通常也會有很多局限性。這個特性也不例外。RLS不兼容針對內存優化的表和變更數據捕捉。此外,如果不用RLS保護,Full Text Indices(全文索引)和DBCC SHOW_STATISTICS也可能“泄漏”信息。
RLS是一個等待已久的特性,它使微軟數據平臺產品在功能全面角度向Oracle和DB2靠近。在更多地了解特性及其在應用程序的實現方式之后,它的工作方式將變得更加清晰。表面上,RLS似乎只是一個在將應用程序從Oracle或DB2遷移過來時才需要的特性。但是,在現代環境中數據威脅是真實存在的,RLS有利于減小數據的潛在漏洞。它在用戶感知不到的情況下限制返回的記錄行數。雖然使用視圖和觸發器也能實現行級安全性,但是由于訪問邏輯更加集中和靠近數據,因此這個新特性減小了應用程序的維護難度和復雜性,從而在實現上更加簡單。