[食譜好菜] SQL Server 中「使用者(User)」與「角色(Role)」的授權關係。

上一篇文章大致地了解了 SQL Server 登入及使用者之間的關係,登入只是個開始而已,只是能進到 SQL Server 而已,這時候還不能存取任何資料庫物件,還需要得到授權,要在 SQL Server 授權存取資料庫物件,就不得不提到「使用者(User)」及「角色(Role)」。

使用者(User)

每一個 SQL Server 資料庫都會有屬於自己的使用者,有實際存取資料庫物件行為的是使用者,它也是真實世界的使用者在 SQL Server 的代表身份,使用者如果沒有得到授權,是不能存取任何資料庫物件的。

當一個資料庫建立起來之後,SQL Server 會建立一些預設的使用者。

角色(Role)

每一個 SQL Server 資料庫都會有屬於自己的角色,角色是授權使用者存取資料庫物件的一種方式,角色定義了一組資料庫物件的存取權限,大至整個資料庫,小至一個資料表的欄位都可以去定義存取它們的權限。

建立資料庫的時候,SQL Server 也會建立一些預設的角色。

授權

「授權」三項要素:授予的對象、權限、操作的目標,使用者及角色都可以分別對資料庫物件做授權,我在實驗環境分別建了一個 test_user 使用者、test_role 角色,並將 test_user 加入到 test_role,然後在使用者及角色的「安全性實體」這個頁籤裡面,將 dbo 這個結構描述,一個設為授與,一個設為拒絕。

設定完成之後,同時會在結構描述 dbo 的「權限」頁籤裡面出現 test_user 及 test_role 的權限設定。

這邊就要提到 SQL Server 的授權原則,SQL Server 的授權原則是採用「拒絕優先原則」,就是說使用者沒有被授與資料庫物件權限,預設就是拒絕,如果使用者被拒絕資料庫物件權限,那麼就是拒絕。

所以剛剛我們實驗的,針對同一個資料庫物件一授與一拒絕的授權方式,最終 test_user 連資料表都看不到,即使交換過來設定也是一樣。

SQL Server 的權限是設計得相當細緻,而且很有彈性,權限設定做為保護資料的其中一道門檻,我們應該要好好地利用它,做好權限規劃,如果因為疏於規劃權限,而致使系統承受了資訊安全的風險,身為開發者的我們責無旁貸。

結構描述(Schema),每一個 SQL Server 資料庫都會有自己的結構描述,結構描述是從 SQL Server 2005 開始才有的東西,它是一群資料庫物件的集合,這個集合是邏輯上的,它有點像是 C# 中 namespace 的概念,所有的資料庫物件如果沒有特別設定結構描述,預設的結構描述為 dbo

參考資料

C# 指南ASP.NET 教學ASP.NET MVC 指引
Azure SQL Database 教學SQL Server 教學Xamarin.Forms 教學